Context injection vs. stuffing: retrieve or paste?

There are two ways to get knowledge in front of a model. You can stuff the window: paste everything you might need and trust the large context to sort it out. Or you can inject context: pull in only the slice the task needs, on demand, through retrieval, a tool call, or a targeted reference. This guide is about which one to reach for. It is a decision guide, not a tutorial on how retrieval works under the hood. For that, the deep guides are linked throughout.

Two strategies, stated plainly

Stuffing the window means front-loading the model with the whole corpus and hoping the big window absorbs it. You paste the docs, the logs, the schema, the history, all of it, and ask your question on top. It is the path of least resistance because it needs no system: just a prompt and a large window.

Injecting context means treating the window as a budget you spend deliberately. You bring in exactly what the task needs and nothing else. The material arrives through one of a few channels:

• RetrievalFetching the relevant text from your own data at answer time and feeding only that to the model, instead of sending everything., where a search step finds the relevant passages and passes only those.
• A tool call, where the model asks a service or database for a specific record when it needs one.
• A targeted reference, where you name the exact file or section to load (an @-mention in CLI tools), instead of dumping the directory.
• Structured on-demand loading, where stable rules sit in context and detail is pulled in only when a step calls for it.

The difference is not "small prompt vs. big prompt." It is whether what lands in the window is chosen or dumped. Stuffing dumps. Injection chooses.

Is retrieval just a workaround for small context windows?

It is tempting to read retrieval as a crutch for windows that were too small, now obsolete because windows are huge. Treat injection as a design discipline you apply on purpose, the same way you would not load an entire database table into memory just because the machine has the RAM. You select.

A large window changes the threshold at which stuffing breaks, but it does not remove the three pressures that make injection the right call. Those pressures are cost, attention, and maintenance. They decide the question every time. The window getting bigger, covered in what a 1-million-token context window means, moves the line; it does not erase it.

What decides whether to inject or stuff?

Cost per request

Every token you send is paid for on every request. Stuff a 300,000 token corpus into a window and you pay for 300,000 tokens each time you ask a question, even when the answer lives in two paragraphs. Injection sends the two paragraphs.

The gap compounds with volume. A one-off question swallows the stuffing cost once and you move on. A feature that answers a thousand questions a day pays the full window a thousand times. At that scale, sending only what each question needs is not an optimisation, it is the difference between viable and not.

One caveat softens this for stable, repeated stuffing: prompt cachingStoring a stable prefix of your prompt so repeat calls reuse it cheaply instead of reprocessing the whole thing each time. lets a fixed prefix be reused at a fraction of the input price on later calls. If you paste the same large block over and over, caching pulls the cost argument back towards stuffing. It does not help when the pasted content changes between calls, because each change invalidates the cached prefix.

Attention degradation

A model does not weight every token equally. It attends most to the start and end of a long context and least to the middle. A fact buried in the middle of a giant paste is the fact most likely to be missed. This is the lost-in-the-middleThe tendency of a model to underweight information sitting in the middle of a very long context, attending more to the start and end. effect, and it gets worse the more you stuff.

So stuffing has a quality cost on top of the money cost. Past a point, adding more text makes answers worse, because the signal the question needs is drowning in text the question does not. Injection sidesteps this: fewer, more relevant tokens means the answer-bearing content sits in a window small enough to be read sharply.

Maintenance and staleness

A pasted block is a snapshot, frozen at the moment you pasted it. If the source moves, pricing, inventory, a wiki under active editing, a ticket queue, your snapshot is wrong by the next question and nothing tells you. Someone exports a doc, pastes it for weeks, and never notices it drifted.Common gotchaA stale paste fails silently: it returns confident answers from yesterday's data with nothing flagging the drift.If the source changes between questions, point at the live source instead of trusting a one-time export, or at least timestamp the paste so you know when to re-pull it.

Injection points at a live source. Refresh the index or call the tool again and the next answer sees the current state. The maintenance burden flips: stuffing is cheap to set up and expensive to keep correct, while injection costs a system to build but stays current on its own. The discipline of keeping your knowledge base fresh only matters once you inject; a static paste has no freshness to keep.

The decision table

Read it as a tilt, not a tally. If every signal points to stuffing, stuff. The moment one of the three pressures bites hard, cost at volume, attention on a bloated paste, or a moving source, lean to injection.

A flowchart for the call

The flow is a funnel: stuffing survives only when the material fits, stays put, is the slice you need, and is not queried so often that cost dominates. Fail any gate and injection wins.

A worked example: a support-docs corpus crossing the line

Watch one corpus grow and the tipping point reveals itself. The numbers are illustrative; the shape is what matters.

