Claude apps gateway pooled budgets: what the changelog says

The changelog for Claude Code 2.1.316, dated October 31, 2026, lists pooled group budgets for the Claude apps gateway: one monthly budget that a group's members share, on top of each member's own spend limit. If your developers reach Claude through the gateway, the decision is whether a group needs a shared budget in addition to per-seat caps, and how to size it before you use the new pooled_budget setting on the spend limits admin API.

As of November 1, 2026, the spend limits page still says a group cap is a per-seat default that each member inherits, not a shared pool. It doesn't mention pooled_budget, so the changelog line is the only source here for pools. BaristaLabs interpretation: a pool would bound what the group spends together, and the per-member cap would still limit one runaway agent.

What changed in Claude apps gateway spend limits?

The Claude Code changelog entry for 2.1.316 reads: "Added pooled group budgets to the Claude apps gateway: one monthly budget that a group's members share, on top of each member's own limit, set with pooled_budget on the spend limits admin API."

The Claude apps gateway is Anthropic's self-hosted service between Claude Code clients and your model provider, according to the gateway documentation. Developers sign in with your identity provider (IdP), the gateway holds the upstream credential, and it forwards inference to Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform, Microsoft Foundry or the Anthropic API. The gateway server runs from the same claude binary as the CLI (claude gateway --config gateway.yaml), so expect pooled budgets to need a gateway server on 2.1.316 or later (BaristaLabs interpretation; the changelog names no minimum server version).

How the docs describe group caps

The spend limits page states: "A group or organization cap is a per-seat default that each member inherits, not a shared pool." A $100 daily cap on a contractors group means $100 per contractor per day, however many contractors there are.

The rest of the documented model covers per-member caps. The docs don't say how much of it applies to pools:

• Scopes and periods. Each POST /v1/organizations/spend_limits creates or replaces one cap from {scope, amount, period}. A scope is a user (the OIDC sub), an rbac_group (an IdP group name) or the organization. Periods are daily, weekly or monthly, and each enforces independently.
• Resolution order. A developer's effective cap is a per-user override, then the most restrictive of their group caps, then the org default, then unlimited. The order resolves per period. admin.group_limit_mode: max switches the multi-group tie-break to least restrictive.
• Blocking. A developer over a cap gets a 429 with error.type: billing_error, x-should-retry: false, and a message naming the period and reset time. Caps reset on UTC boundaries: daily at 00:00 UTC, weekly on Monday, monthly on the first.
• Amounts. Caps are whole-number strings of USD cents. The docs call the metered amounts "USD estimates, a circuit breaker rather than an invoice," to be reconciled against your provider's usage reporting.

What the changelog does and doesn't define yet

The changelog says three things about the pool: the pool is monthly, the group's members share it, and it applies "on top of each member's own limit." As of November 1, 2026, the spend limits page doesn't yet describe the pooled_budget setting, and it still says group caps are not a shared pool. The request shape, the pool's reset time, whether an exhausted pool blocks requests, the error a member would see, and how /effective reports pool spend aren't in the reference yet. Check the page before you script against the setting.

BaristaLabs interpretation: the changelog doesn't say how the two limits interact. If "on top of" means two checks, a member can be stopped by their own cap while the pool has room, and the pool can stop the group even when each member is under their own cap. Confirm that before you rely on it.

Who should use a pooled group budget?

BaristaLabs interpretation: a pool fits teams whose spend is uneven across people but bounded as a group. Per-seat caps force a trade-off: set them high enough for the heaviest week of your heaviest user, and the group total can climb well past what finance planned. Set them low, and the people doing the most work hit a 429 first.

BaristaLabs interpretation: a pool lets you set the group total you actually budgeted while keeping per-member caps as a fuse for runaway sessions. Groups with flat, predictable usage gain little from it; per-seat caps already bound them. Teams running agent fleets or long refactors, where a few people carry most of the load in a given month, gain the most.

This resembles the shared-capacity trade-off covered in Gemini Enterprise pooled quota as a shared failure domain: if the pool blocks members when it runs out, one heavy user could spend capacity a teammate expected to have. If you're still separating hard caps from alerts and provider quotas, start with quota vs. rate limit vs. spend cap.

Why it matters for teams on a shared cloud credential

The gateway reports to-date spend per principal. The docs explain that by default the gateway forwards all inference through one shared upstream credential, "so your provider's bill attributes everything to that credential, not to individual developers." The documented caps apply per developer, and none covers a team's combined spend. BaristaLabs interpretation: if the pool is enforced as a hard limit, it fills that gap without per-team cloud credentials.

Two documented behaviors limit how hard the per-member caps are. The docs don't say whether they apply to pools:

• Enforcement fails open by default. If the gateway's Postgres store is unreachable, requests proceed unmetered. enforcement.fail_closed_on_error: true blocks them instead. The docs put it this way: "Fail-open keeps a store outage from becoming an inference outage; fail-closed guarantees no unmetered spend."
• Amounts are estimates. The gateway prices requests from list prices or your pricing.overrides, not from the provider's invoice, so a pool metered the same way could still differ from the bill.

Recommended first step: size the pool from one month of gateway spend

BaristaLabs recommendation: size the pool from data the gateway already holds, and keep per-member caps in place.

1. Upgrade the gateway server to Claude Code 2.1.316 or later in a non-production environment first.
2. Near month end, pull month-to-date spend per developer: GET /v1/organizations/spend_limits/effective?period[]=monthly&sort=spend_desc. Each row carries the principal's last-seen IdP groups, so you can total spend per group. A developer in several groups appears under each, so totals by groups can double count, and last-seen groups may be stale. Without a user_ids[] filter, the endpoint lists principals with recorded spend.
3. Once the pooled_budget request shape is documented, set the pool near what the group actually spent plus the headroom you'd approve, not the sum of everyone's per-seat caps.
4. Keep or tighten the per-member monthly cap. Consider a daily cap too, so one member has a lower limit on what they can spend in a day.
5. Decide whether fail_closed_on_error matters more to you than availability, and record that choice.
6. After the first month, compare the gateway's figures with your provider's usage reporting, as covered for Anthropic's own reporting endpoints in the Usage and Cost Analytics API post.

For the wider rollout questions a gateway raises (identity, spend ownership and offboarding), see putting the Claude Code gateway in writing.

Sources and scope

• Claude Code changelog, 2.1.316, October 31, 2026
• Claude apps gateway spend limits, accessed November 1, 2026
• Claude apps gateway configuration, accessed November 1, 2026
• Claude apps gateway overview, accessed November 1, 2026
• Spend Limits API (Claude Enterprise), accessed November 1, 2026

Of these sources, only the changelog covers pools. It says they exist, are monthly, are shared by a group's members and apply "on top of" per-member limits. The sources don't document the pooled_budget request shape or how pool exhaustion is reported. The changelog doesn't say which spend limits admin API it means. The gateway serves its own admin API at /v1/organizations/spend_limits, which mirrors the wire shapes of Anthropic's Spend Limits API (Claude Enterprise only), and the gateway docs say Anthropic's public POST is user-only today. BaristaLabs interpretation: pooled_budget most likely belongs to the gateway's own API, but that is unconfirmed. For help setting caps and pools for your teams, see AI consulting.