Two of the most important cost levers for long-running Claude agents pull in opposite directions. Prompt caching works because each request re-sends a prefix that is byte-for-byte identical to the last one — the cached portion is billed at a steep discount instead of full input price. Context editing works by changing that history: the clear_tool_uses_20250919 strategy removes stale tool results from the prompt server-side, shrinking what the model processes. The collision is direct, and Anthropic's docs state it plainly: clearing tool results invalidates cached prompt prefixes. From the cleared point onward, the next request no longer matches what's in the cache, and those tokens are billed as a fresh cache write rather than a cheap cache read.
Why this isn't a reason to skip context editing
The naive reading — "context editing breaks my cache, so I'll disable it" — gets the economics backwards for long agent sessions. Without editing, an agent's history grows monotonically; you pay (discounted) input cost on an ever-larger prefix, and eventually you hit the context window ceiling regardless of price. Editing trades a one-time cache miss at each clearing event for a permanently smaller prompt on every subsequent request. The question is not whether to clear, but whether each clearing event removes enough to be worth the cache invalidation it causes.
That is precisely the knob Anthropic provides: clear_at_least sets a minimum amount of tokens that must be cleared each time the strategy activates. A clearing event that removes a trivial amount of context would still invalidate the cache from that point — the worst of both worlds. Setting clear_at_least ensures the strategy only fires when the context-window savings are large enough to justify re-writing the cache, and stays quiet otherwise.
clear_at_least — concentrate the invalidation cost into a few events whose savings clearly dominate.Thinking blocks follow the same logic
The second strategy, clear_thinking_20251015, has the same cache interaction in miniature: keeping thinking blocks preserves the cache, clearing them invalidates it at the clearing point. This is worth knowing because the model defaults differ — Opus 4.5+ and Sonnet 4.6+ keep all prior thinking by default, while earlier models and all Haiku versions keep only the last turn's. If you override the defaults to clear thinking more aggressively, you are accepting cache invalidation in exchange for the space; make that trade deliberately, not by copy-pasting a config between models.
Measuring instead of guessing
You don't have to reason about this in the abstract — the API reports both sides of the ledger. Each response's context_management.applied_edits includes cleared_input_tokens, telling you exactly how much each clearing event removed. On the caching side, the standard usage fields report cache reads and writes per request (see cache read vs write pricing for how those bill). And before committing to a configuration, /v1/messages/count_tokens returns original_input_tokens and input_tokens side by side, so you can replay a real production transcript against candidate trigger/keep/clear_at_least values and see the shrinkage without spending a single inference dollar.
A tuning workflow that works in practice: start from the defaults (trigger at 100,000 input tokens, keep the 3 most recent tool pairs), replay a few representative sessions through count_tokens, then raise clear_at_least until clearing events are few and fat. Watch the ratio of cache-write tokens to cache-read tokens in your usage data before and after enabling editing — if writes spike without a corresponding drop in total input tokens, your clears are too small or too frequent.
The 3P footnote
Both halves of this interplay travel well: prompt caching and context editing are available on all four third-party platforms — Claude Platform on AWS, Amazon Bedrock, Google Vertex AI, and Microsoft Foundry (context editing is beta everywhere; on Foundry, Microsoft's docs confirm it with the same context-management-2025-06-27 header). The tuning logic in this article is therefore platform-independent, which is rarer than it should be in the agent-feature landscape.
Where to go next
The mechanics of what gets cleared are in the server-side context editing deep dive; the caching side lives in prompt cache mechanics and cache read vs write. For the third leg of long-agent context management, see the memory tool.