Claude Code spend limits: working with per-member caps

On Claude Team and Enterprise plans the bill is per seat, and so is the ceiling. On Team and seat-based Enterprise seats, each member’s Claude Code, Claude and Cowork usage draws from that seat’s own allowance³. On the usage-based Enterprise seat nothing is included, and every token bills at API rates⁴. If you own the bill, you have one switch, three kinds of monthly spend limit, a request queue, a dashboard with an export, and on Enterprise plans two APIs. We covered what changed and when in a separate explainer. This page is about the controls themselves: how each one works, how far its reach goes, and the question they leave open.

Which plan you are on

Individual Pro and Max plans are not covered here.

The controls, one at a time

The seat allowance

What it does. On Team and seat-based Enterprise seats the allowance is the default ceiling³: a rolling five-hour window and a weekly window, shared across Claude, Claude Code and Cowork³, sized by seat tier. A Standard seat carries 1.25 times the Pro plan’s usage per session and a Premium seat 6.25 times². Weekly limits reset at a fixed time each week that is assigned to the account, and a member receives the full weekly allowance each cycle². On the usage-based Enterprise seat there is no allowance to reach⁴.

Where it stops. The allowance is the member’s own. Usage limits on Team plans are per member, not applied to the team as a whole². A member who reaches the weekly wall waits for the reset or, if usage credits are on, starts spending, while the unused remainder of the seat next to them resets with everyone else’s on its own schedule². Usage inside the allowance is not metered in dollars³, so the spend report has nothing to say about who is close to the wall and who never approaches it.

The usage credits switch

What it does. This is the overage switch, and it starts off. An Owner or Primary Owner turns it on in Organization settings under Usage and sets a monthly spend limit for the organization, or leaves it unlimited¹. Once it is on, members on Standard and Premium seats continue working past their included limits at standard API rates¹. Team organizations prepay the credits; seat-based Enterprise organizations are billed at the end of each month for what was used¹. It applies to Team and seat-based Enterprise plans. On the usage-based Enterprise seat there is nothing to switch on, because every token already bills⁴.

Where it stops. It is one switch for the whole organization with one number behind it. Off means every seat is a hard weekly wall. On with no organization limit means an open invoice at API rates until a narrower limit says otherwise. On with an organization limit means that when the limit is reached, a member whose request would bill to credits is stopped until an administrator raises the limit the message names³. The switch decides between an open invoice and a hard stop, and the limits below it decide where the stop lands.

Organization, seat-tier, group and per-member spend limits

What it does. Monthly dollar limits below the organization’s. On seat-based Enterprise plans a separate limit per seat tier¹. On Enterprise plans a per-user monthly limit assigned to each group⁶. On every plan an individual monthly limit per member¹. They resolve in a fixed order: an individual limit overrides the group or seat-tier limit, which overrides the organization-wide default¹⁶, and a member in more than one group gets the higher or the lower group limit depending on a setting⁶. On the usage-based Enterprise seat the same organization and individual limits exist, can be set to unlimited, and consumption is billed either way⁵.

Where it stops. Every one of them is a ceiling on one entity’s spend past its allowance. When a member exceeds theirs, they cannot use Claude, Cowork or Claude Code again until the next billing period, or until the limit is adjusted¹. A per-member limit changes when that member stops. It has no view of the allowance another member did not use, and it cannot hand a blocked member any of it. Set low enough to protect the budget, it blocks the members who were doing the most work. Set high enough not to, it protects nothing.

The request queue

What it does. A member who reaches a limit sees a link to request usage credits, or runs a command in Claude Code that sends the request to the organization’s administrators³, and administrators receive a daily email listing the organization’s outstanding requests¹.

Where it stops. Each request is a decision for a person, once a day, about one member’s ceiling. The queue tells an administrator who is asking. It does not tell them who is holding allowance they will not use, and answering a request moves the invoice, not the allowance.

The analytics dashboard and the spend report

