OpenAI SDK retries sleep full Retry-After (days) and Escape cannot abort

[catoncat]

Summary

When retry.provider.maxRetries > 0, pi-ai passes that value into the OpenAI/Anthropic SDK maxRetries option. Those SDKs:

1. treat every HTTP 429 as retryable
2. sleep the full Retry-After with no delay cap
3. use a plain setTimeout sleep that ignores AbortSignal

So a usage-limit 429 with a multi-day Retry-After freezes the agent on working, and Escape cannot interrupt.

This is separate from the provider actually being out of quota: the provider correctly returns 429, but Pi's handling makes the failure look like a hang.

Reproduction

Provider evidence (OpenCode Go)

curl -sS -D - \
  -H "Authorization: Bearer $OPENCODE_GO_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"model":"kimi-k3","messages":[{"role":"user","content":"hi"}],"max_tokens":8}' \
  https://opencode.ai/zen/go/v1/chat/completions

Observed:

HTTP/2 429
retry-after: 277403

{
  "type": "error",
  "error": {
    "type": "GoUsageLimitError",
    "message": "Monthly usage limit reached. Resets in 3 days. ..."
  }
}

With the OpenAI client (maxRetries: 0) this fails in ~800ms.
With maxRetries: 2 (as configured via Pi settings) the client starts sleeping ~3 days.

Pi evidence

pi --provider opencode-go --model kimi-k3 --no-session --no-tools -p "hi"

• process opens HTTPS to OpenCode
• UI / non-interactive run stays in working with no output
• Escape / abort does not end the wait while the SDK is in sleep(retry-after)

Root settings that re-enable the hole (defaults are safer):

{
  "retry": {
    "provider": {
      "maxRetries": 2,
      "maxRetryDelayMs": 60000
    }
  }
}

maxRetryDelayMs is not applied on the openai-completions path; only some custom transports (e.g. Codex) cap delays.

Why Escape fails

OpenAI SDK:

// openai/internal/utils/sleep.mjs
export const sleep = (ms) => new Promise((resolve) => setTimeout(resolve, ms));

// openai/client.mjs retryRequest
timeoutMillis = timeoutSeconds * 1000; // full Retry-After, no cap
await sleep(timeoutMillis);

Pi Escape calls agent.abort() → AbortSignal, but the SDK retry sleep does not listen to it.

Expected

1. Usage-limit / multi-day Retry-After should surface as a normal error immediately (or within agent-level abortable backoff).
2. Escape must be able to cancel provider waits.
3. retry.provider.maxRetryDelayMs must actually bound provider waits, or SDK retries must stay disabled.

Related

• fix(ai): disable hidden provider 429 retries #4991 disabled default SDK retries (maxRetries ?? 0) but still forwarded explicit options.maxRetries from coding-agent settings, which reopens this hole when users set retry.provider.maxRetries > 0.
• Docs already warn to keep provider maxRetries at 0, but a mis-set value currently freezes the session instead of failing closed.

Suggested fix

Always force OpenAI/Anthropic SDK maxRetries: 0. Keep abortable agent-level retry, which already classifies terminal quota/billing/usage-limit errors as non-retryable.

PR incoming.

[github-actions]

This issue was auto-closed. All issues from new contributors are auto-closed by default.

Maintainers review auto-closed issues daily and reopen worthwhile ones. Issues that do not meet the quality bar in CONTRIBUTING.md will not be reopened or receive a reply.

If a maintainer replies lgtmi on one of your issues, your future issues will stay open. If a maintainer replies lgtm, your future issues and PRs will stay open.

See CONTRIBUTING.md.

[catoncat]

Follow-up in my own words:

I hit this while using opencode-go/kimi-k3. Provider returned 429 GoUsageLimitError with retry-after ~3 days. With retry.provider.maxRetries=2, pi forwarded that into the OpenAI SDK, which sleeps the full Retry-After and ignores abort, so the UI stuck on working and Esc did nothing.

I can implement the fix (force SDK maxRetries=0; agent-level retry already handles this correctly). Please reopen if this looks worth fixing. Happy to wait for lgtm before any PR work.

(AI helped with investigation; this comment is mine.)

[petrroll]

Listening on abort signall makes perfect sense to fix, but for the rest, wouldn't it be better to cap retry after & maybe provide user-visible error if what comes from the SDK is larger than X?

Rather than force shut all retries? Especially if a user explicitly sets it.

EDIT:
It seems the other part is already beeing done (as per the merged PR you linked by mitsuhiko), i.e. 1 and 3 in your expectations, do these not work as expected?:

• it enforces a 60 second upper bound for retry-after which is what other systems also do
• it sniffs the error messaage and tries to detect out of usage 429s and does not retry them

[badlogic]

we obky fix the abort signal. @petrroll want to send a PR?

[petrroll]

Happy to today evening :)

My laptop is back