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

This change improves Claude runtime-limit feedback by recording recovery events and clearing active warning banners once processing resumes. It also refines Claude turn accounting, terminal-outcome messaging, runtime-warning ingestion, and related provider documentation.

Confidence Score: 5/5

Safe to merge.

No outstanding blocking issues remain. The previously raised rejected-rate-limit lifecycle concern was explicitly withdrawn by greptile-apps[bot] after the SDK’s parked-query behavior was clarified. The previously reported stale runtime-warning behavior is fully fixed: recovery now emits a keyed resolved warning and the warning selector suppresses the resolved warning for the active turn.

Files Needing Attention: None.

_{Reviews (3): Last reviewed commit: "fix(claude): clear recovered usage warni..." | Re-trigger Greptile}

[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.

[leoisadev1]

This is Leo's agent.

I verified the new warning banner in the actual bot and group chats on 3119ab1, including desktop/narrow widths, completed/interrupted removal and surrounding reply/navigation behavior. The original missing-warning defect is addressed. All 119 focused tests pass.

The new same-turn recovery finding is valid by independent source tracing: ClaudeAdapter.ts clears rejectedRateLimitTypes on allowed/allowed_warning/overage recovery and emits account.rate-limits.updated, but emits no thread activity that supersedes the persisted warning. activeThreadRuntimeWarning scans only persisted runtime.warning for the still-running turn. It therefore continues to present the pause message after recovery. The reviewer calls this non-blocking; I retain it as a repair requirement because the new status needs a correct way out while the same turn continues.

Please add a typed recovery/clear signal consumed by the current bot and group warning selector, and deterministic committed coverage for rejected -> allowed in the same running turn, overlapping blocked windows, and re-blocking after recovery. Clear only the recovered condition, preserve unrelated warnings, and keep terminal/new-turn suppression. Verify the banner disappears without ending the SDK query or Akeru turn. Do not reinstate the withdrawn request to force a terminal state on rejection. Rerun focused tests and fresh PRGL.

This comment is not verified Orca delivery or executed repair; the authorized Orca executable remains unavailable.

[leoisadev1]

This is Leo's agent.

The keyed recovery signal on 696c0eb addresses the first rejected -> allowed case, but the requested re-blocking case still fails in the shipped adapter. I extended the new committed recovery test in a private scratch copy: emit rejected five_hour/reset R, allowed five_hour/reset R, then rejected five_hour/reset R again in the same turn. Collect through a queued terminal result so the test observes the complete ordered event sequence without sleeps. Expected three runtime.warning events: blocked, resolved, blocked. Actual two: blocked, resolved. The deterministic assertion fails in the 26ms suite; production source is unchanged in this reproduction.

Cause: announcedUsageLimits.keys retains the original limitKey after recovery, so the repeated rejection is suppressed even though rejectedRateLimitTypes becomes blocked again. The client has already consumed the resolved marker, so it stays without a warning while Claude is blocked again.

Please re-arm warning emission when a recovered window becomes blocked again, while preserving duplicate suppression during one uninterrupted blocked episode and independence of overlapping windows. Add this actual adapter regression as a committed test, including a second window remaining blocked while the first recovers/re-blocks. Keep the newly added typed recovery signal and avoid ending the SDK query. Rerun focused tests and PRGL. Orca remains unavailable; this comment is evidence, not verified worker delivery.