Token-Control Patterns for Multi-Step Claude Agents

People building multi-step Claude agents keep hitting the same wall: the cost doesn't scale linearly with the work — it scales with the square of the conversation. A 10-step agent doesn't cost 10× a single step; it can cost far more. This guide is the why and the three fixes, all real Claude/Claude Code features you can paste today. The root cause is one fact most people skip past: the Claude API is stateless. It has no memory of your conversation between calls. So every time your agent takes a step, your code re-sends the entire transcript so far — the system prompt, every prior message, and every prior tool result — just so the model has the context to answer. Step 2 re-pays for step 1. Step 10 re-pays for steps 1 through 9. That re-payment is where the tokens go. The community has been loud about the bill — people report eye-watering single-run costs (more on that, honestly, below). The good news: there are three documented levers that attack the re-payment directly. Skim the table, then steal the snippets.

Here's the part that surprises people. When you call Claude, the model doesn't remember the last call. The API is stateless — each request is self-contained. For a chatbot that's fine; for a multi-step agent it's the whole problem. To give the model the context to take step N, your code (or the agent harness) sends the complete conversation up to that point: the system prompt, every user and assistant message, and crucially every tool result from every prior step — file reads, search dumps, API responses, the lot. Those tool results are usually the heaviest part. So the input you pay for grows with every single step, and you pay for the accumulated history again on each one. That's the 'stateless tax.' It's not a bug and it's not avoidable in the raw API — it's how stateless inference works. What you can control is how big that re-sent context is, and how much of it you pay full price for. The three patterns below are exactly those two levers: make the carried context smaller, and make the unchanged part of it cheap.

If every step re-sends the whole transcript, the first lever is obvious: make the transcript smaller. Claude gives you two distinct, real mechanisms for this — and they do different things, so use the right one. Context editing prunes. As turns accumulate, it clears stale content — old tool results and completed thinking blocks — out of the transcript based on configurable thresholds. It does not summarize; it removes. That depth-3 file dump from step 2 that nothing references anymore? Gone, so you stop re-sending it. (Docs: build-with-claude/context-editing.) Compaction summarizes. When the conversation approaches the context-window limit, the server condenses earlier history into a compaction block, server-side. The critical, easy-to-miss rule: you must append the response's full content (response.content) back onto your messages each turn — not just the text. The compaction block lives in that content, and the API uses it to replace the compacted history on the next request. Extract only the text and you silently lose the compaction state. (Beta header compact-2026-01-12.) Claude Code does compaction automatically — that 'compacting conversation' you see is this, native. If you're building on the raw API, here's the conceptual shape.

Pattern 1 shrinks the context. Pattern 2 makes the part you do keep re-sending cheap. This is the single highest-leverage move for multi-step agents. Prompt caching lets Claude reuse a previously-processed prefix instead of reprocessing it. You mark a content block with cache_control: {type: "ephemeral"} and the API caches everything up to that point. On the next request with the same prefix, those tokens are served from cache. Cache reads cost roughly 0.1× of the full input price — about a 90% discount on the cached portion. Writes cost ~1.25× (a one-time premium, 5-minute TTL), so by the second request you're already ahead. The one rule that governs everything: caching is a prefix match. The cache key is the exact bytes from the start of the prompt up to your breakpoint. Any single byte change anywhere in that prefix invalidates the cache for everything after it. Render order is tools → system → messages, so put your stable content first (frozen system prompt, deterministic tool list, prior tool results) and your volatile content (this step's new question, timestamps, per-request IDs) last — after the last breakpoint. For a multi-step agent the payoff is direct: the giant accumulated history is mostly stable from one step to the next, so it reads from cache at ~0.1× instead of being re-paid at full price every step.

Once you're caching, parallelism gets a non-obvious gotcha that quietly costs you the entire discount. Fanning work out is great when the calls are read-only and independent — many agents (Claude Code included) run parallel-safe tools like search and file-reads concurrently. The trap is caching: a cache entry only becomes readable after the first response that wrote it begins streaming. So if you fire N concurrent requests that all share the same big prefix, none of them can read a cache the others are still in the middle of writing — they all race, they all miss, and every one of them pays the full write price. You wanted N cache reads and got N cache writes. The fix is a tiny bit of sequencing at the front. Send one request first. Await its first streamed token — not the whole response, just the first token, which is the signal that the cache has begun being written. Then fire the remaining N−1. Those now read the cache the first one wrote, at ~0.1×. You keep almost all the parallelism and pay for the shared prefix once.

Here's a concrete, illustrative example with the arithmetic exposed so you can reproduce the logic on your own workload. This is NOT a guaranteed result — it's a model to reason with. Real numbers depend on how much of your context is stable, your step count, and how heavy your tool results are. Your numbers will vary. Setup: a 10-step agent carrying a ~20K-token context (system + tools + accumulated history/tool results). We'll count input tokens processed at full price, in 'full-price-token' units (so a cache read at 0.1× counts as 0.1 units per token). We ignore the small new-instruction tokens per step — they're the same in every scenario and tiny next to the 20K. Naive (no patterns): every step re-sends ~20K at full price. 10 steps × 20K = ~200K full-price tokens. This is the stateless tax in full. With prompt caching: step 1 writes the ~20K to cache at ~1.25× = ~25K units. Steps 2–10 read that ~20K from cache at ~0.1× = 9 × 2K = ~18K units. Total ≈ 25K + 18K = ~43K units — roughly a 4–5× reduction versus naive, just from caching the stable prefix. (As later steps add new stable history, you re-cache incrementally; the shape holds.) Add context editing: if pruning stale tool results shrinks the carried context from ~20K toward, say, ~12K over the run, every per-step number above scales down with it — both the writes and the reads get cheaper because there's simply less to carry. Caching and pruning compound: one makes the context cheap, the other makes it small. The takeaway isn't the specific figure — it's the direction and magnitude: the stateless tax is real and roughly quadratic, and the cached + pruned path turns most of it into a ~0.1× line item.

Two things get conflated constantly in the community, and getting them wrong makes your cost reasoning worthless. Worth 60 seconds to get straight. The scary single-run figures are other people's reports, not a law. You'll see community posts about a single prompt costing a fortune, or one run burning hundreds of thousands of tokens. Treat those as community estimates and anecdotes — they depend entirely on that person's context size, step count, and effort settings. They are not a guaranteed outcome, and they're not ours. We cite them only to show the direction the stateless tax pushes costs; the patterns here are how you push back. The '$200' is a subscription plan, not a per-token price — don't mix them. Claude Max is a consumer subscription (a flat monthly plan, $200/mo tier). API pricing is completely separate and is per token: for Claude Opus that's on the order of $5 per 1M input tokens and $25 per 1M output tokens. If you're building on the API, your bill is driven by tokens — which is exactly why the three patterns above matter — not by the consumer plan price. Conflating 'the $200 plan' with 'API cost' will make every estimate you do nonsense. So: attribute the pain to the community, frame the big figures as reported-not-guaranteed, reason in per-token API pricing, and verify with usage on real responses. Then the numbers are yours and they're honest.