Reset-derived 429 in an OpenAI combo blocks same-account fallback models #590

Client or integration

Codex App, using OpenCodex subagent routing through defined multi model combo in failover mode: combo/sub.

Area

Proxy and routing. The affected state is the shared Codex account-pool cooldown.

Summary

A 429 from the first OpenAI target in a failover combo is promoted to a hard cooldown for the entire Codex-login account. That prevents the combo from trying later fallback models that use the same account.

In my case, the first target was a Spark model with exhausted quota. The intended fallback path was Terra/Luna. The upstream availability is model-specific for this workflow, but the proxy stores the 429 as account-wide reset-derived state. Subsequent Terra/Luna attempts return a local 429 before reaching upstream.

I expected the failover combo to try the later models, or for a reset-only 429 to remain a short, probeable target/model-level avoidance rather than blocking the account.

Reproduction

1. Configure the canonical openai provider with Codex-login pool mode and the main account.
2. Configure a failover combo for subagents whose first target is a quota-limited Spark model and whose later targets are Terra/Luna under the same openai provider.
3. Send a subagent request through combo/sub after the Spark target begins returning 429 responses with Codex reset headers but no explicit Retry-After.
4. Observe the first 429 set account health to reset-derived.
5. Observe later same-account fallback attempts return OpenCodex's local Selected Codex account (main) is cooling down 429 instead of reaching Terra/Luna.
6. Run ocx account clear-cooldown openai main or restart the proxy. The later models work again.

The issue is especially easy to trigger when multi-agent work sends several same-account OpenAI requests concurrently.

Version

@bitkyc08/opencodex 2.7.41

Operating system

macOS 26.4.1

Provider and model

Canonical OpenAI Codex-login provider in pool mode. A failover combo was ordered Spark → Terra/Luna; all targets used the same openai account.

Logs or error output

2026-07-28T02:44:33.645Z: originating combo 429

Selected Codex account (main) is cooling down until 2026-07-28T02:59:33.645Z (source: reset-derived).
Run 'ocx account list openai' to find the id, then 'ocx account clear-cooldown openai <id>' to lift it, or switch accounts with 'ocx account use openai <id>'.

The deadline is exactly 15 minutes after the originating failure, matching the reset-derived cooldown cap. During that interval, later same-account fallback requests fail locally. Restarting works because account-health state is process-local.

Screenshots and supporting files

The request-log and error-detail screenshots show interleaved successful and 429 OpenAI attempts during the multi-agent burst, followed by the combo/sub error above. They can be supplied if maintainers need them.

Redacted configuration

{
  "providers": {
    "openai": {
      "adapter": "openai-responses",
      "baseUrl": "https://chatgpt.com/backend-api/codex",
      "authMode": "forward",
      "codexAccountMode": "pool"
    }
  },
  "combos": {
    "sub": {
      "strategy": "failover",
      "targets": [
        { "provider": "openai", "model": "Spark target" },
        { "provider": "openai", "model": "Terra target" },
        { "provider": "openai", "model": "Luna target" }
      ]
    }
  }
}

Additional implementation context

The combo child enters the normal Responses pipeline, whose canonical OpenAI target records the 429 against the shared account. The #433 recovery path only permits one probe after five minutes; ordinary 200 responses preserve the existing hard cooldown. This leaves a substantial window where same-account combo fallback cannot occur.

Related: #433.

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.