Context Engineering Is Not Prompt Engineering

In June 2025, Andrej Karpathy told developers to retire the term prompt engineering, and three months later came Anthropic's guide to context engineering. Context engineering is the job of deciding what goes into the context window, in what order, and what gets left out. LangChain's Lance Martin gave the discipline a taxonomy the same month: write, select, compress, isolate. None of it is abstract. Chroma already showed 18 frontier models degrading well before their advertised limit, and Anthropic's own agents condense a sub-agent's work down to 1,000 to 2,000 tokens before it reaches the coordinator. The industry did not rename prompt engineering for fun. The bottleneck, and the bill, moved somewhere else.

Published 2026-07-10 by Dor Amir on the Nadir blog.

Filed under Context & Compression.

Karpathy renamed the job in one tweet

In June 2025, Andrej Karpathy posted that he preferred "context engineering" over "prompt engineering." His reasoning: "people associate prompts with short task descriptions you'd give an LLM in your day-to-day use. When in every industrial-strength LLM app, context engineering is the delicate art and science of filling the context window with just the right information for the next step." Source: Andrej Karpathy, X post, June 2025.

That is a narrow-sounding complaint about word choice. It is not one. "Prompt" implies the bottleneck is phrasing, the sentence you type before the model answers. In a real production system, the model never sees your prompt in isolation. It sees a context window assembled at runtime from a system prompt, retrieved documents, tool schemas, conversation history, memory, and the output of whatever the agent did three steps ago. Calling the discipline "prompt engineering" points everyone at the wrong lever. The tweet went to the top of Hacker News within a day. Source: Hacker News discussion, June 2025.

Three months later, Anthropic made the renaming official with an engineering guide of its own: Effective context engineering for AI agents, published September 2025. Its framing: "context must be treated as a finite resource with diminishing marginal returns," the same way human working memory is finite. The guide introduces an idea worth sitting with: an attention budget. Every token you add to the window is not free just because the window is large enough to hold it. It draws down a budget the model spends on deciding what to weight.

Why now, not two years ago

Nothing about attention mechanics changed in 2025. Three things happened at once that made the old habit, when unsure whether something is relevant, include it anyway, expensive in a way it had not been before.

Context windows got large enough to make that habit feel free. Gemini 2.5 Pro shipped a 1-million-token window. The implicit marketing promise of a bigger window is that it is strictly better than a smaller one. It is not. This blog has already covered the research showing why: Chroma tested 18 frontier models from 1,000 to 1,000,000 tokens, and every one of them got measurably worse before hitting its context limit. Context rot is what happens when "the window can hold it" gets treated as the same question as "the model should read it."

Agent loops multiplied the number of times that habit gets paid for. A single agent step already reruns the entire conversation history through the model on every turn. Multi-agent orchestration multiplies that same overhead roughly 15 times, and a research agent can spend 82% of its token budget on structural overhead before writing a word of the actual answer. None of that is one bloated prompt. It is the same undisciplined context assembly, repeated at every hop.

And the failure mode got a name and a mechanism, not just a vibe. Chroma's methodology extended the classic needle-in-a-haystack test with distractors and low-similarity questions, and found the decline was steepest exactly where production agents are weakest: long histories full of plausible-but-irrelevant tool output. Source: Chroma Research, "Context Rot," 2025. The quality problem and the cost problem turned out to be the same tokens.

The taxonomy that stuck: write, select, compress, isolate

Around the same time, LangChain's Lance Martin published a working taxonomy for the discipline: context engineering is "the delicate art and science of filling the context window with just the right information at each step of an agent's trajectory," broken into four strategies: write, select, compress, and isolate. Source: Lance Martin, "Context Engineering for Agents," June 23, 2025. It is a useful taxonomy precisely because it is not a new idea. Every strategy in it already has a cost number attached, mostly from research this blog has already covered.

