To make a Claude Code weekly limit last, keep each session short and specific, clear context between tasks, use a smaller model for routine work, and give each project a fixed share of the week that you check against /usage. Most of a blown limit comes from a few long sessions carrying a large context, and that is the easiest thing to change.
Everything stated about limits here comes from Anthropic's own pages, read in October 2026. Anthropic does not publish the limits as a number of prompts or hours on those pages, so there are no such numbers below.
How do Claude Code limits work?
Anthropic's help article on using Claude Code with a Pro or Max plan says both plans have "a five-hour session limit and a weekly limit", and that Max plans also have a separate weekly limit for Fable. Three facts shape everything else:
- The limits are shared. Activity in Claude and in Claude Code counts against the same limits. A long chat in the desktop app comes out of the same week as your coding sessions.
- The session limit resets every five hours and the weekly one once a week. The usage limits article does not name a day. Claude Code shows your reset time when you hit a limit, and
/usageshows where you stand before that. - Usage depends on what you send. The model you pick and the length and complexity of the conversation both count.
When you reach a limit you can wait for the reset or, if you have turned them on, continue on usage credits at extra cost. In an interactive session, Claude Code 2.1.234 or later waits in the open session and continues the task by itself after the reset, as long as you leave the session open.
What burns usage fastest?
Anthropic's cost documentation for Claude Code is specific about this. In rough order of how often each one catches me:
| Cause | Why it costs | Fix |
|---|---|---|
| Long context | Claude Code sends the full conversation with every request, and every batch of tool results adds another request. A one-line question in an all-day session draws usage for the whole conversation. | /clear between unrelated tasks |
| Cache misses | The first message after a break longer than the cache lifetime (an hour on a subscription) reprocesses the full context. | Finish or clear before a long break |
| Subagents and agent teams | Each one sends its own requests with its own context. The docs put agent teams at about seven times a standard session when teammates run in plan mode. | Use them for work that needs them |
| Model choice | The docs say Sonnet handles most coding tasks well and costs less than Opus. | /model; a smaller model for routine tickets |
| Thinking | Thinking tokens are billed as output tokens. | /effort lower for simple tasks |
| Scheduled tasks and loops | A loop fires on its interval even while the session is idle, sending the full context each time. | Stop loops you are not watching |
Where did my week go?
Run /usage. On a subscription it shows your plan usage bars and a breakdown of recent usage attributed to skills, subagents, plugins and individual MCP servers. It also flags behaviours, such as long context or cache misses, that account for 10% or more of recent usage. Press d or w to switch between the last 24 hours and the last 7 days.
One limitation to keep in mind: the docs say the breakdown is approximate and computed from session history on this machine, so usage from another computer or from claude.ai is not in it. The bars are the plan's own figures. The breakdown explains your local share.
How do you budget a weekly limit across projects?
The /usage breakdown attributes usage to skills, subagents, plugins and MCP servers. I have not found a view of it by repo, so I keep the split by hand. It takes two minutes a week.
- Decide the shares on reset day. For example: the project that ships this month 50%, the second one 30%, everything else 20%. Write it down.
- Read the weekly bar before and after a block of work. If the bar was at 22% when I sat down with a project and 31% when I stopped, that block cost nine points. One line in a notes file.
- Stop when a project's share is gone. This is the whole point. Without it, the most interesting project eats the week by Wednesday and the one with a deadline gets nothing.
For scripted runs there is a second signal. claude -p --output-format json includes a total_cost_usd field in its output. On a subscription it is not what you pay, and the docs call it a client-side estimate, but it is a consistent unit for comparing one run with another. Keep each project's run logs in its own folder and add them up:
cat ~/night-logs/shop/*.json | jq -s 'map(.total_cost_usd) | add'How should you schedule work against the resets?
- Know your reset time. It is on the limit message and in
/usage. Plan the week from that time. - Pace by day. If you work five days, about a fifth of the week per day is the line. Past it by a wide margin on day two means a change of model or scope for the rest of the week.
- Use the end of the week for speculative work. The limit resets, so allowance left on the last day is the cheapest you will have. That is when I queue the experiments and the big refactor I was not sure about.
- Cap unattended runs.
--max-turnsstops aclaude -prun that is going in circles before it takes the evening's allowance with it. The setup is in How to run Claude Code overnight, safely.
Why do small tickets use less?
Because cost follows context, and a small ticket has a small context. Compare two ways of doing the same afternoon of work:
- One session, four hours. By the end, every request carries the files, test output and conversation from all four hours. Take a break longer than the cache lifetime and the next message reprocesses all of it.
- Six tickets, each in a fresh session. Each starts with the project instructions and the files that ticket needs. Nothing from ticket two is paid for again during ticket five.
A ticket is small enough when you can write it in a paragraph that names the files, the behaviour and the check. The docs make the same point from the other side: a vague request such as "improve this codebase" triggers broad scanning, while a specific one lets Claude work with minimal file reads. Give the agent a test it can run, so it finds its own mistakes without three more rounds with you. Tests first with coding agents shows how.
Small tickets are also the ones you can review quickly, which matters once you run more than one agent. See How to manage multiple Claude Code and Codex sessions.
Where Vakr fits
The notes file works until you have several projects and agents running while you are away. Vakr, the Mac app I make for people who run Claude Code and Codex, gives each Project a share of your weekly limit and shows it next to the Project's progress and agents. Budgets are part of the free tier. A queue that holds a task until your limit allows it, and a week plan that paces queued runs against the limit, belong to the paid tier, which is not on sale yet; during early access everything is unlocked. Vakr uses the subscription you already have and never sells tokens. There is a waitlist.
Questions
When does the Claude Code weekly limit reset?
Once every week. Anthropic's help pages do not name a fixed day. Claude Code shows the reset time in the message when you hit the limit, and /usage shows your current standing.
Does using Claude chat count against my Claude Code limit?
Yes. Anthropic states that the limits are shared across Claude and Claude Code, so all activity in both counts against the same limits.
How many prompts or hours do I get per week?
The help pages I checked give no number. Usage depends on the model, the length of the conversation and the tools in use, so two people on the same plan can get very different amounts of work out of a week.
Does /clear really save usage?
Yes. Claude Code sends the full conversation with every request, so stale context is paid for on every later message. /clear starts a fresh context. Use /rename first if you want to find the old session again with /resume.
How Vakr compares with other tools for running agents: One, Orca, T3 Code, Agentbox and Conductor.