Autocompact thrashing error with a small autoCompactWindow: counter is per model response, message blames files/tool output, subagents are killed

Summary

With a per-model autoCompactWindow of 100,000, the session (and every subagent) hits "Autocompact is thrashing" after only a few tool calls, even when no large file or tool output is involved. The message blames "a file being read or a tool output", but in this setup the likely cause is that the window left after fixed context (system prompt, tool definitions, instruction files, memory index) is tiny, and the "within 3 turns" counter counts model responses in the tool loop rather than user turns. Subagents are killed by the same error while doing trivial one-command tasks.

This may be considered "working as designed", but the message, the counter and the lack of any guard make it very hard to diagnose.

Environment

• Claude Code 2.1.295 (also seen on 2.1.293)
• Android / Termux (arm64), running the official native build through a third-party launcher. I have not reproduced this on a stock desktop platform, but the logic described below lives in the shipped bundle, not in the launcher.
• Models: Claude Haiku 5.5 and Claude Sonnet 5.5 (both affected, so it is not model specific)
• Settings: autoCompactWindow: 100000 saved per model (via /autocompact / modelSettings), autoCompactEnabled: true
• Instruction files auto-loaded every session: about 50 KB of project instructions plus about 20 KB of memory index at the time (a rough estimate of 25-30k tokens before the first message; I have since trimmed both, so I cannot give a measured number)

What happens

1. Work normally for a short while, or start a subagent with a trivial task (one shell command).
2. A compaction runs, the context refills to the threshold within a few tool calls, and after three of these in a row the session stops with this error (shown in the terminal):

Autocompact is thrashing: the context refilled to the limit within 3 turns of the previous compact, 3 times in a row. A file being read or a tool output is likely too large for the context window. Try reading in smaller chunks, or use /clear to start fresh.

1. Subagents terminate with the same message wrapped in an API error (the parent only sees the failure notification below). They never read a large file; they only start with the same fixed context.

Agent "<task description>" failed: Agent terminated early due to an API error: Autocompact is thrashing: the context refilled to the limit within 3 turns of the previous compact, 3 times in a row. A file being read or a tool output is likely too large for the context window. Try reading in smaller chunks, or use /clear to start fresh. (error type invalid_request)

The subagent had only been asked to run one shell command (a commit / push / PR creation). In at least one case the command itself had already completed before the error killed the agent, so the parent could not tell whether the work had been done.

Why (from reading the 2.1.293 bundle; please correct me if I misread it)

• With an explicit window the proactive threshold is window - min(maxOutputTokens, 20000) - 13000, i.e. 67,000 tokens at window = 100000. After a compaction the fixed context plus the summary already uses a large part of that, so only a few tool calls fit before the next compaction.
• The reactive path is skipped when an explicit window is below 200,000, so only this proactive path is active.
• The circuit breaker increments its counter when a compaction happens while turnCounter < 3 and trips at 3 consecutive hits. turnCounter appears to be incremented once per model response in the agent loop (not once per user message), so three quick tool calls count as "3 turns".
• Result: with a small window and a normal-sized fixed context the breaker trips by design, and the error text points the user at the wrong cause.

Additional observation I cannot explain

I also saw the same error on Haiku 5.5 with the window left at auto. I do not know the cause of that case.

Expected / suggestions

• Warn or refuse when the configured window is not comfortably larger than fixed context + reserved output (or show the current fixed-context size in /autocompact).
• Make the error say what actually refilled the context (instruction files / memory / tool definitions / small window), not only "a file or tool output".
• Count user turns or the tokens added since the last compaction instead of model responses.
• Do not kill subagents for this; fall back to a plain summary or fail with an actionable message.

Related

#85489 (warning blames a file or tool output when the refill came from re-injected project instructions), #98158 (subagent crashes with the same error), #72857, #96379, #82131