Weekly limit depletes disproportionately to 5h-session limit on Max 20x — quantified telemetry shows ~5x drift vs historical baseline

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Weekly usage limit on Max 20x is depleting 2-5x faster relative to actual token consumption than my historical baseline, even after extensive client-side mitigation. The 5h-session and weekly buckets appear miscalibrated relative to each other since the May 6 5h-doubling rollout.

Quantified observations:

1. Statusline drift (real-time): I run a custom statusline tracking delta-to-linear-consumption-curve for both buckets. At a single moment: 5h window shows -43% (well below expected linear burn), weekly shows +21% (well above expected linear burn).

1. Drift accumulates with usage, not time: Within the same 5h window, 13 minutes apart, a 1pp 5h-burn produced a 1pp weekly-drift increase. The weekly bucket should mathematically be ~33x larger than a single 5h slot, so 1pp 5h ≈ 0.03pp weekly would be expected. Observed ratio is roughly 33x off.

1. Day-to-day token comparison via ccusage:

April 24, 2026 (pre 5h-doubling, 5 parallel projects, intensive terminal switching):

• Cost: $242.30
• Total tokens: 322,501,893
• Cache creates: 10,887,933
• Cache reads: 310,808,556
• Output: 802,419

May 9, 2026 (post 5h-doubling, 1 project, 1 session, subjectively less intensive):

• Cost: $627.52
• Total tokens: 1,042,274,342
• Cache creates: 10,763,960
• Cache reads: 1,029,659,911
• Output: 1,844,324

Cache-create counts are nearly identical (10.9M vs 10.8M), implying comparable distinct-context volume. But cache-reads are 3.3x higher and total cost 2.6x higher despite a less intensive workload. The shape of consumption changed, not the workload.

1. Historical baseline: Peak week pre-May 6 consumed ~$3,800 in API-equivalent cost = ~70% weekly limit. May 9 alone consumed ~$627 = ~25% weekly limit in 13h. Per-dollar weekly burn rate is roughly 5x the historical rate.

What Should Happen?

Weekly limit consumption should remain proportional to actual token throughput, with the weekly bucket sized to accommodate many full 5h sessions — not roughly two, which is what the current 1pp:1pp drift ratio implies.

After the May 6 5h-limit doubling, either the weekly limit should have been doubled commensurately, or the per-token weekly cost should be unchanged. Currently neither appears to hold: the same workload pattern that previously consumed ~$3,800 for 70% weekly should not now consume ~25% weekly in a single day for ~$627.

Error Messages/Logs

No CLI errors. The issue is silent — visible only in usage telemetry, not in error logs.

ccusage outputs are included in the "What's Wrong?" section above.

Statusline screenshots showing the -43% / +21% drift at two timestamps 13 minutes apart in the same 5h window are available on request (cannot embed in this form). Happy to share via DM or attached comment.

Steps to Reproduce

This is a usage-pattern observation, not a deterministic CLI failure. To reproduce or verify the discrepancy:

1. Use Claude Code on a Max 20x plan with substantial Opus consumption (multiple sessions per day, 100M+ tokens per day).
2. Pull daily totals from ccusage for a pre-May-6 day and a post-May-6 day with comparable workload character.
3. Compare per-dollar and per-token consumption against weekly-limit progress in /usage.
4. Observe that the same per-token cost generates more weekly-bucket consumption than before May 6.

Configuration during my observations:

• CLI: 2.1.138 (latest)
• Models: Opus 4.6 (manually pinned to avoid Opus 4.7 tokenizer + 1M-context default)
• Auto Mode: off
• /compact: triggered manually at 40% context
• DISABLE_TELEMETRY: not set (cache-TTL fallback bug from earlier versions does not apply)
• Cache hit ratio: ~96:1 read-to-write (healthy, no client-side caching pathology)

Despite all of the above mitigations, the +21% weekly drift persists in real-time.

