Your agentic loop has its own private bucket called seven_day_oauth_apps, and it's the one that 429s you.
Almost every guide on this topic talks about the rolling 5-hour cap or the all-up weekly quota, as if there is one number a loop has to stay under. There isn't. The endpoint that powers claude.ai/settings/usage returns seven separate Window fields, each with an independent utilization fraction and an independent resets_at. An OAuth-authenticated agentic client (Claude Code, an MCP host loop, a CLI that signed in through OAuth) is counted in a specific one called seven_day_oauth_apps. That bucket is invisible to every local-log tracker on the planet. It is the bucket your loop will actually 429 against. This page is about how to see it.
The mistake every other write-up makes
The shape of the question is wrong. "What is the agentic loop usage limit on Claude Pro?" presupposes one number. There isn't one. Anthropic's consumer plans run a fan of rolling windows side by side: a 5-hour bucket that catches bursts, a 7-day all-up bucket that catches sustained throughput, two model-specific 7-day buckets (Sonnet and Opus), a client-auth-specific bucket for OAuth-authenticated apps, and two more internal-codename buckets the team has not documented publicly. Each of these has its own ceiling and its own clock.
A 429 fires the moment any one of them passes 100%. So the answer to the question is not a number, it's a pointer: figure out which Window field your loop is actually pushing. For most agentic workflows on a Pro or Max plan, that field has a name. The name is seven_day_oauth_apps.
The seven Window field names returned by /api/organizations/{org}/usage. Each carries its own utilization and resets_at.
The anchor fact, in 0 lines of Rust
The simplest way to verify the seven-Window claim is to read the parser ClaudeMeter ships. The struct below is from src/models.rs in the open source repo at github.com/m13v/claude-meter. If a field on the response disappears, this struct fails to deserialise loudly. If a new one appears, it reads as None and you patch the struct.
Each field is the same Window shape: a utilization fraction and an absolute UTC reset timestamp. That is the unit of every limit on your plan.
See your own seven_day_oauth_apps in 30 seconds
You don't have to install ClaudeMeter to confirm any of this on your own account. You just need DevTools, a curl, and a Cookie header.
The Referer header is load-bearing. Drop it and you get a 403. ClaudeMeter sets it on every poll for the same reason (src/api.rs line 126).
The seven Windows, one card each
What each bucket actually measures, in plain language. The OAuth-apps card is the one your agentic loop will live and die in.
five_hour
Rolling 5-hour window. Counts every call from every client logged into your account, regardless of how it authenticated. The slide is continuous; resets_at on this Window moves with it.
seven_day
All-up rolling 7-day. The big aggregate. If this is at 100%, you are out across the board. Less interesting for an agentic loop than the OAuth-apps split below.
seven_day_sonnet
7-day rolling restricted to Sonnet generations. Splits by model, not by client. A loop running mostly Sonnet shows up here.
seven_day_opus
Same shape, restricted to Opus. Hits hard if your loop ever picks Opus for planning steps. Independent of seven_day_sonnet.
seven_day_oauth_apps
The agentic-loop bucket. Counts traffic from clients that signed in via OAuth (Claude Code, MCP host loops, OAuth-authenticated CLIs). Independent ceiling. Independent resets_at. This is almost always the one that 429s an agentic workflow first, and it's the one local-log readers cannot see at all.
seven_day_omelette
Internal codename. ClaudeMeter parses it because it ships in the JSON. Inspect your own response to see how it moves on your account.
seven_day_cowork
Internal codename, appears tied to a Claude-Code-flavoured surface. Same Window shape: utilization plus its own resets_at.
What the JSON looks like in the wild
Below is a representative shape of the response from a real account mid-loop. The interesting line is the gap between five_hour at 12% and seven_day_oauth_apps at 91%. The loop hasn't been bursty in the last few hours, but it has been steady all week, and Anthropic is counting that on a separate bucket from the all-up 7-day.
“A loop at 12% on five_hour and 91% on seven_day_oauth_apps will 429 from the second number, not the first. You cannot see this from a JSONL counter.”
claude-meter, src/models.rs:18 + extension/background.js:7
How the cookie reaches the endpoint without a single paste
One Manifest V3 extension, one credentials: 'include' fetch
The cookie never leaves Chrome's cookie jar. The extension asks Chrome to attach it on the outgoing request. The menu bar app reads the snapshot off a localhost socket and identifies which browser sent it by looking up the peer TCP socket's owning process.
What different trackers actually see when an agentic loop is running
Local-log readers are useful for token counting and only token counting. They cannot see seven_day_oauth_apps because the bucket has no on-disk representation; it is computed by Anthropic against a denominator the server never reveals.
| Feature | Other open source trackers | ClaudeMeter |
|---|---|---|
| Sees five_hour utilization (the rolling 5-hour cap) | Local-log readers (ccusage, Claude-Code-Usage-Monitor, phuryn): No. Cookie-paste readers: Yes after paste. | Yes. Live, every 60 seconds, no paste. |
| Sees seven_day_oauth_apps (the agentic-loop bucket) | Local-log readers: No, never. The bucket lives only on the server. Cookie-paste readers: Yes after paste, until the cookie rotates. | Yes. The Manifest V3 extension reuses your live claude.ai cookie via credentials: 'include'. |
| Sees the per-bucket resets_at and surfaces it as 'in 2d 7h' | Local-log readers: No. Cookie-paste readers: Sometimes; many surface only the all-up 7-day. | Yes. Every Window's resets_at is parsed and rendered in the menu bar and CLI. |
| Survives an Anthropic field rename without going silently wrong | Most parsers: silent drift if a field disappears. ClaudeUsageBar: silent. lugia19's extension: noisy on the chat-UI side. | Loud failure. Parses into a typed Rust struct (src/models.rs). A rename shows '!' in the menu bar. |
| Setup: cookie copy-paste required | ClaudeUsageBar: Yes, every rotation. hamed-elfayome: Yes or embedded webview. ccusage: N/A (local). lugia19: No (browser-resident). | No. Manifest V3 extension; Chrome attaches the cookie automatically via credentials: 'include'. |
| Multi-org on one account (personal Pro plus work Team) | Local readers: per-machine logs only. Cookie-paste tools: one cookie at a time. lugia19: per active org. | Yes. Iterates account.memberships and polls /usage for every org. |
The five steps to take before your loop 429s
Step 1: Identify which bucket your loop is moving
Open claude.ai/settings/usage with the loop running. The fraction that climbs fastest is the one you're constrained by. For most agentic Claude Code workflows that's seven_day_oauth_apps; for chat-heavy work it's five_hour first. ClaudeMeter exposes all seven so you don't have to keep refreshing the settings tab.
Step 2: Read the resets_at on that bucket, not the calendar
The 7-day buckets are rolling, not Sunday-midnight. resets_at is an absolute UTC instant when the oldest counted traffic falls off. If seven_day_oauth_apps shows resets_at = 2026-04-29T17:42:13Z, that's when capacity starts releasing on the OAuth-apps bucket specifically. Other buckets reset on their own clocks.
Step 3: Decide whether to throttle the loop or upgrade the plan
If five_hour is the binding constraint, your loop is bursty and throttling fixes it. If seven_day_oauth_apps is the binding constraint, throttling alone won't help: you have a sustained-throughput problem against a weekly ceiling, and the answer is either a higher tier (the denominator is bigger), splitting the loop across an OAuth-authenticated and a Console-API path, or accepting the cap.
Step 4: Pick a tracker that surfaces the actual binding bucket
If you can't see seven_day_oauth_apps, you can't tell whether you're 12 hours from a 429 or 4 days. Local-log readers show you tokens sent, which correlates loosely. ClaudeMeter, ClaudeUsageBar (after paste), hamed-elfayome's app (after webview sign-in), and lugia19's chat-UI extension all read server truth in some form. Pick the one whose setup story you tolerate.
Step 5: Pin a parser that fails loudly
Every server-truth tracker reads an undocumented endpoint. Anthropic can rename a field on any deploy. ClaudeMeter deserialises into a typed struct so the menu bar shows '!' instead of an old number when a field disappears. If you build a custom dashboard against this endpoint, mirror that pattern: typed parse, loud failure, never optimistic.
Honest tradeoffs
The endpoint is undocumented. Anthropic can rename seven_day_oauth_apps on a deploy, drop it, or fold it into seven_day. If you build a custom dashboard against this field, deserialise into a typed struct so a rename surfaces as a loud failure instead of an old number that quietly stops moving. ClaudeMeter does this in src/models.rs.
The seven_day buckets are rolling, not calendar-aligned. The resets_at on the Window object is the only honest countdown. If your loop ran continuously seven days ago, that's when the bucket starts releasing capacity, hour by hour, not all at once at a wall-clock midnight.
ClaudeMeter is macOS-only and the maintainer has said Linux/Windows aren't planned. If you're on Linux, the same curl above works just as well in a cron; you just don't get a menu bar. The bucket is the same. The fix is the same.
See seven_day_oauth_apps live in your menu bar
ClaudeMeter is free, MIT, and the menu bar binary plus the Chrome extension take about three minutes total. The extension does not ask for a session key. The CLI prints --json if you want to feed the bucket into your own dashboard.
Trying to keep an agentic loop under the OAuth-apps weekly cap?
Bring the loop. We'll walk through which bucket is actually binding and what to do about it in 15 minutes.
Frequently asked questions
What is the actual usage limit an agentic loop hits on a Claude Pro or Max plan?
Not one limit. Three at minimum, evaluated independently. The five_hour rolling window measures everything you and any client logged into your account sent in the last 5 hours. The seven_day all-up window measures the same thing across 7 days. And seven_day_oauth_apps measures the subset that came from OAuth-authenticated clients (Claude Code, agentic CLIs, MCP host loops that signed in through the OAuth flow rather than carrying a console API key). An agentic loop can be at 12% on five_hour and 91% on seven_day_oauth_apps because the loop has been hammering one bucket all week without a heavy session in the last few hours. The 429 fires against whichever Window passes 100% first.
Where does the seven_day_oauth_apps field actually come from?
It is a field on the JSON body returned by GET https://claude.ai/api/organizations/{org_uuid}/usage, which is the same private endpoint claude.ai/settings/usage renders from in your browser. It is not on api.anthropic.com. It is not in the Console. It is not exposed in any OpenAPI document. ClaudeMeter parses it directly into a typed Rust struct (src/models.rs lines 18 through 28), and the Manifest V3 extension (extension/background.js lines 5 through 12) fetches it with credentials: 'include' so your browser attaches the existing claude.ai session cookie. No paste, no keychain prompt.
How is seven_day_oauth_apps different from seven_day_sonnet or seven_day_opus?
The model-named buckets (seven_day_sonnet, seven_day_opus) split usage by which model generated the answer. seven_day_oauth_apps splits by how the client authenticated. A Claude Code session that picks Sonnet for code review and Opus for hard tasks contributes to seven_day_sonnet, seven_day_opus, AND seven_day_oauth_apps simultaneously. The cap on each is independent, so an agentic loop that mostly drives Sonnet can blow seven_day_oauth_apps without ever stressing seven_day_opus.
Why can't ccusage or Claude-Code-Usage-Monitor see this?
Both of those tools walk ~/.claude/projects/*.jsonl on disk and sum the inputTokens and outputTokens recorded in each transcript line. That is a numerator. seven_day_oauth_apps is a fraction whose denominator the server keeps private and adjusts on its own deploys. A local-log reader can tell you how many tokens this machine sent. It cannot tell you what fraction of your plan ceiling Anthropic counted, because the ceiling is not on disk. ClaudeMeter calls the same private endpoint claude.ai/settings/usage uses, which is the only place that fraction lives.
What are seven_day_omelette and seven_day_cowork?
Two more Window fields ClaudeMeter parses out of /api/organizations/{org}/usage. They appear to be Anthropic's internal codenames for product surfaces (a casual reading is that 'cowork' covers the Claude-Code-style coworking sessions and 'omelette' covers another internal lane). Anthropic has not documented them publicly. ClaudeMeter exposes them because they ship in the JSON whether you read them or not, and ignoring fields that exist is how trackers go quietly wrong on a deploy. If you want to see them on your account, hit the endpoint in DevTools and inspect the response.
Does an agentic loop running through the Console API hit any of these buckets?
No. The consumer plan endpoints under claude.ai/api/organizations and the Console API under api.anthropic.com are completely separate billing surfaces. Console API traffic is metered by tokens per minute and billed against your prepaid balance, with anthropic-ratelimit-* HTTP response headers exposing the per-minute counters. The five_hour, seven_day, and seven_day_oauth_apps fields only count traffic against your Pro or Max plan. If your loop signs in via OAuth to consume your plan quota (the way Claude Code does by default), it lands in seven_day_oauth_apps. If it carries an sk-ant- key from the Console, it never touches /api/organizations/{org}/usage at all.
When does seven_day_oauth_apps actually reset?
The same Window struct ClaudeMeter parses for every bucket has a resets_at field that is an absolute UTC timestamp, not a clock-time interval. The seven_day window is rolling, not calendar-aligned, so resets_at moves forward as the oldest counted traffic falls off the trailing 7-day boundary. ClaudeMeter prints this as 'in 2d 7h' in the menu bar. There is no scheduled Sunday-midnight reset; if your loop ran continuously seven days ago, that's when this bucket starts releasing capacity, hour by hour.
Can I curl this endpoint myself to confirm seven_day_oauth_apps is real?
Yes. Open claude.ai/settings/usage in DevTools. In the Network tab, find the /api/organizations/{some_uuid}/usage request and right-click > Copy as cURL. Run it from your terminal. The response is a JSON body with seven Window fields including five_hour, seven_day, seven_day_sonnet, seven_day_opus, seven_day_oauth_apps, seven_day_omelette, and seven_day_cowork. The Referer header is load-bearing; drop it and the request 403s. ClaudeMeter does the same call automatically every 60 seconds and POSTs the snapshot to a localhost bridge at 127.0.0.1:63762 so the menu bar stays current without you opening DevTools again.
If I'm on Max 20x, are these buckets bigger or just the same shape?
Same shape, bigger denominator. The /api/organizations/{org}/usage endpoint returns seven Window fractions on every plan tier from Pro through Max 20x; the difference is the ceiling each fraction is computed against. ClaudeMeter does not need to know your tier, because the server already collapsed it into a 0..1 fraction. This is also why a 'pure tokens' tracker mis-reads tier upgrades: the same machine sending the same tokens shows 90% on Pro and 22% on Max 20x, but only the server knows that.
Will the field name seven_day_oauth_apps last forever?
No. It is undocumented and Anthropic can rename it on any deploy. ClaudeMeter mitigates by deserialising into a strongly typed Rust struct, so a rename surfaces as a loud parse error in the menu bar (you see '!' instead of a number) instead of a silently wrong fraction. If you write your own curl-and-jq dashboard against this field, plan for the rename. The internal field has been stable through April 2026 and has carried an agentic-loop-shaped utilization on every account I've checked.
Keep reading
Why local token counters cannot see what Anthropic enforces
Server quota is a fraction with a private denominator. Local counters have the numerator only.
Tracking a rolling 5-hour window without a stopwatch
The window slides continuously. resets_at on the Window struct is the only honest countdown.
Open source Claude usage trackers, sorted by what they actually read
Seven trackers, two camps: local-log vs server-endpoint. The agentic-loop bucket is only visible to the second camp.