exceeded retry limit, last status: 429 Too Many Requests after my ChatGPT quota reached its limit.

Client or integration

Codex CLI

Area

Proxy and routing

Summary

When using Claude through OpenCodex, I receive the following
error: “exceeded retry limit, last status: 429 Too Many Requests.”

Environment: VSCode => Codex Extension => OpenCodex => anthropic/claude-opus-5-5
The problem started after my ChatGPT quota reached its limit, while my Claude quota had not yet reached its limit.
Before the ChatGPT quota was exhausted, Claude worked normally through OpenCodex without any issues.
My Claude hourly, weekly, and monthly quotas are still below their limits. I’m currently on the 20x plan.
However, once the ChatGPT quota reaches its limit, Claude also stops working through OpenCodex, even though Claude’s own quota has not been reached.
When I use Claude directly through the Claude Extension in VSCode, it works normally and I do not encounter any quota or limit issues.
I checked the logs and confirmed that the proxy is working correctly. Requests are being sent to Claude as expected based on the selected model.

Thank you.

Reproduction

ocx start --port 10100
typing promt in codex extension (inside VSCode)
Response : exceeded retry limit, last status: 429 Too Many Requests

Version

2.78.0

Operating system

Windows 11 Enterprise 26H2 / Intel(R) Core(TM) i9-14900K / RAM 64 GB / NVME

Provider and model

anthropic/claude-opus-5-5

Logs or error output

{
  "requestId": "ocx-xxxxx07e7c8fa99e7f1abe5e",
  "timestamp": 1791260033820,
  "model": "claude-opus-5-5",
  "provider": "anthropic",
  "admissionKind": "loopback",
  "inboundProtocol": "responses",
  "conversationId": "a66e52bfcaxxxxxaf50b5cf0",
  "requestedModel": "anthropic/claude-opus-5-5",
  "requestedAlias": "anthropic/claude-opus-5-5",
  "requestedEffort": "high",
  "configuredServiceTier": "fast",
  "configuredSpeedLabel": "fast",
  "tierOutcome": {
    "wireKind": null,
    "wireValue": null,
    "fastOutcome": "not-requested",
    "confirmation": "unknown"
  },
  "resolvedModel": "claude-opus-5-5",
  "wireModel": "claude-opus-5-5",
  "status": 429,
  "durationMs": 240,
  "errorCode": "upstream_reset_replay_refused",
  "closeReason": "non_stream",
  "upstreamError": "The upstream exchange did not complete reliably. The request may already have been processed; automatic replay was stopped.",
  "usageStatus": "unreported",
  "attempts": [
    {
      "ordinal": 1,
      "provider": "anthropic",
      "model": "claude-opus-5-5",
      "adapter": "anthropic",
      "status": 429,
      "durationMs": 192,
      "sendCount": 1,
      "recoveryKinds": [],
      "usageStatus": "unreported",
      "requestedEffort": "high",
      "tierOutcome": {
        "wireKind": null,
        "wireValue": null,
        "fastOutcome": "not-requested",
        "confirmation": "unknown"
      },
      "errorCode": "upstream_reset_replay_refused",
      "failureStage": "headers-only",
      "failureCause": "rate-limit",
      "resendPermission": "permitted",
      "displayMetrics": {
        "tokPerSecond": {
          "kind": "unavailable",
          "reason": "usage_missing"
        },
        "decodeTokPerSecond": {
          "kind": "unavailable",
          "reason": "usage_missing"
        },
        "cost": {
          "kind": "unavailable",
          "reason": "usage_missing"
        }
      }
    }
  ],
  "spend": {
    "sends": 1,
    "settled": 1,
    "unresolved": 0
  },
  "routeDecision": {
    "version": 1,
    "decisionId": "a3xxx7ccb",
    "createdAt": 179xxxx862,
    "requestedModel": "anthropic/claude-opus-5-5",
    "routeKind": "explicit-provider",
    "requirements": [],
    "candidates": [
      {
        "provider": "anthropic",
        "model": "claude-opus-5-5",
        "eligible": true,
        "exclusions": []
      }
    ],
    "selected": {
      "candidateIndex": 0,
      "provider": "anthropic",
      "model": "claude-opus-5-5",
      "reason": "explicit-provider-namespace"
    }
  },
  "protocolTrace": {
    "v": 1,
    "inbound": "responses",
    "mode": "translated",
    "upstream": "messages",
    "requestPath": [
      "responses",
      "ir",
      "messages"
    ],
    "responsePath": [
      "messages",
      "ir",
      "responses"
    ],
    "reasonCodes": [
      "cross-wire-ir"
    ],
    "attempts": [
      {
        "ordinal": 1,
        "upstream": "messages",
        "mode": "translated",
        "requestPath": [
          "responses",
          "ir",
          "messages"
        ]
      }
    ],
    "contractVersion": "2026-09-25.2"
  },
  "failureStage": "headers-only",
  "failureCause": "rate-limit",
  "resendPermission": "permitted",
  "displayMetrics": {
    "tokPerSecond": {
      "kind": "unavailable",
      "reason": "usage_missing"
    },
    "decodeTokPerSecond": {
      "kind": "unavailable",
      "reason": "usage_missing"
    },
    "cost": {
      "kind": "unavailable",
      "reason": "combo_attempt_unavailable"
    }
  }
}

