The Same Announcement Reads as '+25%' and as 'a 17% Cut' — Checking the Math on Claude Code's September 14 Weekly Limit Change

On the morning of August 30, I checked the help center to confirm when the weekly limit boost would end. The page said it ran through August 31, 2026. The day before, however, Anthropic's developer account had announced something different: the boost continues through September 13, and from September 14 the standard weekly limit itself rises permanently. For more than a full day, the official permanent documentation and the official announcement disagreed with each other.

As an indie developer, I run Claude Code every day for the routine processing behind my apps and for automated operations across several sites, so this date mismatch was not something I could shrug off. I had been sketching my September schedule on the assumption that the extra capacity would disappear at the end of August. If you have been planning around the same assumption, here is what I found once I sat down and checked the numbers.

The short version: what changes, and when

The scope is narrow: this applies to the weekly limit for Claude Code on Pro, Max, Team, and seat-based Enterprise plans. The 5-hour rolling window is unaffected. The limits for Claude on web, desktop, and mobile, and for Cowork, are explicitly outside this promotion according to the help center.

One more thing worth pinning down: Anthropic has never published absolute token numbers for these weekly limits. The whole change can only be discussed in ratios — which also means that unless you measure your own consumption, you cannot judge whether it affects you at all. We will get to the measuring part below.

Why "+25%" and "a 17% cut" are both correct

The announcement says the standard weekly limit rises permanently by 25%. A follow-up posted the same day adds that, compared to today, this works out to roughly a 17% reduction for Claude Code. Growth and shrinkage, both describing one change. It looks contradictory until you notice that the two figures use different reference points.

Index the pre-promo standard weekly limit at 100 and the picture becomes clear:

The verification takes two divisions. 125 ÷ 100 = 1.25, hence +25% against the pre-promo baseline. 125 ÷ 150 ≈ 0.833, hence a 16.7% drop against today's level, which rounds to the 17% in the follow-up.

A misreading is making the rounds: "the boost goes from 50% to 25%, so that's a 25% cut." The arithmetic itself is wrong there — you should compare levels (150 versus 125), not increments (50 versus 25). In fairness, I nearly made the same subtraction when I had only read the headline.

Percentages are also irreversible in a way that matters here. Going from 150 down to 125 is a 16.7% decrease, but going from 125 back up to 150 would require a 20% increase. If you have quietly adopted the promotional level as the baseline in your budget planning, that asymmetry becomes your estimation error.

The transferable habit from this episode is small but durable: whenever a percentage appears in a vendor announcement — or in your own reports — write down the reference point next to it. "+25%" is meaningless on its own; "+25% versus the pre-promo standard" survives the next announcement intact. All three figures in this change (+25%, −17%, +50%) are honest numbers, and every misunderstanding I have seen so far came from dropping the reference point, not from the numbers themselves.

Whether you are affected is a /usage question

The only workloads this change actually hurts are the ones whose consumption has grown into the boosted capacity — the 150 side of the index — over the past three and a half months. If you have never hit the weekly limit, nothing changes for you in practice: from September 14 you are still at 125, above where you were before the promotion started.

Checking is straightforward. Run /usage inside Claude Code and read the "Current week (all models)" row. If that row sits comfortably below 100% at the end of a typical week, the September change is a non-event for you. If it regularly climbs past the 60–70% range, you are close enough that a 16.7% haircut deserves a closer look. Writing down today's value is the first step either way.

If typing the command every day feels tedious, you can put the number in your status line instead. A status line script receives JSON on stdin, and rate_limits.seven_day inside it carries the weekly consumption percentage (used_percentage) and the reset time (resets_at).

#!/bin/bash
# ~/.claude/statusline.sh — show weekly usage in the status line, log once per day to CSV
input=$(cat)
week=$(echo "$input" | jq -r '.rate_limits.seven_day.used_percentage // empty')
reset=$(echo "$input" | jq -r '.rate_limits.seven_day.resets_at // empty')
 
if [ -n "$week" ]; then
  # Append one line per date, so the log gets exactly one entry a day
  log="$HOME/.claude/week-usage.csv"
  today=$(date +%F)
  grep -q "^${today}," "$log" 2>/dev/null || echo "${today},${week}" >> "$log"
  printf "week %s%% (resets %s)" "$week" "$reset"
else
  printf "week: n/a"
fi

Register it in ~/.claude/settings.json and it appears from the next session onward:

{
  "statusLine": {
    "type": "command",
    "command": "~/.claude/statusline.sh"
  }
}

The practical point of the daily CSV is the comparison across the cutover date. With two weeks of values banked before September 13, you can see how your consumption rate behaves after September 14 in your own numbers rather than in the vendor's ratios. The rate_limits object also exposes five_hour, seven_day_opus, and seven_day_sonnet — from which you can read off the underlying structure: one shared weekly pool with per-model inner allowances.

If you do hit the limit, start with model allocation

Suppose the log shows you have been reaching the weekly ceiling. The realistic lever that requires no plan change is the pool structure just mentioned: the weekly pool is shared across models while holding per-model inner limits for Opus and Sonnet. Moving your routine, repetitive steps off the most expensive model shifts the weekly consumption profile directly.

I split models across my own site operations, so I have decided not to wait for September 14 — I am re-measuring the allocation for routine steps like article formatting and asset classification now. One prerequisite before counting what unattended runs consume: confirm that the runs themselves are all actually firing as scheduled. I wrote up that verification procedure, including a case where half of my scheduled runs had silently stopped launching, in Half of My Scheduled Runs Vanished Without a Single Error.

Announcements move first, documentation follows

Back to the mismatch I opened with. As of August 30, the help center page still said the boost ran through August 31. The announcement channel moved first; the permanent documentation lagged behind. This episode made the ordering unusually visible.

If your capacity planning treats support articles as the source of truth, it is worth flipping the order: read the announcements first, then check whether the documentation has caught up. And anchor the final decision not in official ratios but in your own measurements. Open /usage today and note your current weekly consumption — the baseline that keeps September 14 from being a surprise starts with that one line.