What it does. Settings, then Analytics, shows cost analytics: usage limits, spend concentration, total spend and spend by model⁷. On Team plans Owners and Primary Owners can see it; on Enterprise plans Owners, Primary Owners and Admins can, though Admins cannot view spend⁷. The spend report export lists each person’s use of each model with requests, prompt and completion tokens, and net and gross spend, summed over a window of up to 90 days⁷. Spend data refreshes daily and has a one-day delay⁷.

Where it stops. On Team and seat-based Enterprise plans the report covers usage-credit spend and appears once usage credits are turned on³; the export only reflects spend that exceeds the seat allotment⁷. A dashboard shows. It does not act. Look at the concentration rather than the average, because the members who draw on credits set the invoice and the members who never approach their allowance set the waste, and the two groups are rarely the same people.

The Enterprise Analytics API and the Enterprise Admin API

What it does. On Enterprise plans a Primary Owner creates an Analytics API key with the read:analytics scope⁸, and the Enterprise Analytics API returns per-user usage and cost reports across Claude surfaces, including Claude Code⁹. The Enterprise Admin API, in public beta for Enterprise organizations with usage credits enabled, reads each member’s effective limit and period-to-date spend and sets or clears per-member overrides¹⁰.

Where it stops. The Analytics API is not available on the Teams plan⁸, and the Admin API serves Enterprise organizations with usage credits enabled¹⁰; on Team plans the per-user path is the export³. On seat-based Enterprise plans the cost and usage endpoints reflect usage credits only⁹. The Admin API writes one thing, a member’s override, while seat-tier, group and organization defaults are configured in claude.ai settings¹⁰. So the programmatic control is the same ceiling, one member at a time.

The administrator’s dilemma

Every one of those controls is a ceiling. The dilemma is that no height is correct.

The wall itself moved this week. On Team and seat-based Enterprise seats the weekly limit in Claude Code was 50% higher from May 13, 2026 through September 13, 2026¹². From September 14 the standard is 25% higher than it was before that promotion, a 17% reduction compared with the promotional level¹³¹⁴. Whatever limit you set this month sits on an allowance smaller than last week’s.

What a limit actually moves

Each control acts on one axis: how much one entity, whether the organization, a seat tier, a group or a member, is allowed to spend past its allowance. The problem the per-seat model creates lives on a different axis: who has headroom on Thursday.

Blocking and resetting unused are not opposite failures that a well-chosen limit sits between. They happen in the same organization, in the same week, to different seats. The members on agent workflows reach the wall while the allowance on the seats around them expires at the reset. Lowering a limit moves the blocked day earlier. Raising it moves the cost onto the invoice. Leaving usage credits off makes the wall everyone’s. None of those settings moves a single hour of allowance from a member who will not use it to one who will, because a limit cannot do that. It is a distribution problem being addressed with a ceiling.

Nor is this particular to Anthropic. Each vendor’s coding tool ships a ceiling of its own, and none of them ships the route.

The route that moves the allowance

What a seat-based organization needs is the thing missing from the figure above: a way for allowance that would otherwise reset unused to reach the member who ran out, before the week ends. On a usage-based plan it is the same route in dollars: a per-member limit that follows demand within a budget rather than sitting where it was set. Then the limit can stay where it protects the budget, because a member who reaches it has somewhere to go.

We are building Spillway Ops for that route. The Claude Code connection is in development, as the product page says. On Enterprise plans it uses the Enterprise Analytics API for per-member usage and cost⁹, and the Enterprise Admin API for per-member spend-limit overrides, in public beta for organizations with usage credits enabled¹⁰. On Team plans the per-user path is the spend report export³, so the route there runs through the export and a person until that changes. Either way it reads usage metadata and sets per-member limits through Anthropic’s admin API, with no repository access, no prompt contents and no code. Unused allocation flows to the members who need it, so spend falls without anyone losing a tool. If you are choosing a limit this month, we would like to hear which one and why.