Claude adds on-demand compaction for long-running agents

“Restart the worker after its queue drains.” Shorten that to “restart approved” and the topic survives while the permission changes. This hypothetical case is a useful way into conversation compaction: replacing older exchanges with a smaller record while keeping the conditions the next action needs.

Anthropic added on-demand compaction on September 14. The Claude API beta uses compact-2026-09-04 and the top-level compaction parameter to return a signed summary block. The application can put it before later messages in place of the history it summarizes.

For a workflow that can change shared state, follow the conditional approval through that replacement. Do the rejected options remain rejected? Does “after the queue drains” still govern the next proposed restart? A lower token count cannot answer those questions.

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.

Finding “restart” and “queue” in the summary is not enough. Inspect the proposal that follows: does the agent wait for one before doing the other? The relationship carries the permission.

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

The summary may finish while new evidence arrives. Record its cutoff and keep later exchanges when installing it, while retaining required original evidence under the data policy. Otherwise today’s correction can disappear during a successful compression of yesterday’s discussion.

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 a smaller working record whose next decision still makes sense, with a clear account of what was replaced. A later model release adds a new compatibility question to that same test.

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.

Suppose the worker conversation continues after a model response that includes a thinking block. The client carries that returned block forward with the conversation, then appends the next question about the queue. That is different from rewriting an earlier instruction or tool definition while replaying the old block: its preceding context has changed. Opus 5.5 checks that prefix. With mismatch behavior unset, ordinary requests on accounts created on or after August 31, 2026 can return a 400 error for the mismatch; older accounts can pass failing blocks through. Anthropic documents append-only updates and an explicit option to drop affected blocks. Dropping may keep the request running, but the model no longer has that block’s reasoning. A successful response alone does not show that the worker’s earlier context survived.

The on-demand guide adds another question for our restart condition. Suppose an instruction was introduced in a system message partway through the conversation, and that message is then replaced by the summary. Its instructions cease to apply when summarized; any still needed must be stated again through the documented message flow. Keeping the words “queue drains” somewhere in a readable summary is therefore not the same as retaining the governing instruction. This is a specific migration check, not a claim that every previous application was broken.

Replay the worker case after the migration. Is the queue-drain condition still in force, and will execution controls check it against current state? If either answer is no, the old workflow still has something important the new one lost. This documentation-based follow-up makes no hands-on Opus 5.5 claim; it supplies a test that distinguishes an accepted API request from a useful continuation of the work.

Back to the original report