← LLM & RAG Fundamentals / 05
hard★ EssentialNewGoogleAnthropicGlean

New models accept enormous context windows. Should we drop RAG and just put all our documents in the prompt?

Try it in the practice workspaceDraft your answer before comparing it with the rubric.

A larger context window changes what fits in a request. Decide whether to use it by checking corpus size, freshness, permissions and cost per successful query, including cache misses.

Updated Nov 2026 · Original practice questions with worked answers and teaching rubrics. Our editorial policy explains the sources, review process and limits.

Original practice question. The scoring rubric is our teaching guide. How we research and score answers

TL;DR: Sometimes, for small, stable, shared document sets, especially with prompt caching. For a large, changing, permissioned corpus, keep retrieval as the baseline. Sending hundreds of thousands of tokens per query costs far more than retrieval, adds latency, can lower answer quality on details buried in the middle, cannot enforce per-user permissions on a shared prompt, and still fails once the corpus outgrows the window. Use long context selectively: for a single long document the user is working on, or after retrieval.

How to approach it

Ask how big the corpus is, how often it changes, whether different users may see different documents, and the query volume. Then compare the two approaches on cost, latency, quality, permissions and scale, with numbers.

A strong answer

The appeal. No chunking, no embeddings, no retrieval failures: the model sees everything. For a small set of documents it can work very well.

The arithmetic. Suppose a corpus of about 500,000 tokens (a few hundred pages of policies and product docs), 200,000 queries a day, Claude Sonnet 5.5 list prices as of 6 November 2026 ($2 per million input tokens, $0.10 for cache reads, $10 output), and 500-token answers. Assume 30 days, all cached-prefix reads hit, and omit cache writes, storage, retrieval and other operating charges from this model-call-only comparison:

ApproachInput per queryCost per queryMonthly cost
Whole corpus in every prompt, no caching500,000 tokensabout $1.00about $6.0M
Whole corpus, cached prefix (plus 2,000 fresh tokens)500,000 cachedabout $0.06about $354,000
RAG: 8,000 tokens of retrieved context8,000 tokensabout $0.02about $126,000

Caching changes the picture dramatically, from absurd to merely three times RAG's cost. That point is easy to miss, and it means long context is a real option for small, shared, stable corpora. It is still more expensive, and the cache must be rewritten whenever the corpus changes.

Run the rate limits too, because they kill the uncached design before the bill does. 200,000 queries a day is about 139 a minute on average. Without caching, that is roughly 69 million input tokens a minute; the published Scale-tier limit for Claude Sonnet 5.5 is 10 million (rate limits, checked 6 November 2026). Cache reads do not count toward that limit, so the cached design uses about 280,000 a minute for the fresh tokens. Pricing can also change with length: Claude Haiku 5.5 charges $0.10 per million input tokens up to 100,000 tokens of prompt and $0.50 above it, so a cheaper model can stop being cheap at exactly the prompt sizes this design needs.

Beyond cost.

  • Latency. Processing hundreds of thousands of tokens takes time, even with caching helping considerably. Retrieval plus a short prompt usually answers faster.
  • Quality. Models can miss or misweight details in very long inputs. Liu et al.'s Lost in the Middle (TACL 2024) found performance was highest when the relevant information sat at the start or end of the input and degraded when it was in the middle. RULER (COLM 2024) tested 17 long-context models: nearly all passed the simple needle-in-a-haystack test, yet only about half of those claiming 32,000 tokens or more held satisfactory performance at 32,000 on harder tasks. The advertised window is a capacity, and the effective window is something you measure. Retrieval puts the five most relevant passages in front of the model; a huge prompt asks it to find them. Test on your own questions; results vary by model.
  • Permissions. If different users may see different documents, one shared prompt containing everything cannot enforce that. Build prompts from each user's authorized documents. Permission-scoped shared prefixes may still be cached, but access changes must invalidate affected entries. Retrieval filters by permission before anything reaches the model.
  • Freshness. An edit invalidates the affected prefix or derived summary; include source versions and access changes in the cache contract.
  • Scale. Corpora grow. A wiki of 50 million tokens will not fit in any window.
  • Citations. Retrieval knows which passage it supplied; with a huge prompt, attributing an answer to a source is harder.

Where long context does win.

  • A user working with one long document: analysing a 300-page contract, a codebase, a long transcript. Compare full context with retrieval on the actual task; neither wins by definition.
  • Small, shared, stable reference sets (a few hundred pages that rarely change), with caching. Anthropic's contextual retrieval guidance draws the line at about 200,000 tokens, roughly 500 pages.
  • After retrieval: retrieve whole sections or documents instead of tiny chunks, using the larger window to give the model more surrounding context.
rendering diagram…

My recommendation for a typical enterprise knowledge product: keep RAG, use the larger window to retrieve bigger, more complete passages, and use full long context for tasks centred on one document.

Price source: Anthropic rate card, checked 6 November 2026.

What interviewers probe next

"Retrieval keeps missing answers; long context would fix that." It might, but measure recall first. Inspect whether the source was parsed, authorized and indexed before trying hybrid search or reranking. Compare improvements on the missed cases and a held-out set.

"Prices keep falling. Won't long context be cheap soon?" Possibly; the permission and freshness constraints remain. Re-run the cost comparison when prices change.

How it's scored

SignalWeakHireStrong Hire
ArithmeticNo numbersCost per query comparisonIncludes caching, showing it narrows but does not close the gap, and checks the design against rate limits
ConstraintsCost onlyCost and qualityLatency, middle-of-context quality, permissions, freshness, scale and citations
RecommendationYes or noDepends on corpusClear rule by corpus type, long context for single-document tasks and after retrieval

Common mistakes

Ignoring prompt caching, or assuming it makes long context free.

Forgetting per-user permissions, which a shared prompt cannot enforce.

Assuming models use every part of a very long context equally well.

See RAG explained and prompt and prefix caching.

That one was free, and so are 5 answers per topic without an account. Signing in raises that to 9, saves your bookmarks and helps you choose what to review using your own recall ratings.sign in with Google · free · no card
HOW DID IT GO?
0
UP NEXT ON YOUR JOURNEY
NOTES & DISCUSSION · 0

No comments yet. How would you have answered?