Anthropic Cuts Claude Code Weekly Limits by 17%

A 17% cut means, in practice, losing one out of every six units of weekly work with the agent. That is the adjustment Anthropic is applying to the current weekly limits of Claude Code, according to the report published by BleepingComputer.

For anyone using Claude Code every day, the number matters less than its unit: this is not a short window that recovers in a few hours, it is the cap that defines how much work fits into a week.

What is known and what is not

The available information is limited to the percentage cut on current weekly limits. There is no detail on whether the adjustment applies equally across plans, from what date, or how it is split between models. Until Anthropic spells it out in its usage documentation, the sensible move is to treat the 17% as a magnitude rather than a table, and to check the real consumption of your own account before replanning anything. It is also worth not extrapolating to the API: Claude Code limits and API consumption are different things, and the headline only covers the former.

Why it matters more than it looks

Short limits are absorbed by waiting. A weekly cap is not: if the team burns through it on Thursday, Friday is worked without the agent. That turns the limit into a planning variable rather than a passing annoyance. A team that had calibrated its week assuming a certain margin has to recalibrate with 83% of the previous budget, and the heaviest tasks (long refactors, migrations, reviews across large repositories) are precisely the ones that tolerate stopping halfway worst.

There is also a second order effect. When the weekly budget tightens, the incentive is to launch fewer exploratory runs and more well prepared ones. That is healthy discipline, even if it arrives imposed: every badly specified task that has to be repeated now costs a little more than it did last week.

How to absorb the cut without doing less work

What has worked for us at ElephantPink mostly points in the same direction: spend context only where judgement is involved.

1. Model per task. Renames, formatting, mechanical extraction and boilerplate generation do not need Opus 4.8. Haiku 4.5 or Sonnet 4.6 handle that stretch at a considerably lower cost.
2. Bounded context. Rereading a 2,000 line file to change three of them is paid for on every turn. Reading ranges, keeping a short CLAUDE.md and closing sessions that no longer contribute anything is the cheapest lever available.
3. Delegate to subagents. A subagent returns the conclusion, not the dump of the twelve files it had to open to get there. The main context stays small for longer.
4. Hooks for what needs no judgement. Formatting, linting and tests in PostToolUse run on their own. Asking the model to do it on every turn is paying tokens for something a shell command does better.
5. MCP servers that filter. An MCP that returns 400 rows so the model can keep three is burning budget. Filtering belongs in the server, not in the prompt.

None of these measures offsets 17% on its own, but together they cover quite a bit more than that in most of the workflows we have measured.

Our take

Adjusting limits in a product with real marginal cost is normal, and it is preferable to the silent alternative of quietly degrading quality behind the scenes. What can reasonably be asked of Anthropic is predictability: clear figures, notice with some margin, and a simple way to see your own consumption before hitting the cap. The cut is annoying, and even so a good part of the work it forces (less useless context, more delegation) is work we should already be doing.