Claude is more likely to skip or under-weight an instruction sitting in the middle of a long system prompt than one placed at the very start or the very end — a measurable effect called positional bias, not a random glitch. It happens because models trained on how people write tend to treat the opening and closing of a document as more important, a pattern that shows up across Claude, GPT, and Gemini alike. The fix isn’t simply “put everything at the top”: research published in 2025 found the effect itself changes shape as a prompt gets longer, which means the right fix depends on how full the context window already is.
The Research Behind “Lost in the Middle”
The effect gets its name from a 2023 Stanford paper, “Lost in the Middle: How Language Models Use Long Contexts” by Nelson F. Liu and co-authors, later published in TACL. Testing models on tasks where a document had to retrieve one specific fact placed at different positions in a long input, the paper found a consistent U-shaped accuracy curve: performance was highest when the needed fact sat at the very beginning or the very end of the context, and dropped — sometimes sharply — when it sat anywhere in the middle. That’s the baseline finding most “write better system prompts” advice since then has been built on, usually simplified to “front-load your most important instructions.”
It’s Not as Simple as “Put It at the Top”
A 2025 paper, “Positional Biases Shift as Inputs Approach Context Window Limits” by Blerta Veseli, Julian Chibane, Mariya Toneva, and Alexander Koller, tested how that U-shaped curve changes as the input gets closer to filling a model’s entire context window — and found it doesn’t hold steady. The Lost-in-the-Middle effect is strongest when the input fills up to about half of the model’s total context window; past that point, the advantage of being at the very beginning falls steeply, to the point that first-position accuracy for retrieval drops below middle-position accuracy. Meanwhile, the advantage for content placed at the end holds up and, in some of the paper’s reasoning results on a large model, last-position content outperformed both middle and first. In other words: the closer you push a prompt toward the model’s context ceiling, the less “put it first” helps and the more “put it last” does.
The paper also found that reasoning accuracy tracks retrieval accuracy closely — when a model correctly finds the relevant fact, its reasoning about that fact improves dramatically. For one model tested, Qwen-2.5-32B, reasoning accuracy rose from 0.38 to 0.82 — a 116% increase — once retrieval of the relevant fact succeeded, averaged across the datasets used. That’s useful context for diagnosing a failure: if Claude’s answer is wrong, the more specific question isn’t “is this model bad at reasoning” but “did it actually retrieve the instruction in the first place.”
The same 2025 paper also found that at full context length, a different ranking emerged on reasoning tasks for one of the larger models tested, Llama-3-70B: accuracy went last position, then middle, then first — the opposite of the primacy advantage most prompt-writing advice assumes. Middle and last-position accuracy on that model’s reasoning task at full length even exceeded what the same positions scored at shorter input lengths, which the authors attribute to the model shifting its attention patterns as it nears the edge of what it can hold, rather than simply degrading uniformly everywhere.
What This Looks Like in Practice
Picture a system prompt with eight numbered instructions: formatting rules first, a tone guideline, then — buried around instruction five — “never reveal pricing information unless the user asks directly,” followed by three more unrelated formatting rules. In a short prompt, Claude might catch instruction five reliably. Stretch the same system prompt to several thousand tokens by adding a long list of product descriptions or FAQ content after it, and instruction five is now sitting in the thinned-out middle third of a much longer input — exactly where the research says retrieval gets weakest. The practical symptom is Claude occasionally mentioning pricing when it shouldn’t, not because the instruction is unclear, but because it’s effectively less visible to the model at that position and length.
The same pattern shows up in retrieval-augmented setups, where it’s arguably more common: a system prompt carries three or four firm behavioral rules, and then a retrieved document — a knowledge-base article, a support ticket, a product manual excerpt — gets inserted after those rules and before the user’s question. The longer that inserted document, the more the original rules get pushed toward the thinned-out middle of the full request, even though nothing in the prompt’s wording changed. Teams debugging this kind of regression often start by rewriting the instruction to be clearer, when the actual variable that changed was how much retrieved content got inserted that day.
A Quick Way to Test for It Yourself
You don’t need an academic benchmark to check whether this is happening in your own prompt — you need a canary instruction and a few minutes. Pick one unambiguous, easily verifiable rule — “always end your response with the word DONE in brackets” works well because compliance is trivial to check by eye. Place it at the start of your system prompt, run ten representative requests, and record the compliance rate. Then move the identical instruction to roughly the middle of the same prompt and repeat, then to the end. If compliance drops noticeably in the middle position and recovers at the end, you’ve confirmed the effect on your specific prompt and model rather than assuming it applies based on a paper testing different tasks and different models. This is also the fastest way to find your prompt’s actual danger zone, since the weak spot isn’t always the exact midpoint — it shifts with how the rest of the content is structured.
Fixes That Match What the Research Actually Found
- Duplicate the critical instruction at the end, not just the start. Since end-position accuracy holds up even as prompts approach the context limit, repeating your highest-stakes rule as the last line of the system prompt — after the reference material, not before it — is the more reliable half of the “repeat important instructions” advice.
- Know roughly how full your context window is. A system prompt plus a short user message filling 10% of a 200K-token window behaves differently than the same system prompt with a 150K-token document attached. The fix that works at low fill ratios (front-loading) is the one that degrades fastest at high fill ratios.
- Shorten before you reposition. If an instruction keeps getting missed, cutting the unrelated content around it reduces how “buried” it is more effectively than moving it half a position up or down in a prompt that stays just as long.
- Treat retrieval and compliance as separate problems. If you can confirm (by asking Claude to first restate the relevant rule in its own words) that it did retrieve the instruction, and it still didn’t follow it, that’s a compliance issue — closer to the kind our piece on vague negative instructions covers — not a positional one.
What Doesn’t Reliably Fix It
Formatting tricks that feel like they should help — writing the instruction in all caps, prefixing it with “IMPORTANT:” or “CRITICAL:”, adding exclamation marks — aren’t what either paper tested or found responsible for the effect. The bias the research documents is about token position within the context window, not about emphasis markers within the text at that position. A capitalized instruction buried at the 50% mark of a long prompt is still buried at the 50% mark; the fix that the data actually supports is moving it, shortening around it, or duplicating it near the end, not making it louder where it already sits.
Where This Fits With Other Prompt Structure Choices
Positional bias compounds with other structural issues rather than replacing them. If you’re already enforcing a strict output shape, pairing position-aware placement with embedding a JSON schema directly in the prompt gives Claude a format to anchor the end-of-prompt instruction to, rather than leaving it as a lone sentence competing with everything before it. And if the long content pushing your real instructions into the middle third is the same large context you’re sending on every call, caching that content — as covered in our context caching comparison — doesn’t change the positional math, but it does make it cheap enough to test different placements without re-paying full price for the unchanged portion each time. For a broader checklist of what makes a system prompt reliable beyond positioning alone, see how to write a system prompt that works. None of this replaces testing on your own prompt and model version — position effects reported for one model generation don’t necessarily transfer exactly to the next one, which is exactly why the canary-instruction test above is worth running again whenever you switch models or substantially change prompt length.
Photo: Books in a stack by Evan Bench, licensed under CC BY 2.0, via Wikimedia Commons.
