Re-check compaction after every agent step

[AshishKumar4]

The compaction check ran once, at the start of a turn. A turn whose tool results grew the prompt past the provider limit failed mid-turn with a context error; the user pressed retry, and only that second turn compacted. Robert hit this on Sol at roughly 512K tokens.

runAgent now owns the loop the Overseer used to run around it: load the durable history, run one pass, publish any checkpoint the pass produced, go again until a pass finishes. The Overseer's side is one await runAgent(...) plus two hooks, loadChatHistory and commitChatCompaction, which are the two private helpers it already had. A pass ends early either because it compacted instead of prompting the model, as before, or, new here, because a persisted tool step left the next request over the compaction trigger. That decision sits in shouldStopAfterTurn beside the other stop reasons: the step's measured prompt plus its tool results as the model will see them (not the details copy), or, when the provider reported no usage, a reload regardless so the turn-start estimator measures the whole prompt, the same rule that check already follows. Cancellation, connection requests and pending approvals still end the turn ahead of compaction.

The 30-step cap on a turn is gone. It came from the ai-sdk's stepCountIs(30) and was carried over when the loop moved to pi-agent-core; nothing else needed it.

GPT-5.6 Sol, Luna and Terra also gain a compactionInputBudget of 272K, the point past which OpenAI prices their input higher. Compaction sizes against that instead of the 1.05M window. The window and output limit are unchanged; getModelTokenLimits returns the smaller of the two as inputBudget, so nothing else moves.

Tests: the GPT-5.6 limits in agent-compaction.test.ts, plus the full backend suite and integration. The post-step decision is five lines over two functions the suite already covers (estimateProjectionTokens, shouldCompactChat); the scripted-model harness reports a fixed token count and has no summarizer, so an end-to-end test of it would mean building that, and the incident is the end-to-end check. Build and lint clean.

[github-actions]

Preview: pr493-agent-step-compaction

https://pr493-agent-step-compaction-router.cloudflare-os-previews.workers.dev

Dashboard · deleted when this PR closes

[devin-ai-integration]

Note

This report is out of date. Scroll down for Devin Review's latest report on this PR.

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.

[ask-bonk]

• P2 agent-compaction.ts:271: UTF-16 length divided by four severely undercounts CJK/high-density Unicode tool results. The next prompt can exceed the provider limit without triggering compaction, and retries repeat the same estimate. Use conservative or tokenizer-backed accounting.
• P3 agent.ts:3534: Reloading discards CodePreviewManager state. After a failed/no-op edit triggers compaction, the next non-edit tool cannot clear the client’s active-file marker, leaving stale editing UI until the agent stops.

github run

[AshishKumar4]

On the two Bonk points:

P2, chars/4 undercounting CJK: that is the estimator the turn-start check has always used; the post-step check adds the same estimate to the provider-measured total for the step, so the two checks agree and each step re-anchors on real usage. Not changing the estimator here. #494 caps what one result can contribute, which bounds the exposure.

P3, the active-file marker surviving a reload: real. runAgent now clears it before returning reloadForCompaction, the same thing a non-edit tool start does, so the rerun's fresh preview manager starts from the state the client sees.

[ask-bonk]

• P3 packages/workshop-shared/src/api.ts:1292: Exported SUGGESTED_MODELS no longer has a direct doc comment; the documentation now attaches to private SUGGESTED_MODEL_CATALOG. This violates the shared public API documentation requirement. Move or duplicate the JSDoc onto the export.

github run

[AshishKumar4]

The SUGGESTED_MODELS doc: moved onto the export, with the per-field docs on the entry type where they belong.

[ask-bonk]

LGTM!

github run

[ask-bonk]

• P2 packages/workshop-backend/src/agent.ts:3510: When provider usage is unavailable (totalTokens === 0), the post-step check counts only tool results and drops the existing estimated context. A large result can therefore push the next request over budget without triggering compaction. Maintain a running estimate for zero-usage steps and add coverage for this case.

github run

[ask-bonk]

LGTM!

github run

[AshishKumar4]

Bonk P2 (19:37) and Devin on the zero-usage case: both right, and I was wrong to remove it. The turn-start check at agent.ts:2619 already treats measuredTokens > 0 as the condition for trusting provider usage and estimates the whole prompt otherwise, so the post-step check dropping that rule made the two disagree. Restored.

While there, the decision moved out of its own exported helper and into shouldStopAfterTurn beside the other stop reasons, which is where it reads best; the helper's unit test went with it, for the reason in the PR body.

[ask-bonk]

LGTM!

github run

[devin-ai-integration]

Devin Review found 2 new potential issues.

[ask-bonk]

• P2 packages/workshop-backend/src/agent.ts:3550: A failed automatic compaction is retried after every subsequent tool step. Persistent summarization failures therefore add an expensive failed request and full replay per step. Latch the failure for the current runAgent() turn before reloading again.

github run