Hypothesis space:

1. Weekly-limit calibration was implicitly reduced relative to the 5h limit during the May 6 rollout, but not communicated.
2. Cache-reads are now weighted differently in weekly-limit accounting than in pre-May-6 behavior or in API-credit accounting.
3. Server-side tracking discrepancy similar to the prompt-caching bug that triggered the Feb 27, 2026 fleet-wide weekly reset.

Related: #57632

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.123

Claude Code Version

2.1.138

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

<img width="514" height="106" alt="Image" src="https://github.com/user-attachments/assets/617fdc0d-fdb2-4d4e-aa27-52779b6eeb27" />
<img width="462" height="78" alt="Image" src="https://github.com/user-attachments/assets/35dc45d5-de7d-4013-ad31-3cf609b99337" />

Values calculated by this formula:

five_h=$(echo "$input" | jq -r '.rate_limits.five_hour.used_percentage // empty')
five_h_resets=$(echo "$input" | jq -r '.rate_limits.five_hour.resets_at // empty')
seven_d=$(echo "$input" | jq -r '.rate_limits.seven_day.used_percentage // empty')
seven_d_resets=$(echo "$input" | jq -r '.rate_limits.seven_day.resets_at // empty')

# 5h + 7d delta
if [ -n "$five_h" ]; then
  five_h_int=$(printf '%.0f' "$five_h")
  c=$(color_for "$five_h_int")
  five_seg="5h ${c}$(bar "$five_h_int") ${five_h_int}%${reset}"

  # 5h: Restzeit vor Label, Abweichung dahinter
  if [ -n "$five_h_resets" ]; then
    now_ts=$(date +%s)
    window5=$((5*3600))
    remain5=$(( five_h_resets - now_ts ))
    [ "$remain5" -lt 0 ] && remain5=0
    elapsed5=$(( window5 - remain5 ))
    [ "$elapsed5" -lt 0 ] && elapsed5=0
    [ "$elapsed5" -gt "$window5" ] && elapsed5=$window5
    target5=$(awk -v e="$elapsed5" -v w="$window5" 'BEGIN { printf "%.1f", e/w*100 }')
    delta5=$(awk -v u="$five_h" -v t="$target5" 'BEGIN { printf "%.0f", u-t }')
    if [ "$delta5" -gt 3 ]; then dc5="$red"
    elif [ "$delta5" -lt -3 ]; then dc5="$green"
    else dc5="$yellow"
    fi
    if [ "$delta5" -ge 0 ]; then sign5="+"; else sign5=""; fi
    rh=$(( remain5 / 3600 ))
    rm=$(( (remain5 % 3600) / 60 ))
    remain5_str=$(printf '%d:%02d' "$rh" "$rm")
    five_seg="${gray}${remain5_str}${reset} ${five_seg} ${dc5}${sign5}${delta5}%${reset}"
  fi

  if [ -n "$seven_d" ] && [ -n "$seven_d_resets" ]; then
    now_ts=$(date +%s)
    window=$((7*86400))
    elapsed=$(( window - (seven_d_resets - now_ts) ))
    [ "$elapsed" -lt 0 ] && elapsed=0
    [ "$elapsed" -gt "$window" ] && elapsed=$window
    target_pct=$(awk -v e="$elapsed" -v w="$window" 'BEGIN { printf "%.1f", e/w*100 }')
    delta=$(awk -v u="$seven_d" -v t="$target_pct" 'BEGIN { printf "%.0f", u-t }')
    if [ "$delta" -gt 3 ]; then
      dc="$red"
    elif [ "$delta" -lt -3 ]; then
      dc="$green"
    else
      dc="$yellow"
    fi
    if [ "$delta" -ge 0 ]; then sign="+"; else sign=""; fi
    five_seg="$five_seg ${dc}${sign}${delta}%${reset}"
  fi

  out="$out   |   $five_seg"
fi