Two features, one folder in every builder's head: ways to lower the agent's token bill. So people reach for prompt caching and context editing interchangeably, turn one on, and wonder why the number barely moved. They are not substitutes. One changes the price of the tokens you keep sending; the other changes how many tokens you send at all. Confuse them and you'll apply a discount to a window that's overflowing, or delete history to save a bill that caching had already made cheap.

Here's the whole distinction in one screen, and it's worth memorizing:

Prompt caching lowers the price per token on an unchanged prefix — a cache read costs 0.10× standard input, a 90% discount — but every token is still there. Context editing lowers the count — it deletes old tool results so those tokens leave the window. A discount and a delete are not the same tool, and they solve different failures.

Prompt caching: a discount, not a delete#

Prompt caching stores a prefix — your system prompt, tool definitions, a long document, few-shot examples — so the next request that repeats it reads from cache instead of reprocessing. On Anthropic's API a cache read costs 0.10× standard input; a cache write costs 1.25× at the 5-minute TTL or 2× at the 1-hour TTL, and reading a cached block resets its TTL, so high-frequency workloads rarely pay the write after warm-up (Anthropic, prompt caching).

What caching does not do is make your context smaller. The tokens are all still in the window; you're just paying a tenth to reprocess the stable part. That's a huge win when a big, unchanging prefix gets reused inside the TTL — and it's nothing when your problem is that the window itself is filling up. A 90% discount on a context that's about to overflow still overflows.

Context editing: a delete, not a discount#

Context editing attacks the count. The clear_tool_uses_20250919 strategy drops the oldest tool results once the prompt crosses a trigger — 100,000 input tokens by default — keeping the last keep (default 3) and leaving a placeholder so the model knows something was removed (Anthropic, context editing). This is what lets a long-horizon agent keep going: in Anthropic's 100-turn web-search evaluation, context editing cut token consumption 84% and let agents finish workflows that otherwise died of context exhaustion, lifting performance 29% alone and 39% paired with the memory tool (Anthropic, context management). We walked the editing-vs-summarizing choice in Context Editing vs Compaction vs the Memory Tool; the point here is narrower: editing removes tokens, caching never does.

Where they fight: the cache#

Now the part that surprises people. The two levers share one resource — the cached prefix — and they pull against it. Anthropic's docs say it plainly: clearing tool results invalidates cached prompt prefixes below the point where content was removed. So a naive "clear on every turn" loop turns yesterday's cache reads back into cache writes, and the feature you added to cut the bill starts padding it.

That's exactly why the strategy ships with clear_at_least: it won't clear unless it can remove at least that many tokens, so you only eat the re-write when the savings justify it. The docs' own guidance — clear enough tokens to make the cache invalidation worthwhile — is the whole reconciliation in a sentence.

The rule: cache the head, edit the tail#

The structure that makes both pay off at once:

The one-line routing, then. Stable prefix, short-to-medium runs → prompt caching, and if you only do one thing, do this one. Long, tool-heavy runs hitting the window → context editing, because no discount fixes a full window. Nearly every production agent wants both — but ordered, not stacked blindly: cache the head, edit the tail, and set clear_at_least so the discount and the delete stop fighting and start compounding. They were never the same tool; used together on purpose, they're the two halves of the same bill.