Fixing Claude Rate Limit Exceeded Errors with an AI Gateway

TL;DR

• A Claude rate limit exceeded error is an HTTP 429 returned when your organization crosses one of three per-minute ceilings: requests, input tokens, or output tokens.
• Anthropic applies rate limits separately per model class, so a 429 on one Claude model leaves capacity on the others untouched, which is what makes gateway routing effective.
• Client-side retry loops handle bursts, but they add no capacity; once a limit is saturated, backoff converts errors into queue depth.
• Bifrost rotates API keys on a 429, fails over to Claude on Bedrock or Vertex AI, and enforces per-team budgets before traffic reaches Anthropic, with no application code changes.
• Bifrost adds 11 microseconds of overhead per request at 5,000 requests per second, so the routing layer does not become the next bottleneck.

The Claude API enforces limits at the organization level across three per-minute dimensions, and exceeding any one of them returns a 429. A Claude rate limit exceeded error is therefore a capacity signal, not a bug, and the durable fix is a traffic layer that can move the request somewhere with headroom. Bifrost, the open-source AI gateway built in Go by Maxim AI, sits between your application and Anthropic, rotating keys, applying backoff, and failing over across provider paths that carry independent quota. This post covers what the error actually means, how to identify which limit fired, and how to configure automatic retries and fallbacks so a saturated quota stops surfacing as a user-facing failure.

What a Claude Rate Limit Exceeded Error Means

A Claude rate limit exceeded error is an HTTP 429 response with an error type of rate_limit_error, returned when an organization crosses a per-minute request or token ceiling on the Claude API. The response body names the limit that was breached, and in the standard case it carries a retry-after header giving the number of seconds until capacity returns.

Two details make this error different from a generic 429. First, limits are enforced per organization rather than per API key, so issuing a second key inside the same organization does not create a second quota pool. Second, per Anthropic's rate limits documentation, the API uses a token bucket algorithm, meaning capacity replenishes continuously instead of resetting on a clock boundary. A limit of 60 requests per minute can be enforced closer to one request per second, so a short burst can trigger a 429 while your hourly average looks comfortable.

That mismatch between average and instantaneous usage is why the error so often appears next to a dashboard showing low utilization, and why the fix belongs in the traffic layer rather than the application. The broader treatment lives in this guide to managing Claude rate limits across production workloads.

The Three Limits Behind a 429 Too Many Requests Response

A 429 too many requests response from Claude can originate from any of three independent per-minute dimensions, each measured separately for each model class. Exhausting one is sufficient to fail the request even when the other two have headroom, which is why reducing request count alone frequently fails to resolve the error.

ITPM is the dimension that constrains agentic workloads, because every turn of an agent loop ships the accumulated context as input. Anthropic's documentation notes that for most current models, cache reads do not count toward ITPM, so prompt caching raises effective throughput without any change to the underlying limit. The anthropic-ratelimit-* response headers report the limit, the remaining budget, and the reset timestamp for each dimension, which is the fastest way to identify which ceiling actually fired.

A gateway is the natural place to read those headers, because it sees every response across every service in the organization rather than one application's slice. Bifrost exposes that view through native Prometheus metrics and OpenTelemetry traces, so rate-limit pressure becomes a monitored signal instead of a support ticket.

Why a Claude Usage Limit Fires Below Your Quota

A Claude usage limit can fire well below the number shown in the console for four distinct reasons, and each has a different fix. Treating all 429s as one condition is the most common diagnostic mistake, because two of the four are not rate limits at all despite carrying the same status code and error type.

The spend-cap case deserves attention because it defeats standard retry logic. Anthropic's documentation states that when an organization reaches its tier spend cap, requests return a 429 with no retry-after header, and usage stays paused until 00:00 UTC on the first day of the following month. An SDK's automatic retries will loop against that response indefinitely and never succeed. A gateway that classifies failures by error code, rather than by status alone, stops that loop and routes to a provider path that still has budget.

The 529 case is similarly distinct. It signals capacity constraints on Anthropic's side and is unrelated to your quota, so the correct handling is provider-level failover rather than backoff. Bifrost applies both behaviors from the same routing configuration, which is covered in more depth in this walkthrough of how an AI gateway absorbs LLM rate limits and outages.

Client-Side Fixes and Where They Run Out

Client-side handling is necessary and insufficient. Exponential backoff with jitter, concurrency caps, and prompt caching all reduce how often a Claude rate limit exceeded error appears, but none of them adds capacity. When a limit is genuinely saturated for a sustained period, backoff converts a fast failure into a slow one.

• Exponential backoff with jitter smooths bursts and prevents synchronized retry storms across replicas. It does nothing for sustained saturation.
• Concurrency limiting keeps a worker pool from overshooting RPM. It requires every service in the organization to cooperate, which rarely holds past the second team.
• Prompt caching lowers ITPM consumption because cache reads are excluded on most models. It helps only where prompts share long stable prefixes.
• Tier upgrades raise the ceiling. They are the correct answer when demand is genuinely growing, and they take time and money to arrange.