Week one. Fifty articles. The whole help centre is fifty short articles, maybe 40,000 tokens. It fits with enormous room to spare, it changes a few times a month, and most questions are answered by the same handful of pages. You stuff it. Every question gets the full set, the model finds the answer, and you have nothing to build or maintain. Reaching for retrieval here would be infrastructure for a problem you do not have.

Month six. Four hundred articles. The corpus is now around 300,000 tokens. It still technically fits a large window, so the temptation is to keep stuffing. But two pressures have woken up. Support is editing articles weekly, so a paste exported on Monday is wrong by Thursday. And the answer to any one ticket lives in two or three articles out of four hundred, so the model is reading 300,000 tokens to use 2,000 of them. Answers get vaguer because the relevant page is buried in the middle of a wall of unrelated text. This is the tipping point: it fits, but fitting is no longer the question.

Year two. Five thousand articles. It does not fit, full stop. The decision is made for you. You cannot name which article holds the answer, so finding it is the work, and that is exactly what search does.

The lesson is the middle stage. The corpus crossed from "stuff it" to "inject it" long before it stopped fitting. The window size told you the wrong thing; the three pressures told you the truth.

The same arc plays out over a large codebase, and it tips earlier than people expect. Twenty files fit and you can name them, so you paste them. At a few hundred files the repository may still fit a large window, but the bug you are chasing touches three files out of three hundred, and you do not know which three in advance. Stuffing the whole tree pays for all of it and buries the relevant functions in unrelated code; the model spends its attention reading getters and config it will never use. So you point a tool at the repository, let a search step find the three files, and inject only those. The tipping point is the same as the support docs: it arrived when you stopped being able to name the slice, not when the code stopped fitting.

Cost, freshness, and maintenance as the corpus grows

The decision table tells you which side a signal lands on. This one shows why injection pulls ahead as a corpus scales, across the three dimensions that cost you something over time.

The pattern is the crossover. Stuffing is cheaper to start and gets steadily more expensive and more fragile with every document and every edit. Injection costs more up front and then barely moves as the corpus grows, because each query still pays only for its slice. Small and static, stuffing wins on simplicity. Large or changing, injection wins on every line that compounds.

Injection has its own costs, and ignoring them leads to the opposite mistake. The store has to run, the search step has to be tuned so it returns the right slice, and you have to evaluate retrieval on its own before you trust the answer. A bad search step injects the wrong slice, which is worse than stuffing because the model never sees the page that held the answer. The reason injection still wins at scale is not that its costs are zero; it is that its costs are fixed while stuffing's costs grow. You pay the system once and the per-query bill stays flat. That trade only pays off past the point where the corpus is large, changing, or queried hard enough to matter, which is exactly what the three pressures are measuring.Common gotchaThe most expensive way to read this guide is to treat injection as the always-correct upgrade and switch the moment a corpus feels big.If you wire up retrieval without measuring the search step on its own first, a weak retriever injects the wrong slice, the model never sees the page that held the answer, and you get confident wrong answers that are harder to catch than a stuffed paste that at least contained the fact. Evaluate retrieval in isolation, and stay with stuffing until one of the three pressures bites.

Test the call before you build it

You do not have to commit to either side blind. Both ends of the decision are cheap to probe from the CLI before you build anything permanent.

To test whether stuffing holds, paste the candidate material and ask the hardest real questions against it:

claude "using only docs/refunds.md and docs/checkout-flow.md, answer: how long is a refund token valid, and what happens after it expires?"

If the answer is correct and points at the right place, stuffing works for that question; ship the simple thing. Watch for two failure shapes. If the answer is wrong even though the fact is in the text, the paste is too noisy and you are seeing attention degrade. If you cannot even decide which documents to paste, that is the search problem wearing a disguise, and it is the clearest sign you have crossed into injection territory.

When is stuffing the window fine?

Stuffing is not a sin. For a large class of work it is the correct, simplest choice, and reaching for retrieval there is effort spent on a problem you do not have.

• A small, stable corpus. A signed contract, a finished spec, a research paper. It fits, it will not move, and there is nothing to keep fresh.
• A one-off task. Reviewing a single pull request: the diff and touched files fit, they are exactly what you want, and they will not change mid-review. Paste it.
• Material that fits with room to spare. If the relevant set is a handful of documents you can name and they leave plenty of window for the model to work in, pasting them whole avoids the chunk-boundary problems that come from splitting too finely.
• The same big block, queried often, with caching on. Caching makes repeated stuffing of a stable prefix cheap, which pulls the cost argument back towards pasting for sources you query a lot but never change.

The deeper treatment of the paste-it path, including how to pressure-test it before building anything, lives in RAG or a long prompt.

When does context injection win?

Injection earns its setup cost when one of the pressures turns decisive.

