Fable 5 promotional usage allowance is inequitable — depends on weekly-reset timing, not usage

Resolved 💬 1 comment Opened Jul 5, 2026 by uguremrah Closed Jul 9, 2026

Summary

The temporary Fable 5 promotional allowance ("up to 50% of your plan's weekly usage limit," July 1 – July 7) is not applied fairly across users, because its size depends on when an individual account's weekly reset happens to fall relative to the promo window — not on how much anyone actually uses. Accounts whose weekly reset lands inside the July 1–7 window get their weekly quota (and therefore their 50% Fable allowance) refreshed a second time during the promotion, effectively doubling their usable Fable 5 quota. Accounts whose reset falls outside the window get only one allowance. Two customers on the same plan, paying the same price, end up with very different amounts of promotional Fable 5 access purely due to reset-day luck.

Background

  • Fable 5 returned on July 1, 2026, and Anthropic reset both 5-hour and weekly rate limits for all users on that date (the second such reset in three weeks, after a similar reset on June 13).
  • Per Anthropic's own announcement: "Until July 7, you can use up to 50% of your plan's weekly usage limit on Fable 5. If you hit your limit, you can continue on Fable 5 with usage credits. Fable 5 draws down usage faster than Opus 4.8." (https://x.com/claudeai/status/2072402639644766602)
  • Weekly usage limits reset "at a fixed time each week that is assigned to your account" (per the Claude Help Center), and that reset day/time is different per account — it is not synchronized to the July 1 promo start.

The fairness problem

Because the 50%-of-weekly-limit Fable allowance is recalculated every time an account's own weekly window resets:

  • An account whose weekly reset falls, say, on Saturday July 4 gets a brand-new weekly quota mid-promotion, and therefore a second 50% Fable allowance, entirely within the July 1–7 window.
  • An account whose weekly reset falls on Wednesday (before July 1, or on/after July 8) only gets one 50% allowance for the entire promotional period, because their reset never falls inside the window a second time.

This means the effective promotional benefit — real dollar/token value on a metered-after-cutoff product — differs by roughly 2x between otherwise-identical customers, based solely on which day of the week their account happens to reset. This isn't a usage-based or plan-tier difference; it's an artifact of promo-window/reset-cycle misalignment.

Concrete example (my own account)

  • Plan: Max (20x)
  • Weekly reset: Wednesday 6:59 PM — i.e., the next reset after the promo start falls on July 8, after the July 7 cutoff, so my account only gets a single Fable allowance for the whole promotional period.
  • Current weekly usage: All models 54% used, Fable specifically 78% used, with no second refresh coming before the promo ends.
  • By contrast, based on public reports, accounts whose weekly reset lands within July 1–7 get a full second allowance before the cutoff.

Ask

Please apply the same effective Fable 5 promotional value to all paid accounts, regardless of where their personal weekly-reset day happens to fall relative to the July 1–7 window. Some options that would fix this (any one would help):

  1. Prorate the promotional allowance by calendar time within the fixed July 1–7 window, independent of each account's own weekly-reset cycle, rather than deriving it from "50% of whatever the current weekly window is" every time that window happens to roll over.
  2. Cap the promotional allowance at one 50%-of-weekly-limit grant per account for the whole window, regardless of how many weekly resets occur inside it — so accounts with a mid-window reset don't get a second grant.
  3. Extend an equivalent one-time top-up to accounts that only received a single allowance window, so total promotional value is equalized across accounts.

Any of these would restore parity between customers on the same plan. Thanks for looking into this.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