The Claude Opus 4.7 rate limit is three endpoints, not one number
Most guides on this topic give you a ceiling: X messages per 5 hours, Y Opus prompts per week. That answer is a projection from the real data, not the data itself. The actual gate that decides whether your next Opus 4.7 call 200s, bills against overage, or 429s is three private endpoints on claude.ai/api/organizations/{org}/*. ClaudeMeter is the only tool that polls all three and serves the combined state over a localhost HTTP bridge so your scripts can read it before Claude Code does.
Why one number cannot answer this question
A rate limit is usually discussed as a fraction: you are at 72 percent, you have 28 percent left. For Opus 4.7 that framing is dangerous. Your next request has three possible outcomes (200, billed 200, 429), and the utilization fraction on its own cannot distinguish them. The outcome depends on whether extra-usage billing is enabled on your account, whether your plan is active, and which of the two utilization floats (5-hour or Opus weekly) is the one at 1.0.
The server encodes those three facts in three separate JSON payloads. ClaudeMeter fetches them in one tick and treats them as a tuple. That tuple is the real rate-limit state.
The three endpoints, named
Every tick, ClaudeMeter's fetch_usage_snapshot calls four endpoints on claude.ai/api. Three of them feed directly into the Opus 4.7 rate-limit decision.
/organizations/{org}/usage
The quota gate. Returns seven utilization floats and a resets_at per float. For Opus 4.7, five_hour and seven_day_opus are the two that matter. Both must stay below 1.0. This is the only endpoint every other tracker looks at, and on its own it cannot tell a hard 429 from a billed 200.
/organizations/{org}/overage_spend_limit
The fallback gate. Returns is_enabled, used_credits, monthly_credit_limit, out_of_credits. When utilization hits 1.0, this endpoint decides whether Anthropic bills you or rejects the request. Missing from every local-log tool; ccusage and Claude-Code-Usage-Monitor have no way to see it.
/organizations/{org}/subscription_details
The plan gate. Returns status, billing_interval, payment_method.brand. Defines the denominator of every utilization fraction. A past_due or canceled subscription 429s you regardless of utilization, which no quota tool surfaces.
/api/account
The identity gate. Returns email_address and memberships. ClaudeMeter uses this to loop over every org you belong to, because an Opus 4.7 user with a personal Pro account and a team Max account has two separate three-endpoint stacks to watch.
The anchor fact: here is the fetch, in full
This is every HTTP request ClaudeMeter makes to learn your Opus 4.7 rate-limit state. All three are authed with your browser's existing claude.ai cookies, fired in parallel by the background worker every 60 seconds:
The decision tree a request actually takes
Five consecutive reads against the three endpoints. Any one of them can flip the outcome from 200 to billed-200 to 429.
From three JSON payloads to one boolean: can I send this Opus 4.7 prompt?
1. Read usage.five_hour.utilization
Shared across every model. If this is at or above 1.0, Opus 4.7 will 429 even when the Opus weekly bucket is empty. This is the most common surprise: a Sonnet-heavy morning can block Opus in the afternoon.
2. Read usage.seven_day_opus.utilization
Opus-only weekly float. Fills fastest on 4.7 because the tokenizer expands 1.0x to 1.35x and adaptive thinking generates more hidden output tokens than 4.6. Sonnet calls do not touch this float.
3. Branch on overage.is_enabled and overage.out_of_credits
If either utilization is at 1.0, this is where the 429 vs billed-200 decision happens. is_enabled=true AND out_of_credits=false is the only combination that converts a limit-hit into a successful response.
4. Sanity-check subscription.status
A past_due or canceled subscription is treated as 'no plan' server-side. Utilization denominators collapse and the request rejects. ClaudeMeter reads this on every tick so the CLI can flag the mismatch before you see an opaque error.
5. Issue the Opus 4.7 request, or wait for resets_at
If steps 1 to 4 say the call will succeed or bill, send it. If they say it will 429, read the resets_at timestamp on the pinned float and sleep until then. resets_at is returned on every tick and the extension renders it as 'now, Xm, Xh, Xd' in popup.js lines 17 to 27.
The three payloads, one outcome
Three independent JSON responses collapse into a single true/false on whether your Opus 4.7 request will succeed. This is the logic the rate limiter itself runs server-side.
Three endpoints → rate-limit decision
The part nobody else has: a localhost bridge
ClaudeMeter's menu-bar app opens an HTTP server on 127.0.0.1:63762. The browser extension POSTs a fresh snapshot to /snapshots on every 60-second tick. That same path accepts GET, so any process on your machine can curl the current rate-limit state without touching claude.ai directly.
Local-log tools like ccusage and Claude-Code-Usage-Monitor have no equivalent. They read your JSONL and summarize it; there is no HTTP surface to hit, no overage or subscription state they know about, and no path from a Bash script to “is my next Opus 4.7 call safe to send.”
Reading the bridge from a shell
A single curl returns the combined snapshot for every org you are in. Here is the minimal read that extracts the three fields a pre-flight check cares about:
The overage endpoint, in the struct
This is the endpoint nobody else is reading. It is the one that converts “utilization hit 1.0” into either a 429 or a billed 200, and the one that decides whether your extra_usage.monthly_limit is still spendable:
Two booleans do the real work: is_enabled (you have opted in to paid overage) and out_of_credits (you have not exhausted the monthly cap). Both must be in the good state for a utilization-hit to become a billed success instead of a rate-limit error.
A real pre-flight script, end to end
This wrapper gates an Opus 4.7 call on the three-endpoint state served by ClaudeMeter's local bridge. It exits 1 if the 5-hour float is pinned, 2 if the Opus weekly float is pinned and overage is not available, otherwise invokes Claude Code:
The numbers, verbatim
From the open-source client and Anthropic's Opus 4.7 release notes. No invented benchmarks.
What has to be true for an Opus 4.7 call to go through
Preconditions the rate limiter actually checks
- usage.five_hour.utilization < 1.0. Shared across Sonnet and Opus; a Sonnet-heavy session will pin this first.
- usage.seven_day_opus.utilization < 1.0. Opus-only weekly. Fills faster on 4.7 than it did on 4.6 for the same workload.
- overage.is_enabled is true AND overage.out_of_credits is false. If this flips, a utilization hit becomes a 429 instead of a billed 200.
- subscription.status is active. A past_due subscription produces rate-limit-shaped errors that no utilization float can explain.
- Your claude.ai cookie is fresh. All three endpoints reject with 401 if your browser session has expired, and ClaudeMeter surfaces the error in the menu bar immediately.
Server truth vs local logs
Two different questions, two different answer sets. Only one matches what Anthropic's Opus 4.7 rate limiter actually enforces.
| Feature | Local log tools | ClaudeMeter |
|---|---|---|
| Reads usage.five_hour.utilization | No, estimates from local JSONL | Yes, verbatim from /api/organizations/{org}/usage |
| Reads seven_day_opus (Opus-only weekly) | No, cannot separate Opus from total | Yes, surfaced on its own row |
| Knows if overage billing is live | No, /overage_spend_limit is not in local logs | Yes, polled every 60 seconds |
| Knows if subscription is past_due | No | Yes, via /subscription_details |
| Accounts for the 4.7 tokenizer expansion | No, local token count is pre-expansion | Yes, server applies it before utilization is returned |
| Counts hidden adaptive-thinking tokens | No, omitted thinking is not in JSONL | Yes, already in utilization |
| Exposes state over localhost HTTP for scripting | No | Yes, http://127.0.0.1:63762/snapshots |
| Multi-account support | No | Yes, iterates /api/account memberships |
The honest caveat
Every one of these endpoints is undocumented. The /usage shape has been stable for months, but /overage_spend_limit gained out_of_credits in a silent release, and /subscription_details has changed fields twice this year. ClaudeMeter deserializes into strict Rust structs, so a breaking change shows up as a parse error in the menu bar, not as silent wrong numbers. The repo is MIT and under 2,000 lines; you can read the entire request path in about ten minutes.
Watch the three endpoints live, for free
ClaudeMeter runs in your macOS menu bar, polls all three endpoints every 60 seconds, and serves the combined snapshot at 127.0.0.1:63762/snapshots. Free, MIT, no keychain prompt with the browser extension.
Frequently asked questions
What is the Claude Opus 4.7 rate limit in plain numbers?
There is no plain number. The limit is two utilization floats (five_hour and seven_day_opus) whose denominators depend on your plan (Pro, Max 5x, Max 20x). When either float reaches 1.0 the next Opus 4.7 request returns 429. Anthropic raised the denominators when 4.7 launched to offset adaptive thinking, but the raw numeric ceiling is never exposed to the client. The only authoritative signal is GET https://claude.ai/api/organizations/{org}/usage, which returns the current fraction.
Why do you say the rate limit is three endpoints, not one?
Because the outcome of a rate-limited request depends on three independent server facts. (1) /api/organizations/{org}/usage says whether your quota utilization is below 1.0. (2) /api/organizations/{org}/overage_spend_limit says whether extra-usage billing is enabled and has credit, which decides if a limit-exceeded call bills through or hard-stops. (3) /api/organizations/{org}/subscription_details gives the plan tier that sets the utilization denominator. ClaudeMeter polls all three in src/api.rs lines 16 to 60.
What is the difference between 'hitting the limit' and '429'?
They are not the same event. 'Hitting the limit' means a utilization float reached 1.0. What happens next depends on /overage_spend_limit. If extra_usage.is_enabled is true and out_of_credits is false, your request is metered against the monthly_limit and returns 200, so there is no 429. If is_enabled is false or out_of_credits is true, the same prompt 429s. ClaudeMeter reads this endpoint on every 60-second tick so the distinction is visible before you send the request.
Where is the Opus 4.7 limit actually enforced, client-side or server-side?
Server-side, entirely. The tokenizer change in Opus 4.7 runs on Anthropic's infrastructure. The 1.0x to 1.35x expansion is applied before the token count is written to your utilization buckets. Any client-side token counter (including ccusage and Claude-Code-Usage-Monitor) is reading a pre-expansion number. That is why your local log and your Settings page disagree after a heavy Opus 4.7 session.
Can I check the rate limit from a shell script before I send a request?
Yes, if you run ClaudeMeter. The menu-bar app starts a localhost HTTP bridge at http://127.0.0.1:63762/snapshots (extension/background.js line 2). The browser extension POSTs a fresh snapshot to that URL every 60 seconds, so a shell script can curl the same URL and read utilization, overage, and subscription at once. No auth, loopback only. This is the piece that distinguishes ClaudeMeter from any local-log reader: the rate-limit state is served over HTTP on your machine.
What fields in the JSON actually matter for Opus 4.7 specifically?
Four. usage.five_hour.utilization (shared with Sonnet, hard gate), usage.seven_day_opus.utilization (Opus-only weekly, 4.7 fills this fastest because of the new tokenizer and adaptive thinking), overage.is_enabled and overage.out_of_credits together (decide fallback vs 429), and subscription.status (inactive or past_due overrides everything else). The other usage fields (seven_day_sonnet, seven_day_oauth_apps, seven_day_omelette, seven_day_cowork) exist in the payload, but Opus 4.7 traffic does not trip them on their own.
How often do I need to re-read these endpoints?
ClaudeMeter polls every 60 seconds. That cadence is set in extension/background.js line 3 (POLL_MINUTES = 1). You can tighten it, but the usage bars on claude.ai itself only refresh once a minute, so faster polling just duplicates the same response. A 60-second cadence is enough to catch a bucket crossing 0.80 (ClaudeMeter's warn threshold in background.js line 87) before you type your next prompt.
If I hit the limit, when does it actually unblock me?
The server returns a resets_at ISO-8601 timestamp inside the Window struct alongside every utilization fraction (src/models.rs lines 3 to 7). For five_hour it is usually somewhere inside the next five hours, sliding on each request. For seven_day_opus it is usually a fixed UTC rollover. The popup formats this as 'now, Xm, Xh, Xd' in extension/popup.js lines 17 to 27. Treat it as authoritative, not the 'weekly reset' that Anthropic's public help center describes.
Does the overage endpoint exist for every account?
No. /overage_spend_limit returns 404 on free accounts and on Pro accounts that have never touched extra usage. The Rust client in src/api.rs lines 31 to 45 treats that case as a soft None rather than an error. The TypeScript extension does the same in extension/background.js line 27. If your account does not return an overage object, the rate limit is binary: under 1.0 you are fine, at 1.0 you 429.
How is this different from just reading ~/.claude/projects/*.jsonl with ccusage?
Local JSONL files are a record of what your Claude Code client logged, not what Anthropic billed. They miss the 4.7 tokenizer expansion (applied server-side), adaptive thinking tokens that 4.7 hides by default (display: omitted), any peak-hour multiplier, and the overage/subscription state entirely. ccusage answers 'how many tokens did my machine send.' ClaudeMeter answers 'what will Anthropic do on my next Opus 4.7 request.' Both are useful; they are not substitutes.
Is there an API I can call without running ClaudeMeter?
Yes, but only with a logged-in claude.ai cookie. Open DevTools on claude.ai/settings/usage, copy the Cookie header from the Network panel, and curl https://claude.ai/api/organizations/{your_org_uuid}/usage. The org UUID is in the URL of any /settings page. Anthropic has not documented this endpoint, and they can change the shape at any time. ClaudeMeter is open source so you can read the exact request shape in src/api.rs before you try it yourself.
Keep reading
Claude Code Opus 4.7 usage limits
The same rate limit from the Opus-only weekly angle. Where seven_day_opus lives in the schema and why 4.7 fills it faster than 4.6.
Claude Pro 5-hour window quota
five_hour is not a 45-message counter. One float on a sliding clock, shared across every model. How and when it resets.
The Claude rolling window cap is seven windows
Anthropic publishes two rolling windows; the endpoint returns seven. Every field, what it gates, and which ones Opus 4.7 actually trips.
Got a payload that breaks the three-endpoint model?
If your account returns an extra Opus-specific field, a different overage shape, or a subscription state the decision tree does not cover, send it over. We patch the struct same day.
Book a 15-minute call →