A goal session accumulated enough history (a re-armed goal on an already-long session) to exceed Anthropic's input limit:
anthropic: prompt is too long: 205102 tokens > 200000 maximum (invalid_request_error, HTTP 400)
(session ses_01kx6423nef95t30vxgs36p80s, volume harness-dev-sessions-v2, 2026-07-10.)
Once a session's history crosses the cap, every subsequent turn fails identically — a deterministic 400, so the goal loop's retries burn out immediately and the session is permanently dead for prompting. There is no compaction, summarization, truncation, or even a distinct error surface; the operator finds out via a stalled goal whose error names a provider limit.
This is the natural failure mode of exactly the sessions harness is for (long-running goal work), and it interacts badly with the otherwise-good practice of re-arming a goal on an existing session to preserve context.
Suggested layers (independent, any subset helps):
- Distinct classification — the provider adapter should mark context-overflow as its own error kind so the goal loop can fail with a clear "context exhausted" reason instead of generic stall, and
last_turn.error names it.
- Preflight guard — the engine knows the request size; refusing/warning before the wire call (with usage surfaced on
GET /session) lets orchestrators rotate sessions proactively.
- Compaction primitive — a summarize-and-truncate operation (explicit API and/or automatic at a threshold) that folds old turns into a synthetic summary message, journals the compaction durably, and preserves the invariants LoadSession/ResolveOrphanToolCalls establish (no orphaned tool_use across the compaction boundary).
Context: both this session and its sibling were re-armed after the provider-overload stall (#61); the sibling (shorter history) completed fine — the overflow needed the combination of a long first attempt plus a resumed second.
A goal session accumulated enough history (a re-armed goal on an already-long session) to exceed Anthropic's input limit:
(session
ses_01kx6423nef95t30vxgs36p80s, volumeharness-dev-sessions-v2, 2026-07-10.)Once a session's history crosses the cap, every subsequent turn fails identically — a deterministic 400, so the goal loop's retries burn out immediately and the session is permanently dead for prompting. There is no compaction, summarization, truncation, or even a distinct error surface; the operator finds out via a stalled goal whose error names a provider limit.
This is the natural failure mode of exactly the sessions harness is for (long-running goal work), and it interacts badly with the otherwise-good practice of re-arming a goal on an existing session to preserve context.
Suggested layers (independent, any subset helps):
last_turn.errornames it.GET /session) lets orchestrators rotate sessions proactively.Context: both this session and its sibling were re-armed after the provider-overload stall (#61); the sibling (shorter history) completed fine — the overflow needed the combination of a long first attempt plus a resumed second.