The structural weakness is scope. Each control lives inside one application while the quota is shared across the organization, so a batch job starting at the top of the hour can consume the ITPM budget an interactive product depends on, and neither service can see the other. That requires a shared control point, the argument developed in this analysis of budget and rate limit architecture for multi-tenant LLM platforms.

How an AI Gateway Routes Around Claude Rate Limits

An AI gateway is a single entry point that receives every model request from an organization and decides which provider, key, and model each one goes to. Because it holds that decision, it can respond to a 429 by moving the request rather than returning the error, and it can do so without any change to calling code.

Anthropic applies rate limits separately for each model, which the documentation states directly: different models can be used up to their respective limits simultaneously. Provider paths compound that. Claude models are available through the Anthropic API, through AWS Bedrock, and through Google Vertex AI, and each path carries its own credentials and its own quota. A fallback chain across those paths keeps the same model family serving traffic while the Anthropic-side window slides.

The open-source Bifrost gateway implements this with a two-stage recovery. Retries handle failures inside a provider: on a 429 it marks the key as used for the current cycle, rotates to another key in the pool, and still applies backoff, because account-level quotas are often shared across keys. Fallbacks handle failures of the provider itself: once the retry budget is exhausted, the request moves to the next provider in the chain, and that provider receives a full retry budget of its own. The Bifrost AI gateway treats permanent credential failures differently again, marking a key dead immediately on a 401 or 403 without waiting, since backoff cannot revive a bad credential.

Load Balancing Claude Keys Through an LLM Gateway

An LLM gateway distributes traffic across multiple credentials before any limit is reached, which is more effective than reacting after a 429. Bifrost uses weighted random selection across a key pool, so a key attached to a higher tier can be assigned a larger share of traffic while a backup key absorbs the remainder.

Weighted load balancing supports several patterns that matter for Claude specifically:

• Tier-aware weighting. Assign higher weights to organizations or accounts with larger quotas so traffic naturally concentrates where headroom exists.
• Model-scoped keys. Restrict a key to specific models so an expensive Opus workload cannot consume the budget reserved for Haiku traffic.
• Graduated key rotation. Shift weight progressively during a credential rollover rather than cutting over in one step.

At enterprise scale, weights stop being static. Adaptive load balancing adjusts them from live error-rate, latency, and throughput measurements, and nodes share rate-limit signals so a saturated key is backed off across the fleet within a region rather than being rediscovered independently by each instance. A circuit breaker removes consistently failing routes from rotation and favors recovering ones so they return quickly. The mechanics of weighting, health checks, and failover ordering are covered in this guide to load balancing in an AI gateway.

Configuring Claude Failover in Bifrost

Setting this up is a configuration change rather than a migration. Bifrost is a drop-in replacement for the Anthropic SDK, so pointing an existing client at it means changing the base URL and the key.

import anthropic

client = anthropic.Anthropic(
    base_url="<http://localhost:8080/anthropic>",
    api_key="<YOUR-BIFROST-VIRTUAL-KEY>"
)

Provider credentials and retry behavior are registered through the gateway configuration. The following registers two Anthropic keys with weighted distribution and a retry policy tuned for rate-limit recovery:

curl -X POST <http://localhost:8080/api/providers> \
  -H 'Content-Type: application/json' \
  -d '{
    "provider": "anthropic",
    "keys": [
      {"name": "primary",   "value": "env.ANTHROPIC_API_KEY_1", "models": ["*"], "weight": 0.7},
      {"name": "secondary", "value": "env.ANTHROPIC_API_KEY_2", "models": ["*"], "weight": 0.3}
    ],
    "network_config": {
      "max_retries": 3,
      "retry_backoff_initial": 500,
      "retry_backoff_max": 5000
    }
  }'

Backoff follows min(retry_backoff_initial × 2^attempt, retry_backoff_max) with jitter between 0.8 and 1.2, producing waits of roughly 400 milliseconds to 5 seconds across successive attempts. Registering Bedrock and Vertex AI as additional providers gives the fallback chain somewhere to go once the Anthropic pool is exhausted, and routing rules express finer conditions through CEL expressions evaluated per request. The same configuration applies unchanged behind in-VPC or air-gapped deployments.

API Rate Limiting and Budgets Inside the Gateway

API rate limiting at the gateway prevents one team from consuming the organization's shared Claude quota. Rather than discovering the conflict as a 429 in production, Bifrost enforces per-consumer ceilings before a request is ever sent to Anthropic, so the noisy workload is throttled and the quiet one keeps its capacity.

Virtual keys are the unit of control. Each carries its own budget, rate limits, model permissions, and provider configuration, and they compose hierarchically across customers, teams, and individual keys. Budget and limit enforcement then makes the allocation explicit: a batch pipeline can be capped at a fraction of the organization's ITPM so an interactive service always retains headroom, which is the same isolation Anthropic offers through workspace sub-limits, applied across every provider at once instead of one.

