The density tax: why a short, fact-packed paste can be harder than a long one
AI-generated audio discussion of this module — same content, spoken.
Overview
Everything you’ve been told about long inputs is about length — the window fills, reliability sags, so paste less and put the answer at an edge. This is about a different lever. In June 2026 a group at Politecnico di Torino held the length fixed and changed only how tightly the facts were packed — and watched models that were near-perfect on a sparse context drop below 60% on a dense one of the exact same size. The catch isn’t how much you paste. It’s how much distinct information you cram into it.
The content
The obvious read is that a model struggles when you give it too much — a long thread, a fat folder, a hundred pages. Trim it down and the problem goes away. That’s the lesson of context rot, and it holds.
But it isn’t the whole story. Dettori and colleagues ran three “find-the-needle” benchmarks at an identical ~12k tokens with the target fact pinned to the same position, and varied only one thing: lexical density — the rate at which the text introduces distinct information. As the density climbed, accuracy fell off a cliff. Near-perfect retrieval in the sparse version collapsed below 60% in the dense one. Loosen the packing again and performance came back. Length constant, position constant — density did the damage on its own.
Read that against what the field already knew. Length was one factor (a full window sags). Position was a second (facts in the middle get missed). Density is a third, and it’s the one nobody was watching. Two paragraphs where every clause is a new number can be harder for the model than ten pages of ordinary prose — because prose is mostly connective tissue the model can skim, and a packed table is all signal with nowhere to rest.
The honest caveat: this was run on open-weight models from 9B to 685B, on synthetic needle tasks — nobody has measured ChatGPT, Claude or Gemini this way, and the exact 60% is a lab number, not a promise about your tool. Treat it as a caution, not a measurement. But the mechanism is general enough to plan around, and it maps straight onto the inputs you most want a precise answer from: a pricing schedule, a spec sheet, a dense contract clause, a page of packed figures. The stuff where every row is a distinct fact is exactly the stuff at peak density — call it the density tax, and it’s heaviest precisely where you can least afford a wrong lookup.
So the move isn’t “paste less” — you may already be down to the one table that matters. It’s unpack before you ask. Isolate the handful of rows that could hold the answer and ask against just those; or when you can’t tell which row, split the dense block into a few chunks and put the same question to each, then reconcile. Short isn’t the same as easy.
Try it
Take a dense artefact you actually use — a rate card, a comparison table, a stats-heavy page, a clause-packed section. Ask the model for one specific value buried in it: “What’s the figure for X under condition Y?” Note the answer. Then paste only the single row or line that holds it, and ask exactly the same question again.
Watch what happens between the two runs. If the answer changes, firms up, or suddenly arrives with less hedging, you’ve just seen the density tax on your own data — the fact was always there; the packing was hiding it. Make the habit the takeaway: when the material is dense and the answer has to be right, isolate or chunk before you trust the reply. Where this earns nothing: ordinary prose or a short, self-contained ask — there’s no packing to loosen, so don’t add a step. The skill is spotting which inputs are dense enough to tax.
Additional reading
- Dense Contexts Are Hard Contexts: Lexical Density Limits Effective Context in LLMs — Dettori et al. (4 June 2026) — the density finding: identical ~12k-token length, controlled needle position, retrieval collapsing below 60% as information density rises. Note the scope: open-weight models (9B–685B) on synthetic needle benchmarks, not the major hosted assistants.
- Context Rot: How Increasing Input Tokens Impacts LLM Performance — Chroma Research (14 July 2025) — the length factor: reliability degrading as inputs grow, tested across 18 models (since superseded — read it for the pattern).
- Lost in the Middle: How Language Models Use Long Contexts — Liu et al., TACL 2024 — the position factor: the U-shaped curve where facts in the middle of a long context get missed.
Editor’s note
When I first read about this, it actually reshaped my way of thinking about context management. I think I held the genuine belief that context rot is related almost exclusively to length because more token intake creates more static for a model to sort through. The irony is that instead of this being true, useless same-value token noise appears to be substantially less significant than key information density. You could significantly trim your context and potentially see practically no improvement if you’ve packed your key facts tighter. I still hold this to be a finding that is supported by testing but unproven as a completely generalisable fact, but I definitely implement the finding’s implications into the way I work.
// three assertions against what you just read · results stay in this browser
The study held the input length (~12k tokens) and the target fact's position fixed, and changed only one thing. What did it change, and what happened?
The module is careful about what the finding does and doesn't establish. Which statement matches its scope?
You need one specific figure out of a dense pricing table. What does the module tell you to do?
Was this useful for your daily work?