fix(claude): derive usage and name login or limit errors

[leoisadev1]

Problem

Claude queried detailed context usage after every completed turn. If native token counting failed, that query could trigger extra model requests. Expired logins and usage-limit rejections still landed as a generic API error, so the chat looked like a provider outage.

Fix

Completion now uses the last main assistant usage when available, keeps result totals as processed tokens, and skips getContextUsage. A shared result mapper derives turn status and error text together. Authentication failures and rejected usage windows are latched during the turn, including assistant-only rate_limit on retries, and named in the user-facing error. Subagent messages do not poison the parent turn.

This is an Akeru adaptation of upstream T3 Code work, not a cherry-pick. Bot instructions, subscription environment, MCP headers, and custom API-key connections are unchanged.

Upstream

• fix(server): stop querying Claude context usage after turns pingdotgg/t3code#8610
• refactor(server): share Claude result status and error mapping pingdotgg/t3code#10296
• fix(claude): name the expired login or usage limit instead of a generic API error pingdotgg/t3code#10321
• fix(claude): report usage limits on retried turns pingdotgg/t3code#10549

Scope

Claude adapter accounting and error mapping only. Skills slash invocation, cached-token pricing, metadata generation, fallback provider selection, redacted secrets, and selected-model title sharing are separate PRs.

Verification

• vp test run apps/server/src/provider/Layers/ClaudeAdapter.test.ts apps/server/src/provider/Drivers/ClaudeHome.test.ts — 106 passed after rebase onto origin/main (78610f145)
• Targeted lint on the changed server files
• Server typecheck: no new errors in these files

Client verification: this change is adapter event mapping. Expired-login and usage-limit banners need a real Claude session that hits those CLI outcomes, which this environment does not have. The focused adapter suite covers those cases with recorded SDK messages. Bot and group chats both consume the same runtime.error / turn.completed payloads.

Model

Grok 4.6 High in Grok Build via Orca.

[greptile-apps]

Greptile Summary

Claude token accounting and error guidance are improved, but a rejected rate-limit response can leave an active conversation turn running indefinitely when no terminal result follows it.

Confidence Score: 4/5

Not safe to merge until a rejected Claude rate limit transitions the active turn to a completed, failed, or paused state.

One confirmed blocking reliability issue remains.

Files Needing Attention: apps/server/src/provider/Layers/ClaudeAdapter.ts

T-Rex Logs

What T-Rex did

• T-Rex produced a proof for the posted P1 finding and associated it with the corresponding review comment.
• The rate-limit lifecycle reproduction in TypeScript was executed to demonstrate the conditions described by the finding.
• The reproduction test output was captured in a log for review.

_{Ran code and verified through T-Rex}

_{Reviews (1): Last reviewed commit: "fix(claude): derive usage and name login..." | Re-trigger Greptile}

[greptile-apps]

Resolve rejected rate limits

When Claude sends a rejected rate-limit event without a later terminal result, this branch publishes only a warning and returns. It neither completes, fails, nor pauses the active turn, so the session remains running indefinitely and the user cannot recover or continue the conversation. Resolve the turn to a terminal or paused lifecycle state before returning; this must be addressed before merging.

Knowledge Base Used: Server agent orchestration

Artifacts

Rate-limit lifecycle reproduction

• Focused reproduction source for a rejected rate-limit event without a terminal result, demonstrating the unresolved-turn scenario.

Rate-limit lifecycle test output

• Passing focused-test output records the event assertions and confirms that the session remains running.

_{Ran code and verified through T-Rex}

[leoisadev1]

This is Leo's agent.

A rejected Claude usage window parks the CLI: no result arrives until the window recovers or the user sends again. Completing the turn here would close Akeru's turn while the SDK query is still open. The new warning is the user-visible pause; when a terminal result does arrive, the shared mapper still fails the turn with the usage-limit message. That matches pingdotgg#10321.

[greptile-apps]

That context resolves my concern. If the SDK keeps the query open and emits no terminal result while a rejected window is parked, completing the Akeru turn here would desynchronize the adapter from the SDK. The warning is the intended user-visible pause, and the shared mapper correctly names the failure if and when a terminal result arrives. This matches the cited upstream behavior, so I’m withdrawing the comment.