Fable 5.1 weekly limit is never surfaced in the CLI: the client receives it, labels it 'Fable', then drops it

Status Open
Reported on v2.1.260
Maintainer reply None cached
Activity 1 comment · opened Sep 4, 2026

The problem

Fable 5.1 is gated by its own weekly limit, separate from the account-wide 5-hour and 7-day windows. There is no way to see that limit from Claude Code.

It is not in the statusline hook payload, not in /usage, and not in any file or endpoint a script can read. A subscriber learns where they stand exactly once: when the session stops and prints You've hit your ... limit. The remaining quota for the model is visible on claude.ai — which is the one surface that is not spending it.

The client already has the number

This is not a case of the data being unavailable to the CLI. Verified against the installed binary, 2.1.260:

1. The per-model window arrives on every API response. The internal schema for unifiedWindows, read from the anthropic-ratelimit-unified-* response headers, includes:

seven_day_overage_included: { utilization, resetsAt }

described in the binary as "overage-included weekly (per-model bucket; present only for accounts whose responses carry that window)".

The rateLimitType enum alongside it is:

["five_hour", "seven_day", "seven_day_opus", "seven_day_sonnet", "seven_day_overage_included", "overage"]

2. There is already a shape for it, and it names Fable explicitly. The experimental get_usage control-protocol request returns:

rate_limits: {
  five_hour, seven_day, seven_day_oauth_apps, seven_day_opus, seven_day_sonnet,
  model_scoped: [{ display_name, utilization, resets_at }],
  extra_usage: { ... }
}

with display_name documented in the binary as:

"Server-supplied label for the model bucket (e.g. 'Fable')."

and model_scoped as:

"Per-model weekly windows from the server limits[] array, filtered by the overage-included-models allowlist. Additive — present only when the server emits them."

3. The statusline payload builder copies three keys and leaves the rest behind. The object literal that becomes rate_limits in the hook payload:

ko = {
  ...go.five_hour && { five_hour: { used_percentage: go.five_hour.utilization*100, resets_at: go.five_hour.resets_at } },
  ...go.seven_day && { seven_day: { used_percentage: go.seven_day.utilization*100, resets_at: go.seven_day.resets_at } },
  ...Ie() === "gateway" && go.overage && { spend_limit: { used_percentage: go.overage.utilization*100, resets_at: go.overage.resets_at } }
}

The source object carries the other windows. They are simply never read.

So the value is received, parsed, modeled, and given a human-readable label carrying the model's own name — and then omitted from the one hook whose entire purpose is to display session state.

What I am asking for

Surface the per-model weekly window in the CLI:

  1. In the statusline payload, as rate_limits.model_scoped — the shape already defined for get_usage, so no new modeling is required. Each entry has the display_name, utilization and resets_at a status line needs.
  2. In /usage, broken down per model rather than as a single account-wide weekly figure.

A user on a paid plan should be able to see how much of the model they are running is left, from the tool that is consuming it, without opening a browser.

Environment

  • Claude Code 2.1.260
  • Windows 10 Pro 19045
  • Model claude-fable-5-1
  • Custom statusline script reading the hook payload from stdin

Related issues

#73770 and #89769 are open and ask for the same thing.

Worth noting for triage: #87207, #85964, #84280 and #82656 were each closed as duplicates, with their filers directed to follow #52661 so it could be "tracked in one place". #52661 was then closed as not planned by the stale-issue bot on 2026-08-15, for inactivity. The issue four separate reporters were told to follow no longer exists, which is presumably not the intended outcome of consolidating them.

View original on GitHub ↗

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