StrategyWhat it meansAlready measured here
WritePersist state outside the window instead of re-sending it in full every turnAnthropic's compaction, see below
SelectRetrieve only what a step needs, just in time, instead of loading everything up frontRAG pipelines fetch 20 chunks, the model reads 3
CompressSummarize, prune, or losslessly re-encode whatever must stay in the windowPrompt compression cuts input bills 3 to 5x in production
IsolateGive each sub-agent its own clean, scoped context instead of one shared, sprawling oneSub-agent results condense to 1,000 to 2,000 tokens, see below
One context window, four strategies: write persists state outside the window via compaction, select retrieves just-in-time and cuts a typical 20-chunk RAG fetch to the 3 chunks actually used, compress applies LLMLingua-style re-encoding for up to 20x reduction, and isolate gives each sub-agent a clean scope that condenses to 1,000 to 2,000 tokens before reaching the coordinator.
One context window, four strategies: write persists state outside the window via compaction, select retrieves just-in-time and cuts a typical 20-chunk RAG fetch to the 3 chunks actually used, compress applies LLMLingua-style re-encoding for up to 20x reduction, and isolate gives each sub-agent a clean scope that condenses to 1,000 to 2,000 tokens before reaching the coordinator.

Three of those four rows are old news on this blog under different names. What is new, and worth its own section, is what Anthropic's guide adds to "write" and "isolate": a specific mechanism for each, not just a principle.

Compaction and progressive disclosure: the part with an actual recipe

Compaction. When a session nears its context limit, summarize the conversation and reinitialize with the condensed version instead of the full transcript. Anthropic's guide is specific about what a good compaction step keeps and drops: preserve architectural decisions, unresolved bugs, and implementation details still in play, and discard redundant tool outputs and superseded steps. Source: Anthropic, "Effective context engineering for AI agents," September 2025. This is the same principle behind multi-turn conversations billing your first message 20 times over, except compaction is the fix applied proactively instead of discovered on an invoice.

Structured note-taking. An agent maintains a persistent scratchpad, a to-do list, or a memory file outside the context window and reads back only the piece it needs for the current step. This is how a long-running coding agent tracks a 50-step plan without carrying all 50 steps in every turn's input. The note-taking is cheap. Re-sending the entire plan every turn is not.

Just-in-time context. Instead of loading a file's full contents, load a reference, a file path, an identifiers, and fetch the content only when a step actually needs it. Anthropic calls this progressive disclosure: the agent discovers relevant context incrementally rather than front-loading everything it might conceivably need. It is the same shape of fix as a browser agent switching from a full accessibility-tree dump to compact element references, a 55x spread in tokens for reading the identical page.

Sub-agent isolation. A specialized sub-agent gets its own clean context window, does the exploration or research, and hands back a condensed result, typically 1,000 to 2,000 tokens, to the coordinating agent. Source: Anthropic, "Effective context engineering for AI agents," September 2025. The coordinator's context stays small no matter how much scratch work the sub-agent did to get there. That is the mechanism, not just the principle, behind the isolation gains this blog measured in multi-agent orchestration.

A context budget, sketched

None of this requires a framework. It requires a function that decides, on every turn, what earns a place in the window before the window fills up on its own:

# Allocate a fixed token budget across context sections, in priority order
def assemble_context(system_prompt, tools, memory, retrieved_docs, history, budget):
    context = []
    remaining = budget

    # Fixed costs first: the model can't function without these
    context.append(system_prompt)
    remaining -= count_tokens(system_prompt)
    context.append(select_tools(tools, task))       # select: only the tools this step needs
    remaining -= count_tokens(context[-1])

    # Write: pull in only the memory relevant to the current step, not the whole log
    relevant_memory = select_relevant(memory, task, top_k=3)
    context.append(relevant_memory)
    remaining -= count_tokens(relevant_memory)

    # Select + compress: retrieve narrowly, then shrink what's kept
    top_docs = retrieve(retrieved_docs, task, top_k=3)
    compressed_docs = compress(top_docs, ratio=0.3)
    context.append(compressed_docs)
    remaining -= count_tokens(compressed_docs)

    # Write: compact history once it stops fitting cleanly in what's left
    if count_tokens(history) > remaining:
        history = compact(history, keep="decisions_and_open_threads")
    context.append(history)

    return context

That is the whole idea. Every one of the four strategies shows up as a decision inside one function: what gets selected, what gets compressed, what gets written to memory instead of resent, and what gets isolated into a sub-agent call that returns a summary instead of a transcript.

What to ship this week

Where routing fits in a discipline about context

Context engineering answers what goes into the call. It does not answer which model the call goes to, and that is a second, independent axis on the same bill. A well-engineered context sent to a frontier model on every request is still spending more than it needs to on the model side. Nadir routes each request to the cheapest model that can handle it once the context is already built, and Context Optimize applies the compress strategy from this taxonomy automatically, no LLMLingua integration to wire up yourself. The two axes multiply the same way compression and routing already do: engineer what you send, then route it to the model that should read it.

