Context editing vs compaction in the Claude API

Try 3 questions on this

Pick an answer to see why each option is right or wrong.

1. Your team enables compaction on a long-running assistant, sending the beta header compact-2026-01-12 and context_management: {"edits": [{"type": "compact_20260112"}]} on every request. Your loop extracts the text from each response and appends it to messages as an assistant turn. The conversation keeps growing until it exceeds the context window, as though compaction never ran. What change would most effectively resolve this issue?

   Right. In the game that’s Renown for your Context Management and Reliability building.

   Not that one: B is right. In the game your Context Management and Reliability building would lose a little Renown, and this question would come back later.

   Your answerA.Lower the compaction trigger threshold below its 150K-token default so it fires earlier in the conversation.The default trigger of about 150K tokens is not what is failing. Compaction runs and emits its blocks; the loop throws them away, so the next request arrives with the full uncompacted history no matter when the trigger fires.The answerB.Append the entire response.content list to messages each turn instead of only the extracted text.Compaction returns its summarized state as a compaction block inside response.content. The client must append that whole content list back to messages each turn, because the API drops the blocks preceding that block and continues from the summary.Your answerC.Raise max_tokens on every request so the compaction summary has room to be produced.Compaction emits its summary as a block in the response, and the response here is not being truncated — the loop receives it and then throws it away when it extracts only the text. Raising max_tokens buys more room for output the client is already discarding, so the next request still arrives carrying the full uncompacted history.Your answerD.Mark the conversation prefix with a cache_control breakpoint so the compacted history is reused.A cache_control breakpoint lets the API reuse a previously written prefix instead of reprocessing it, at 0.1x the base input rate on a hit. It is a cost and latency mechanism, not a context-window mechanism: the prefix being cached here is the full uncompacted history, so caching it makes the same oversized request cheaper rather than smaller.

   Show the full explanation and doc quotes

   Extracting only the text silently discards the compaction state, so every request arrives with the full uncompacted history.

   Written from platform.claude.com/docs/en/build-with-claude/compaction

2. Your agent enables clear_tool_uses_20250919 on a request whose large stable prefix is cached. Clearing now fires often but removes only a few thousand tokens each time, and the resulting cache rewrites cost more than the clearing saves. What change would most effectively address this issue?

   Right. In the game that’s Renown for your Context Management and Reliability building.

   Not that one: D is right. In the game your Context Management and Reliability building would lose a little Renown, and this question would come back later.

   Your answerA.Set exclude_tools to the names of the tools producing the small resultsexclude_tools shields named tools from clearing permanently. It cannot express the general rule that a clearing pass must be worth its cache cost.Your answerB.Set clear_tool_inputs to true so that each clearing removes more contentclear_tool_inputs extends clearing to the tool_use parameters as well as the results. It raises the yield of a pass but still permits passes that clear too little to be worthwhile.Your answerC.Raise keep so that fewer of the older tool result pairs are eligible for clearingRaising keep preserves more recent pairs and therefore shrinks the amount cleared per pass, deepening exactly the imbalance described.The answerD.Set clear_at_least to a token value worth the cache invalidationclear_at_least sets a minimum number of tokens that must be removable before clearing runs at all.

   Show the full explanation and doc quotes

   Because clearing invalidates the cached prefix from the clearing point onward, this is the parameter that stops a small clear from triggering an expensive cache rewrite.

   Written from platform.claude.com/docs/en/build-with-claude/context-editing

3. Your agent accumulates large tool results that are never referenced again once acted upon, and your team has confirmed that nothing in them needs to be recalled later. Input tokens per turn are rising, and the team proposes handling this with compaction rather than with tool-result clearing, on the grounds that the two strategies cost about the same. How should you evaluate this proposal?

   Right. In the game that’s Renown for your Context Management and Reliability building.

   Not that one: A is right. In the game your Context Management and Reliability building would lose a little Renown, and this question would come back later.

   The answerA.Clearing is cheaper: compaction bills for a summarization generation that has to read the history, and clearing drops those results server-side and generates nothing at all.A compaction pass reads the accumulated history and generates a summary, billed as ordinary input and output tokens and reported as its own entry in usage.iterations.Your answerB.Compaction is cheaper: compaction bills for a summarization generation that replaces the history once, and clearing bills the cleared history back as output on the next turn.Clearing is a server-side edit to the context the API assembles for the next request. It produces no tokens of its own, so there is no output charge to weigh against compaction's.Your answerC.Clearing is cheaper: compaction bills for a summarization generation that is charged at a premium long-context rate, and clearing is charged at the ordinary input rate.Both strategies are billed at the model's ordinary rates. What separates them on cost is that compaction runs an extra generation over the history and clearing does not.Your answerD.Compaction is cheaper: compaction bills for a summarization generation that is written to the cache, and clearing sends an uncached prefix on every request that follows.The compaction pass is billed as input and output tokens, and it appears as its own iteration in the usage report. Landing in a later cached prefix does not make the generation that produced it free.

   Show the full explanation and doc quotes

   Tool-result clearing deletes content server-side with no generation at all. When nothing in the results needs to be recalled, the summary buys nothing and clearing is the cheaper strategy.

   Written from platform.claude.com/docs/en/build-with-claude/compaction