"Your org is out of extra usage for the month. we let your admin know." What a Mac agent actually does with that sentence
That message comes back from Anthropic when a Team or seat-based Enterprise org has spent its entire monthly extra-usage budget. Every public answer to it is the same: contact your admin, wait for month rollover, or pay a proxy vendor. This page is about something different. Fazm, a consumer Mac agent, has three regex sites in its ACP bridge that detect that exact phrase, a Swift mapping that turns Anthropic's "overage" rate-limit type into a human label, and a pre-query guard that flips the app from the blocked pool onto a $10 built-in fallback pool so the agent loop keeps running while your admin figures out billing.
What every public answer covers
The first-page results for this exact query are Anthropic's own help center, two GitHub issues on anthropics/claude-code, a paid-proxy vendor post, and community threads. They all land on the same three options: ping the admin, wait for the month to reset, or pay a middleman. Useful answers. None of them describe what a consumer app does with the string itself.
What those pages do not tell you
The client-side gap
- Anthropic's help center tells you to contact your admin; it does not describe what happens inside a third-party client when the string arrives.
- GitHub issues on anthropics/claude-code show users asking for the same behavior; the CLI's public answer is to wait or change plan, not to auto-fail-over.
- Paid-proxy vendors frame this as a reason to use their gateway; they do not show source-level detection in a shipping consumer app.
- No top SERP result cites a specific file path and line number for the regex that detects the literal phrase.
- No top SERP result distinguishes the HTTP-402 billing error path from the HTTP-429 rate-limit path; they are two separate routes into the same message.
- No top SERP result explains why an accessibility-API agent burns through the fallback pool more slowly than a screenshot-based one.
The anchor fact
The literal string "out of extra usage" appears in three regex branches of one Fazm file.
The file is acp-bridge/src/index.ts. The three lines are 1903, 1991, and 2034. All three sit inside error-handling branches that fire when the ACP SDK throws, and all three use the same case-insensitive regex pattern that includes the literal substring out of extra usage. The Swift side completes the pattern: the rate-limit type "overage" is mapped to the human label "extra usage limit" at ChatProvider.swift:543, and a pre-query guard at lines 2271-2277 flips the app onto a $10 built-in fallback pool before the next message fires. This is the path no SERP result describes.
- ▸acp-bridge/src/index.ts:1903 — inner-catch regex matching "out of extra usage" plus five sibling billing phrases, case-insensitive.
- ▸acp-bridge/src/index.ts:1991 — non-retryable error branch that re-checks the phrase when deciding between { type: "credit_exhausted" } and a generic { type: "error" } message.
- ▸acp-bridge/src/index.ts:2034 — outer-catch regex with the same pattern, the final safety net before the bridge throws to the caller.
- ▸acp-bridge/src/index.ts:1901-1902 — structured path: apiRetryErrorType in { "billing_error", "rate_limit" } or apiRetryHttpStatus in { 402, 429 }.
- ▸Desktop/Sources/Providers/ChatProvider.swift:476 — static let builtinCostCapUsd: Double = 10.0, the ceiling on the bundled fallback pool.
- ▸Desktop/Sources/Providers/ChatProvider.swift:543 — case "overage": return "extra usage limit", the machine-to-human label mapping.
- ▸Desktop/Sources/Providers/ChatProvider.swift:2271-2277 — pre-query guard that flips bridgeMode before the next sendMessage() fires.
- ▸Desktop/Sources/Chat/ACPBridge.swift:1599-1605 — BridgeError.creditExhausted human message with the "upgrade to Claude Pro" fallback copy.
- ▸Desktop/Sources/AnalyticsManager.swift:1000 — creditExhausted(previousMode:) analytics event for post-mortem and conversion tracking.
The handler, in four numbers
Four counts that describe the shape of Fazm's handler for this specific error. Each counts up from zero as you scroll it into view.
For context, the total number of lines added to handle this path across the bridge and the Swift client is under 0 lines of production code. The rest is existing plumbing: the bridge mode switch already existed for the $10 cap, and the regex site already existed for generic billing errors. The new work was wiring the phrase into the same pipeline.
The signal, routed from five inputs to four outputs
Five different things can tell Fazm the org is out of extra usage. All five funnel through one hub in the ACP bridge and fan out to four Swift side effects. You do not need to know which path fired; the outcome is the same.
Anthropic signals -> Fazm bridge -> Swift UI
What happens between the response and your next message
Five moments, in order. The first is Anthropic sending the sentence. The last is your next message going out on a live pool. Everything in between is happening inside the app without a modal, without a retry storm, and without waiting on your admin.
Step 1 - Anthropic returns the sentence
The org has exhausted its monthly extra-usage budget. Anthropic sends back a 402 or 429 response whose body text contains the literal phrase "your org is out of extra usage for the month. we let your admin know." This is standard Team and seat-based Enterprise behavior and is documented in Anthropic's help center under "Manage extra usage for Team and seat-based Enterprise plans."
Step 2 - The ACP bridge catches it
Fazm's Node bridge at /Users/matthewdi/fazm/acp-bridge/src/index.ts runs two layers of detection. The structured path reads the Anthropic error envelope and matches on errorType billing_error or rate_limit, or HTTP status 402 or 429 (line 1901-1902). The fallback regex at line 1903 matches "out of extra usage" directly against the error text. Either path sends { type: "credit_exhausted", message: errMsg } back to Swift.
Step 3 - Swift maps overage to a human label
At ChatProvider.swift line 543 the rateLimitTypeLabel(_:) helper has a case that maps Anthropic's machine type "overage" to the UI string "extra usage limit." The published property rateLimitType is set, rateLimitStatus goes to "rejected," and showCreditExhaustedAlert flips to true.
Step 4 - The pre-query guard triggers the fallback
On the next user message, the guard at ChatProvider.swift lines 2271-2277 runs before sendMessage(). If bridgeMode is "builtin" and the cumulative cost is at the $10 cap, the app switches to "personal." The inverse path fires when personal mode is the one that returned "out of extra usage" and drops the user back onto the builtin pool. Either way the user's next message goes out on a live account.
Step 5 - The tool-call loop keeps running
Because Fazm reads the macOS accessibility tree instead of screenshots (AppState.swift:439-472), the bytes-per-turn on the fallback account stay small. The user typically does not notice the handoff. The only visible artifact is the one-line banner tied to showCreditExhaustedAlert and a matching entry in the analytics event creditExhausted(previousMode:) at AnalyticsManager.swift:1000.
The bridge regex, verbatim
Condensed from the inner catch of handleQuery(). The structured path reads Anthropic's error envelope; the regex path reads the message text. Either signal short-circuits retries and sends a credit_exhausted session message to Swift.
Overage becomes "extra usage limit"
Anthropic's rate_limit event carries a machine type. The Swift client maps that type to a human label before the UI ever sees it. The case you care about for the org-cap path is the last one before the default.
The four moving parts of the fallback
Two pools, one handoff, and a perception layer that makes the handoff economically viable. None of this is exotic. It is the minimum a consumer Mac agent needs to survive an org-level cap without looking broken.
Personal pool (OAuth)
User's own Claude account via OAuth through the ACP SDK. When the org cap fires, this pool is blocked until the admin raises it or the month rolls. Fazm detects the phrase and flips the user off this pool automatically.
Builtin pool ($10 cap)
Fazm's bundled Anthropic key, gated by static let builtinCostCapUsd: Double = 10.0 at ChatProvider.swift:476. Cumulative spend lives in the builtinCumulativeCostUsd @AppStorage key and survives app restarts.
Automatic handoff
switchBridgeMode(to:) tears down the old bridge, rebuilds the new one, re-registers auth handlers, and eagerly starts the new mode. Pre-query guard (lines 2271-2277) triggers it before the next user message goes out. If a query is in-flight the switch is deferred to avoid killing the active stream.
Accessibility-first perception
The chat loop reads the macOS accessibility tree (AXUIElementCreateApplication, AXUIElementCopyAttributeValue) rather than screenshots. Text per turn is kilobytes, not hundreds of kilobytes. The fallback pool lasts far longer under the same workload as a screenshot-first agent.
The $10 cap and the pre-query guard
The budget is a single constant. The counter is a persisted @AppStorage key. The handoff is seven lines of Swift that fire before every user message. When the personal pool returns "out of extra usage", the inverse of this guard (at line 2895 inside the inner error catch) flips the user the other way.
Fazm vs. a typical third-party Claude client
A screenshot-based agent and an accessibility-API agent pay very different costs under an org-level cap. The column on the right describes the most common third-party behavior I saw while researching this page: surface the error and stop.
| Feature | Typical Claude client | Fazm (AX-tree + dual-pool fallback) |
|---|---|---|
| Where the phrase is detected | Typically surfaced as a raw error string to the user with no in-app handling | Three regex sites in acp-bridge/src/index.ts (1903, 1991, 2034) plus structured 402/429 parser at 1901-1902 |
| What happens to the in-flight query | Often retried up to the SDK's retry budget, burning more quota attempts before surfacing | Pending tools are marked completed, timers cleared, credit_exhausted event sent to the UI — no silent retry against the dead pool |
| Next user message | Returns the same error again until the user manually switches account | Pre-query guard flips bridgeMode to a live pool before sendMessage() fires |
| Fallback pool | None, or a user-provided second key the user must configure manually | Bundled Anthropic key, $10 per-user cap tracked in @AppStorage, survives restarts |
| Cost per turn under fallback | Screenshot images, hundreds of KB per turn; fallback budget depletes fast | Accessibility-tree text, kilobytes per turn; burns through $10 cap slowly |
| Admin notification | Same (no client re-sends the billing event) | Takes Anthropic's "we let your admin know" at face value; does not duplicate the event |
What the user actually sees
No modal. No dead-end screen. One line, sourced from BridgeError.creditExhausted. The second clause is what fires when the builtin pool is the one that ran out; the first clause fires when the personal pool hit the org cap. Both point at an immediate action the user can take without calling the admin.
Verify the line numbers yourself
A repo checkout and three commands. If any line number on this page drifts, this terminal block is how you catch it. Captured on 2026-04-20 against the main branch.
The honest takeaway
The literal sentence "your org is out of extra usage for the month. we let your admin know." is Anthropic telling every seat in a Team or Enterprise workspace that the org has hit its monthly cap at standard API rates. The admin owns the cap. You do not. Every public answer to the error lands on some version of "ping your admin, or wait." That advice is correct and it is also incomplete.
The incomplete part is that a client can do work here. Fazm catches the phrase in three places in the bridge, maps Anthropic's overage type to a human label on the Swift side, and flips the bridge onto a different pool before the next message. The $10 builtin pool is a small buffer, but it is enough to finish the current task for most loops, especially an accessibility-API loop that does not spend image tokens.
Read the three regex sites in acp-bridge/src/index.ts if you are building a similar app. Read the rateLimitTypeLabel(_:) helper in ChatProvider.swift if you want the machine-to-human mapping. Read the pre-query guard at lines 2271-2277 if you want the handoff pattern. All three are public and live in the Fazm repository. That is more information than any SERP result for this keyword currently provides.
Want the same fallback pattern in your own Claude client?
I will walk through the acp-bridge regex, the Swift bridge-mode switch, and the $10 built-in credit pool on a 20-minute call.
Book a call →Your org is out of extra usage for the month FAQ
What does "your org is out of extra usage for the month. we let your admin know." actually mean?
It is Anthropic's surfaced message when a Team or seat-based Enterprise org has spent its entire monthly extra-usage budget at standard API rates. Seats each include some base usage, and the admin can enable extra usage on top. Once the org-wide cap is hit, every seat in the org starts getting that sentence back on API requests. The only levers the end user has are: wait until month rollover, switch to a personal plan, or get the admin to raise the cap. Anthropic's help center is explicit that end users cannot change the cap themselves.
Is this the same error as "you are out of extra usage" on a personal plan?
No, and the difference matters. On a personal plan the message is "you're out of extra usage" and only affects your own balance; you fix it by topping up auto-reload or claiming a credit. The org variant "your org is out of extra usage for the month. we let your admin know" is an organization-wide cap. Nothing you do on your own account unblocks it. That is the structural reason most troubleshooting guides fall short: they tell you to manage a balance you do not own.
What HTTP status or error type does this come back as on the API?
It surfaces as a billing_error or rate_limit error from the Anthropic API, typically with HTTP status 402 (payment required) for hard billing caps or 429 (too many requests) for soft rate-limit throttles in the overage bucket. Fazm's acp-bridge at /Users/matthewdi/fazm/acp-bridge/src/index.ts lines 1901-1902 treats all four as equivalent: apiRetryErrorType === "billing_error" || apiRetryErrorType === "rate_limit" || apiRetryHttpStatus === 402 || apiRetryHttpStatus === 429. That single condition covers both the structured Anthropic error envelope and the raw HTTP status, so the app does not care which form the message arrives in.
What does Fazm specifically do when it sees this message?
Three things, in order. One, the ACP bridge regex at acp-bridge/src/index.ts:1903 detects the literal substring "out of extra usage" inside the error text and marks the query as credit-exhausted so it never retries the same call again. Two, the Swift client maps Anthropic's "overage" rate-limit type to a human label "extra usage limit" at Desktop/Sources/Providers/ChatProvider.swift:543 and flips showCreditExhaustedAlert to true. Three, ChatProvider.swift lines 2271-2277 run a pre-query guard: if the user is on the personal OAuth pool and that pool is now blocked, the next query automatically swaps bridgeMode back to builtin, which draws from Fazm's own $10 free credit pool. The loop keeps running while the admin figures out billing.
Where is the exact "out of extra usage" regex in the Fazm source?
Three sites in one file. /Users/matthewdi/fazm/acp-bridge/src/index.ts line 1903 (inner catch, pre-retry guard), line 1991 (non-retryable error surfacing), and line 2034 (outer catch, terminal error path). All three use the same pattern: /credit balance is too low|insufficient.*(credit|funds|balance)|you've hit your limit|you have hit your limit|hit your.*limit|rate.?limit.*rejected|out of extra usage|unable to verify.*membership/i. Three entry points, one regex, one outcome: a credit_exhausted session message that the Swift UI picks up to switch modes.
What is the $10 built-in credit pool?
Fazm ships with a bundled Anthropic key that is rate-limited per-user by a cost cap. The constant is at Desktop/Sources/Providers/ChatProvider.swift:476: static let builtinCostCapUsd: Double = 10.0. The cumulative cost is tracked in an @AppStorage key builtinCumulativeCostUsd and persisted across launches. When it crosses $10 the app flips to personal OAuth. When the personal account throws "out of extra usage" the app flips back, up to the remaining budget. This two-way handoff is the part that keeps an agent loop alive across an org-level cap.
Does this apply if I am on Claude Pro personally instead of a Team plan?
The same code path handles both, but the upstream cause is different. On Team or Enterprise the cap is org-wide and you will see "your org is out of extra usage for the month". On a Pro plan the cap is personal and you will see "you're out of extra usage". Fazm's regex catches both with one phrase ("out of extra usage") and both get routed through the same fallback. The user's experience is identical: the message surfaces once, the mode switches silently, and the next tool call executes on the builtin pool.
Why is a screenshot-based agent worse under this cap than an accessibility-API agent?
Token economics. Screenshot-first agents send full-resolution images to Claude on most turns, which translates to thousands of image tokens per action. Fazm reads the macOS accessibility tree at Desktop/Sources/AppState.swift around lines 439-472 (AXUIElementCreateApplication, AXUIElementCopyAttributeValue) and sends structured text instead. A typical accessibility snapshot is a few KB of text versus hundreds of KB of image data. The practical effect under an org-level extra-usage cap is that a Fazm loop burns through the cap far slower than a vision-first agent. When the cap is already hit, the accessibility-first path also uses less of the fallback $10 pool to recover.
Will the admin actually get notified?
Anthropic surfaces the "we let your admin know" language because the billing event fires an org-level notification in the admin console for Team and Enterprise plans. Fazm does not re-notify; it takes Anthropic at its word and focuses on keeping the user's loop usable. The app's local notification (showCreditExhaustedAlert at ChatProvider.swift:370, rendered in SettingsPage.swift:870 and OnboardingChatView.swift:514) is strictly for the end user. It does not re-send anything to the admin.
Can I verify these line numbers myself?
Yes. Clone the Fazm repository and run these from the repo root. grep -n 'out of extra usage' acp-bridge/src/index.ts returns lines 1903, 1991, and 2034. sed -n '540,546p' Desktop/Sources/Providers/ChatProvider.swift prints the overage-to-extra-usage-limit mapping. sed -n '473,480p' Desktop/Sources/Providers/ChatProvider.swift prints the builtinCostCapUsd = 10.0 constant. sed -n '2271,2277p' Desktop/Sources/Providers/ChatProvider.swift prints the pre-query guard that triggers the mode switch. All line numbers were verified on main on 2026-04-20.
What should I do right now if my chat just hit this?
In Fazm the answer is nothing; the next message routes through the built-in pool automatically up to $10 of spend. In any other client (Claude.ai web, Claude Code, Claude Desktop, third-party apps without fallback), the only real options are: contact your org admin to raise the extra-usage cap, wait for the calendar rollover, switch to a personal plan for this task, or route through a bring-your-own-key path if the app supports it. None of those options restore the work in progress; they only unblock future requests.
Comments (••)
Leave a comment to see what others are saying.Public and anonymous. No signup.