Conclusion

Karpathy's complaint was about a word, but the word was hiding the actual engineering problem. "Prompt" suggests the fix is phrasing. "Context" names the real object: a runtime-assembled window with a finite attention budget, filled from a handful of sources that all compete for space. Anthropic gave that object a mechanism, compaction, structured notes, progressive disclosure, sub-agent isolation. LangChain gave it a taxonomy that makes the sources easy to audit one at a time. None of the four strategies is new to a reader of this blog. What is new is having one name for all of them, and a budget to hold them to.

Related reading


Sources: [Andrej Karpathy, X post, June 2025](https://x.com/karpathy/status/1937902205765607626). [Hacker News discussion](https://news.ycombinator.com/item?id=44379538). [Anthropic, "Effective context engineering for AI agents," September 2025](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents). [Lance Martin, "Context Engineering for Agents," June 23, 2025](https://rlancemartin.github.io/2025/06/23/context_engineering/). [Chroma Research, "Context Rot: How Increasing Input Tokens Impacts LLM Performance," 2025](https://www.trychroma.com/research/context-rot). [Microsoft Research, "LLMLingua-2: Data Distillation for Efficient and Faithful Task-Agnostic Prompt Compression," 2024](https://arxiv.org/abs/2403.12968).


More on context & compression

What Nadir is

Nadir is an LLM router. Nadir sizes every prompt and routes it to the cheapest model that still clears your quality bar. A small decision model reads each prompt against your model menu and picks the lowest-cost model it expects to handle it. When the decision model is uncertain or unavailable, the request goes to the strongest model on the menu. The routing step makes no call to your model provider.

Nadir runs two ways. The decision API returns a model, reasoning-effort, cache, context, and policy recommendation without calling a model provider, beside the gateway you already run. That is how a shadow-mode evaluation works, and its projected savings stay advisory. The OpenAI compatible managed proxy executes the route, and migration is a two-line change: point the base URL at api.getnadir.com and set model to auto. On that path an optional verifier can score a complete non-streaming answer and escalate to a stronger model when it misses the configured bar. Streaming bypasses post-generation verification. BYOK is supported on every tier.

For coding agents, Nadir Auto is a terminal launcher for Claude Code or Codex that asks Nadir for the main-session model before each turn, with your configured model as the fallback and cost ceiling. Delegation integrations for Claude Code, Codex, or Cursor instead recommend a model tier for subagent work, and the agent decides. Either way inference runs on your own provider account, so Nadir holds no provider keys on that path.

What the numbers are, and what they are not

Nadir publishes each evaluation with its scope. On checkable code, run-check-escalate solved 392 of 395 common HumanEval and MBPP problems (99.2%), graded by running the canonical tests; that applies only to tasks with runnable deterministic tests. Nadir-Tumbler posts an arena_score of 72.3 on RouterArena's public scorer, 5th of 23 routers, which measures the routing decision on RouterArena's own model pool. A reference-assisted RouterBench evaluation over 11,420 held-out triples produced a 60% lower projected cost than always-Opus with about 98% retained quality and a 1.7% catastrophic-route rate. That experiment gave the verifier the expensive-model reference answer, which production does not have, so it is a research ceiling and not the deployed path.

None of these is a production guarantee, a universal savings rate, or a forecast for any particular workload. Customer savings are reported from measured execution against a declared baseline, and customer quality only from outcome-labelled traffic. Projected savings and realized savings are separate artifacts and are never blended.

Design-partner program

Three rungs, picked by risk appetite. Rung 0 Shadow runs advisory decision calls alongside live traffic and returns a projected receipt, with nothing in the request path changed. Rung 1 Hosted is the two-line swap on a production slice and returns a realized receipt. Rung 2 On-prem is a supervised six-week proof of concept inside the partner's VPC, where no prompt, response, or usage reaches Nadir. The commitments are the same at every rung. Apply for a rung directly: Rung 0 Shadow, Rung 1 Hosted, or Rung 2 On-prem. Not sure which fits? Start at getnadir.com/contact/?reason=design-partner.

Licensing

NadirClaw is the self-hosted core, source-available under the PolyForm Noncommercial License. Source-available is the correct label; NadirClaw is not open source. Nadir Route's hosted plan has no base fee and charges a variable fee only on measured savings from requests Nadir executed.

Pages on this site

Machine-readable summaries of this site: llms.txt and llms-full.txt.