The weekly cap that kills long Claude Code workflows is not the one you are watching.
Your six-hour refactor 429s at the four-hour mark. claude.ai web chat in the other tab still works fine. That asymmetry is the tell: the bucket that fired is seven_day_oauth_apps, not the aggregate seven_day field the web settings page shows. Below is the pre-flight check, the live signal to watch while the loop runs, and the abort threshold.
Read the OAuth-apps bucket, not the aggregate.
Long Claude Code workflows charge seven_day_oauth_apps, a typed weekly bucket on the same /api/organizations/{org}/usage payload claude.ai/settings/usage already calls but never renders. The settings page draws one bar (the 5-hour bucket) and a "low" label for everything else. The OAuth-apps bucket is the one that actually walls your CLI. If it is above 0.70 before you start a multi-hour refactor, the cap will fire mid-workflow. Source: the open-source claude-meter parser at src/models.rs, lines 18 to 28.
The bucket the CLI does not name
claude-meter parses every weekly bucket the server returns. They are declared as first-class Rust struct fields, which means the layout is stable across releases and you can read the exact contract without guessing. The OAuth-apps bucket is the one labeled below; everything you submit through the Claude Code CLI charges it. The aggregate seven_day bucket is the one the web Settings page draws; it includes both your CLI traffic and your web traffic, but it is not the cap that fires for a CLI-driven long workflow.
One Window for each bucket. utilization is a float on [0.0, 1.0]. The server 429s your CLI the moment any one of them crosses 1.0, and the CLI does not tell you which one fired. For long workflows the only float that matters in practice is seven_day_oauth_apps. Sonnet-vs-Opus splits and the aggregate are secondary checks.
Three phases of a long workflow against the cap
The framework is just three numbers read at three different moments. Pre-flight asks "should I start?" Mid-flight asks "is the slope still safe?" Abort asks "can I land this before 1.0?" Same field, three decisions.
Pre-flight: read the right bucket before you start
seven_day_oauth_apps, not seven_day. Anything above 0.70 means the cap will fire mid-workflow on any realistic six-hour Claude Code session.
Mid-flight: watch the slope, not just the level
ClaudeMeter polls every 60 seconds. The 10-minute delta is your burn rate. If the float climbs by 0.05 in 10 minutes you are at 0.30 per hour and a wall is coming whether the level is 0.55 or 0.85.
Abort: stop the loop before 0.92, not after 1.0
A 429 mid-tool-call sometimes leaves the project in a half-edited state where the next session has to re-read context. That re-read itself charges the same bucket. Soft-aborting at 0.92 with a manual git commit preserves the work and the quota.
Pre-flight: a 60-second check before kicking off
The default print of the claude-meter CLI shows the 5-hour bar, the aggregate weekly, and the Sonnet/Opus splits. The OAuth-apps bucket is one jq command away. Run both before you fire the long refactor; the OAuth-apps number is the one that decides whether the workflow can land.
The reading above (seven_day_oauth_apps at 0.72) means roughly 28% of the OAuth-apps weekly quota is left. On a typical Opus 4.7 refactor that climbs at 0.05 to 0.10 per hour, that is at most six hours of headroom and probably less. A 30-hour workflow is not going to fit. Split it, drop to Sonnet, or wait.
The feasibility formula
You do not need a calculator. The mental model is one ratio.
delta_utilization over the last 10 minutes is your honest burn rate right now. Two readings 10 minutes apart from claude-meter give you that. Divide remaining_quota_share by it to get minutes until the wall. Compare to the workflow you are about to start. If the wall arrives first, change the plan.
Mid-flight: what the slope tells you that the level does not
The level (current utilization) is a snapshot. The slope (change per minute) is the signal. ClaudeMeter polls every 60 seconds, which means after 10 minutes of a running workflow you have a real burn rate to read against. Two diagnostics fall out of this:
- A sudden 5x slope means the loop just escalated model class (Sonnet to Opus, often silently) or doubled the prompt context. Catch it within minutes, not after the wall.
- A flat slope after a refactor means the next phase is going to be cheaper than the last one. You can let the loop run with confidence. Long agentic workflows have phases; the model is not charging at a constant rate.
Abort: why 0.92 is the right threshold, not 1.0
Stopping the loop yourself at 0.92 is cheaper than stopping at 1.0. When a 429 fires mid-tool-call, Claude Code occasionally leaves the working directory in a half-edited state. The next session needs to re-read context to figure out where you left off; that re-read itself charges the same bucket you just walled on. So you lose work AND quota.
A soft abort at 0.92 means you manually break the loop, run git commit -am "WIP: long workflow checkpoint", and decide between three continuations. Drop to Sonnet (charges seven_day_sonnet separately and might still have room). Enable extra_usage and let metered billing finish the run. Or sleep until resets_at on the bucket that is closest to firing. claude-meter prints resets_at as an absolute UTC timestamp; two parallel agents in different shells converge on the same wake-up moment because it is not a relative duration.
What the inline CLI error throws away
The CLI prints one generic string for all eight buckets. Everything you need to plan around a long workflow lives on the same JSON the web settings page already calls; it is just not surfaced inline.
| Feature | Claude Code inline error | claude-meter (this product) |
|---|---|---|
| Knows seven_day_oauth_apps exists | No. The CLI emits one generic rate_limit_error string for all eight buckets. | Yes. seven_day_oauth_apps is a typed field on UsageResponse (models.rs line 24). |
| Pre-flight number before the workflow starts | Nothing. You have to type /usage manually inside an active claude session. | claude-meter (the CLI) or the menu bar bar; one keystroke or one glance. |
| Live burn-rate signal during a long loop | Token counts in ccusage; useful, but unrelated to the float the server enforces. | Polls every 60 seconds. The 10-minute delta on the bucket is your burn rate. |
| Names the specific bucket that walled you when 429 fires | No bucket name in the inline error. You guess. | Whichever bucket is at 1.0 in the popover is the one that fired. |
| Reports the absolute UTC resets_at | Inline error says 'try again later'. | Absolute timestamp per bucket; render as 'in 2h' or 'in 3d' via extension/popup.js. |
| Surfaces extra_usage dollar burn for post-wall continuation | Lives on a different endpoint (/overage_spend_limit); not in the CLI error. | Third row in the popover when extra_usage.is_enabled is true. |
Why ccusage does not catch this
ccusage and Claude-Code-Usage-Monitor read ~/.claude/projects/*.jsonl and sum input/output tokens per session. That is a real, useful number for project-level token attribution. It is not what the server enforces. Anthropic applies per-message weights that depend on model class, attachments, tool calls, and time-of-day multipliers, none of which are written to your local JSONL. The predictable outcome: ccusage says 5% used, the CLI 429s on the same workflow. They are measuring different things. Run them together; ccusage for token attribution, claude-meter for the float that gates your loop.
Where this comes from
Every number in this guide reads off two open files: src/models.rs declares the bucket shape, and src/api.rs is the once-per-minute fetcher. The browser extension at extension/background.js uses the cookie your browser already holds, posts the same JSON to a localhost bridge, and removes the manual claude.ai cookie-paste step that earlier OSS plan trackers required. MIT licensed.
Mid-refactor and the wall just fired?
Fifteen minutes to walk through your last 24 hours of buckets and decide whether to wait, split, or enable metered billing.
Frequently asked questions
Why does my long Claude Code workflow wall while claude.ai web chat in the other tab still works?
Because the bucket that fired is almost certainly seven_day_oauth_apps, not seven_day. OAuth-authenticated traffic (Claude Code CLI, MCP host loops, agentic Python scripts) charges its own weekly bucket. Web chat charges seven_day. The two are independent, so your account can sit at seven_day=30% and seven_day_oauth_apps=100% at the same time. The CLI 429s. The web tab does not. The field is declared as a first-class Option<Window> on UsageResponse at src/models.rs line 24 of the open-source claude-meter Rust source.
What's the pre-flight check before I kick off a six-hour refactor?
Read seven_day_oauth_apps utilization before anything else. If it is below 0.40, you have headroom. Between 0.40 and 0.70 you should split the work into checkpointable chunks. Above 0.70 the cap will fire mid-workflow on any realistic agentic loop and you should either wait for resets_at, drop to Sonnet (which charges seven_day_sonnet separately), or enable extra_usage so prompts after the wall bill against pay-as-you-go credits at API prices.
How fast does seven_day_oauth_apps actually climb during an active workflow?
Faster than seven_day, because every CLI message charges it and nothing else does. On Opus 4.7 a non-trivial multi-file refactor can move the float by 0.05 to 0.10 per hour. ClaudeMeter polls every 60 seconds so you can read the slope live; if you go from 0.62 to 0.68 in ten minutes, you are running at 0.36 per hour and a six-hour workflow will wall you near the four-hour mark. Drop to Sonnet, shorten the prompt context, or abort.
What's the abort signal I should set?
Stop the loop when seven_day_oauth_apps crosses 0.92 with more than 30 minutes of work remaining, or when (1.0 - utilization) divided by your last 10-minute burn rate is less than the remaining workflow duration. The first half-edited commit is recoverable; a 429 mid-tool-call sometimes leaves Claude Code in a state where the next session has to re-read context and that re-read itself charges against the same bucket.
Doesn't ccusage tell me this?
No. ccusage reads ~/.claude/projects/*.jsonl and counts input/output tokens. Tokens are not what Anthropic enforces. The seven_day_oauth_apps bucket applies per-message weights that depend on model class, attachments, tool calls, and time-of-day multipliers, none of which are in your local JSONL. The predictable outcome: ccusage says 5% used and the CLI 429s. They measure different things. Run them together; ccusage for token attribution per project, ClaudeMeter for the server-truth float that gates your loop.
If seven_day_opus is at 95% can I just switch to Sonnet and keep going?
Often yes. Each model has its own weekly bucket (seven_day_sonnet, seven_day_opus) on top of the aggregate seven_day and the OAuth-apps bucket. If seven_day_opus is full but seven_day_sonnet is at 50% and seven_day_oauth_apps is at 70%, switching the model class to Sonnet keeps you going until the next constraint binds. Most of a long refactor is mechanical (rename, move, adjust import, update test) and Sonnet handles it at a fraction of the weekly weight. Reserve Opus for the genuinely hard subproblems after reset.
Will enabling extra_usage save a long workflow from walling out?
Conditionally. If extra_usage.is_enabled is true on /usage and used_credits is below monthly_credit_limit on /overage_spend_limit, messages that would have walled instead bill against pay-as-you-go credits at API prices. If is_enabled is false, or out_of_credits is true, the wall stays. For a long workflow this is the realistic continuation path; you want the live dollar burn visible so you can decide to land the work or stop. ClaudeMeter renders extra_usage as a third row in the popover when it is present, sourced from the ExtraUsage struct at src/models.rs lines 9-16.
What does the resets_at field actually tell me?
Absolute UTC timestamp at which the oldest still-counted message ages out of the trailing 168-hour window for that specific bucket. It is not a calendar boundary. Two users at the same utilization will have different resets_at because their charging histories differ. claude-meter --json prints it; the extension popup renders it as 'in 2h' or 'in 3d' via fmtResets in extension/popup.js. For a long workflow this is the only honest 'when does my cap come back' number; anything else is a guess.
Is ClaudeMeter actually open source, and what does it send anywhere?
Free, MIT licensed, source at github.com/m13v/claude-meter. The browser extension makes one HTTPS request per minute to claude.ai using the session cookie your browser already holds, then posts the result to a localhost bridge at 127.0.0.1:63762 that the menu bar app listens on. No telemetry, no cloud account, no analytics ping. Read extension/background.js lines 14 to 44 if you want to audit the exact requests before you install.
Related guides
After the wall: which bucket fired and how to read it
Once 429 happens, the OAuth credentials Claude Code stashed in macOS Keychain plus api.anthropic.com/api/oauth/usage will name the bucket the CLI hid.
Hours are a vibes metric, the server enforces a float
Anthropic publishes Sonnet hours per plan; the cap that actually fires is a utilization float on a rolling 168-hour window with seven buckets stacked on top.
Personal OS workflows charge a different bucket entirely
Scheduled routines and Cowork runs charge seven_day_cowork and seven_day_oauth_apps simultaneously. The chat UI never shows either of them.
Comments (••)
Leave a comment to see what others are saying.Public and anonymous. No signup.