Claude Code Usage Limits: How Teams Manage Them
Claude Code usage limits run on a five-hour session clock and a weekly clock, and API access adds organization-wide rate limits. This guide explains both, and how Bifrost enforces team budgets, key rotation, and provider fallback from one endpoint.
TL;DR
- Claude Code usage limits run on two clocks for paid Claude plans: a session allowance that resets every five hours, and a weekly allowance that resets at a fixed time assigned to the account.
- Claude Code, the Claude apps, and IDE sessions draw from the same plan pool, so a morning spent in chat reduces the afternoon's coding capacity.
- Organizations running Claude Code on API credentials hit a different ceiling: provider rate limits that return
429errors once several engineers work concurrently. - Bifrost routes Claude Code through a single endpoint where budgets, rate limits, key rotation, and provider fallback are enforced centrally, so one team cannot consume the organization's capacity.
- Bifrost adds 11 microseconds of overhead per request at 5,000 requests per second in sustained benchmarks, so the control layer does not become the new bottleneck.
Claude Code usage limits are metered on two clocks for every paid Claude plan: a session allowance that resets every five hours, and a weekly allowance that resets at a fixed time assigned to the account. One developer experiences that as an occasional pause. A 200-engineer organization experiences it as unpredictable capacity, because the same pool covers Claude Code, the Claude apps, and IDE sessions. Bifrost, the open-source AI gateway built in Go by Maxim AI, moves that problem somewhere a platform team can act on it: Claude Code points at one endpoint, and routing, budgets, and failover are enforced there instead of on each laptop.
What Are Claude Code Usage Limits?
Claude Code usage limits are the capacity controls Anthropic applies to paid Claude plans: a rolling session limit that resets every five hours, plus a separate weekly limit that applies across models. Anthropic's Pro plan documentation describes both clocks and notes that the weekly reset lands at a fixed time assigned to each account.
Neither clock is expressed in tokens. How much work a session buys depends on message length, attached file size, conversation length, the model selected, and the effort level. Two engineers on identical plans can exhaust the same allowance at very different rates, which is why per-seat planning tends to fail at organizational scale. The Claude Pro usage limits breakdown covers the individual-plan mechanics in more depth.
The second thing to know is that limits differ by how Claude Code reaches a model. Subscription seats, direct API credentials, and cloud provider deployments are three separate metering systems.
| Access path | Limit that applies | Reset behavior | What a platform team controls |
|---|---|---|---|
| Subscription seat (Pro, Max, Team, seat-based Enterprise) | Session allowance plus a weekly allowance | Five hours, and weekly at a fixed account time | Plan tier and user behavior only |
| Claude Platform API credentials | Organization-level request and token rate limits | Short rolling windows | Key pool, routing, retry policy |
| Amazon Bedrock or Google Vertex AI | Per-account or per-project model quotas by region | Short rolling windows | Region spread, quota requests, routing |
Why Claude Code Usage Limits Are Harder for Teams
For teams, the difficulty is not the size of the allowance but the absence of a shared view. Every seat meters independently, nothing aggregates, and the first signal that capacity ran out is an engineer blocked mid-task. Anthropic notes that usage across Claude surfaces counts toward the same subscription limits, which makes consumption harder still to attribute.
Three failure modes show up repeatedly once Claude Code is deployed across more than a handful of engineers:
- Silent billing drift. An
ANTHROPIC_API_KEYleft in a shell profile causes Claude Code to bill API usage instead of the subscription, so spend appears in a place nobody is watching. - Uneven consumption. A few engineers running long agentic sessions can account for most of a team's usage, and without per-user accounting there is no way to see it.
- No overflow path. When a seat is exhausted, work stops. There is no mechanism on the laptop to send the next request somewhere with capacity.
Centralizing these decisions is the practical fix, and it is the same reasoning behind governing Claude Code usage across engineering teams rather than per individual. An enterprise AI gateway for running Claude Code on any model makes the whole fleet legible from one place.
Claude Code Rate Limits Beyond the Subscription
Claude Code rate limits on the API path are enforced per organization rather than per developer, covering requests and tokens over short rolling windows. Concurrency is what exhausts them: twenty engineers running agentic sessions generate far more traffic than twenty people typing in a chat window, and the result is 429 responses returned mid-task.
This class of limit is the one infrastructure can absorb, because the fix is mechanical. More credentials, more providers, and a retry policy that understands the difference between a dead key and a throttled one will keep sessions moving. The Bifrost AI gateway classifies each failure before retrying: a 429, 401, 402, or 403 is treated as a per-key problem and rotates to a different credential from the pool, while a 5xx or network failure reuses the same key with exponential backoff and jitter. Rate-limit rotations still apply backoff, because account-level quotas are often shared across keys.
When every retry is exhausted, automatic fallbacks move the request to the next provider in the chain, and each fallback provider gets its own full retry budget. Practical patterns for this are covered in handling LLM rate limits and outages with a gateway.
What an LLM Gateway Changes for Claude Code
An LLM gateway is a service that sits between Claude Code and model providers, handling authentication and exposing provider-compatible endpoints. Anthropic's own enterprise deployment guidance recommends this path for organizations that need centralized usage tracking across teams, custom rate limiting or budgets, or centralized authentication management.
Claude Code is built for it. Setting ANTHROPIC_BASE_URL points the client at a gateway with no change to how engineers work, and ANTHROPIC_BEDROCK_BASE_URL and ANTHROPIC_VERTEX_BASE_URL do the same for cloud provider deployments. That single indirection is what turns a per-laptop limit into a policy question. A fuller treatment of the trade-offs sits in the guide to choosing a gateway for Claude Code.
What a gateway cannot do is raise a subscription seat's allowance. Session and weekly limits belong to the plan. What it can do is make sure the rest of the organization's capacity, across credentials, providers, and clouds, is reachable when a seat runs out.
Running Claude Code Through Bifrost
The open-source Bifrost gateway connects to Claude Code through a virtual key rather than an Anthropic account. Setting ANTHROPIC_AUTH_TOKEN to a Bifrost virtual key sends it as a bearer token, which Bifrost uses for both authentication and routing, so no Anthropic credentials are needed on the machine at all. The full configuration lives in the Claude Code integration docs.
Model selection is a routing decision rather than a client setting. Routing rules rewrite an arbitrary alias that Claude Code sends, such as sonnet-model, to whatever provider and model should serve it at that moment, matched on request attributes including headers. The same alias can resolve differently per team or per environment without anyone editing a local config file.
Because Bifrost speaks the Anthropic API format natively, this is a drop-in change: one environment variable, no code. The performance cost is published on the Bifrost benchmarks page, at 11 microseconds of added overhead per request at 5,000 requests per second.
Budgets and Rate Limits Per Team, Not Per Laptop
Bifrost enforces spending and throughput limits through virtual keys, the primary governance entity, arranged in a hierarchy of customer, team, virtual key, and provider config. Every applicable budget in that chain is checked independently, and a single failure blocks the request, so a team ceiling holds even when an individual key has room left.
Budgets and rate limits are configured with a maximum and a reset duration of 1m, 1h, 1d, 1w, 1M, 1Q, or 1Y, and day-and-longer periods can be calendar aligned in UTC instead of rolling. Token and request limits apply at the virtual key and provider config levels. Providers that exceed their budget or rate limits are excluded from routing rather than returning an error, which is what keeps a session alive when one path is exhausted.
| Bifrost control | Limit it addresses | Where it is enforced |
|---|---|---|
| Budgets with reset durations | Uncontrolled spend on API and usage-based plans | Customer, team, virtual key, provider config |
| Token and request rate limits | Concurrency exhausting a shared organizational quota | Virtual key and provider config |
| Key rotation on per-key failures | 429, 401, 402, and 403 responses from one credential |
Retry layer |
| Provider fallback chains | A provider or region running out of capacity | Routing layer |
| Response caching | Repeat requests consuming allowance unnecessarily | Cache layer |
At fleet scale, issuing keys by hand does not hold up. Access profiles define a reusable policy covering providers, models, budgets, rate limits, and MCP tool access, then auto-issue a per-user virtual key with its own counters when a user gains the matching role. A user can hold several profiles, and if one profile's budget is spent, another can cover their requests. The Bifrost governance overview maps these controls end to end, and per-team token governance covers the allocation patterns that tend to work.
Claude Code with Bedrock, Vertex AI, and Other Providers
Running Claude Code on Amazon Bedrock or Google Vertex AI spreads load across separate quota pools, since each cloud meters independently of the Claude Platform API. Bifrost treats Bedrock and Vertex AI as ordinary providers, so the same Claude model can be served from whichever path has capacity.
Beyond Claude, Bifrost unifies 25+ providers and more than 10,000 models behind one OpenAI-compatible API. A routing rule can send planning work to a Claude model and mechanical edits to something cheaper, which lowers consumption on the constrained path without changing the developer's workflow. Provider routing resolves these decisions against the Model Catalog, whose pricing data is synced on startup and refreshed periodically, every 24 hours by default.
Semantic caching removes another slice of demand by replaying a stored response for an identical or sufficiently similar request, so the provider is never called. Approaches to multi-provider setups are covered in running Claude Code on Bedrock, Vertex, or your own models.
Claude Code Monitoring and Cost Visibility
Claude Code monitoring through a gateway captures every request centrally, with inputs, outputs, token counts, cost, latency, and the provider that served it. Bifrost's built-in observability logs asynchronously, so tracing adds nothing to request latency, and it records an attempt_trail showing which credential was tried on each retry and why it failed.
That trail is the difference between knowing a limit was hit and knowing which key, team, and provider were involved. Metrics export to Prometheus and traces to any OpenTelemetry backend, and audit logs record administrative activity separately, signed with an HMAC key and archivable to object storage for compliance retention.
With that data in one place, capacity planning stops being guesswork. Related reading: tracking Claude Code token usage and monitoring coding agents.
Claude Code at Enterprise Scale
Claude Code enterprise deployments need the gateway itself to be more reliable than the limits it manages. A single open-source Bifrost instance handles roughly 3,000 to 5,000 requests per second, which covers most engineering organizations. Beyond that, clustering synchronizes state across nodes with automatic service discovery, and distributed rate limit tracking means a cluster enforces one organizational ceiling rather than one per node.
For regulated environments, Bifrost Enterprise supports in-VPC and on-premises deployment, OIDC-based user provisioning, and role-based access control. The governance resource hub collects the policy controls in one place.
For production hardening specifically, see access control and cost limits for Claude Code and Claude Code logging and spend limits.
Frequently Asked Questions
How to avoid Claude Code usage limits?
Subscription session and weekly limits cannot be raised, so the practical approach is to reduce consumption and add overflow capacity. Route Claude Code through a gateway, spread traffic across multiple credentials and providers, cache repeated requests, and send lighter tasks to cheaper models. The Bifrost gateway handles all four from one endpoint.
What is the 5-hour usage limit in Claude Code?
The five-hour limit is a rolling session allowance on paid Claude plans that resets five hours after the session window opens. It is measured as a share of capacity rather than a token count, so long conversations, large attachments, heavier models, and higher effort settings consume it faster. A separate weekly limit applies on top.
Is Claude Code unlimited?
No. Every paid plan meters Claude Code, and the allowance is shared with the Claude apps and IDE sessions. Usage-based enterprise agreements remove the fixed session ceiling but bill actual consumption, which makes cost governance more important rather than less once the hard stop disappears.
How can I see my usage limits in Claude Code?
Claude Code reports the current session through its own status commands, and plan usage appears in Claude settings. Neither view aggregates across an organization. A gateway solves that by logging every request centrally, which is what Bifrost observability provides per user, team, and provider.
What LLM does Claude Code use?
Claude Code uses Anthropic's Claude models by default and can reach them through the Claude Platform API, Amazon Bedrock, or Google Vertex AI. Pointed at a gateway, it can also reach models from other providers using the same Anthropic-format requests. Bifrost exposes 25+ providers through one compatible API.
Do Claude Code usage limits still apply behind a gateway?
Subscription limits follow the plan and are unaffected. A gateway changes which limits bind in practice by adding credentials, providers, and clouds behind one endpoint, and by enforcing organizational ceilings with virtual keys rather than leaving each machine to manage its own credentials.
Getting Started with Claude Code Usage Limits Under Control
Claude Code usage limits stop being a daily interruption when routing, budgets, and failover are enforced in one place rather than negotiated per laptop. Point Claude Code at the Bifrost platform with one environment variable, allocate budgets per team, and give every engineer an overflow path when a provider is throttled. The Bifrost resources library covers the governance and routing patterns in detail.
To see how Bifrost handles Claude Code usage limits across your engineering organization, book a demo with the Bifrost team.
