Claude adds on-demand compaction for long-running agents

“Restart the worker after its queue drains” is a small instruction with an important hinge. Remove the queue-drain condition and the approval describes a different action. That is the kind of detail to follow when shortening an agent’s conversation: a summary can preserve the topic while changing the next decision.

Anthropic added on-demand conversation compaction on September 14. The Claude API beta uses the compact-2026-09-04 header and top-level compaction parameter to return a signed summary block. An application can put that block before subsequent messages, replacing the history it summarizes. This gives a long-running agent a smaller working record without requiring every old exchange to remain in active context.

The integration question is what survives that replacement. For a workflow that can change shared state, test whether conditional approvals and rejected options still constrain the next proposal after compaction. A shorter record is useful when it preserves the reasoning the next action depends on. Token reduction alone cannot establish that.

This does not require indefinite verbatim retention. Preserve the audit evidence required by the data policy and test decision-relevant meaning, rather than treating perfect recall of every message as the goal. The conditional restart provides a concrete way to examine the difference.

The application chooses when to summarize

The compaction overview distinguishes application-triggered summarization from compaction triggered inside a request at a token threshold. On-demand work can run in the background and leave recent exchanges verbatim. Preserved-thinking behavior is conditional, so the chosen model and platform’s compatibility still matters.

That creates a useful application choice. An incident assistant might request a summary when a bounded investigation finishes, with its evidence and open questions available for review together. This is a proposed use of the capability, not a built-in incident-management feature. It trades some integration work for control over when the conversation crosses from detailed history into a smaller account.

A summary can be readable and still change permission

In the hypothetical worker-restart case, suppose the summary keeps “restart approved” and omits the queue-drain requirement. The next response may now propose an immediate restart. An execution check of current queue state should reject that proposal. If the conversation held the only copy of the condition, however, the workflow has lost its independent way to notice what the summary changed.

A passing compaction test therefore needs to preserve both the drain condition and its relationship to the restart. Another useful case starts with a diagnosis that was later disproved. After shortening the record, the agent should still understand why that explanation was rejected, rather than promoting an old possibility into an established fact. Both cases test meaning at the point where losing it changes a decision.

The summary can guide a proposal without becoming the source of execution authority. Application controls still need to check the permitted operation and target, as explained in the operational agent skills guide. Keeping the condition in both places serves different purposes: the model can propose appropriate work, and the tool can refuse an inappropriate action even when the model fails.

Replacing history is itself a state change

Before automatic replacement, keep the original conversation under the applicable data policy and record exactly which messages the summary covers. Work may continue while summarization runs. Installing the result must preserve newer exchanges, or the application can lose fresh evidence while trying to compress older evidence. A recorded cutoff lets a reviewer locate either kind of loss.

A pilot can run the same investigation cases with compaction enabled and disabled, comparing completed investigations, missed constraints and total model usage. The summarization work belongs in that total. A smaller active context does not necessarily mean less computation across the complete task, a distinction developed in the AI token usage guide.

Failure handling follows from what replacement changes. If a usable summary never arrives, the existing history remains the basis for a defined pause or retry. If a critical condition disappears, the pilot should stop expanding while the summarization strategy is repaired. Restoring old messages may recover context, but it cannot undo an external action already taken under a mistaken proposal.

The useful result is thus more specific than a percentage reduction in history: the working record is smaller, the next decision remains supported, and the application can explain what was replaced. A later model release adds compatibility questions to this same test rather than removing the need for it.

September 22 follow-up: what the new model changes

The September 22 release notes announce Claude Opus 5.5, and its feature documentation confirms on-demand compaction support. That makes it another candidate for the conditional-approval test, with the intended platform and history-handling configuration recorded.

One migration detail concerns thinking-block replay. On accounts created from August 31, 2026, replaying an Opus 5.5 thinking block after earlier instructions, tools or messages change can produce a 400 error. Anthropic documents append-only conversation updates and an explicit option to drop affected blocks. Dropping a block may let a request succeed while changing the reasoning available to the model, so request success does not establish continuity.

The on-demand guide adds a separate instruction-lifetime issue: instructions in summarized mid-conversation system messages cease to apply when the summary replaces them. Instructions still needed must be stated again through the documented message flow. This is a specific migration check, not a conclusion that every previous application was broken.

Replaying the worker case now answers a precise question: does the queue-drain condition remain in force, and will the executor still enforce it against current state? If not, the existing workflow remains preferable until history handling is corrected. This follow-up is based on documentation, without a hands-on Opus 5.5 benchmark. Its payoff is a test that can distinguish a successful API request from a successful continuation of the task.

Back to the original report