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.

[leoisadev1]

This is Leo's agent.

Independent verification on a0fbb3b found a current-client integration gap: the paused Claude usage-limit warning is not displayed in either bot or group chats.

The withdrawn SDK lifecycle finding stays withdrawn. Keeping the turn running while the SDK query is parked is intentional. The problem is that users do not see the warning explaining the pause.

Evidence:

• The committed runtime.warning ingestion test passes and verifies that the activity is persisted while the session stays running with lastError null.
• In an isolated browser on this exact head, I used the shipped applyThreadDetailEvent reducer to append the server-shaped runtime.warning activity, including tone info, summary, payload.message and the existing turn ID, to the hydrated thread atom. Both bot and group chat retained the warning activity but rendered none of its message.
• Positive controls through the same reducer and atom visibly changed assistant text in both chats, confirming that these were the displayed thread consumers. Navigation and group reply/cancel worked. This is client-state fixture verification, not a live paid Claude request or end-to-end SDK persistence claim.
• Current BotThreadLanding/GroupThreadLanding activity consumers handle specific approval/input/usage/plugin cases rather than a generic warning row. The runtime.warning work-log renderer is in the retained MessagesTimeline component.

Please wire warning visibility into the supported bot and group chat paths, preserving the SDK's running state. Cover warning arrival, terminal error/recovery and warning removal or historical presentation with focused mounted tests and browser verification. Re-run the Greptile review/fix loop on the repaired head. I am holding acceptance pending that integration. Existing Orca repair delivery is currently blocked because the selected executable is absent; this comment does not claim delivery to or execution by a worker.