Claude Code Usage Limit Calculator: When Does Your Window Actually Run Out?

Usage draws down on a rolling 5 hour window and a weekly window at the same time. A rolling window is not a calendar block: it opens when your usage starts and it carries with you, so the reset is always measured from that opening rather than from the top of the hour.

Because both run together, the one that empties first is the one you feel. Late in a heavy week the weekly window binds even though the session bar looks comfortable, and that is exactly the case where waiting five hours changes nothing. The calculator names which window binds rather than reporting both and leaving you to guess, since the answer decides whether you should take a break or stop for the week.

The usage view does more than draw two bars. It attributes recent consumption to skills, subagents, plugins and individual MCP servers, each as a percentage of the total, and it flags behaviours such as long context and cache misses when they are driving the number up.

That breakdown is the actionable half. If this calculator says your pace cannot reach the reset, the fix is not to type less. It is to look at which line in that attribution is large and unexpected: an MCP server pulling more context than you remember granting it, a subagent fanned out wider than the task needed, or a session long enough that the cache is being missed on every turn.

Not ideal for: deciding between plans. Nothing here compares Pro against Max, because doing that honestly would need the quota numbers that are not published.

The help centre is explicit that Pro and Max usage limits are shared across Claude and Claude Code, so all activity in both counts against the same limits. The same article notes that using Claude Code inside VS Code, its forks, or JetBrains IDEs counts toward that same usage. On Teams and Enterprise, each member draws on a per-seat allowance that resets on the same pair of windows and is shared with Claude chat and Cowork.

This is the usual explanation for a burn rate that looks wrong. An afternoon of long chat threads in the browser shows up in the terminal as a window that emptied faster than the work in front of you can account for.

The cost command computes its dollar figure locally, from session token counts priced at standard list rates. The documentation is direct about who that is for: it is intended for API users, and subscribers have usage included in their subscription, so the session cost figure is not relevant for their billing.

It is also computed from local session history on one machine, which means usage from another device or from claude.ai is not in it. Two developers comparing dollar figures across laptops are comparing two partial views. The plan usage bars are the ones tied to the windows, and they are the ones this calculator takes as input.

Search this keyword and you will find tables handing out hours per plan, messages per window, prompts per five hours. I went looking for where those numbers come from. The mechanism is documented in detail. The capacity is published too, but only in relative terms: the pricing page says Max gives 5x or 20x the usage of Pro per 5-hour session, and that a Team premium seat is 5x a standard seat. The same page says how much you can do depends on the length and complexity of your work.

A multiplier with no base cannot be resolved into hours. Twenty times an unpublished number is still an unpublished number, and the complexity caveat means it would not be a constant even if it existed. That is the whole reason this page has no plan dropdown. Reading a percentage out of the CLI is less convenient than picking Pro or Max from a list, and it is the only version of this tool whose output does not rest on a figure somebody made up. If an absolute quota is ever published, a plan selector becomes possible and this section will say so.