Token Maxxing Is a Bad Habit, and Biotech's Data Structures Make It an Expensive One

There is a specific habit I keep seeing in teams that adopted large language models early and enthusiastically: when a task involves a lot of data, the instinct is to paste as much of it as possible into the context window and let the model figure it out. Context windows have grown from a few thousand tokens to hundreds of thousands, even millions, and the marketing around that growth has quietly encouraged a mental model where a bigger window means you no longer need to think about data architecture — you just pour everything in.

I have started calling this "token maxxing," and I think it deserves to be treated as a bad practice rather than a clever use of a new capability. It is a bad practice everywhere. In biotech, where the underlying data structures are large, dense, and often feed decisions that matter, it is a bad practice with real cost attached.

Why "the model saw all my data" is a false comfort

Attention degrades over long context, and it does not degrade evenly. Independent evaluations of long-context performance — most notably the "needle in a haystack" family of tests — have consistently shown that models are more reliable at retrieving and reasoning over information near the beginning or end of a long context than information buried in the middle. This is not a fringe finding; it has been replicated across model families and context lengths. A model that "has" your 200-page validation report in context has not necessarily read it the way a human reviewer would. It has processed it in a way that systematically privileges some parts over others, and the parts it deprioritises are not the parts you chose — they are wherever the architecture's attention pattern happens to lose resolution.

A large context window is not a database, and treating it like one produces a specific kind of overconfidence. A relational database or a purpose-built retrieval system returns exactly the records that match a query, with a guarantee about what was and was not included. A model reasoning over a stuffed context window gives you an answer that feels comprehensive because it had access to everything, but offers no such guarantee about what it actually weighted, noticed, or silently discounted. The output looks the same either way — confident, fluent, specific — which means the failure is invisible until something downstream contradicts it.

Cost scales in a way that punishes the habit at exactly the volume biotech operates at. Genomic, proteomic, and high-throughput screening datasets are not modestly sized. A single NGS run, a plate-based screening campaign, or a longitudinal patient registry easily produces data volumes where "just paste it all in" means paying, in tokens and latency, for a brute-force pass over data that a targeted query would have resolved in a fraction of the cost. Teams that scale this habit up as their data volume grows are scaling an inefficiency, not a capability.

Why this is a specific threat to early adopters in biotech

Early AI adopters are, by definition, moving faster than their organisation's governance has caught up to. That is generally a reasonable trade in the early phase of adopting any capability — but token maxxing compounds it in a way that is easy to miss until the damage is structural.

It removes traceability at exactly the moment traceability matters most. If a model's output influenced an interpretation, a go/no-go decision, or a section of a report, the question "what specifically did it base that on" needs an answerable answer. A targeted retrieval pipeline can show you the exact records that were passed to the model and cite them. A stuffed context window cannot — the honest answer to "what did the model actually attend to" is "we don't fully know," which is a sentence that does not survive an audit, a due diligence review, or a serious internal challenge to a scientific conclusion.

It creates a false sense that data architecture work is no longer necessary. The genuinely valuable AI adoption pattern in biotech R&D — build a proper retrieval layer over your literature and internal data, structure your assay metadata so it is queryable, define what "relevant context" means for a given question before you ask it — takes real engineering effort. Token maxxing feels like it delivers the same outcome without that effort, right up until the dataset grows past the point where the illusion holds, or a subtly wrong answer makes it into something that matters. Teams that skip the architecture work because a bigger context window made it feel optional are building on a foundation that does not scale with their own data growth.

It disguises a scaling cliff as a scaling curve. Performance on stuffed-context tasks degrades gradually and then falls off a cliff as data volume crosses whatever threshold the model's effective attention span can no longer cover well — and that threshold is not announced, tested, or predictable in advance for a given use case. An organisation that has been getting "good enough" results by token maxxing on a growing dataset has no early warning system for when that stops being true. The failure shows up as a bad decision, not as a clean error message.

What the alternative actually looks like

None of this is an argument against large context windows — they are genuinely useful, particularly for holding conversational state or reasoning across a bounded, well-curated set of documents. The argument is against context stuffing as a substitute for data architecture. The teams getting durable value from AI in biotech R&D are doing the less glamorous work: retrieval systems that fetch the specific records relevant to a query, structured metadata that makes assay and sample data queryable rather than requiring a model to parse it fresh every time, and a clear definition of what "context" a given question actually needs before reaching for the largest window available.

That approach is slower to set up and less impressive in a demo. It is also the only one that keeps working as the dataset — and the stakes riding on getting the answer right — keep growing.

---

If your team's AI workflows have grown by adding more to the prompt rather than building the data layer underneath it, that is a scaling problem that gets more expensive to fix the longer it waits. I help life science organisations build AI adoption on infrastructure that actually scales — get in touch if that gap sounds familiar.