[otavio]

Problem

Switching a long-running thread back to Claude ACP fails with "Insufficient context allowance for the provider handoff" (#22407). When an ACP turn ends, its idle state_update.usage.totalTokens counts the tokens spent across every model request in the turn. T3 saved that number as the context size and dropped the window size that usage_update had reported. The handoff check then used the 128k fallback window and computed a budget of zero.

Change

Only usage_update (used/size) sets context usage now. parseSessionUpdateEvent no longer turns idle state_update usage into a UsageUpdated event, and the adapter no longer sends that frame down the usage path. Idle state handling is unchanged.

Scope and approval

Fixes #22407. The issue includes a full diagnosis that traces the saved 1,303,139 back to the sum of two request totals. The fix only deletes the wrong mapping. Threads that already have the bad value saved stay blocked until a new usage_update replaces it.

Verification

• vp test run packages/provider-acp/src/server/runtimeModel.test.ts apps/server/src/orchestration-v2/Adapters/AcpRegistryAdapterV2.test.ts: 61 passed. The existing adapter test encoded the bug: its last snapshot was { usedTokens: 3_000 } with no window size. The test now ends on the usage_update snapshot, which keeps maxTokens.

• I drove @agentclientprotocol/claude-agent-acp@0.92.0 (the version in the report) directly over stdio, with one prompt that runs three sequential Read tool calls on Opus 5.5. These are the last frames it sent (the turn's usage comes in the prompt response, and T3's ACP client turns it into the idle state_update):

  usage_update  {"used":37347,"size":1000000,"cost":{"amount":0.3145576,"currency":"USD"}}
  prompt result {"stopReason":"end_turn","usage":{"inputTokens":8,"outputTokens":212,
                 "cachedReadTokens":57180,"cachedWriteTokens":37340,"totalTokens":94740}}
  

  totalTokens is 2.5× the real context size after just three requests. I fed those frames into the old and new parseSessionUpdateEvent, kept the last UsageUpdated snapshot the way the adapter does, and ran the real handoffBudget:

  before {"usedTokens":94740}                                                handoffBudget = 1256
  after  {"usedTokens":37347,"maxTokens":1000000,"cost":{...}}               handoffBudget = 64000
  

  One short turn already shrinks the budget to about 1k tokens, and the longer turns in the report reach 0. With the fix, the budget stays at the 64k cap.

Validation script

const W = "<worktree>/packages";
const { handoffBudget } = await import(`${W}/provider-core/src/server/handoffBudget.ts`);
const frames = [
  { sessionUpdate: "usage_update", used: 37347, size: 1000000, cost: { amount: 0.3145576, currency: "USD" } },
  { sessionUpdate: "state_update", state: "idle", stopReason: "end_turn",
    usage: { inputTokens: 8, outputTokens: 212, cachedReadTokens: 57180, cachedWriteTokens: 37340, totalTokens: 94740 } },
];
// zz-head-runtimeModel.ts is `git show HEAD:packages/provider-acp/src/server/runtimeModel.ts`
for (const [label, file] of [["before", "zz-head-runtimeModel.ts"], ["after", "runtimeModel.ts"]]) {
  const { parseSessionUpdateEvent } = await import(`${W}/provider-acp/src/server/${file}`);
  let contextUsage = null;
  for (const update of frames)
    for (const e of parseSessionUpdateEvent({ sessionId: "s", update }).events)
      if (e._tag === "UsageUpdated") contextUsage = e.usage;
  console.log(label, JSON.stringify(contextUsage), handoffBudget({ tokenCap: 200_000, userText: "hi",
    attachments: [], providerThread: { contextUsage }, nativeContextEstimate: 0 }));
}

I did not reproduce the full Codex → Claude ACP switch in a running app.

Made with Claude Opus 5.5 via Claude Code in T3 Code.

[macroscopeapp]

Approvability

Verdict: Approved at 65be69c

Macroscope's review found this PR approvable — This is a narrowly scoped ACP bug fix that prevents idle turn totals from overwriting the context-window usage used for provider handoffs, while preserving explicit usage updates and idle-state handling. The accompanying production and test changes are isolated and limited in scope.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: 52bb5c8
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: b055fde2-01f8-4fd1-8113-9fa530d11385

📥 Commits

Reviewing files that changed from the base of the PR and between 65be69c and 26bc67d.

📒 Files selected for processing: 1

• packages/provider-acp/src/server/adapter.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 8 remain after this review.

📝 Walkthrough

The ACP v2 adapter and runtime no longer use idle state_update notifications with usage data to update context usage or emit UsageUpdated events. Usage handling remains tied to usage_update. Tests now expect no idle-state usage event and two child-thread usage snapshots.

Changes: ACP usage handling

Layer / File(s)	Summary
Filter idle state usage updates packages/provider-acp/src/server/adapter.ts, packages/provider-acp/src/server/runtimeModel.ts, packages/provider-acp/src/server/runtimeModel.test.ts, apps/server/src/orchestration-v2/Adapters/AcpRegistryAdapterV2.test.ts	The adapter and runtime no longer treat idle state_update usage as a context-usage update or emit a UsageUpdated event from it. The tests expect no event for idle state updates and two child-thread usage snapshots.

Priority: ➖ Normal

Estimated code review effort: 2 (Simple) | ~8 minutes

Change: Bug fix · Severity of issue fixed: Medium

Suggested reviewers: juliusmarminge

Merge Risk: ⚪ Minimal · up to 26bc6

The change preserves context capacity updates while preventing turn-consumption totals from blocking provider handoffs.

Architecture risk: 🔵 Low · up to 65be6

The change affects 2 systems.

Changed systems: packages/provider-acp, apps/server

Architecture concerns
No architecture-level concerns identified.

Review details

Systems and components

• observed — packages/provider-acp (library) was modified; 3 changed files map to changed impact.
• observed — apps/server (service) was modified; 1 changed file maps to changed impact.

Before / after behavior

• observed — Modified behavior in apps/server/src/orchestration-v2/Adapters/AcpRegistryAdapterV2.test.ts: Removed the expected { usedTokens: 3_000 } context usage entry from the child-thread assertion.
• observed — Modified behavior in packages/provider-acp/src/server/adapter.ts: Removed handling of idle state_update notifications with embedded usage from the metadata-update branch.
• observed — Modified behavior in packages/provider-acp/src/server/adapter.ts: Made the metadata-update branch return unconditionally instead of conditionally checking for a state_update.
• observed — Modified behavior in packages/provider-acp/src/server/runtimeModel.test.ts: Changed the idle compaction test expectation from matching a UsageUpdated event with usedTokens: 420 to requiring an empty event list.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title clearly identifies the ACP fix and its effect on provider handoffs.
Description check		The description includes all required sections, explains the problem and change, references issue #22407, and provides focused test results plus limitations. It is sufficiently complete for this focus…
Linked Issues check		Issue #22407 requires that ACP context usage come from usage_update (used/size), and that turn-level consumption not overwrite context occupancy. The whole-PR adapter diff (merge base to head, package…
Out of Scope Changes check		The whole-PR adapter diff contains only the usage-path routing change for idle state_update. Its final return in the usage branch is equivalent for usage_update and session_info_update, which already …

Full details: Description check

Explanation

The description includes all required sections, explains the problem and change, references issue #22407, and provides focused test results plus limitations. It is sufficiently complete for this focused fix.

Full details: Linked Issues check

Explanation

Issue #22407 requires that ACP context usage come from usage_update (used/size), and that turn-level consumption not overwrite context occupancy. The whole-PR adapter diff (merge base to head, packages/provider-acp/src/server/adapter.ts) removes idle state_update with usage from the usage/metadata branch in handleSessionUpdate. Only usage_update and session_info_update now enter that branch. So an idle state_update no longer sets the saved context usage. The usage_update path is unchanged and keeps usedTokens, maxTokens, and cost. The runtimeModel.ts change (removal of the state_update to UsageUpdated mapping) is described in the PR description and the change summary, and the PR author reports a test that expects no event for idle state updates. The runtimeModel.ts whole-PR diff could not be read: the changed blobs were missing from the checkout, and the head file read was truncated before the parser section. That removal is therefore supported by the adapter diff and author evidence, not by a direct read of the parser change. The fix does not repair threads that already store the bad value; the PR states this, and the issue does not require repair of stored data.

Full details: Out of Scope Changes check

Explanation

The whole-PR adapter diff contains only the usage-path routing change for idle state_update. Its final return in the usage branch is equivalent for usage_update and session_info_update, which already returned before this change. The change summary lists further edits to runtimeModel.ts (removed state_update usage mapping), runtimeModel.test.ts (idle state updates now expect no event), and AcpRegistryAdapterV2.test.ts (obsolete third child-thread usage expectation removed, final snapshot keeps maxTokens). These edits support the same behavior change required by #22407. No unrelated source, schema, or workflow change appears in the reviewed evidence. The runtimeModel.ts diff was not directly readable, so this verdict relies on the change summary for that file.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

thanks to otavio for correctly separating turn spending from context occupancy and preserving the explicit usage window and cost.

replacement: https://git.cafe/pingdotgg/t3code/pulls/27927

github rejected the fork push with http 403 despite advertising maintainer edits, so this was rebuilt on current main. it carries your four-file fix unchanged and preserves author credit. i compared the original diff against the replacement: nothing dropped or moved.

verification: both regression assertions fail against main; all 68 focused tests pass with the fix. blacksmith vp run check:changed passes, including lint, 13-package typecheck, and 69 tests. captured-frame replay restores the handoff budget from 1,256 to 64,000. two independent reviewers found no issues. a fresh live provider switch through the client remains unverified. this original pr stays open.

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

Verified in a real dev environment

partial verification only. the acp token-accounting fix remains unverified because this vm has no authenticated claude account.

• read the diff, description and discussion. tested github/main at 15fe2832727893cbdd2214383f9f971474849695 in a separate worktree first, then the exact pr head 26bc67d3f489edfff7a84153f19a30dfdd254191. ran vp i in each checkout and only one background dev server at a time, with isolated state.

• drove the actual web app with the repo’s playwright and /usr/bin/google-chrome. created projects pointing at the real git repo, created threads and sent real codex gpt-6.1-sol turns through the local proxy. no mocks, fixtures, replay provider or database writes.

• configured the real claude-agent-acp 0.92.0 executable through settings. on both main and the pr, switching from codex to this acp instance and submitting a message reached the provider and failed with Authentication required.

• on the pr, switching back to codex completed successfully and recalled the earlier conversation marker: CODEX_RECOVERED_OK MAIN_ACP_OK. reloading the app retained the conversation and recovery response. the earlier MAIN_ACP_OK response visible before the handoff was also produced by codex, not claude.

• blacksmith: vp test run packages/provider-acp/src/server/runtimeModel.test.ts apps/server/src/orchestration-v2/Adapters/AcpRegistryAdapterV2.test.ts passed all 61 tests across both files. github reports 20 passing checks and 7 skipped checks on this head. no local tests or repo-wide checks were run.

read-only inspection of each dev database confirmed these persisted runs:

main: codex / gpt-6.1-sol                         completed
main: acpRegistry_claude_acp_verification / haiku  failed
pr:   codex / gpt-6.1-sol                         completed (two turns)
pr:   acpRegistry_claude_acp_verification / haiku  failed
pr:   codex / gpt-6.1-sol                         completed (recovery)

claude auth status: loggedIn=false, authMethod=none
pr ACP contextUsage: null
pr Codex contextUsage: usedTokens=23001, maxTokens=258400

main-side authentication blocker:

pr-side recovery after the same authentication blocker:

inspected the captures and checked uploaded video playback and seeking. no source changes or pushes.

Not verified

• the original insufficient-context failure on main, preservation of usage_update.used/size after a successful acp turn, and successful codex → claude acp → codex → claude acp handoff after substantial token spending. authentication fails before claude can produce usage, so there is no before/after proof of the changed behavior. green ci does not establish this.
• native desktop, ios/android, macos/windows and remote/relay/tunnel clients were not exercised on this linux vm.