Instructions Before or After Your Data in a Prompt?
For anything longer than a page, the document goes at the top and the instruction goes at the bottom. There is documented evidence for it, and a caching argument that makes it free money.
Put the data first and the instruction last. For prompts containing a long document, a transcript, a spreadsheet dump or anything else past roughly a page, the reliable ordering is: material at the top, question at the bottom. Whether instructions go before or after your data in a prompt is one of the few structural choices with a documented effect. Anthropic's prompting best practices documentation states it directly for inputs over 20,000 tokens: place long documents near the top of your prompt, above your query, instructions and examples, and notes that queries at the end can improve response quality by up to 30 percent in tests, especially with complex multi-document inputs.
For short prompts, where the data is a paragraph rather than a report, the ordering barely matters and you should optimise for readability instead. The rest of this is about the long case, because that is where the mistake is expensive.
Why instructions before or after your data changes a prompt's answer
Two effects, both mundane.
The first is recency. Instructions placed after a large body of text sit closest to the point of generation, and the model is least likely to have drifted from them. Instructions buried above 30,000 tokens of source material compete with everything that followed them. This is the same phenomenon behind the general observation that models attend unevenly across a long context, which we covered in does a bigger context window mean better answers. A bigger window does not distribute attention evenly across it.
The second is task framing. When the instruction comes last, the model reads the material without a predetermined lens and then applies the task. When it comes first, the model has been told what to look for before it looks, which sounds helpful and often produces answers shaped by the question rather than the source. For summarisation and extraction that is a downgrade.
The caching argument, which is the stronger one
Prompt caching stores the processed form of a stable prefix so repeat requests skip re-reading it. Caches match on prefix, from the start of the prompt to the first difference. If your prompt is structured as document, then question, and the document is the same across many questions, every question after the first hits the cache. If it is structured as question, then document, nothing matches and you pay in full every time.
Structure | Cache behaviour across 20 questions | Effect |
|---|---|---|
Document, then question | One full read, 19 prefix hits | Lower cost, much lower time to first token |
Question, then document | 20 full reads | Full cost and latency on every call |
So the same ordering that produces better answers also produces cheaper and faster ones, which is a rare alignment. The rules on what counts as a cache hit are provider-specific and covered in how prompt caching works. The one habit that matters: stop editing the top of your prompt casually. Changing a word in the stable prefix invalidates everything after it.
A template that holds up
<documents>
<document index="1" source="q3-report.pdf">
...full text...
</document>
<document index="2" source="competitor-filing.pdf">
...full text...
</document>
</documents>
First, quote the passages from the documents above that bear on the
question, with their document index. Then answer using only those
quotes. If the documents do not contain the answer, say so.
Question: Which of the two companies has more exposure to currency risk,
and on what evidence?Three things are doing work there. The documents are wrapped and labelled, so the model can cite which one it used. The instruction to quote first forces grounding before reasoning, which is the single cheapest hallucination reduction available on document tasks. And the actual question is the very last line, where it is hardest to lose.
If your task is specifically summarisation, the sibling techniques are in how to prompt AI to summarise a long document, which goes deeper on chunking and on what to do when the document exceeds the window.
When to put instructions first instead
Two cases, and only two.
The task changes how the material should be read. Translation is the clearest example: the model needs to know the target language and register before processing a long source, or it does the work twice. Same for transcription cleanup with a specific style guide.
The data is short. Under a few hundred tokens, recency effects are negligible and the ordering that reads most naturally to a human is fine. Optimise for the person maintaining the prompt.
There is also a legitimate middle path: a brief task statement at the top, the documents, then the detailed instruction and question at the bottom. You pay a small cache penalty if the top statement varies, so keep it generic enough to stay stable.
Test it on your own task in ten minutes
Do not take the 30 percent figure and apply it to your case. Measure it.
Take twenty real inputs with known correct answers. Twenty is enough to see a large effect and not enough to see a small one, which is fine because you only care about large effects.
Run both orderings against the same model, same settings, same day.
Grade on something binary. Did it find the right clause, extract the right number, cite a real passage. Avoid graded scores from another model at this stage, since they add noise where you are trying to remove it.
Look at the failures, not the average. If one ordering fails on the same three long documents, you have learned something specific and actionable.
This is context engineering rather than prompt wording, and the wider set of decisions it belongs to is laid out in what context engineering means.
Questions
Does this apply to every model?
The documented figure is Anthropic's, for Claude. The underlying effects, recency and cache prefix matching, are general to transformer models and to how caching is implemented across providers, so the ordering is a safe default. Verify the size of the effect on your own model.
Where do few-shot examples go?
With the instructions, after the documents. The documentation places examples alongside the query rather than above the long input.
Should the instruction be repeated at the top and bottom?
It can help on very long inputs, and it costs tokens and cache stability. Try the single trailing instruction first, and only duplicate if you measure a problem.
Does prompt length itself matter here?
Yes, separately. Ordering is about placement, length is about how much you send at all, and sending less is usually the bigger win. How long a prompt should be deals with that half.
What about system prompts?
A system prompt sits above everything and is a good home for stable role and format rules. Keep the task-specific question out of it and in the trailing user message, or you lose the ordering benefit entirely. The general framework is in the prompt engineering fundamentals.
How did this land?
About the author
Developer Advocate
Steve builds something with Swarmz every week and writes up what worked, what broke, and what he'd do differently. Tutorials and hands-on guides are his lane.
