A weekly-cap workflow that actually fits inside seven days

On a rolling 7-day window from your first prompt, not a fixed wall-clock time. So if you sent your first prompt of the week at 09:14 on a Tuesday, that prompt rolls off the window at 09:14 the following Tuesday. The cap is in addition to the 5-hour session window, which resets every five hours from the first message of a session. Both can fire on the same prompt: a single chat turn can be the one that pushes you over a 5-hour ceiling, a weekly ceiling, or both. The streaming response from Anthropic includes a rateLimitType field that tells you which one was hit ('five_hour' or 'weekly') plus a resetsAt UNIX timestamp for the exact unlock moment.

Anthropic announced the new weekly rate limits for Claude Pro and Max on July 28, 2025 and rolled them out on August 28, 2025. The official estimate at announcement time was that the new limits would apply to less than 5 percent of subscribers based on then-current usage, so most casual Pro users will hit the 5-hour window long before they ever brush against the weekly cap. The weekly limits matter for heavy Claude Code users, anyone running a long Sonnet or Opus session every working day, and people who script multiple agents against the same plan. Source: Anthropic on X, July 28 2025, plus the Pro/Max plan pages on claude.com.

Anthropic's published ranges at the August 2025 rollout: Pro ($20/mo) gets approximately 40 to 80 hours of Sonnet per week through Claude Code. Max 5x ($100/mo) gets 140 to 280 hours of Sonnet plus 15 to 35 hours of Opus. Max 20x ($200/mo) gets 240 to 480 hours of Sonnet plus 24 to 40 hours of Opus. The ranges are wide because the actual hours depend on your prompt size, tool-call count, and how much output you stream. A heavy prompt with a lot of cached input and a long output burns the same wall-clock minute faster than a one-shot generation. Anthropic does not publish a precise token-to-minute formula.

Haiku is on the same family of plans, but it is the cheapest model and burns the weekly hours far slower than Sonnet for the same work. Anthropic's published ranges are stated in Sonnet and Opus hours, not Haiku hours. Practically, a Haiku turn for scaffolding, file edits, copy tweaks, or trivial tool calls is the cheapest way to make forward progress when your Sonnet hours are running thin. mk0r leans on this directly: src/app/api/chat/model/route.ts pins FREE_MODEL = 'haiku' for anonymous and free-tier sessions, and the model picker in src/components/header.tsx exposes Haiku, Sonnet, and Opus separately so a Pro user can route the easy turns to Haiku and reserve Sonnet for the turns that actually need it.

Inside Claude.com on a Pro, Max, Team, or seat-based Enterprise plan: Settings then Usage. There are progress bars for the 5-hour session window and the weekly limits. The page distinguishes Opus from non-Opus usage because the Opus weekly cap is separate from the overall weekly cap. Inside Claude Code or a builder that streams the structured rate_limit_event, you also get a real-time signal: the event includes a utilization field between 0 and 1 that tells you how close to the cap the most recent prompt left you. A status of 'allowed_warning' is the soft warning that you are approaching the wall.

Anthropic's streaming response carries a rate_limit_event with a rate_limit_info object. The event carries eight fields: status (allowed, allowed_warning, rejected, unknown), resetsAt (UNIX milliseconds for the unlock moment), rateLimitType (e.g. 'five_hour' or 'weekly'), utilization (0 to 1), overageStatus, overageDisabledReason, isUsingOverage, surpassedThreshold. mk0r forwards all eight at src/core/vm-scripts.ts:143-163, typed in src/lib/chat-events.ts:73-83. The stock @agentclientprotocol/claude-agent-acp wrapper drops the message because it has no mapping for rate_limit_event yet, which is why most Claude-backed builders surface only a generic 'something went wrong' toast.

Only when a deadline is real. Extra usage on Max plans is billed at standard API rates, which is fine for a single high-value session but adds up across a week. The cheaper move 90 percent of the time is to wait the rolling window out. Read the resetsAt epoch the streaming response gives you, convert it to your local time, and schedule the next heavy session for then. If the work cannot wait, the API path with prompt caching (cache reads at 0.1x base, cache writes at 1.25x base for the 5-minute cache) is usually cheaper than enabling extra usage on the consumer plan, because cache reads bill against the API account directly and you control the cache hit rate.

No, not if the new builder uses the same Anthropic credentials. The cap travels with the credentials, not the tool. If both builders authenticate against your Pro plan via OAuth, or both use your personal API key, you hit the same wall in both places. The only way to route around the weekly cap is to route through different credentials: a separate Anthropic API account, a different OAuth identity, or a different model provider entirely for the work that does not have to be Claude. The flip side: connecting a builder via OAuth instead of an API key means the build sessions bill your Pro plan, which is exactly what you want when Pro is otherwise sitting idle while the API spend climbs.

Three things, all readable in the source. First, anonymous sessions are pinned to Haiku at src/app/api/chat/model/route.ts line 5 (FREE_MODEL = 'haiku'), so the cheapest model carries the first turn and the next-prompt iteration loop. Second, signed-in users with a connected Pro or Max plan get the OAuth path: src/app/api/chat/route.ts decides between the shared API key and the user's OAuth blob, and inference billed against an OAuth scope absorbs into the same plan they already pay for. Third, when a weekly cap actually fires, the patched ACP forwards the structured event so the chat UI can show 'usage limit reached, resets at H:MM' instead of a generic error toast. Three small things, but together they turn the weekly cap from a brick wall into a planned schedule.