Feature request: per-agent auto-compact window (separate boundaries for coordinator session vs subagents)
Feature request
Allow the auto-compact window to be scoped per agent role: one boundary for the main (coordinator) session and a different one for subagents dispatched via the Agent tool / custom agents.
Current behavior
The auto-compact window is a single session-wide value, resolved from CLAUDE_CODE_AUTO_COMPACT_WINDOW / --autocompact / /autocompact / the autoCompactWindow setting. Subagents inherit the session's resolved auto-compact configuration unconditionally:
- Agent definition frontmatter (
.claude/agents/*.md) supportsmodel,effort,maxTurns, tool lists, etc., but has no context/compaction field (autoCompactWindow,maxContextTokens, or similar). - There is no subagent-scoped env var or setting either; raising
CLAUDE_CODE_AUTO_COMPACT_WINDOWraises the boundary for the coordinator and every subagent in that session.
Problem
In orchestration workflows (a coordinator session dispatching many implementer/reviewer subagents), the coordinator accumulates context much faster than any individual subagent and needs more headroom, while subagents should stay on a tight budget so each task converges within one context window. Example desired configuration:
- coordinator (main session): compact at 400k
- subagents: compact at 200k
With autoCompactWindow: 200000, the coordinator compacts too early; with CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000, subagents lose their 200k ceiling and the budget can only be enforced indirectly (task sizing, maxTurns), not by the compactor.
Proposed solutions (any one would suffice)
- An
autoCompactWindow(orcontextWindow) field in agent frontmatter, per agent definition; or - A subagent-scoped setting/env var, e.g.
CLAUDE_CODE_SUBAGENT_AUTO_COMPACT_WINDOW(analogous toCLAUDE_CODE_SUBAGENT_MODEL); or - A structured setting, e.g.
"autoCompactWindow": {"main": 400000, "subagents": 200000}.
Environment
- Claude Code v2.1.250, macOS (arm64)
- Repro: set
autoCompactWindow: 200000(or the env var), run a coordinator session that dispatches subagents — both roles compact at the same boundary with no way to differentiate.
3 Comments
+1 i dont understand how this hasnt been thought off
Same need here, coming from the other direction.
I have a dispatcher session that runs on autopilot until it hits a goal I set.
It wants a small window, around 200k, because most of what it piles up is
per-cycle bookkeeping the next cycle doesn't need. The subagents are the
opposite. They do the heavy reading, so I want those on the full 1M.
So mine is main 200k, subagents 1M. That's the mirror of the 400k/200k in your
report. Opposite direction of yours, which I think argues for a real split
rather than just letting subagents be smaller than main.
The {"main": ..., "subagents": ...} object would work for me. The frontmatter
field is good on top of that for per-agent tuning, but the coarse split is the
part that actually solves the orchestration case.
One other thing and I'm not sure it belongs in this issue: the auto-compact
window is a threshold, not a ceiling. For a loop running unattended for hours
I'd rather declare a bound than a trigger point. That might be its own ask.
+1 with field measurements supporting this (from a delegated-coding-agent harness, 7 days of fleet data): 20 of 218 Agent-tool subagent spawns peaked above 350k tokens of context, top peaks 863k and 940k, the latter confirmed by its compact_boundary record (preTokens 940331, postTokens 22455). With auto-compact firing only near the model window, large-window subagents re-read hundreds of thousands of stale tool-result tokens at cache-read pricing on every call before any compaction happens. Composition of the over-200k cohort's model-visible content: about 40% Bash tool results, 26% the agent's own Edit/Write payloads, 23% Read results. Happy to share methodology. (I filed #90862 for the same need before finding this issue; closing it as a duplicate of this one.)