[BUG] Interactive CLI demands usage credits for Fable 5.1 on Team plan while `claude -p` and Remote Control sessions on the same login are served Fable

Status Closed — not planned
Reported on v2.1.227
Maintainer reply None cached
Activity 1 comment · opened Sep 12, 2026 · closed Sep 12, 2026

Preflight Checklist

  • [x] I have searched existing issues. Closest match is #79386 (closed as fixed in 2.1.227). This reproduces on 2.1.265 CLI, Team plan, Linux, and includes evidence that the block is client-side.
  • [x] This is a single bug report
  • [x] I am using the latest version of Claude Code

What's Wrong?

On a Team plan (seat tier team_tier_1, org has extra usage disabled), the interactive CLI refuses to run Fable 5.1 and shows the consent dialog "Fable 5.1 requires usage credits". Dismissing it swaps the turn to Sonnet 5 and the transcript records:

{"type":"system","subtype":"model_consent_fallback","content":"Switched to Sonnet 5 for this session · Fable 5.1 requires usage credits · /model to change","choice":"cancelled","originalModel":"claude-fable-5-1","fallbackModel":"claude-sonnet-5"}

Accepting the dialog sends me to the credit setup page instead of continuing, because extra usage is disabled at the org level.

The API itself serves Fable to this same login without any credit requirement:

  1. claude -p --model fable 'reply ok' (same machine, same OAuth login, no bridge env) succeeds. The result JSON modelUsage lists claude-fable-5-1 with tokens billed.
  2. A Remote Control child session (claude remote-control, driven from the desktop app) on the same account runs Fable 5.1 continuously with no dialog.

So the block is the interactive client's consent gate, not the server. Reading the bundled source, the gate keys off two cached values in ~/.claude.json:

  • cachedGrowthBookFeatures.tengu_saffron_lattice = {"enabled": true, "planLimitsEndDate": "2026-07-20T07:00:00Z"} (date already passed, so the client treats Fable as credits-only)
  • cachedExtraUsageDisabledReason = "org_level_disabled", which is not on the client's allow-list (org_level_disabled_until, org_spend_cap_reached, out_of_credits), so even a recorded fableOverageConsentV2 entry does not clear the gate.

Non-interactive -p runs and bridge child sessions never evaluate this gate, which is why they work. This is not the expired-token cause described in #79386: the same fresh token serves Fable in -p mode seconds before the interactive dialog refuses it.

What Should Happen?

If the org's entitlement includes Fable 5.1 (as the API demonstrates by serving it), the interactive CLI should send the request rather than demand usage credits. If the entitlement genuinely requires credits, -p and Remote Control sessions should be gated the same way. The two paths should agree.

Error Messages/Logs

Switched to Sonnet 5 for this session · Fable 5.1 requires usage credits · /model to change

Transcript event subtype: model_consent_fallback, choice: "cancelled".

Steps to Reproduce

  1. Team plan login, org with extra usage disabled, after 2026-07-20.
  2. claude in a terminal, /model fable, send any prompt.
  3. Observe the "requires usage credits" dialog; press Esc; turn runs on Sonnet 5.
  4. In the same shell: claude -p --model fable --output-format json 'reply ok'. Observe success with claude-fable-5-1 in modelUsage.
  5. Optionally: claude remote-control, drive the session from the desktop app, pick Fable. Works.

Claude Model

Fable 5.1 (claude-fable-5-1)

Is this a regression?

Unknown. Previously reported in #79386 and marked fixed in 2.1.227; still present in 2.1.265.

Last Working Version

Unknown

Claude Code Version

2.1.265 (session where it reproduced); 2.1.269 currently installed.

Platform

CLI (terminal)

Operating System

NixOS, Linux 6.18

Terminal/Shell

zsh in zellij

Additional Information

Related: #79386, #79441, #84694. The transcript model_consent_fallback event and the -p success are from the same minute on the same machine and login.

View original on GitHub ↗

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