The rolling 5-hour wall in Claude Code is mostly your MCP servers, billed many times.

Yes, but only on cache-miss turns. Anthropic's prompt cache reads cached prefixes at 10% of the input rate, so a warm turn pays almost nothing for the system prompt and MCP tool definitions. The trap is the cold turn: model switch (Sonnet to Opus), /compact, MCP server toggle, or just a 5-minute idle gap (the default cache TTL) invalidates the cache. The next turn re-sends every byte of overhead and bills it at 1.25x input (the cache-write rate). 30K to 100K tokens of MCP definitions, billed several times per 5-hour window, is a real fraction of the five_hour bucket that ccusage cannot show you because the JSONL log lines are written before the server-side reweighting lands.

Anecdotal but consistent across heavy users: 8 to 15. Model switches alone cause one each: a refactor that starts on Sonnet, escalates to Opus 4.7 for the hard part, drops back to Sonnet for cleanup, is three cold turns. /compact is another, common in long sessions where the window pressure forces a flush. Toggling an MCP server (claude mcp add or remove) invalidates the tool-index region. And the default cache TTL is 5 minutes, so any pause longer than that, lunch, a Slack thread, a meeting, returns you to a cold prefix. Multiply 30K of MCP overhead by 10 cold turns and you have charged the rolling 5-hour bucket for 300K input-equivalent tokens worth of overhead before counting a single one of your prompts.

No. The Settings page renders a single bar for the five_hour field, period. Inside that float, MCP overhead, system prompt, file reads, your prompts, tool outputs, and thinking tokens are all blended into one utilization percentage. The endpoint returns no per-component breakdown. /context (inside Claude Code) shows the live breakdown of the 200K context window for the current turn only, but that is a different surface than the 5-hour bucket and it has nothing to say about the past 4 hours and 59 minutes that the bucket actually remembers. So you cannot directly read 'MCP is X percent of my 5-hour fill.' What you can do is watch the bar climb before and after pruning MCP servers and see the slope flatten.

Two-step: run /context inside Claude Code right now and note the tool-definition line; then poll GET https://claude.ai/api/organizations/{org_uuid}/usage and note five_hour.utilization. Run /context again 10 cold turns later (cause cold turns deliberately by switching model). The MCP tool definitions line will be the same; five_hour.utilization will have moved more than the ccusage local sum would predict. The delta minus the prompt-byte delta is roughly your MCP-overhead-times-cache-miss tax. Or skip the manual loop and watch ClaudeMeter, which polls /usage every minute and pins five_hour to the menu bar.

Mostly yes for context window, partly yes for the 5-hour bucket. With auto, Anthropic loads MCP schemas only when the eager set would exceed 10% of the context window (about 20,000 tokens). So a one-or-two-server setup gets eager loading and a five-or-more-server setup falls back to deferred (names only, ~120 tokens, schemas fetched on demand). For window pressure that is huge. For the 5-hour bucket it is still real but smaller, because when the model actually invokes a tool whose schema was deferred, that turn fetches and bills the schema, and that turn is by definition a cold turn for that schema. The net effect is fewer schema bytes flowing per session than the worst case, but the bytes that flow still re-bill on cache miss.

Different clock, same underlying tokens. seven_day_oauth_apps is the rolling 168-hour bucket that only fills from OAuth-authenticated traffic (Claude Code + MCP, not claude.ai browser chat). five_hour is the 5-hour bucket that fills from every client on the account. MCP overhead lands in both: it charges five_hour because it is part of every Claude Code turn, and it charges seven_day_oauth_apps because the Claude Code turn is OAuth-authenticated. So MCP-heavy users see both buckets climb. The 5-hour wall bites first inside one session, the OAuth weekly bucket bites first across a full week of work.

It buys headroom, not invisibility. Anthropic doubled the rolling 5-hour limit on Pro, Max, Team, and seat-based Enterprise plans on May 6, 2026. So the same MCP-overhead-times-cache-miss math now fills a 2x larger bucket; you hit the wall later, but at the same fill rate. And the weekly caps were not doubled, so the OAuth weekly bucket still climbs at the original rate. If you noticed the 5-hour wall less in mid-May and started noticing seven_day_oauth_apps walls earlier in the week, this is the reason.

From the same endpoint claude.ai/settings/usage renders. The Rust struct in src/models.rs at /Users/matthewdi/claude-meter declares UsageResponse with seven Window fields plus extra_usage; five_hour is the first one. The browser extension's extension/background.js polls https://claude.ai/api/organizations/{org_uuid}/usage every 60 seconds with credentials: 'include' (your existing claude.ai session cookie), POSTs the JSON to the menu-bar app on localhost:63762, and the SwiftUI popover renders five_hour.utilization plus its resets_at as a relative duration. No cookie paste, no telemetry, single HTTPS request per minute to claude.ai. Source: github.com/m13v/claude-meter, MIT license.

ccusage walks ~/.claude/projects/*.jsonl and sums input_tokens, output_tokens, cache_creation_input_tokens, and cache_read_input_tokens that Claude Code wrote during streaming. That is a faithful local-token measurement. It does not include the server-side tokenizer expansion, the peak-hour multiplier, or full thinking-token spend, all of which land on the five_hour float on the server. So on a session with several cache-miss turns and an MCP-heavy setup, ccusage's percentage typically lags the server's by 15 to 30 points. They are both right at what they measure; the server's number is the one that decides your next 429.

Three concrete moves. First, set the extended cache TTL flag so the cache stays warm across 5-minute idle gaps; this turns a lot of would-be cold turns warm. Second, stop manually switching models mid-session unless the next turn genuinely needs the bigger model; every switch is a guaranteed cold turn that pays the full MCP overhead. Third, drop MCP servers you do not actively use this week; each pruned heavy server (Jira-class is ~17,000 tokens by itself) shrinks the per-cold-turn re-bill. ClaudeMeter does not change any of these for you; it lets you see whether each move actually flattens the five_hour slope.