v5.5.0

Added

usage_fable segment — a per-model weekly usage gauge, showing the separate weekly limit that /usage lists as its own row. Uses the same gauge styles, colors, and forward-looking ratio as usage_5hour / usage_weekly, and takes the same gauge and width options.

  ██   94 % → 10:28     ██   83 % → Sat 18:14   Fable ██   77 % → Sat 21:59
  └─ 5h ────────────┘   └─ weekly ──────────┘   └─ per-model ─────────────┘

Despite the name the segment is generic:

Option	Values	Default	Description
model	model display name	Fable	Which per-model limit to show (case-insensitive)
only_current	0/1	0	Show only while that model is active; also skips the usage request in other sessions
label	full/short/none	full	Label left of the gauge — Fable, F, or none. Text follows model=
gauge	vertical/blocks/none	blocks	Gauge style
width	even integer >= 2	4	Gauge width

Changed

usage_fable is included in the default segment list. It is self-gating, so it stays invisible on accounts without a per-model weekly limit.

Limitations — please read

This segment cannot use the modern data path, and that has consequences worth knowing:

• Claude Code's stdin rate_limits carries only five_hour and seven_day — no per-model data at all, verified live through CC 2.1.220. The only available source is the deprecated OAuth API.
• It therefore costs a usage request. Disk-cached for SL_USAGE_CACHE_DURATION (default 300 s), so roughly one request per 5 minutes, not one per render. Remove usage_fable from SL_SEGMENTS, or set only_current=1, and no extra request is made.
• It will stop rendering when that API is removed. It fails silently rather than erroring.
• Whether you have a per-model cap at all depends on your account — plan tier, model access, and API/extra-usage settings all play into it, and those rules are Anthropic's to change. The segment models none of them: it renders whatever scoped limit the API returns and stays empty otherwise.
• Needs credentials (macOS Keychain or ~/.claude/.credentials.json); without them it renders nothing.
• No burndown — usage_burndown is driven by the shared seven_day window only.

Full details in the README.