• The corpus is large, or changing, or spread across sources. A 50,000 document support archive, a wiki edited all day, three systems that each hold part of the answer. Stuffing cannot assemble that cleanly, and a snapshot of it is wrong by the time you read the answer.
• You cannot name the slice in advance. When finding the right document is the work ("which of 4,000 articles covers expired refund tokens"), search is the point. Sending all 4,000, even if they fit, would bury the answer and cost far more.
• Volume makes per-request cost dominate. A high-traffic feature pays the window on every call. Trimming each request to its needed slice is the whole ballgame.
• Freshness is non-negotiable. Live pricing, inventory, a moving ticket queue. Point at the source so every answer reflects the current state.

How to fill the window with exactly the right slice is the subject of Context engineering and Feed Claude the right context. The retrieval machinery beneath injection is covered in RAG fundamentals and, end to end, in Build a simple RAG pipeline.

Can I inject context without a vector store?

Injection does not always mean building retrieval infrastructure. The cheapest form is a targeted reference: in a CLI workflow, naming the exact files instead of dumping the tree.

claude "using only src/billing/invoice.ts and src/billing/tax.ts, explain how line-item tax is rounded"

That loads two files and nothing else. It is injection by hand: you chose the slice. The same instinct, scaled up, becomes a tool the model calls rather than a corpus you paste. You register a search or data service once and let the model pull the relevant pieces on demand.

{
  "servers": {
    "company-docs": {
      "command": "npx",
      "args": ["-y", "@example/docs-search-tool"]
    }
  }
}

Now "find the article on expired refund tokens and explain the fix" becomes a search step that locates the article followed by a read step that brings only that article into context. That is injection feeding a focused prompt, with no store of your own to maintain.

The hybrid most teams settle on

The two strategies are not rivals. The common production pattern uses injection to select and stuffing to read: retrieve or call a tool to pick a small set of whole documents, then paste those documents in full.

You get search to find the right material and a clean, complete paste for the model to reason over. You avoid sending the whole corpus, and you avoid severing a fact from its qualifying sentence by chopping documents into fragments. For most real systems this is the answer, not a compromise.

The hybrid also extends in the other direction: not all of context has to be retrieved. A useful framing is two layers. A small, stable layer sits in context on every call (the system rules, the schema, the few facts that are always relevant) and is the natural thing to cache. A volatile layer is injected per question (the specific articles, the live record, the matched code). You are not choosing stuff-everything or inject-everything; you are deciding which slices are stable enough to keep resident and which should be fetched fresh.

Mistakes that push people to the wrong side

• Treating the big window as permission to skip the decision. "It fits, so paste it" ignores cost at volume and attention degradation. Fitting is necessary, not sufficient.
• Building retrieval for three stable PDFs. A vector store for a handful of unchanging docs is infrastructure for a problem you do not have. Stuff it and move on; add injection when the corpus grows.
• Pasting whole files when one function is the answer. In a coding workflow, dumping an entire 2,000-line module to ask about one helper buries the relevant lines and pays for the rest. Name the function or the two files that matter, not the directory.
• Pasting a snapshot of a moving source. The quiet failure. The copy drifts, the answers go stale, and nothing flags it. If the source changes, point at the live source and refresh it instead of re-exporting by hand.
• Never refreshing a stale paste. A cousin of the above, worth its own line because it is so common. The first paste is correct, so nobody revisits it; weeks later the answers are quietly wrong. A pasted block has no expiry and nothing reminds you it has one.
• Stuffing past the noise threshold. People keep adding to a paste until answers degrade and blame the model. The signal is not whether it technically fits, it is whether the relevant content is buried among text the question does not need.
• Chopping documents that should stay whole. When you do inject, over-aggressive chunking can split a fact from the sentence that qualifies it. The select-then-paste hybrid keeps each retrieved document intact.

The decision is not permanent

The call you make today is correct for today's corpus, not forever. The whole point of the worked example is that the right answer changed as the corpus grew, and it changed before anything broke loudly. So treat the decision as something to revisit, and watch for the signals that you have quietly crossed the line:

• The paste no longer fits without trimming, so you are already curating by hand.
• You catch yourself deleting sections to make room, which is manual injection with none of the benefits.
• Answers have gotten vaguer with no change to the questions, the classic sign of attention degrading on a bloated paste.
• Someone reports an answer that is out of date, and the cause is a paste nobody refreshed.

Any one of those means stuffing has outgrown its fit and it is time to inject. The good news is that the move is incremental: start with targeted references, graduate to a tool the model calls, and reach for a full store only when the corpus demands it.

The rule of thumb

Stuff when the material is small, stable, fits with room to spare, and you are asking once or twice. Inject the moment one of the three pressures turns real: cost at volume, attention degrading on a bloated paste, or a source that moves. And when in doubt, use the hybrid: inject to choose the documents, stuff to read them whole. The window getting bigger raised the threshold. It did not retire the discipline.