{"version":"2.1.267","anchor":"gateway-skips-retry-eligible-status-marking-for-429s-tied-to","canonical_anchor":"gateway-skips-retry-eligible-status-marking-for-429s-tied-to","heading":"Gateway skips retry-eligible-status marking for 429s tied to forwarded user identity","tier":"internal","area":"Elsewhere","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.267\/e\/gateway-skips-retry-eligible-status-marking-for-429s-tied-to","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.267","markdown":"### Gateway skips retry-eligible-status marking for 429s tied to forwarded user identity\n\nGateway no longer treats per-user 429 rate limits as generic retryable errors when forwarding user identity\n\n**What**\n\nClaude Code's model gateway (the component that routes requests to an upstream AI provider) can be configured to forward a user's identity to the upstream. When a request made this way, using the 'raw' upstream kind with `forwardUserIdentity` and a resolvable user email, comes back with a 429 (rate limited) response, the gateway no longer marks it as a generic retryable error status.\n\n**Why**\n\nA 429 tied to a specific forwarded user's identity reflects that user's own rate limit rather than a generic gateway problem, so it no longer gets bucketed with other retryable gateway errors.\n\n- Area: Elsewhere\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 1\/5"}