Screenshots and supporting files

Redacted configuration

Checks

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

Issue reopened

The report now contains the information required by the automated check. Thanks for updating it.

The supplied trace shows an eligible explicit Anthropic route and one physical Anthropic send returning HTTP 429 at the headers-only stage. It does not show a ChatGPT send or establish that exhausting ChatGPT quota caused this refusal. configuredServiceTier: fast is also not proof that Anthropic Fast was requested; this trace records fastOutcome: not-requested.

There is a second detail to investigate: the public error is upstream_reset_replay_refused, while the attempt records failureCause: rate-limit and resendPermission: permitted. That needs the original upstream classification, not a forced retry or quota reset.

Please provide the exact Codex extension/CLI version, whether this Anthropic route uses stored OAuth or an API key, and the sanitized upstream 429 error type/message plus rate-limit/Retry-After headers for this same request. Remove tokens, cookies, account/organization IDs and request contents. Do not post the whole config or credential store. A direct-Claude success and quota screenshots alone cannot distinguish a route-specific limit, cooldown or error-projection problem. Keeping this open; no live account operation or paid request was performed.

Triage on current dev (a12bb1f). We could not confirm that ChatGPT quota exhaustion is what blocks Claude here.

What the code and a local probe show:

Main-account quota policy applies only to canonical OpenAI forwarding (src/server/responses/core-auth.ts). A synthetic run that moved stored ChatGPT accounts and main quota through 0% → 100% → 0% produced identical Anthropic results every time: one send, HTTP 429, rate_limit_exceeded. Anthropic health is classified from Anthropic's own headers.
Your trace also shows a single physical Anthropic send that failed at the headers-only stage with failureCause: rate-limit, and no ChatGPT send.
The wording "exceeded retry limit" comes from the Codex client, not from repeated retries. Current Codex treats usage_limit_reached and quota codes as terminal errors, but maps any other 429 body directly to RetryLimit. A translated Anthropic 429 (rate_limit_error) therefore shows that message even after one attempt.
One discrepancy remains open: an ordinary Anthropic 429 does not produce upstream_reset_replay_refused locally, so we cannot yet explain that public error code in your trace.

To go further, could you share:

Exact Codex extension version and its bundled CLI version.
Whether the Anthropic provider uses OAuth (Claude subscription) or an API key, and whether the Anthropic account pool is enabled.
Your retry-related settings.
The sanitized upstream error type/message and any anthropic-ratelimit-* / retry-after headers for the failing request.
Whether the direct Claude extension uses the same account and model.

We are not turning arbitrary 429s into terminal quota errors without that evidence.

fix(logs): attribute proxy replay refusals as transport-ambiguous (#6887

Fixed on dev by #6887 (squash 6c826bdad2). A refusal to resend after an upstream reset before any output is synthesized as a 429. That 429 is no longer recorded as a provider rate limit, so it does not push the account into rate-limit handling.

Navigation Menu

Repository navigation

exceeded retry limit, last status: 429 Too Many Requests after my ChatGPT quota reached its limit. #6658

Client or integration

Area

Summary

Reproduction

Version

Operating system

Provider and model

Logs or error output

Screenshots and supporting files

Redacted configuration

Checks

Issue reopened

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

exceeded retry limit, last status: 429 Too Many Requests after my ChatGPT quota reached its limit. #6658

Description

Client or integration

Area

Summary

Reproduction

Version

Operating system

Provider and model

Logs or error output

Screenshots and supporting files

Redacted configuration

Checks

Activity

github-actions commented on Oct 6, 2026

Issue reopened

Ingwannu commented on Oct 6, 2026

lidge-jun commented on Oct 8, 2026

lidge-jun commented on Oct 10, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions