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

[thomaswillner]

Independent corroboration from a third route, which I think narrows the cause usefully.

I hit the same user-visible failure on a path that shares neither of your two variables: no OAuth, no TUI. Mine is a plain API-key 429 from a custom OpenAI-compatible provider (api: openai-completions, local proxy), in non-interactive -p batch mode, on 0.7.2 / macOS arm64. Details in #1474.

What that eliminates

Your point 5 — the activity tracker holding waiting until model output arrives — is a convincing explanation for why the TUI looks healthy. But my run has no TUI at all, and it still never terminates. So the display layer cannot be the cause of the stall itself; it only determines how the stall is presented. That leaves your points 3 and 4 (the unbounded stream read, and _isRetryableError defaulting to retry) as the load-bearing ones, and it extends the blast radius past the two providers you examined: Anthropic OAuth, Codex, and a generic OpenAI-compatible provider all reach it.

A documented guarantee that did not hold

This is the part I find most actionable. packages/coding-agent/docs/settings.md (line 147) states:

When a provider requests a retry delay longer than retry.provider.maxRetryDelayMs (e.g., Google's "quota will reset after 5h"), the request fails immediately with an informative error instead of waiting silently.

packages/ai/src/types.ts (126–133) repeats it in the type contract, and buildSimpleOptions forwards maxRetryDelayMs generically to providers.

My case is that documented example, only more extreme: maxRetryDelayMs was 30000, and the advertised reset was ~102 hours — over four orders of magnitude above the cap. The documented outcome is "fails immediately with an informative error". The observed outcome was zero output and no exit, killed externally at 240s, with the daemon log ending at:

Supervisor command prompt_and_wait failed: Error: Daemon worker client closed

Control: the same invocation with --provider/--model pointed at a healthy route exited 0 immediately, so this is isolated to the dead route.

Hypothesis, explicitly not verified: the cap is only consulted when a 429 is returned and the SDK is deciding whether to sleep on the server-requested delay. If the failure instead manifests as the stalled stream you describe in point 3, the cap is never reached and the documented fail-fast path is unreachable. That would make one fix — bounding the stream wait — restore the documented behavior for all three provider paths. I have not traced the enforcement site, so I would not want that treated as more than a hypothesis worth a maintainer's five minutes.

One requirement your "Expected behavior" list does not yet cover

Your list is written for an interactive session: clear Waiting, display the error, persist a diagnostic. All correct. For headless and autonomous use the bar is higher:

• A non-zero exit code and a structured error on stderr. Unattended, "clear Waiting" has no meaning and there is nobody to press Escape. Note that every one of your four evidence rows ends in a manual abort — that escape hatch does not exist in -p, in cron, or under --autonomous.
• A hang is strictly worse than an error here: it consumes the entire wall-clock budget and produces nothing to branch on, so supervising wrappers cannot distinguish "still working" from "dead route" and cannot fail over.

I would suggest adding that to the user-visible rule, since it is the same fix with a different terminal surface, and it is the difference between a degraded run and a lost one.

On your scoping question

Nobody has answered it, so for whatever an outside data point is worth: one focused issue for the user-visible rule reads better than provider-specific splits, precisely because the rule is provider-independent — three different provider paths, one symptom. The provider-specific work (nested Codex quota parsing, Anthropic OAuth metadata) is then implementation detail under it, and the stream-bound fix is the one that likely covers routes nobody has reported yet, including mine.

Happy to re-run any proposed fix against the 429-with-long-reset route, or to supply a sanitized batch-mode trace if a maintainer names the fields that would help. I am not asking for a PR invitation here — flagging the extra route because it changes what the fix has to cover.

[thomaswillner]

Correcting my own hypothesis above, and replacing it with a measurement.

I guessed the cap was unreachable because a stalled stream preempts it. That is wrong. The 429 is returned promptly, the SDK does decide what to do with it, and it sleeps anyway — because nothing compares the server-requested delay to maxRetryDelayMs at all.

What I measured

1. The cap is declared, plumbed, defaulted, documented — and never consumed. On current main, a repository-wide search for maxRetryDelayMs returns 10 files: types.ts (declaration), simple-options.ts and proxy.ts (forwarding), sdk.ts and settings-manager.ts (defaulting to 60000 and migrating the old retry.maxDelayMs), side-question.ts, agent.ts, both CHANGELOGs, and settings.md. No provider implementation appears in that list — not anthropic.ts, not openai-completions.ts, not openai-codex-responses.ts.

Independently, in the shipped 0.7.2 dist/bundle the token occurs 22 times and none of them is a comparison — every site is an assignment or a forward. Two independent artifacts, same conclusion.

2. What actually happens instead. Both vendored Stainless SDKs — anthropic-6NOSCFKS.js, and chunk-ENTVCTJV.js, which is the OpenAI SDK required by openai-completions-7BADVXTD.js — carry identical logic:

const retryAfterHeader = responseHeaders?.get("retry-after");
if (retryAfterHeader && !timeoutMillis) {
  const timeoutSeconds = parseFloat(retryAfterHeader);
  if (!Number.isNaN(timeoutSeconds)) timeoutMillis = timeoutSeconds * 1e3;
}
...
await sleep(timeoutMillis);
return this.makeRequest(options, retriesRemaining - 1, requestLogID);

await sleep(timeoutMillis) with no bound, at maxRetries ?? 2.

3. The number. My proxy returns, on the cooled model, measured today:

HTTP/1.1 429 Too Many Requests
Retry-After: 153971

Seconds. So sleep(153_971_000) — 42.8 hours, potentially twice. During the original incident the advertised reset was ~102h47m, i.e. ~4.28 days. That is the entire failure: not a stalled stream, not a dead daemon. The process is deliberately asleep inside the SDK, below every layer the agent owns. The daemon's Daemon worker client closed is the echo of my external kill, not a cause.

This also explains why raising retry.provider.maxRetryDelayMs from 30000 to 60000 changed nothing.

What this does not change

It does not touch your Anthropic OAuth evidence. In that path no 429 with a Retry-After is returned at all — the connection simply stays open, which is your point 3, and remains a genuinely separate mechanism. Two distinct causes converging on one symptom. If anything it sharpens your "route any retry delay through the existing abortable, bounded retry policy": there is currently no bounded policy on this path to route through, so that item is not a hardening, it is the missing implementation.

Provenance

packages/ai/CHANGELOG.md 0.50.8 (2026-02-01) introduced the option, citing badlogic/pi-mono#1123, with the trigger example "e.g., Google Gemini CLI" requesting a long delay. Whatever consumed it then, no provider in this repository consumes it now.

I inspected the installed 0.7.2 bundle plus current main via code search; I have not run a debugger against a live 429, so the sleep is inferred from the code path and the header value rather than observed in a stack trace. Happy to be told I am reading the wrong call path.