Compaction can fail or skip silently, leaving huge context

[yxlyx]

Summary

There are sessions where the agent appears to fail to compact context before continuing, causing tiny follow-up turns to fail while still carrying very large context. In one Forge log, compaction triggers and appears to complete, but token accounting immediately jumps to 7,667,872 tokens and triggers compaction again with no clear successful completion nearby.

Evidence

Forge compaction/token-count anomaly

File: .forge/logs/forge.log.2026-06-15

Around lines 294-305:

• Token count was 47872
• Compaction triggered by hook
• Created context compaction summary
• Offloaded full tool results to disk during compaction, count 23
• Usage then reports:
  • conversation_id=13e50235-18b0-45ba-82df-e8984217b777
  • token_usage=45543
  • total_tokens=45864
  • cached_tokens=44544
• Immediately after, local token count becomes 7667872
• Compaction triggers again
• No obvious second successful compaction record appears nearby

Session/conversation ID:

13e50235-18b0-45ba-82df-e8984217b777

High-context failed follow-up turns

File: codegraff/harness.trajectory.jsonl

Relevant entries:

• line 34: successful turn, context_tokens=125629
• line 35: tiny follow-up did u create an issue and pr for this, ok, still context_tokens=123142
• line 36: tiny follow-up yes for 1, failed, still context_tokens=123142
• line 38: successful long turn, context_tokens=214803
• line 39: follow-up failed immediately, context_tokens=214803
• line 47: later parent turn reached context_tokens=238981

This suggests context remained huge across turns instead of being compacted before the next request, or that compaction failed/skipped silently.

Expected behavior

• When context approaches the threshold, the agent should compact reliably before the next turn.
• After compaction succeeds, active context/token count should decrease substantially.
• If compaction fails, the error should be logged clearly.
• If a provider returns a context-window error, the system should compact and retry or show a clear actionable error.

Actual behavior

• Compaction appears to trigger but context/token count remains huge or becomes nonsensical.
• Tiny follow-up turns can fail with no tools executed while context remains above 100k/200k tokens.
• The logs do not clearly show whether compaction succeeded, failed, or was skipped.
• In one case, token count jumped to 7667872 immediately after compaction.

Suspected areas

Likely areas to inspect:

• codegraff/src/main.zig
  • compactAt
  • last_context_tokens
  • compact()
  • provider usage parsing / context_tokens
  • compaction empty-summary/failure handling
• Compare with devswarm/src/codex_appserver.zig, which appears to have more explicit context-window retry/compaction handling.

Potential root causes:

• Token usage is missing/stale/misparsed, so compaction does not trigger correctly.
• Compaction fails or returns an empty summary but history remains unchanged.
• Compaction only happens after successful turns, so provider context-window failures are not recovered.
• Token accounting may explode after compaction, as shown by 7667872.
• Subagent/workflow output may return too much context to parent sessions without pruning.

Search/reproduction helpers

sed -n '288,310p' .forge/logs/forge.log.2026-06-15

grep -RniE 'compact|compaction|compressed|compression|history compacted|compaction failed|empty summary|nothing to compact' \
  .forge codegraff lawbook canvaspilot 2>/dev/null

grep -RniE '"context_tokens":[0-9]{6,}' \
  */harness.trajectory.jsonl */harness.trace.jsonl harness.trace.jsonl 2>/dev/null

grep -RniE '"ok":false|"is_error":true|ContextWindowExceeded|context window|too many tokens|maximum context' \
  .forge */harness.trajectory.jsonl */harness.trace.jsonl harness.trace.jsonl 2>/dev/null