Context engineering is the practice of controlling what an AI agent holds in its working memory at every turn, instead of loading everything up front. Done right, it cuts token spend by 70-90% and stops an agent from re-reading the same codebase, document, or log file on every single message. Most teams running Claude Code or any agent framework are paying full price for context they already paid for ten messages ago, and they don’t know it.
Here is the contrarian part: adding more context does not make your agent smarter. It makes it slower, more expensive, and more likely to lose the thread. The instinct to « give the model everything so it has what it needs » is the single most expensive habit in agentic AI right now, and almost nobody has been told to stop.
The DragonBall Problem With Most Agent Setups
Goku does not stay a Super Saiyan forever. He trains, powers down, banks the gain, and trains again for the next threshold. Most people run their AI agents the opposite way: max power, every session, all the time. Full codebase loaded. Full document loaded. Full conversation history dragged forward on every turn, transformation never released.
An agent that never powers down between tasks is an agent you are paying full price for at every step, whether or not the current question needs any of what it is carrying. Context engineering is the discipline of training in bursts, banking the result to disk, and only pulling back the specific gain the next task actually needs.
What Context Engineering Actually Means
Context engineering is the deliberate management of what enters an AI model’s prompt window on each call, as opposed to prompt engineering, which only shapes how a request is phrased. It governs three things: what gets loaded, what gets cached, and what gets delegated to a separate process before it ever reaches your main thread.
Per Anthropic’s own pricing documentation, cached input tokens cost roughly 10% of a fresh input token, a 90% discount that only applies if the prompt prefix stays byte-for-byte identical between calls. A Branch8 case study tracked one team going from $2,400 to $680 per month in three iterations, a 72% drop, and the bulk of that gain came from two levers: prompt caching and cutting open-ended sessions down to focused ones.
The failure mode is silent. Nothing errors out when you break a cache. You just get billed as if the discount never existed, and most teams never check the number that would tell them.
Step 1: Get the Big Stuff Out of the Prompt
The first rule is the one everyone violates instinctively: if it is large and static, it does not belong in the live prompt. Put the codebase, the reference doc, the log file on disk, and let the agent reach in with a targeted read or a grep when it actually needs a piece of it.
A 108,000-token document loaded into every turn costs you 108,000 tokens on every turn, forever, until the session ends. The same document sitting on disk costs you nothing until a question actually touches it, and then it costs you the size of the answer, not the size of the book. Anthropic and Andrew Ng demonstrated exactly this pattern: dropping a full book into a prompt versus letting an agent retrieve only the relevant section, cutting the same task from 108,000 tokens down to 11.
This is where most of the savings live. Every other step in this article exists to protect the gain this one step creates.
Step 2: Delegate the Noisy Work to Subagents
A test suite failure, a stack trace, a crawl of forty documentation pages: none of that belongs in your main thread. It is not intelligence, it is noise, and noise that lands in your context window stays there, costing you on every subsequent turn for the rest of the session.
A subagent absorbs the mess in its own isolated window and hands back a clean answer. One internal benchmark on multi-domain queries found isolated subagents running at roughly 9,000 total tokens against 15,000 for a pattern that let context accumulate in a single thread, a 40% gap from delegation alone.
Your main thread never sees 4,000 lines of test output. It sees « three tests failed, here is why, » and that is the only version of the truth it needs to keep working.
Step 3: Let the Agent Manage Its Own Memory
Most agents start every session at zero, and the human re-explains the same project context, the same conventions, the same past bugs, and pays tokens to reload all of it every time. That repetition is pure waste, and it is avoidable.
Claude Code’s Auto Memory writes its own notes between sessions, capturing build commands, fixes, and workarounds without being asked, then loads them back in at the start of the next session.
The practical move: run /memory to see what has already been captured, then strip those same facts out of your static instructions file. Anything the agent learns after one session does not belong in the file that gets paid for on every single turn. For larger projects, treat the memory file as a table of contents, not a dump: one line per topic file, so the agent pulls in the ten lines it needs instead of the two hundred it does not.
Step 4: Stop Breaking Your Own Cache
This is the step that costs teams the most money without them noticing. A prompt cache only matches an exact prefix. Change one character before the cache boundary and the entire cache invalidates for that call, silently, at full price, with no error message telling you what happened.
The usual culprits: a timestamp baked into the system prompt that changes every call, a model switch mid-session that reads from a completely separate cache, or a stray reordered tool list.
The fix is structural, not clever: static content at the top in a fixed order, anything that changes goes at the bottom, below the cache boundary. GitHub reportedly keeps its cache hit rate above 94% internally and treats a drop to 70% as a bug worth an incident review. Most teams outside that discipline are running closer to 40% and have never looked at the number.
Step 5: Compact on Your Schedule, Not the Tool’s
Automatic context compaction happens on the tool’s schedule, which means it can trigger mid-task and eat a chunk of your remaining budget at the worst possible moment.
Two commands hand the control back: one shows what is currently occupying the window, the other lets you compact deliberately at a clean break between tasks.
The habit that matters: check context usage when a session starts to feel heavy, and compact between tasks, not in the middle of one.
Comparison: Load Everything vs. Context Engineering
| Approach | Token cost per turn | Cache hit rate | Failure mode |
|---|---|---|---|
| Load everything up front | Full document/codebase size, every turn | Near 0%, breaks on any variance | Silent overbilling, slow responses |
| Context engineering (5 steps above) | Size of the actual question | 90%+ achievable, GitHub reports 94% | Requires discipline, not tooling |
| No memory, re-explain each session | Full context restated manually every session | N/A | Wasted human time and tokens |
| Self-managed memory (Auto Memory) | Marginal, loads only relevant notes | High, static prefix preserved | None if memory file stays a table of contents |
Why Most Teams Get This Wrong
Most teams treat token cost as a pricing problem to negotiate rather than an architecture problem to fix. It is not the model that is expensive. It is the habit of re-sending the same 100,000 tokens of context on every message because nobody separated what the agent is holding from what the current task needs.
Anthropic’s own engineers reportedly treat a cache hit-rate drop as an incident-level event, comparing it to high-frequency trading, where a single percentage point of efficiency is worth millions at scale. Your agent bill runs on the same logic at a smaller size.
If you are serious about running AI agents as infrastructure rather than as an expensive chat window, this is where the Asymmetriq approach comes in: we build managed agent systems for companies that need this discipline applied and maintained, not explained once and forgotten. If you want the condensed, hands-on version instead, the Claude Sprint walks you through building this exact system in four sessions.
FAQ
Q: Is context engineering the same thing as prompt engineering?
A: No. Prompt engineering shapes how you phrase a request. Context engineering controls what enters the model’s window at all, including what stays on disk, what gets cached, and what gets delegated to a subagent before it ever reaches your main thread.
Q: How much can prompt caching actually save?
A: Anthropic prices cached input tokens at roughly 10% of the fresh input rate, a 90% discount, but only when the prompt prefix is byte-for-byte identical between calls. One documented case went from $2,400 to $680 per month in three iterations largely through caching and tighter sessions.
Q: Why does my cache hit rate keep dropping without any error?
A: Cache matching requires an exact prefix. A timestamp in your system prompt, a mid-session model switch, or a reordered tool list breaks the match silently, and you get charged full price with no warning.
Q: Do I need a separate memory database to do this?
A: Not necessarily. Claude Code’s Auto Memory handles session-to-session recall natively. A dedicated memory layer helps at scale, but the biggest gains come from the five structural habits above, not from new tooling.
Q: Is subagent delegation worth the added complexity?
A: Yes for any task that generates a wall of tokens you do not need to keep, like test output or log crawling. Benchmarks show isolated subagent patterns running at roughly 60% of the token cost of letting that noise accumulate in one thread.
Q: Why do most companies get token costs wrong even after reading about prompt caching?
A: They implement caching once and never check the hit rate again. Caching is not set-and-forget. It lives on a number, cache_read_input_tokens, that only tells you the truth if you look at it weekly.
The Verdict
The agents that stay cheap are not run by people with better prompts. They are run by people who know exactly what their agent is holding in its window at every moment, and why. Cache, subagents, and self-managed memory are just three tools inside that discipline, and all three will have different names in six months. The discipline itself will not change. Train, bank the gain, power down, repeat. Run your agent like an engineer, not like someone who dumped a library into the chat and hoped.