findCutPoint silently keeps the whole window when a turn's tool results exceed keepRecentTokens, so compaction becomes a no-op

[Jiaaqiliu]

Environment. prime-agent 0.7.3, main at f8f0036, Node 22.17.0, macOS 15 (darwin 25.5.0).

Summary

When one turn's trailing tool results alone exceed keepRecentTokens, findCutPoint silently falls back to the oldest cut point in the window, which means keep everything. prepareCompaction then finds nothing to summarize and returns undefined, and the user is told the session is too short to compact while the context is above 95%.

Two tool calls in a single turn are enough to reach it.

Root cause

core/compaction/compaction.ts:378:

let cutIndex = cutPoints[0]; // Default: keep from first message (not header)

for (let i = endIndex - 1; i >= startIndex; i--) {
    ...
    if (accumulatedTokens >= keepRecentTokens) {
        for (let c = 0; c < cutPoints.length; c++) {
            if (cutPoints[c] >= i) { cutIndex = cutPoints[c]; break; }
        }
        break;
    }
}

findValidCutPoints (:282) deliberately excludes toolResult entries, so there is never a cut point after the last assistant message. Threshold compaction is triggered at exactly that boundary, where the branch tail is [assistant(toolCalls), toolResult, toolResult, ...]. If the backwards scan crosses keepRecentTokens while still inside those results, no cutPoints[c] >= i exists, the inner loop completes without assigning, and cutIndex keeps its cutPoints[0] initializer.

The threshold is easy to reach: keepRecentTokens defaults to 20000 (:113), estimateTokens is chars/4, and bash output is capped at 50KB per call (tools/truncate.ts:12), i.e. about 12800 estimated tokens each.

Reproduction

Against the exported function, with DEFAULT_COMPACTION_SETTINGS:

const entries = [
  userMessage("turn 1"),
  assistantMessage("a1"),
  userMessage("turn 2"),
  assistantWithToolCall("running two commands", "tc1"),
  toolResult("tc1", 60 * 1024),
  toolResult("tc1", 60 * 1024),
];
findCutPoint(entries, 0, entries.length, 20000);
// { firstKeptEntryIndex: 0, turnStartIndex: -1, isSplitTurn: false }   <- keep everything

Observed behaviour

prepareCompaction (:614) computes historyEnd = 0, so messagesToSummarize is empty and it returns undefined. _performCompaction then throws CompactionSkippedError, and the user sees:

Auto-compaction skipped: Session is too short to compact - try again once it grows

while /usage shows the context near full. It repeats every turn. When the real provider overflow arrives, _checkCompaction runs _runAutoCompaction("overflow", true), which reaches the same prepareCompaction and skips again, so _overflowRecovery advances to "reported" and the session ends with "Context overflow recovery failed after one compact-and-retry attempt." /compact cannot rescue it either, since it funnels through the same code.

There is a quieter second manifestation: once a previousSummary exists, the messagesToSummarize.length === 0 guard no longer returns undefined, so compaction "succeeds" with a firstKeptEntryId that retains the whole window. tokensBefore is unchanged and shouldCompact is still true next turn, which is an unbounded loop of summarization calls that free nothing.

Suggested fix

Fall back to the newest cut point rather than the oldest. Keeping only the last turn is the correct degenerate result when that turn's tail alone exceeds the budget, and the existing split-turn machinery already summarizes the prefix. With the change the example above returns { firstKeptEntryIndex: 3, turnStartIndex: 2, isSplitTurn: true }.

---

I have a fix with a regression test on a branch: fix/compaction-cutpoint-fallback. npm run check passes and the surrounding suites still pass. I opened it as a PR first and the contribution gate closed it, which is what CONTRIBUTING.md says should happen, so I am bringing it here instead. Happy to leave it as is, adjust it, or drop it entirely if you would rather fix this differently.

[sankks11]

I confirmed a real-world recurrence of the quiet second manifestation described here in a daemon-backed openai-codex/gpt-5.6-sol session.

Sanitized journal evidence:

• Version: Prime Agent v0.8.1 was installed during the affected session, with the persisted update/restart marker at 18:28 UTC. The no-progress compaction loop continued on v0.8.1 until the session was archived. The journal does not record the exact pre-update release, so I cannot verify whether the earlier portion ran on v0.8.0 or an older version.
• 77 consecutive automatic compactions over about 3 hours 23 minutes kept the same retained boundary. tokensBefore grew from 255,822 to 279,231 instead of falling.
• The configured model window was 272,000. The maximum compaction input was 302,043, and the maximum provider-reported assistant usage was 291,906.
• The session had an active thread goal. After IPython remained stuck on a previously interrupted cell, 858 goal continuations amplified the failure. There were also 45 direct child admissions; they increased resource pressure, but their transcripts did not enter the root context.
• Threshold compaction later recorded 12 summarization or turn-prefix summarization WebSocket error failures before the session was archived and replaced.

This was not only an uncapped footer percentage. Compaction repeatedly recorded success without advancing the retained boundary or reducing context. Current main at bc0fa7606 still contains the fallback described above. PR #1549 appears to be the focused fix and was closed by the contribution gate rather than for a technical problem.

I think we should land @Jiaaqiliu's fix while preserving authorship, then add a post-compaction progress invariant and regression coverage: a successful compaction must advance the retained boundary or reduce the estimated context. Otherwise Prime should stop automatic retries and surface an actionable terminal error instead of continuing indefinitely.

I am not attaching the raw journal because it contains private prompts and environment details.