Claude API: Compaction on Demand and the `auto` Permission Mode Change Your Agentic Loop Design

Anthropic shipped two operator-facing additions to the Claude API in the week of September 10–14 that affect how you design stateful agentic loops. Neither is a model upgrade. Both change the contracts your code holds with the API.

The first is compaction on demand — a new compact-2026-09-04 beta header that lets you request a conversation summary as a standalone background call, completely decoupled from the turn that the user is waiting on. The second is the auto permission mode in managed agents, which lets the server decide — call by call — whether a tool runs, gets denied, or pauses for your approval. If you have already adopted threshold compaction (compact-2026-01-12) or built agents with managed-agents-2026-04-01, these are the incremental changes that alter your operational posture the most.

Compaction on demand: the compact-2026-09-04 header

Threshold compaction, released earlier this year, automatically summarizes when input tokens hit a configured ceiling. The problem with threshold-based triggering is timing: the summary gets generated inside the same request that the user is waiting on, adding latency at exactly the moment the context window is most loaded.

Compaction on demand fixes this by making summarization a separate API call that returns only a compaction block — no assistant turn, no tool results, just the summary. You can fire it from a background worker while the conversation is idle. When the block arrives, you splice it into your message array, dropping everything before it. The next user turn goes out with the compacted context already in place.

The new header is compact-2026-09-04. You send a dedicated request with a compaction parameter (not context_management.edits) and get back a summary block. On subsequent turns, that block sits at the top of your messages array and the API drops all prior content automatically.

Supported models as of September 17: claude-fable-5-1, claude-mythos-5-1, claude-fable-5, claude-mythos-5, claude-mythos-preview, claude-opus-5, claude-opus-4-8, claude-opus-4-7, claude-opus-4-6, claude-sonnet-5, claude-sonnet-4-6. ZDR-eligible, excluding Covered Models. Available across Claude API, Claude Platform on AWS, Amazon Bedrock, Google Cloud, and Microsoft Foundry — all in beta.

Before and after: what changes in your message loop

With threshold compaction only, your loop looks like this:

# Every turn:
response = client.beta.messages.create(
    betas=["compact-2026-01-12"],
    model="claude-opus-5",
    messages=messages,
    context_management={"edits": [{"type": "compact_20260112"}]},
    max_tokens=4096,
)
messages.append({"role": "assistant", "content": response.content})
# If compaction fired, response.content contains a compaction block.
# The API handles dropping old messages on the NEXT request.

The compaction happens in-band. If the context was large, this turn is slower. Your user waits.

With compaction on demand (compact-2026-09-04), you can run summarization out-of-band:

# Background worker fires when conversation is idle or at a token checkpoint:
summary_response = client.beta.messages.create(
    betas=["compact-2026-09-04"],
    model="claude-opus-5",
    messages=messages,           # the conversation up to now
    compaction={"type": "compact_20260904"},
    max_tokens=4096,
)
compaction_block = summary_response.content[0]  # only the compaction block

# Swap into your message store:
messages = [{"role": "assistant", "content": [compaction_block]}]
# All prior messages dropped; next user turn goes out with compacted context.

The user's next request goes out with no added latency. If your sessions are long-lived — chat support, coding agents, document review — this is the shape change that matters. You get to choose the summarization checkpoint instead of having the API choose it for you.

One operational note: you are now responsible for triggering compaction at the right moment. Threshold compaction is self-managing; on-demand compaction is not. You need token counting (or a heuristic) to know when to fire the background job. If you miss the window and the context overflows, you do not get a fallback summary — you get a 400.

Permission auto mode: server-side trust evaluation for managed agents

The managed agents beta (managed-agents-2026-04-01) originally shipped with two permission modes: always_allow (execute without confirmation) and always_ask (pause, wait for your approval). The defaults are asymmetric: agent_toolset_20260401 defaults to always_allow, while MCP toolsets default to always_ask.

The new auto mode adds a third path. When you set permission_policy: {type: "auto"} on a toolset, the server evaluates each call individually and decides one of three outcomes: run it, deny it, or pause for your approval. You do not know which branch will fire for a given call — that is the point. Anthropic's server-side evaluation considers context it has that your code does not: whether the call looks anomalous, whether the target is in scope, whether the session has accumulated risk signals.

Setting it looks the same as the other modes:

{
  "type": "agent_toolset_20260401",
  "default_config": {
    "permission_policy": {"type": "auto"}
  }
}

Or per-tool, for more granular control than the toolset default.

Important operational constraint: running sessions keep the toolset configuration they were created with. If you change the policy on an existing agent, only new sessions pick it up. Sessions mid-flight continue under the old policy until they terminate.

The audit gap auto creates — and how to close it

With always_allow, your logs show every tool call and its result — your code decided to allow it, so you own the decision. With always_ask, you have an explicit approval event in the session stream — again, clear ownership. With auto, the server made the call. The approval or denial event will appear in the session's event stream, but the rationale — why the server allowed or denied — is not exposed in the current beta.

This matters for compliance teams and for debugging. If an agent gets a denial mid-task, your user sees the task fail without an operator-visible reason. You get an event type, not an explanation.

The practical mitigation right now: do not use auto as your only gate. Use it as a second layer on top of a narrowly scoped toolset. If you are running agent_toolset_20260401, restrict the tool set to what the agent genuinely needs before setting auto — the server's evaluation will be more predictable when the action space is small. Treat unexpected denials as a signal that the request looked anomalous from the server's perspective, and review the session context that preceded it.

For MCP toolsets specifically: the default of always_ask is already conservative. Switching to auto means you trade explicit approval events for server-evaluated flow — worth doing only if session latency from approval round-trips is the actual bottleneck.

What to update in your operator config

For compaction:

• If you want on-demand compaction, add compact-2026-09-04 to your beta header list alongside any existing compact-2026-01-12 usage. The two modes are opt-in independently.
• Build a token checkpoint into your session manager. The Anthropic SDK's token counting endpoint is the clean way to gate the background compaction call.
• On-demand compaction shares the same supported model list as threshold compaction. If the model you are routing to is not on that list, the call returns an error — worth checking before enabling.

For permission policies:

• Policy changes do not affect in-flight sessions. If you need to change behavior for active long-running agents, you will need to create a new agent and migrate sessions to it.
• The auto mode is not a replacement for always_ask on high-stakes toolsets. It is a middle ground suitable for lower-risk tools where the overhead of approval round-trips outweighs the need for explicit operator control on every call.
• MCP server operators in the managed agents environment should note that their default posture is always_ask. If a managed agent with auto permission calls your MCP server, calls may be silently denied server-side. Test this explicitly in staging.

Both features are in beta. API shapes may change before GA. Track compact-2026-09-04 and managed-agents-2026-04-01 separately — they are independent beta flags with independent deprecation timelines.