Introtext
You opened VS Code at nine, sent a single "morning" prompt, and the usage indicator already says 15% gone. That is not a bug. The Claude Code five-hour limit is a rolling window, not a fixed block, and the way it accounts for tokens is loaded against the kind of work senior developers do. Here is what the window actually measures, why a quiet day can still hit the wall by lunch, and what the structural fix looks like.
---Fulltext
TL;DR: The 5-hour limit is a rolling capacity window, not a “Claude got tired” mystery. Work stops when the bucket empties; it resumes when capacity returns — or when another account/lane still has headroom.
The 5-hour rolling window — not what most people think
The phrase "5-hour limit" sounds like a block. Drink your coffee, wait until the top of the hour, get a fresh five hours to spend. That is not how it works. Anthropic's published rate-limit documentation describes the cap as a rolling 5-hour window. The clock starts when you send your first prompt of a new window. Every subsequent prompt accrues toward the same budget until five hours after that first prompt has elapsed, at which point the earliest entries begin to "roll off." If you ration carefully across the whole five hours, the window is constantly recovering at the same rate you spend. If you front-load your usage, you can hit the cap inside the first hour and then wait the remaining four hours staring at a countdown. The window is per-account. There is no day boundary, no weekend reset, no time-of-day grace. The five hours are wall-clock hours measured from your individual activity, anchored to your own behavior. This is the loudest complaint of 2026 on the Claude Code subreddit. The pattern is universal: a developer opens VS Code, runs one or two real tasks, the indicator is suddenly at 60%, and they cannot understand what just happened. The published number — N messages per 5 hours — sounded reasonable. Their reality does not match it.Why a one-line "Morning" can burn 15% of the budget
The mental model most users carry is that "one prompt = one unit of cost." That is not how Claude Code accounts for tokens. Every turn carries far more weight than the user-typed text. A representative single-turn cost in a real Claude Code session: - **System prompt:** 4K to 8K tokens, sent on every turn. This contains the model's behavioral instructions, tool definitions, and project context. - **Tool definitions:** 6K to 20K tokens depending on which MCP servers and built-in tools are wired up. Every call carries the full tool schema for every available tool. - **Project context:** Whatever the editor injected from CLAUDE.md, AGENTS.md, the open file, the IDE selection, and recently-read files. Easily 10K to 50K tokens on a project of any size. - **Conversation history:** Every prior turn in the session, replayed in full. After ten turns of real work, the replay alone can be 30K tokens. - **The user's actual text:** Often less than 100 tokens. The "Morning" you typed. A Reddit thread put it the way the rest of us were already feeling: > a simple 'Morning' took 15% of the 5h limit That is not exaggeration. It is the prompt-cache discount working harder than people realize, and the token bill being larger than people expect. Even with caching, the headers Anthropic returns count cache reads against some accounting. The "Morning" prompt itself was free. The 50K tokens of replayed context behind it were not. The lesson is that the 5-hour window is sensitive to context size, not to typing volume. A developer who keeps long sessions open with a lot of project context attached will burn the cap faster than a developer who opens a fresh session per task. Most senior workflows do the former.The compounding effect on heavy days
The 5-hour window does not exist in isolation. It is the short throttle that sits on top of the 7-day rolling cap. If today's spend is already against the weekly budget, tomorrow's spend has less room to maneuver before the 7-day ceiling kicks in. A worked example, with realistic numbers: | Day | 5-hour windows used | % of weekly budget burned | Cumulative weekly burn | |---|---|---|---| | Monday | 2 (morning + afternoon) | 25% | 25% | | Tuesday | 2 (morning + afternoon) | 25% | 50% | | Wednesday | 1 (morning) | 15% | 65% | | Thursday | Attempt morning session | Cap hit immediately | 65%+ | By Thursday morning you are not blocked by the 5-hour window — you have a fresh one. You are blocked by the 7-day window, which has been quietly accumulating Monday and Tuesday's spend and refusing to let Thursday's heavy session start. The 5-hour countdown is what you see. The 7-day cap is what is actually stopping you. This is what produces the "unusable for 5–6 days per week" pattern that floats through every Claude Code complaint thread. Two heavy days early in the week makes the rest of the week effectively gated by the slower-recovering weekly cap.What most developers try when the wall hits
The progression is predictable: 1. **Stare at the countdown.** The cheapest move in attention, the most expensive in wall-clock time. A `Retry-After: 3600` is one hour of unscheduled break. 2. **Open Claude.ai in a browser tab on a different account.** Sometimes works. The browser-based product has its own rate-limit accounting and gets you unblocked for a short prompt. It does not help when you need Claude Code's tool-using session continuity. 3. **`git stash` and switch projects.** A workflow trick:…