A flat monthly AI subscription is not unlimited. Plans carry usage limits because each request consumes real compute, so a fixed fee has to be paired with a cap. One provider documents a five-hour session limit plus a weekly limit on its Pro and Max plans, shared across its chat apps and coding tool.
What the documentation says
Anthropic's help article on using its coding tool with Pro or Max plans says both plans have a five-hour session limit and a weekly limit, and that Max also has a separate weekly limit for one model family. It states the limits are shared across its web, desktop and mobile apps and the coding tool, so activity in any of them counts. You see warnings as you approach a limit.
The article does not explain the pricing logic behind the design, and it does not say exactly when the five-hour window starts. This post does not guess at either. What can be said generally is that a flat fee covers a variable resource, and a rolling short window plus a longer weekly one limits both bursts and sustained heavy use.
Two windows, two jobs
| Window | What it limits | What you notice |
|---|---|---|
| Session (five hours) | Bursts of heavy use | A long agentic session stops mid-day |
| Weekly | Sustained heavy use | Running out before the week ends |
Both are about consumption, not message count. A short question and a request that reads a large repository are not equal. The same article ties the need for more capacity to larger repositories, and links to guidance on using the plan efficiently.
What happens when you hit one
The article lists options. On Pro: upgrade to a higher plan, turn on usage credits, switch to API credits from the developer console, or wait for the reset. On Max: move to a higher multiple, enable usage credits, use API credits, or wait. If you choose API credits inside the coding tool, they are billed at standard API rates, separate from the plan. It also says that if you hit the session limit mid-response, the tool may finish the current step, and that this counts toward the weekly limit.
How to stretch a plan
These habits follow from how usage accumulates, and are consistent with the idea that bigger context means more consumption:
- Start a fresh conversation for a new task instead of continuing a very long one. Long histories are resent on each turn.
- Point the tool at the files that matter rather than the whole repository.
- Use a smaller model for routine edits when the plan lets you choose.
- Stop a loop that is not converging instead of letting it run.
For why history size matters, read what counts toward a context window.
Plan or metered API
Subscriptions suit individuals with bursty, interactive use. Metered billing suits automated or shared workloads where you need a bill that follows usage and controls such as workspace spend limits. We compared the two for coding in subscription vs API for coding. For team governance, an API with limits per workspace is easier to attribute.
For security teams, note that a personal subscription login on a work machine is also an identity and data question, not only a cost one.
Worked example: two people, one plan type
These situations are illustrative. Priya uses an assistant for short questions and drafting emails, a few dozen small exchanges a day. Marcus runs a coding agent for hours against a large repository, with long sessions that keep growing.
Priya rarely sees a warning. Marcus hits the session limit mid-afternoon, then the weekly limit by Thursday. Both pay the same flat fee, yet their consumption differs by a large factor. That difference is the reason limits exist in a flat plan, and it is why the help article ties higher needs to larger repositories.
What Marcus can do, using the options the article lists, is enable extra usage, switch to metered API credits for heavy work, move up a plan, or change habits. What he should not do is guess at reset times, since the article does not state when the five-hour window begins.
Habits that lower consumption
| Habit | Why it helps |
|---|---|
| One conversation per task | Long histories are carried on each turn |
| Point to specific files | Less material read into context |
| Ask for diffs, not full rewrites | Shorter output |
| Stop a stalled attempt early | Avoids paying for loops |
| Use a lighter model for chores | Where the plan allows a choice |
These follow from how context accumulates, as explained in what counts toward a context window.
A team policy for plans
If your company allows subscriptions for developers, write down:
- Which plans are approved, and who pays.
- Whether work data may be used with personal accounts. A personal login on a work machine is an identity and data question.
- What to do on hitting a limit: wait, request extra usage, or move to a company API key with workspace limits.
- Who reviews usage and how often.
For metered alternatives and team limits, see how to set spend and workspace limits.
Documenting the rule for your team
Write a half page that says what the plan limits are according to the provider, where to see remaining usage, and what an employee should do when they hit one. Link the help article and note the date. Keep it short enough that people read it. A clear rule prevents the two worst outcomes: people sharing credentials to get around limits, and people moving sensitive work to an unapproved tool.
What a manager should ask before buying seats
When a team lead considers plans for developers, a few questions save trouble. Which people will use the plan every day, and which will use it weekly? Do they work on large repositories or documents, which the help article links to higher needs? Is there an expected burst, such as a release week? Who will pay for extra usage if it is allowed? And is the plan approved for work data under your policies?
Run a two week trial with a handful of people and ask them to note each time they hit a limit and what they were doing. That list shows whether habits or capacity is the issue. Revisit after the trial, and write the decision down with the date so you can check it when plan terms change.
What this means for you
A flat fee buys an allowance, not an unlimited supply. Knowing the shape of the allowance, a short session window and a longer weekly one, helps you plan heavy work and avoid being cut off mid task.
Common mistakes
Typical mistakes are assuming a plan is unlimited, running a huge task at the end of a window, keeping one long chat for everything, guessing at reset times the provider does not publish and sharing credentials to get around a limit. Check your usage page, plan big jobs and use the documented options when you need more.
Try it yourself
Click through it at your own pace, or open it full screen. It shows an AI assistant working with Safeguard. Watch how the assistant's work is tied to your project data and guardrails, a useful picture of using an AI tool under company rules instead of a loose personal login.
Quick check
Are paid AI plans unlimited?
Not on the plan documented here. It has a five-hour session limit and a weekly limit, shared across the chat apps and the coding tool.
Do all activities count toward the limit?
The help article says activity in the apps and the coding tool both count toward shared limits.
Can I keep working after I hit a limit?
The article lists options such as usage credits, API credits, upgrading, or waiting for the reset.
Sources
Last reviewed: 19 October 2026.
