fix(claude): recover from "Prompt is too long" & "Autocompact is thrashing" when auto-compaction fails (#1841)

[konard]

Summary

Fixes #1841. A headless solve run filled Claude Code's 200K-token context window. Claude Code's built-in auto-compaction triggered (system status: compacting) but failed (compact_result: failed, compact_error: too_few_groups — one ~125K-token turn dominated the window), so the prompt could never be reduced. The next API call returned the synthetic Prompt is too long (error: invalid_request, terminal_reason: blocking_limit) and the process exited 1 with no recovery.

This PR also handles a second, closely-related dead-end in the same subsystem (requested in PR review): Autocompact is thrashing (terminal_reason: rapid_refill_breaker) — emitted when a large file read or tool output keeps refilling the context within a few turns of each compaction, tripping Claude Code's rapid-refill breaker after 3 rapid refills in a row.

Root cause for both is on the Claude Code side — a well-documented upstream limitation (anthropics/claude-code#46348 and duplicates). On hive-mind's side the failures were simply unhandled exit-1s. This PR adds prevention (a per-turn output cap so a single turn can't dominate the compaction window) + detection of both modes + fresh-session recovery + verbose compaction tracing + auto-commit on all errors.

Before / after

	Before this PR	After this PR
Prompt is too long (compaction too_few_groups)	Unhandled → process exits 1, run lost	Detected → fresh-session restart (auto-commit first), capped at maxContextLimitRestarts
Autocompact is thrashing (rapid_refill_breaker)	Unhandled → process exits 1, run lost	Detected (message or terminal_reason) → same fresh-session recovery
Single turn dominating the window	CLAUDE_CODE_MAX_OUTPUT_TOKENS up to 128K → one un-splittable group → too_few_groups	getClaudeEnv caps per-turn output at floor(window × 0.45) → ≥2 groups always fit → too_few_groups prevented
Auto-commit on crash (uncaughtException / unhandledRejection)	Ran cleanup only — uncommitted work could be lost	Runs the interrupt (auto-commit + push) before cleanup, so work is preserved on every error class
Compaction-lifecycle visibility	Silent — no trace of why the run died	Verbose tracing (🗜️ compacting, ⚠️ compaction FAILED, 📏 Detected …, 📏 Capped per-turn output …)
Backward compatibility	—	Fully preserved: every change is additive/gated by existing defaults; the 150k --sub-session-size default is unchanged; compacting earlier stays opt-in

The failure mechanisms

too_few_groups → Prompt is too long:

context window (200000) fills up
        │
        ▼
system status: "compacting"        ← Claude Code auto-compaction (on by default)
        │
        ▼
compact_result: "failed"           ← compaction FAILS …
compact_error: "too_few_groups"    ← … one ~125K-token turn dominates the window
        │
        ▼
assistant "<synthetic>": "Prompt is too long"   (error: "invalid_request")
        │
        ▼
result is_error:true, terminal_reason:"blocking_limit"  →  exit 1

rapid_refill_breaker → Autocompact is thrashing:

system status: "compacting"        ← compaction SUCCEEDS …
        │
        ▼
context refills to limit within ≤3 turns (large file read / tool output) … ×3
        │
        ▼
assistant "<synthetic>": "Autocompact is thrashing: … use /clear to start fresh."
        │
        ▼
result is_error:true, terminal_reason:"rapid_refill_breaker"  →  exit 1

The breaker is gated behind tengu_auto_compact_rapid_refill_breaker; the "3 turns / 3 times" figures are hard-coded constants (nc6=3, t08=3) in the v2.1.158 binary, with no env/CLI override.

Can we configure compaction to prevent this? (PR review question — verified locally)

"Can we make the threshold smaller or limit the compaction output to reduce the summary prompt?"

Yes for too_few_groups — but lowering the threshold does not fix it; bounding per-turn output does. Verified against the installed binary (Claude Code v2.1.158, strings/constants read directly):

• CLAUDE_CODE_AUTO_COMPACT_WINDOW (threshold) → effective window is min(modelWindow, max(1e5, min(value, 1e6))) (clamp constants cc6=1e5, hL4=1e6). The failing run already had this at 150000 (via --sub-session-size) and still failed.
• too_few_groups is not about when compaction triggers — it's about whether the transcript splits into ≥2 groups. One ~125K-token turn (allowed by CLAUDE_CODE_MAX_OUTPUT_TOKENS=128000) is a single un-splittable group; triggering earlier doesn't add groups.
• The lever that works is CLAUDE_CODE_MAX_OUTPUT_TOKENS — bounding the largest single turn.
• Compaction is env-only — there are NO compaction-related CLI flags in claude --help (v2.1.158). Checked per PR feedback ("check not only for ENVs, but also CLI options"). rapid_refill_breaker thrashing is input-driven, so the output cap does not prevent it — reading large files in smaller chunks does; recovery (fresh session) is the safety net.

getClaudeEnv now caps CLAUDE_CODE_MAX_OUTPUT_TOKENS at floor(window × 0.45) (fraction < 0.5 guarantees cap × 2 < window, i.e. ≥2 groups always fit), with a 32K floor:

window 150000, Opus 4.8: requested 128000 → capped floor(150000 × 0.45) = 67500
  → 67500 × 2 = 135000 < 150000  → ≥2 groups always fit → no too_few_groups

Configurable: HIVE_MIND_MAX_OUTPUT_COMPACTION_FRACTION (default 0.45; 0 disables) and HIVE_MIND_MIN_OUTPUT_TOKENS (default 32000). Full write-up in docs/case-studies/issue-1841/README.md (§0 before/after, §4.1 compaction-config verification, §4.2 backward compatibility & "compact earlier").

What changed

Area	Change
src/config.lib.mjs	Prevention (#1841): computeCompactionSafeOutputCap + knobs, applied in getClaudeEnv to cap CLAUDE_CODE_MAX_OUTPUT_TOKENS at floor(window × 0.45) (32K floor) so one turn can't dominate the compaction window. Also retryLimits.maxContextLimitRestarts (default 1, env HIVE_MIND_MAX_CONTEXT_LIMIT_RESTARTS) — bounds restarts so a fresh session that also overflows can't loop expensively.
src/tool-retry.lib.mjs	classifyRetryableError now flags Prompt is too long / input is too long and Autocompact is thrashing / rapid_refill_breaker with { requiresFreshSession: true, isContextLimit: true }. Centralized, so every tool that uses the classifier benefits (R6).
src/claude.context-limit-recovery.lib.mjs (new)	createContextLimitRecovery — discards the session and restarts fresh (resuming would replay the same over-long transcript forever in headless mode), after auto-committing uncommitted work. Stateful restart cap. Header documents both failure modes.
src/claude.lib.mjs	Recovery wired into both the streamed-result and thrown-exception paths, for both Prompt is too long and Autocompact is thrashing (detected via message or terminal_reason). Thinking-block recovery (#1834) guarded with !isContextLimit so the two recoveries don't collide. Added verbose auto-compaction lifecycle tracing (🗜️ compacting, ⚠️ compaction FAILED (compact_error: …), 📏 Detected "Prompt is too long" / 📏 Detected "Autocompact is thrashing" diagnostics, and 📏 Capped per-turn output …).
src/exit-handler.lib.mjs	uncaughtException / unhandledRejection handlers now run the interrupt (auto-commit + push) before cleanup, latched so it runs once — previously they ran cleanup only and could lose uncommitted work. Guarantees "auto-commit on all errors" (PR feedback).
docs/case-studies/issue-1841/	Deep case study (§0 before/after summary, timeline, event-flow, requirements checklist incl. PR-feedback items, root-cause analysis, §4.1 compaction-config verification vs the v2.1.158 binary, §4.2 backward-compat & compact-earlier, existing-library survey), raw logs/data, research sources, and a reproducible upstream-report draft covering both failure modes (R3).
tests/test-issue-1841-context-limit-recovery.mjs	39 assertions: classification of both error classes, no false-positives / routing separation from thinking-block recovery, restart-cap config, fresh-restart-only behavior incl. auto-commit-before-restart, and the per-turn output-cap math + getClaudeEnv integration.

Why fresh-restart-only (not resume-first)

Unlike the thinking-block recovery (#1834), resuming is futile here: in headless mode the on-disk transcript only grows, so resuming replays the same oversized prompt and the error repeats forever. The only thing that makes progress is a fresh session (equivalent to /clear, which the thrashing message itself recommends), which re-reads the issue/PR/branch state and continues from the already-committed work — hence auto-commit happens before each restart.

Auto-commit on all errors (PR feedback)

Recovery preserves work (commit + push) before each restart, gated by criticalErrorRecovery.autoCommitUncommittedChanges (on by default, HIVE_MIND_AUTO_COMMIT_ON_CRITICAL_ERROR). The existing failure-exit path already auto-committed; this PR closes the remaining gap so the uncaughtException / unhandledRejection crash handlers also auto-commit before cleanup. Work is now never lost on any error class.

Backward compatibility (PR feedback)

Every change is additive and gated by existing defaults. The 150k --sub-session-size default is unchanged, so existing runs behave identically; "compact a bit earlier" stays opt-in via --sub-session-size / CLAUDE_CODE_AUTO_COMPACT_WINDOW rather than changing the default (verified in §4.2). The output cap only lowers an over-large CLAUDE_CODE_MAX_OUTPUT_TOKENS and can be disabled (HIVE_MIND_MAX_OUTPUT_COMPACTION_FRACTION=0).

Upstream report (R1/R5)

Root cause is on Claude Code's side for both modes. It is already reported multiple times upstream (anthropics/claude-code#46348, #23751, #26317, #25620, #24976), so a new issue would duplicate. A self-contained, reproducible report draft covering both failure modes is kept at docs/case-studies/issue-1841/upstream-report.md in case a maintainer asks for a fresh repro.

Reproduce / verify

claude --version                                        # 2.1.158 (Claude Code)
node tests/test-issue-1841-context-limit-recovery.mjs   # 39/39 pass
node scripts/run-tests.mjs --suite default              # 224/224 files pass

Requirements checklist

• R1 — Root cause found (Claude Code side, both modes); documented + upstream issues referenced. Prevention added (per-turn output cap) so too_few_groups is avoided where possible, not just recovered from.
• R2 — Auto-commit uncommitted changes on this error and on all errors by default (crash handlers now auto-commit before cleanup).
• R3 — All logs/data downloaded + deep case study under docs/case-studies/issue-1841/ (incl. §0 before/after, §4.1 compaction-config verification, §4.2 backward-compat).
• R4 — Verbose compaction-lifecycle tracing added to capture it next time.
• R5 — Upstream report drafted for both modes (not filed; would duplicate existing reports).
• R6 — Fix centralized in classifyRetryableError + getClaudeEnv, so it applies across the codebase.
• R7 — Everything in the single existing PR fix(claude): recover from "Prompt is too long" & "Autocompact is thrashing" when auto-compaction fails (#1841) #1842.
• Second failure mode (Autocompact is thrashing / rapid_refill_breaker) handled + reported.
• CLI options checked in addition to ENVs (compaction is env-only; no CLI flags in v2.1.158).
• Backward compatibility preserved (defaults unchanged; earlier compaction opt-in).

[konard]

Working session summary

All work is complete. Here is the final summary.

Issue #1841 — Prompt is too long? — Resolved

PR #1842 is now ready for review with all CI checks passing:
#1842

Root cause

A headless solve run filled Claude Code's 200K-token context window. Claude Code's built-in auto-compaction triggered (system status: compacting) but failed (compact_result: failed, compact_error: too_few_groups — one ~125K-token turn dominated the window). The prompt could never be reduced, so the next API call returned the synthetic Prompt is too long (error: invalid_request, terminal_reason: blocking_limit), exiting 1 with no recovery. The root cause is on Claude Code's side — a documented upstream limitation (anthropics/claude-code#46348 and duplicates).

The fix (applied codebase-wide)

• src/tool-retry.lib.mjs — classifyRetryableError flags Prompt is too long / input is too long with { requiresFreshSession: true, isContextLimit: true }. Centralized, so every tool benefits.
• src/claude.context-limit-recovery.lib.mjs (new) — createContextLimitRecovery discards the session and restarts fresh (resuming would replay the same over-long transcript forever), auto-committing work first. Bounded by maxContextLimitRestarts (default 1).
• src/claude.lib.mjs — wired into both the result and exception paths; thinking-block recovery (API Error: 400 messages.1.content.19: thinking or redacted_thinking blocks in the latest assistant message cannot be modified. These blocks must remain as they were in the original response. #1834) guarded with !isContextLimit so the two don't collide. Added verbose auto-compaction lifecycle tracing.
• src/config.lib.mjs — HIVE_MIND_MAX_CONTEXT_LIMIT_RESTARTS env override.

Requirements addressed

• R1 Root cause found + upstream report drafted (docs/case-studies/issue-1841/upstream-report.md); not filed because it would duplicate #46348 and others.
• R2 Auto-commit before each restart (on by default).
• R3 All logs/data + deep case study under docs/case-studies/issue-1841/.
• R4 Verbose compaction-lifecycle tracing for next time.
• R6 Fix centralized in the shared classifier.
• R7 All in the single existing PR fix(claude): recover from "Prompt is too long" & "Autocompact is thrashing" when auto-compaction fails (#1841) #1842.

Verification

• New test: tests/test-issue-1841-context-limit-recovery.mjs — 22/22 pass.
• Full suite: 224/224 test files pass.
• All CI checks green (lint, test-execution, test-suites, validate-docs, changesets, line-limits, memory-check).
• Working tree clean; main merged into the branch.

---

This summary was automatically extracted from the AI working session output.

[konard]

🤖 Solution Draft Log

This log file contains the complete execution trace of the AI solution draft process.

💰 Cost: $8.449472

📊 Context and tokens usage:

Claude Opus 4.8: (3 sub-sessions)

1. 115.0K / 1M (11%) input tokens, 17.1K / 128K (13%) output tokens
2. 111.5K / 1M (11%) input tokens, 32.8K / 128K (26%) output tokens
3. 73.2K / 1M (7%) input tokens, 11.0K / 128K (9%) output tokens

Total: (43.2K new + 340.8K cache writes + 8.3M cache reads) input tokens, 75.6K output tokens, $8.397241 cost

Claude Haiku 4.5:

• 26.1K / 200K (13%) input tokens, 1.2K / 64K (2%) output tokens

Total: 26.1K input tokens, 1.2K output tokens, $0.052232 cost

🤖 Models used:

• Tool: Anthropic Claude Code
• Requested: opus
• Main model: Claude Opus 4.8 (claude-opus-4-8)
• Additional models:
  • Claude Haiku 4.5 (claude-haiku-4-5-20251001)

📎 Log file uploaded as Gist (4227KB)

• View complete solution draft log

---

Now working session is ended, feel free to review and add any feedback on the solution draft.

[konard]

✅ Ready to merge

This pull request is now ready to be merged:

• All CI checks have passed
• No merge conflicts
• No pending changes

---

Monitored by hive-mind with --auto-restart-until-mergeable flag

[konard]

As I know it is possible to configure compactification in Claude Code, can we make the threshold smaller or limit the compactification output to actually reduce the size of summary prompt?

Double check all the docs of Claude Code on the topic, and check it locally.

[konard]

🤖 AI Work Session Started

Starting automated work session at 2026-05-30T00:06:59.883Z

The PR has been converted to draft mode while work is in progress.

This comment marks the beginning of an AI work session. Please wait for the session to finish, and provide your feedback.

[konard]

As I know it is possible to configure compactification in Claude Code, can we make the threshold smaller or limit the compactification output to actually reduce the size of summary prompt? Double check all the docs of Claude Code on the topic, and check it locally.

Great question — I dug into both the docs and the installed binary (Claude Code v2.1.157) and the answer is nuanced. Yes, we can configure it — but making the threshold smaller does not fix this failure; limiting per-turn output does. I've now implemented the latter. Full write-up: docs/case-studies/issue-1841/README.md §4.1.

The three knobs (verified against the v2.1.157 binary)

Env var	Controls	What I verified
CLAUDE_CODE_AUTO_COMPACT_WINDOW	compaction threshold	Effective window = min(modelWindow, max(100000, value)) — clamped min 1e5, max 1e6, capped to the model window. UI text: "The actual threshold is the minimum of this setting and your model's maximum context window."
CLAUDE_AUTOCOMPACT_PCT_OVERRIDE	trigger percentage	Parsed as a float; lower-only. Upstream #25867 reports it does not reliably prevent the failure.
CLAUDE_CODE_MAX_OUTPUT_TOKENS	max tokens a single turn may emit	Standard Anthropic var. This is the knob that prevents too_few_groups.

Why lowering the threshold alone can't work

The failing run already had the threshold lowered: CLAUDE_CODE_AUTO_COMPACT_WINDOW=150000 is in its env (we set it via --sub-session-size, default 150k). It still failed — because too_few_groups is not about when compaction triggers, it's about whether the transcript can be split into ≥2 summarizable groups. The final turn alone was 125,310 output tokens (allowed by CLAUDE_CODE_MAX_OUTPUT_TOKENS=128000 for Opus 4.8). One ~125K-token turn inside a 150K window is a single un-splittable group. Triggering compaction earlier doesn't add groups — the oversized turn is still indivisible.

The fix (this is what "limit the compaction output" means in practice)

getClaudeEnv now caps CLAUDE_CODE_MAX_OUTPUT_TOKENS at floor(window × 0.45) — fraction < 0.5 guarantees at least two groups always fit (cap × 2 < window), with a 32K floor so long answers stay possible:

window = 150000, model = Opus 4.8
requested CLAUDE_CODE_MAX_OUTPUT_TOKENS = 128000   ← produced the 125K failing turn
capped    CLAUDE_CODE_MAX_OUTPUT_TOKENS = floor(150000 × 0.45) = 67500
           67500 × 2 = 135000 < 150000  → ≥2 groups always fit → no too_few_groups

Configurable / escapable:

• HIVE_MIND_MAX_OUTPUT_COMPACTION_FRACTION (default 0.45; set 0 to disable the cap)
• HIVE_MIND_MIN_OUTPUT_TOKENS (default 32000, the hard floor)

This is defense-in-depth: the cap prevents the failure; the existing fresh-session recovery still catches it if it ever occurs anyway.

Verified locally

$ claude --version
2.1.157 (Claude Code)
$ node tests/test-issue-1841-context-limit-recovery.mjs   # 33 passed, 0 failed
  ✅ Caps Opus 4.8 output (128000) to floor(150000 * 0.45) = 67500
  ✅ Capped output leaves room for >=2 groups in the window (cap*2 < window)
  ✅ getClaudeEnv lowers CLAUDE_CODE_MAX_OUTPUT_TOKENS for Opus 4.8 with a 150k window

Commits: 3b537cde (the cap + tests + docs) and f48c9326 (changeset).

[konard]

🤖 Solution Draft Log

This log file contains the complete execution trace of the AI solution draft process.

💰 Cost: $8.413749

📊 Context and tokens usage:

Claude Opus 4.8: (2 sub-sessions)

1. 116.6K / 1M (12%) input tokens, 40.4K / 128K (32%) output tokens
2. 106.4K / 1M (11%) input tokens, 33.4K / 128K (26%) output tokens

Total: (14.7K new + 276.2K cache writes + 9.1M cache reads) input tokens, 81.9K output tokens, $8.413749 cost

🤖 Models used:

• Tool: Anthropic Claude Code
• Requested: opus
• Model: Claude Opus 4.8 (claude-opus-4-8)

📎 Log file uploaded as Gist (3956KB)

• View complete solution draft log

---

Now working session is ended, feel free to review and add any feedback on the solution draft.

[konard]

✅ Ready to merge

This pull request is now ready to be merged:

• All CI checks have passed
• No merge conflicts
• No pending changes

---

Monitored by hive-mind with --auto-restart-until-mergeable flag

[konard]

Looks like we have similar issue at 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. that should be reported as well. And we need to handle it also. Update the analysis. Recheck every statement for it to be verified and correct.

https://gist.githubusercontent.com/konard/dfda1530492ec2033ad249dcb45efba3/raw/691382f8dd05d0a6aee404629a56f354cbfacd03/solution-draft-log-pr-1780139614800.txt

Also I want to clearly see what was changed in this pull request with before and after summary.

And check not only for ENVs, but also CLI options on Claude Code. And we need to make sure that for all errors we do auto-commit of uncommitted changes.

We need to make sure by fixing this pull request, we don't break anything existing, so the backward compatibility will be preserved, yet, we might want to make compaction a bit earlier.

[konard]

🤖 AI Work Session Started

Starting automated work session at 2026-05-30T11:30:45.859Z

The PR has been converted to draft mode while work is in progress.

This comment marks the beginning of an AI work session. Please wait for the session to finish, and provide your feedback.

[konard]

Working session summary

The background CI watcher confirms it: {"conclusion":"success","failed":[]} — the full run completed successfully with zero failed jobs.

Everything is finalized. PR #1842 is ready for review with all CI green, working tree clean, and all six feedback items from the user's comment addressed. No further action needed.

---

This summary was automatically extracted from the AI working session output.

[konard]

🤖 Solution Draft Log

This log file contains the complete execution trace of the AI solution draft process.

💰 Cost: $11.013480

📊 Context and tokens usage:

Claude Opus 4.8: (3 sub-sessions)

1. 114.0K / 1M (11%) input tokens, 23.6K / 128K (18%) output tokens
2. 116.4K / 1M (12%) input tokens, 33.9K / 128K (26%) output tokens
3. 89.6K / 1M (9%) input tokens, 32.1K / 128K (25%) output tokens

Total: (31.2K new + 341.9K cache writes + 12.3M cache reads) input tokens, 102.9K output tokens, $11.013481 cost

🤖 Models used:

• Tool: Anthropic Claude Code
• Requested: opus
• Model: Claude Opus 4.8 (claude-opus-4-8)

📎 Log file uploaded as Gist (5749KB)

• View complete solution draft log

---

Now working session is ended, feel free to review and add any feedback on the solution draft.

[konard]

✅ Ready to merge

This pull request is now ready to be merged:

• All CI checks have passed
• No merge conflicts
• No pending changes

---

Monitored by hive-mind with --auto-restart-until-mergeable flag

[konard]

Double check https://gist.githubusercontent.com/konard/dfda1530492ec2033ad249dcb45efba3/raw/691382f8dd05d0a6aee404629a56f354cbfacd03/solution-draft-log-pr-1780139614800.txt is included to analysis.

Re-read again #1842 (comment)

We need to ensure all changes are correct, consistent, validated, tested, documented, logged and fully meet each and all discussed requirements in deepest and widest possible sense (check issue description and all comments in issue and in pull request, make sure each and every requirement listed before actually checking if they were addressed). Nothing should be defered or delayed. The scope is the entire repository, every change in one place should also be applied in all places in the codebase and docs. Ensure all CI/CD checks pass.