The rolling 5-hour window is not a 5-hour timer. Here is how Claude Code actually behaves around it.

No. There is no 'session start' event on the server. The window is always defined as the 5 hours ending right now. When you send a message at 09:14, that message is in-window from 09:14 until 14:14 sharp. Send another at 11:30 and it is in-window until 16:30. The bucket measures the cost of every message that has not yet aged out, summed at this moment. Anthropic's help docs talk about a '5-hour session', which is true in the sense that the longest-lived message ages out at 5 hours, but not in the sense of a session timer that ticks down.

Nothing. There is no client-side warning, no progress bar, no 'you have 12% left' message. Claude Code keeps streaming responses normally until the server returns a 429 on the next prompt. The /usage slash command will print a snapshot, but it interrupts your loop and prints once. The first time most people learn the wall is right there is when the agentic loop hits it mid-refactor and aborts.

When the server's five_hour.utilization for your organization passes 1.0 on the request you just sent. The cost is computed server-side from message bytes, model used, peak-hour multiplier, attachments, and tool-call overhead, then added to the running tally. If the new tally crosses 1.0, that request returns 429 with a retry-after pointing at resets_at. Per ClaudeMeter's Rust deserializer at src/models.rs lines 4-7, the Window struct that holds this number has exactly two fields: utilization and resets_at. There is no 'started_at', no 'session_id', no 'first_message_at'. The server does not need any of those to enforce the cap.

Because the window is rolling, not session-based. Imagine your messages from the last hour cost 0.6 of your budget. You step away for 4 hours. When you come back, NONE of those messages have aged out yet, because the oldest one is only 5 hours old. The server still sees 0.6 of your budget consumed. Your only real reset point is when your specific oldest message ages out, and after that the next-oldest, and so on. Reset is gradual, not a cliff.

It is the timestamp when the OLDEST currently-counted message in your window will age out. On a steady Claude Code loop sending one message every couple of minutes, resets_at is roughly 5 hours after your earliest still-in-window message, and it shifts forward by a few minutes every time that earliest message ages out and the next-earliest takes its place. ClaudeMeter renders this in src/format.rs lines 75-98 by formatting the timestamp in your local time and computing the delta from now in days and hours; it never assumes the value is fixed.

Only in the moment, and only if your specific old prompts are heavy. Your utilization right now is the sum of every still-in-window prompt's weighted cost. Sending zero new prompts does NOT decrease utilization until the oldest in-window prompt ages out. If your earliest message in the window cost 30% of your budget, your utilization will not drop by that 30% until 5 hours after you sent it, regardless of what you do in between.

Yes. Pro and Max plans share one usage pool across claude.ai and Claude Code, per Anthropic's help article on using Claude Code with subscription plans. A long PR description you drafted in the browser at 10am is in your five_hour bucket until 3pm, even if you only run Claude Code in the afternoon. Local-token tools like ccusage cannot see the browser-chat half because nothing writes to ~/.claude/projects/*.jsonl when you talk to Claude in a browser tab.

Yes for the snapshot. Claude Code's /usage hits an OAuth-authenticated endpoint at api.anthropic.com/api/oauth/usage. claude.ai/settings/usage hits a cookie-authenticated endpoint at claude.ai/api/organizations/{org_uuid}/usage. Both return the same five_hour.utilization float (sometimes 0-1, sometimes 0-100 in the same payload, normalized by ClaudeMeter as `u <= 1 ? u * 100 : u`). The difference is /usage interrupts your CLI loop; the settings page is a tab; ClaudeMeter polls the same JSON every 60 seconds (POLL_INTERVAL at src/bin/menubar.rs:18) so neither breaks your flow.

Because messages age out. If you poll five_hour.utilization at 13:42 and again at 13:43, and between those two polls a heavy message from 08:42 aged out, the utilization at 13:43 is lower than at 13:42 even though you sent prompts in between. Local token-counting tools cannot show this because tokens do not un-spend themselves on disk. The server-side rolling tally can and does decrease.

Run ClaudeMeter alongside Claude Code. The macOS menu bar shows the live five_hour.utilization percent and the resets_at countdown, polled every 60 seconds from the same endpoint claude.ai/settings/usage uses. When you watch the bar instead of guessing, the wall stops being a surprise: you see it climb past 80%, you wrap up the current task, and you let the oldest messages age out. The browser extension forwards your existing claude.ai session so there is no cookie paste and no second login.