Semantic caching reduces the load those budgets absorb. Bifrost serves repeated requests from an exact-match hash lookup and near-duplicates from an embedding similarity search, and a cached response consumes no Claude quota at all. For repetitive prompts, raising the cache hit rate is often a larger throughput gain than adding another key, and the governance capabilities metering it report per consumer rather than in aggregate.

Claude Code Rate Limit Handling for Coding Agents

Claude Code rate limit errors follow the same mechanics as API rate limits but arrive faster, because parallel subagents and long agent loops resend accumulated context on every turn. That pattern consumes ITPM disproportionately, so a coding session can exhaust a token ceiling while its request count stays modest.

Pointing Claude Code at Bifrost puts the same key rotation, fallback chain, and budget enforcement behind the agent. When the Anthropic path saturates, the session continues against Bedrock or Vertex AI instead of stopping, and per-developer virtual keys make it visible which sessions are consuming shared capacity. That configuration is covered end to end in this guide to choosing an AI gateway for Claude Code, with the governance and routing details in Claude Code gateway routing and cost control.

The routing layer has to be fast enough to sit in an interactive loop. Bifrost adds 11 microseconds of overhead per request at 5,000 requests per second in sustained benchmarks, and route selection contributes under 10 microseconds to hot-path latency, so failover does not register as lag in the editor. Teams comparing routing layers on latency and failover behavior can work through the LLM gateway buyer's guide before committing to one.

What Production Looks Like After the Change

Routing Claude traffic through a gateway changes the failure mode rather than removing the limit. Anthropic's ceilings still apply, but a saturated quota becomes a routing decision resolved in microseconds instead of an error returned to a user.

Three outcomes follow consistently:

• Rate-limit errors stop reaching applications. Key rotation and provider fallback absorb 429s that would otherwise surface, and the spend-cap variant is classified rather than retried into a dead end.
• Capacity becomes allocable. Per-team budgets turn a shared organization quota into explicit allocations, so one workload cannot starve another.
• Pressure becomes observable. Rate-limit headroom, cache hit rate, and per-consumer consumption are measured centrally, which turns tier planning into a data decision.

Model migration, provider outages, and cost control run through the same configuration. Teams needing Claude Code to reach models beyond Anthropic can follow this guide to running Claude Code against non-Anthropic models, and tier mechanics are documented in this reference on Claude rate limit management.

Frequently Asked Questions

How do you fix a rate limit exceeded?

Read the retry-after header and wait the stated interval before retrying, then address the cause. If the limit is saturated rather than briefly exceeded, add capacity: rotate across multiple API keys, fail over to another provider path carrying the same model, or raise the tier. Backoff alone only delays a request that still has nowhere to go.

How to fix Claude limit reached?

Identify which limit fired using the anthropic-ratelimit-* response headers, which report the ceiling, remaining budget, and reset time for requests, input tokens, and output tokens separately. If it is ITPM, prompt caching and context trimming help most. If the 429 has no retry-after header, it is a spend cap and requires a tier change rather than a retry.

Why do I have a usage limit on Claude?

Anthropic applies limits to prevent abuse and to distribute capacity across organizations, and they are set by usage tier rather than per key. Limits rise automatically as an organization builds usage history, and higher ceilings can be requested through the Claude Console. They are maximum allowed usage, not guaranteed throughput.

What is the rate limit on Claude Free?

Consumer Claude plans use message and session caps, which are a separate mechanism from the API rate limits described here. API rate limits apply to organizations calling the Claude API with an API key and are measured in requests and tokens per minute. A consumer plan limit cannot be fixed with retry logic or gateway routing.

What does rate limit exceeded mean on Claude?

It means your organization sent more requests or tokens in a one-minute window than your tier permits for that model class. The API returns HTTP 429 with error type rate_limit_error and, in the standard case, a retry-after header. It reflects account capacity, not a problem with the request itself.

Does an AI gateway increase my Claude rate limits?

No. An AI gateway does not change the ceilings Anthropic sets for your organization. It increases usable throughput by distributing traffic across multiple keys and provider paths that carry independent quota, serving repeated requests from cache, and retrying intelligently. The underlying per-organization limits are unchanged.

What is the difference between a 429 and a 529 from Claude?

A 429 means your organization exceeded its own limit, so the correct response is backoff or added capacity. A 529 means the API is temporarily overloaded on Anthropic's side, independent of your quota, so retrying against the same endpoint may not help. Provider failover is the effective handling for 529s.

Route Claude Traffic Through Bifrost

A Claude rate limit exceeded error is a capacity problem, and capacity problems are solved where traffic is routed rather than where it is generated. Bifrost handles key rotation, provider failover, per-team budgets, and caching from one configuration, with no changes to application code. The Bifrost documentation covers setup, and the Bifrost resource library goes deeper on routing patterns.

To see how Bifrost handles Claude rate limits and multi-provider failover against your own traffic profile, book a demo with the Bifrost team.