[Bug] OAuth subscription exhaustion can leave the TUI on Waiting instead of surfacing the quota error

[sankks11]

Summary

Affected area: provider error handling, automatic retry, and the interactive TUI.

When an OAuth-backed model subscription reaches its usage limit, Prime Agent can stay on Waiting without displaying the provider's quota error. In my reproductions, the request ended only after I aborted it. The durable session entry then contained Request was aborted, zero usage, and no indication that the account was out of quota.

I observed this with Anthropic OAuth in two independent Prime Agent sessions at the same time. I also replayed the Codex usage_limit_reached response against the installed 0.7.2 provider. That deterministic replay found another route to the same visible failure: Codex retries a terminal quota response and reads the nested stream error incorrectly.

The Anthropic stall and the explicit Codex error may require separate changes. The user-visible rule can be the same: a terminal subscription limit should end the request, display any reset information supplied by the provider, and clear Waiting.

Local Anthropic evidence

I recorded the following on:

• Prime Agent 0.7.2
• Linux aarch64 (6.17.0-1018-nvidia)
• Node.js 24.18.0
• Anthropic OAuth and OpenAI Codex OAuth, both configured through /login
• settings.json with no retry.provider or transport override

The timestamps below come from two local JSONL session journals. I intentionally omitted prompt text, tool output, paths, account data, request IDs, and full session IDs.

Session	Last model-input boundary	Manual abort	Elapsed with no completed response	Persisted assistant result
A	2026-08-13 21:01:35.525Z (user prompt)	21:12:15.144Z	10m 39.619s	aborted, Request was aborted, 0 tokens
B	2026-08-13 21:10:52.867Z (user prompt)	21:12:45.044Z	1m 52.177s	aborted, Request was aborted, 0 tokens
A	2026-08-14 04:38:12.189Z (tool result)	04:52:46.906Z	14m 34.717s	aborted, Request was aborted, 0 tokens
B	2026-08-14 04:38:28.138Z (tool result)	04:55:52.731Z	17m 24.593s	aborted, Request was aborted, 0 tokens

The first two rows ended within 30 seconds of each other. The second pair of rows were model continuations in two concurrent sessions using the same Anthropic OAuth subscription. I confirmed from the provider account state that the Anthropic subscription was exhausted at the time. Prime Agent's journals did not record a provider quota code.

Prime Agent did not persist a provider quota event or error in these journals. This sanitized assistant entry is the only terminal evidence:

{
  "role": "assistant",
  "provider": "anthropic",
  "usage": {
    "input": 0,
    "output": 0,
    "cacheRead": 0,
    "cacheWrite": 0,
    "totalTokens": 0
  },
  "stopReason": "aborted",
  "errorMessage": "Request was aborted"
}

The full session files contain private prompts and tool output, so I am not attaching them publicly. I can provide a narrower sanitized trace if a maintainer specifies which event fields would help.

Deterministic Codex replay

For a separate test, I replaced the installed provider transport with local mocks and sent the nested quota payload captured in #863:

{
  type: "error",
  status_code: 429,
  error: {
    type: "usage_limit_reached",
    message: "The usage limit has been reached",
    plan_type: "pro",
    resets_at: Math.floor(Date.now() / 1000) + 600
  }
}

Against the installed 0.7.2 code, the HTTP 429 path made four provider calls and spent about 7 seconds in internal backoff before returning You have hit your ChatGPT usage limit (pro plan). Try again in ~10 min. The WebSocket error event instead emitted Codex error: {"type":"error",...}, exposing the raw payload. The friendly quota message was absent.

This replay used no credentials or provider traffic, and it made no paid request. It confirms that the provider retries an explicit terminal quota response; after the error is emitted, AgentSession._isRetryableError also classifies it as retryable.

Reproduction

1. For the live Anthropic reproduction, authenticate with an Anthropic subscription through /login.
2. Reach the subscription's usage limit.
3. Send a prompt in Prime Agent.
4. On this Anthropic path, the TUI can remain on Waiting without a quota message.
5. Press Escape after waiting. The session journal records an aborted, zero-token assistant message with Request was aborted, without the provider limit or reset information.

The Codex path is the deterministic local-mock replay above. It covers the explicit-error variant without exhausting a real subscription.

Relevant code on current main

I checked current main at 97b994c3:

1. The Codex provider still hardcodes MAX_RETRIES = 3 instead of using the configured provider retry budget.
2. mapCodexEvents reads event.code and event.message. The real quota response puts those values under event.error.type and event.error.message, so this path falls back to JSON.stringify(event).
3. Codex and Anthropic both await an unbounded stream read in openai-codex-responses.ts and anthropic.ts. If the provider leaves the connection open without model data, no error reaches the session.
4. AgentSession._isRetryableError still retries errors by default unless they match one of a few exclusions. It has no exclusion for terminal quota errors.
5. The activity tracker starts assistant requests as waiting and keeps that state until model output arrives. In the TUI, a silent quota response or stalled stream therefore looks the same as healthy time-to-first-token.

Expected behavior

• Parse explicit quota payloads into a concise error. Include the plan and reset time when the provider supplies them.
• Treat terminal subscription or quota exhaustion as non-retryable in both the provider and AgentSession layers.
• Route any retry delay through the existing abortable, bounded retry policy. A multi-hour reset must not become an invisible provider sleep.
• Bound both the first-event wait and waits between events. When either bound expires, clear Waiting and display a transport or stall error.
• Persist a structured failure diagnostic so the session journal records why the turn stopped.

Prior reports and implementation attempts

This consolidates existing reports under the new discussion-first process; it is not a new discovery.

• #863 and unmerged #871 cover parsing nested Codex quota errors while preserving plan and reset information.
• #1232 and unmerged #1362 cover bounding silent provider streams with a stall timeout.
• Open #795 classifies quota exhaustion as terminal and stops automatic background work.
• #1180 covers surfacing Anthropic OAuth quota metadata before the next request stalls.
• Historical upstream Pi reports #4172 and #4551, plus merged retry fix #4991, cover quota parsing, hidden retries, and infinite spinning on a weekly limit.

Prime Agent items #863, #871, #1232, #1362, and #1180 were closed during the issue/PR queue cleanup and migration to Discussions, not because the current source paths were fixed. #795 is open.

Would maintainers prefer one focused issue for the user-visible rule, with separate implementation PRs for quota parsing and classification versus the stream timeout? Or should this first be split into provider-specific discussions? If invited, I can implement the requested scope with faux/mock-provider regressions.