anthropics / anthropics/claude-code
Fable 5.1 weekly limit is never surfaced in the CLI: the client receives it, labels it 'Fable', then drops it
- Lenguaje dominante
- Python
- Estrellas
- 145k
- Forks
- 23.1k
- Métricas de merge de PR
- Métricas de PR pendientes
Descripción
## 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:
```js
["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:
```js
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:
```js
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.
Guía de contribución
No hay ninguna guía de contribución indexada para este repositorio
Línea de trabajo
Start by locating the statusline hook payload builder and the experimental get_usage control-protocol request, then trace how unifiedWindows and model_scoped rate limits reach /usage. Preserve the existing model_scoped fields display_name, utilization, and resets_at in the statusline payload and add the same per-model breakdown to /usage. Done means both CLI surfaces show the server-provided Fable window.
Escrito por el modelo de indexación a partir del texto del issue.
Evaluación
- Stack tecnológico
- python
- Área
- api, cli
- Tipo de issue
- Nueva funcionalidad
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Estado de actividad
- Activo
- Claridad
- Bastante claro
- Aptitud para principiantes
- 55/100