Deciding what goes into the request, and caching the parts that repeat.
Sourced
Concept at a glance
The model works from the context you actually send, not everything your system knows.
Same concept, different task and consequences. Switching starts a fresh walkthrough; prior answers and approvals do not carry over.
Selecting and arranging the instructions, reference material, and history included in each model request.
Follow the selection of information for a particular request. Compare what is available with what is actually included, then see how source selection changes an otherwise similar response.
Reply about warranty coverage using the current manual, not old case notes.
A visible request-context tray, version labels, included/excluded evidence, and answer differences.
The setting makes the example concrete. Carry the underlying pattern into your own work; adapt the sources, tools, and level of oversight to your task.
Reply about warranty coverage using the current manual, not old case notes.
Authored case. Select any record below; nothing is sent to a model.What changed: Establish the facts supplied for this version of the task.
Some available material may be old, irrelevant, or untrusted. Including everything can bury the evidence needed for this decision.
Describe your task to your own model and use Context engineering as a reference. Ask whether it fits, which alternatives meet the same automation needs, and how you would implement and check the result.
Context engineering is deciding what goes into the request: which instructions, which examples, which documents, and how much of the conversation so far. The model knows only what it was trained on and what the request contains, so everything else is a choice your code makes, on every call.
Two things about that choice matter beyond fitting the content in. Order affects cost: Anthropic and OpenAI both cache a matching prefix of a request and bill the reused part at a lower rate, and both tell you to put the content that never changes first and the content that changes every call last[1][2]. Length affects quality on its own: Chroma’s research across 18 models reports that models do not use their context uniformly, and that performance grows increasingly unreliable as input length grows, even on simple tasks[3]. A longer request is not free just because it still fits.
Context engineering sits at level 2, context. Nothing here searches and nothing is decided by the model: your code fixes what goes in, and in what order, before the request is sent.
This page provides primary references and illustrative examples. The examples are scripted, not measured model runs; source references do not establish the correctness of every implementation or outcome.
This separate, scripted trace illustrates the code example discussed in the implementation details. Use it to inspect individual steps, inputs, and outputs.
Assemble one request from fixed parts, cache-friendly order first, and ask once.
This is a scripted illustration, not a recorded model run. Its timing and token figures are not measured performance.
"What is the DW-300's Normal cycle water use?" 2 prior turns of history
The feature to find is the one that saves instructions and files across conversations instead of inside one. Chat apps name it differently: a project, a space, custom instructions, a saved assistant. Look in the sidebar or the settings for anything that says the material will apply to every new conversation. Anthropic’s Claude Projects keeps a project’s files and instructions available to every conversation inside it: that pinned material is the stable part of the request, and what you type each turn is the part that changes[5]. Other makers’ chat apps have the same feature; the ones this site has checked are listed under Out there at the foot of this page.
Pin three things, and nothing else.
Then type only what changed. “Draft the renewal letter for the account in today’s file. It renews 3/14/2027.”
To check it worked, open a brand new conversation inside the project and ask something only the pinned material can answer, such as what your style guide says about bullet lists. An answer with nothing pasted in means the pinned material is reaching the model. No answer usually means what you wrote went into one conversation rather than into the project, which is a different box in most products.
Two moves when the answers get worse instead of better. Start a fresh conversation rather than continuing one that has run for hours: more in the request measurably costs answer quality, not just money[3], and a new conversation keeps the pinned material while dropping the accumulated back-and-forth. And stop adding files once they stop fitting. Past that point a product stops sending all of it and starts searching instead, which is RAG; Claude Projects makes that switch on its own.
None of this is worth setting up for a question you will ask once, with nothing to reuse. Type the question.
The example below builds one request from parts that change at different rates: system instructions and the reference documents never change between calls; conversation history and the question change every call. It puts the parts that never change first and the parts that change last, which is the ordering a caching backend needs to reuse the front of the request[1] [2]. Nothing here searches for anything (the whole synthetic document set goes in, the same way regardless of the question) so this is what RAG’s “put it all in the window” alternative actually looks like in code.
The static block is built once per call from every document in evals/corpus/, concatenated in a
fixed, alphabetical order so its bytes are identical from one question to the next. A
token_budget caps the whole request; what is left after the static block is what the
conversation history gets to use. When history does not fit, the code drops the oldest turns
first and never touches the documents, since the documents are the part later calls can still
reuse from cache. This is the one place the code makes a real decision, and it is a fixed rule,
not a judgment call: nothing here is decided by the model.
Ordering the request is necessary for caching but not sufficient, and the two makers cited above
differ in a way worth reading before you count on a discount. OpenAI documents caching as on by
default for supported models, matching a prefix automatically once it clears a minimum cacheable
length; that minimum is 1,024 tokens on its newest models and different on earlier ones, and
reused tokens are billed at a reduced rate, discounted up to 90%[2]. Anthropic requires
you to mark the end of the reusable prefix with a cache_control field, has a per-model minimum
below which a marked prompt is silently not cached, and prices a cache read as a fraction of its
base input rate (a tenth for most models, lower still for its newest ones) against a write that
costs more than an uncached call[1]. Those are the makers’ own published terms, not
numbers this site has measured, and the write premium is why caching pays off over repeated calls
rather than on the first one.
def run(
question: str,
model: Model,
embedder: Embedder | None,
tracer: Tracer,
*,
corpus_dir: Path = DEFAULT_CORPUS_DIR,
history: list[Message] | None = None,
token_budget: int = TOKEN_BUDGET,
) -> Answer:
del embedder # nothing is retrieved: the whole document set goes in, or none of it does
static_block, static_tokens = _static_block(corpus_dir)
tracer.record(
kind="code",
decided_by="code",
title="Assemble the static, cache-friendly block",
detail="system instructions + the full document set, same on every call",
tokens_in=static_tokens,
)
kept_history = _fit_history(history or [], max(token_budget - static_tokens, 0), tracer)
dynamic = "\n".join(f"{m.role}: {m.content}" for m in kept_history)
user_content = static_block + (f"\n\n{dynamic}" if dynamic else "") + f"\n\nQuestion: {question}"
messages = [Message(role="system", content=SYSTEM_PROMPT), Message(role="user", content=user_content)]
tracer.record(
kind="code",
decided_by="code",
title="Build the final prompt",
detail=f"documents first, then {len(kept_history)} history turn(s), then the question last",
)
completion = model.complete(messages, max_tokens=400)
tracer.record(
kind="model",
decided_by="code",
title="Ask the model once with the full context",
detail=completion.text[:200],
tokens_in=completion.tokens_in,
tokens_out=completion.tokens_out,
ms=completion.ms,
)
return Answer.from_text(completion.text, retrieved_sources=list(load_sections(corpus_dir)))Every step is decided_by: "code": what goes in, in what order, and what gets cut when it does
not fit are all fixed before the model ever sees the request. Run it yourself:
python -m examples.context_engineering --model stub:scriptedSkip this and write a single prompt directly if there is nothing beyond the question itself to include: no documents, no reusable instructions, no history worth keeping. That is plain chat or prompt engineering.
Retrieve instead once the material outgrows the window. This page and RAG are the two answers to the same question, and four things separate them. Size: Anthropic’s engineering team says include a knowledge base under about 200,000 tokens in full and reach for retrieval as it grows past that[4]. Quality: a request that still fits can still answer worse, since performance grows less reliable as input length grows[3], while retrieval keeps the request short whatever the corpus does. Cost: everything you send is billed on every call, discounted to a tenth of the input rate on a cache hit[1] but never to nothing, where a search bills only the few passages it returns. And what you give up by retrieving is the guarantee that the answer’s source was in the request at all: a search can miss the passage, and sending everything cannot.
Illustrative, not measured: no result file exists for this technique yet, so every number below is a worked example. See docs/EVALS.md for how a real run is recorded and scored.
This technique would be scored against the same 60-question synthetic set as every other level,
over the document set in evals/corpus/. Because nothing is retrieved, every source is present
for every question kind, so multi-hop and conflicting-source questions would test whether the
model can still find and join facts inside a long request, not whether the right passage was
fetched. Lookup and numeric questions are the ones most exposed to context rot: a fact the model
could state easily on its own gets buried in material that has nothing to do with the question.
No result file exists for this technique yet (see docs/EVALS.md), so this page cannot say a
number for any of it. Run python scripts/eval_run.py --example context_engineering --model <spec> --dry to project the cost of a real run first. Expect a large number: this is the level
that sends the whole document set on every question.
Cache hit rate on the static block, and tokens billed at the full input rate versus the cached rate. A hit rate that drops for no reason usually means something changed in the part of the request meant to stay fixed.
Dominated by tokens in, most of which is the same material sent again on every call; the caching discount is what keeps that affordable at volume, so a change that breaks caching is a cost regression even if nothing else about the answers changes.
Someone adds a per-request value, such as a timestamp or a reordered list, ahead of the static block and the cache stops hitting. Or the reference material grows past the context window and starts getting silently cut, dropping whichever fact happened to be last.
The token count of the static block versus the dynamic part, whether the call was a cache hit, what (if anything) was trimmed to fit the budget, and the full assembled prompt, so a bad answer traces back to a missing fact rather than a model mistake.
Open a chat app's project or custom-instructions feature. Put a document there instead of pasting it into a message, ask about it, then ask something unrelated in the same project. Does it still see the document?
Run python -m examples.context_engineering --model stub:scripted from the repo root, then lower TOKEN_BUDGET in examples/context_engineering/run.py below the static block's 6,934 tokens. The history budget floors at zero, nothing is cut, and the prompt goes out over budget: it governs history, not the block the cache depends on.
Cause a failure mode above on purpose, with the documents in evals/corpus/.
3 current examples · Products, tools, and models that demonstrate this concept. A selection, not a ranking.
Files and instructions in a chat app
Maker’s documentation Checked 09/18/2026Files and instructions in a chat app
Maker’s documentation Checked 09/18/2026Agent harness
Maker’s documentation Checked 09/19/2026Send the current requirements and relevant schematic notes, rather than every file and every old conversation.
Names listed 09/19/2026. 223 of 223 registry entries have been checked against the maker's own page; the registry marks the rest as unchecked.
Last reviewed 09/19/2026. Pages unreviewed for 90 days are flagged for another pass. Markdown version of this page