Fable 5 gated behind "requires usage credits" in interactive TUI on Max plan

Same here, I have a Max plan as well and I see this:

<img width="929" height="394" alt="Image" src="https://github.com/user-attachments/assets/acfdf335-14ed-4001-beb0-d6c7e6dca902" />

Correction — retracting both the version bisect and the interactive/headless framing in the original report.

Further data from my own transcripts shows the gate is intermittent on a single
version and a single entrypoint, not a 2.1.216 regression and not specific to the
interactive TUI. My earlier tests happened to land on either side of the flip.

Timeline, all 2026-07-23/24, all same account, times EDT:

| local | result | version | entrypoint | session |
|---|---|---|---|---|
| 20:54:54 | gated | 2.1.218 | cli | 14ac1d1b |
| 21:24:08 | served Fable | 2.1.218 | cli | a022d3e3 |
| 21:31:28 | gated | 2.1.218 | cli | 14ac1d1b |
| 21:49:12 | gated | 2.1.218 | cli | 14ac1d1b |
| 21:57:38 | served Fable | 2.1.218 | sdk-cli | 6a023d96 |
| 21:58:42 | gated | 2.1.218 | cli | 14ac1d1b |
| 22:16:29 | served Fable | 2.1.215 | cli | 6f3c8d41 |

The 21:24 row is the decisive one: interactive cli on 2.1.218 served 9 Fable
turns, between gate events at 20:54 and 21:31. So:

• Not a version regression. 2.1.218 both works and fails within ~30 minutes.

2.1.215 also gated on a subsequent fresh session (--model claude-fable-5),
though that run produced no model_consent_fallback record.

• Not interactive-vs-headless. Interactive worked at 21:24.

What does correlate: the additionalModelOptionsCache entry in ~/.claude.json
(the lone claude-fable-5[1m] option) intermittently gains and loses a
" · Requires usage credits" suffix in its description across refetches. I
observed the suffix present ~21:03, absent ~21:10, present again ~21:32. Fable
being served at 21:24 falls inside that gap. Clearing the cache locally does
nothing, because the value is refetched from the server.

So this looks like an intermittently-flipping server-side entitlement/model-options
response that the client faithfully renders as a credits gate, rather than a
client-side check that regressed in a particular build.

Account context unchanged: Max plan, subscription OAuth, Fable usage well under the
50% weekly cap, $0.00 usage credits, overage ineligible.

Apologies for the noise in the original report — the bisect was a sampling artifact.

Independent data point that supports the cache-suffix correlation in the correction above, plus two things I don't think are in the thread yet: the gate survived a weekly limit reset, and it occurred on 2.1.219 (the build whose changelog claims the stale-label fix).

Account: Max 20x, subscription OAuth, usage credits disabled at org level (so overage was never reachable), macOS arm64.

1. The gate persisted across a weekly reset boundary

My weekly window resets Friday 05:00 local. Reconstructed from local session transcripts:

| window | Fable consumption | gate events |
|---|---:|---|
| previous (Thu 07-16 19:00Z → Thu 07-23 19:00Z) | ~1.12B tokens | first model_consent_fallback 07-20 07:19Z |
| current (opened Fri 07-24 05:00 local) | ~0.46M tokens | 13 fallbacks + 6 "You've reached your Fable 5 limit" |

In the previous window I genuinely exceeded the 50% Fable cap — those blocks were correct and expected. The window then rolled, and the gate continued into the new window, where my Fable consumption was effectively zero:

2026-07-24T16:18:12Z  model_consent_fallback  choice=cancelled  originalModel=claude-fable-5
2026-07-24T20:42:32Z  model_consent_fallback  choice=cancelled
2026-07-24T22:09:37Z  model_consent_fallback  choice=cancelled
2026-07-24T23:22:49Z  model_consent_fallback  choice=cancelled
2026-07-25T07:50:28Z  model_consent_fallback  choice=cancelled
2026-07-25T08:55:16Z  model_consent_fallback  choice=switch_default
2026-07-25T09:08:29Z  API error: "You've reached your Fable 5 limit. Run /usage-credits to continue or switch models with /model."
2026-07-25T09:15:18Z  (same)
2026-07-25T09:18:04Z  (same)
2026-07-25T09:35:16Z  (same)
2026-07-25T09:36:58Z  (same)
2026-07-25T09:37:32Z  (same)

The web usage panel for this window reads 8% (all models) — against a Fable cap of 50% of weekly. Six limit-shaped errors on a ~0%-consumed Fable allowance.

Worth noting the 09:08–09:37 cluster surfaced as API errors, not local consent dialogs. If that text originates server-side, it points at rate-limit accounting rather than a purely client-side cached label — possibly a second failure mode alongside the model-options flip.

2. Observed on 2.1.219, i.e. after the stale-label fix

The 2.1.219 changelog has: "Fixed the Fable model row showing 'Requires usage credits' for plans that include it, when a stale cache had baked the label in."

claude doctor reports my first successful update to 2.1.219 completed 2026-07-24. Every gate event listed above from 07-24 16:18Z onward is therefore on 2.1.219 or later. So 2.1.219 did not resolve it here.

3. Corroborates the additionalModelOptionsCache correlation

Currently on 2.1.220, Fable is being served normally, and my single additionalModelOptionsCache entry has no " · Requires usage credits" suffix:

{ "value": "claude-fable-5[1m]", "label": "Fable",
  "description": "Fable 5 · Most capable for your hardest and longest-running tasks" }

Suffix absent → Fable served, which matches the correlation in the correction comment.

Two other local values that look relevant, both fetched today and both indicating Fable should be included for this tier:

tengu_usage_overage_included_models : ["Fable", "Fable 5"]
tengu_saffron_credits_only_tiers    : ["enterprise"]     # this account is default_claude_max_20x
tengu-fable-off-switch              : { "activated": false }
fableOverageConsentV2               : true               # consent already recorded

So the client's own feature flags say Fable is included and not credits-only for a Max 20x tier, while the runtime gate was concurrently asserting the opposite.

Not a workaround, but a note on the fallback

switchModelsOnFlag is false on this account, so the Sonnet reversions were not safeguard-triggered model switching — they came from the consent gate's decline path (getFableDeclineFallbackModel). Worth separating those two paths when triaging, since they produce a similar user-visible outcome.

Two updates: the additionalModelOptionsCache correlation from my correction above does not hold either, and tengu_saffron_lattice has since flipped on this account.

1. Retracting the suffix correlation

In my correction I proposed that the gate tracks a " · Requires usage credits" suffix on the additionalModelOptionsCache description. I now have a direct counterexample: gated while the suffix was absent.

Gate event, 2026-07-25, version 2.1.220, entrypoint cli:

{ "type": "system", "subtype": "model_consent_fallback",
  "content": "Switched to Sonnet 5 for this session · Fable 5 requires usage credits · /model to change",
  "originalModel": "claude-fable-5", "fallbackModel": "claude-sonnet-5",
  "choice": "cancelled", "persistedAsDefault": false,
  "timestamp": "2026-07-25T15:02:07.074Z" }

additionalModelOptionsCache, read 29 seconds later at 15:02:36Z, and also read immediately before the attempt:

{ "value": "claude-fable-5[1m]", "label": "Fable",
  "description": "Fable 5 · Most capable for your hardest and longest-running tasks" }

No suffix, on both sides of the gate event. So suffix-absent does not imply Fable is served, and my earlier 21:03 / 21:10 / 21:32 observations were a coincidence rather than a mechanism. Apologies for a second bad lead.

2. tengu_saffron_lattice has flipped, and matches #79341 exactly

My original "Ruled out" section said this flag was {"enabled": false} with no planLimitsEndDate. As of a server refetch at 2026-07-25T14:51:37Z it reads:

{ "enabled": true, "planLimitsEndDate": "2026-07-20T07:00:00Z" }

That planLimitsEndDate is identical to the one reported in #79341. That account is win32, Max 20x, on 2.1.215; mine is macOS arm64, Max 5x, on 2.1.220. Different platform, tier, and version producing a byte-identical timestamp points at a shared server-side value rather than per-account state.

The timing lines up on both accounts: #79341 first observed the gate ~16 minutes after that timestamp, and my earliest gate event is 2026-07-21T05:02Z. The date is now five days in the past while the flag is enabled: true.

Incidentally, #79341 being on 2.1.215 independently supports the bisect retraction in my correction, since my original table listed 2.1.215 as working.

3. Every local signal was permissive at the moment of the gate

All refetched from the server today at 14:50–14:51Z, ahead of the 15:02:07Z gate:

tengu_usage_overage_included_models : ["Fable", "Fable 5"]
tengu_saffron_credits_only_tiers    : ["enterprise"]      # this account is default_claude_max_5x
tengu-fable-off-switch              : {"activated": false}
cedar_lagoon                        : {"claude-fable": true, "claude-mythos": true}
additionalModelOptionsCache         : no "Requires usage credits" suffix

Every cached client-side input says Fable is included and not credits-only for this tier, and the gate fired anyway. Combined with §1, I don't think any cached local value is the decision input. The gate appears to be decided server-side at request time.

Two other values that may be relevant to triage:

• cachedExtraUsageDisabledReason: "out_of_credits", which is presumably where the "$0.00 in credits" phrasing originates.
• fableOverageConsentV2 is absent on my account. The Max 20x commenter above has it true and reports being served. All of my consent choices have been cancelled, so nothing was ever recorded. If the gate re-arms whenever consent is unrecorded, that would explain why declining is sticky for me and not for accounts that accepted once. I have not tested accepting, since with $0.00 credits it authorizes a charge I'd rather not authorize blind.

Account context

Max 5x, subscription OAuth, no ANTHROPIC_API_KEY, Claude Code 2.1.220 (npm-global), macOS 15.3 / Darwin 25.3.0 arm64, Fable weekly usage well under the 50% cap.

Corroborating data point from a fresh investigation today (2.1.220, Arch Linux, Max plan, default_claude_max_20x tier, "model": "fable" in settings.json).

This matches the corrected theory in the issue description: the gate is intermittent per server refetch, not interactive-vs-headless or version-bound. We tracked it through ~/.claude.json's clientDataCacheSlots (one slot per entrypoint+model probe) across the same account, same CLI version, same cli entrypoint, within a ~5 minute window:

2026-07-25 11:09:50  cli  claude-opus-5
2026-07-25 11:11:02  cli  claude-fable-5     <- served fine, Fable worked this session
2026-07-25 11:16:28  cli  claude-sonnet-5    <- next session, ~5 min later, gated

At 11:16:28 the CLI showed the usage-credits consent prompt; declining produced a silent fallback with no error — confirmed via /model afterward reporting "Kept model as Sonnet 5". No exception, no visible indication anything had changed from the pinned fable setting.

Ruled out independently, in case useful to others chasing this:

• Token refresh — access token was valid the entire window (expiresAt unchanged across both the working and gated sessions), so this isn't refresh-grant-token-loses-entitlement.
• Local cache corruption — full key-by-key diff of ~/.claude.json between a working and a gated snapshot showed only timestamps/slot-ids differing; no state field flips.
• modelAccessCache — empty ([]) in both the working and the gated session. Not a useful signal for this bug; don't chase it.
• Third-party SDK/MCP processes writing the shared config file — present in both snapshots, ruled out by the same diff.

oauthAccount.hasExtraUsageEnabled was false throughout, on an account where Fable is plan-included per the Help Center article linked above — so this looks like the consent/pre-flight check itself misfiring on a refetch, not an actual entitlement change.

The client-side consent gate is masking a server-side rate-limit rejection. Suppressing the gate locally does not unblock Fable — it just surfaces the underlying error.

I was able to test this directly, because at $0.00 credits the consent dialog offers no accept-and-continue path (see §3), so the only way to record consent was to write it into ~/.claude.json by hand.

The experiment

With Claude Code fully quit, I set fableOverageConsentV2: true (it was unset), cleared cachedExtraUsageDisabledReason, and restarted.

Result: the consent dialog is gone, and the requests now fail server-side instead. No model_consent_fallback event has been emitted since the override. Timeline for 2026-07-25, all on 2.1.220, all in one session:

| time (Z) | event |
|---|---|
| 15:02:07 | model_consent_fallback choice=cancelled |
| 15:09:42 | model_consent_fallback choice=cancelled |
| 15:14:11 | API limit error |
| 15:23:25 | fableOverageConsentV2: true written, Claude Code restarted |
| 15:24:55 | API limit error — no consent gate |
| 15:25:14 | API limit error — no consent gate |
| 15:25:21 | API limit error — no consent gate |

The error is:

You've reached your Fable 5 limit. Run /usage-credits to continue or switch models with /model.

My Fable consumption this window is well under the 50% cap. So the server is asserting a Fable limit that has not been reached, and the client consent dialog was a downstream symptom of that, not an independent client-side bug.

This corroborates @sykele007's observation above that their 09:08–09:37Z cluster surfaced as API errors rather than local dialogs, and that it "points at rate-limit accounting rather than a purely client-side cached label." With the client gate removed, that is the only failure mode left.

Which overrides survived the restart

Useful for separating client state from server state:

| key | set to | after restart |
|---|---|---|
| fableOverageConsentV2 | true | true — persisted |
| cachedExtraUsageDisabledReason | null | "out_of_credits" — refetched |
| tengu_saffron_lattice | {"enabled": false} | {"enabled": true, "planLimitsEndDate": "2026-07-20T07:00:00Z"} — refetched |

The client honors locally-written consent but re-fetches the rest, and the server rejects either way. I don't believe any client-side remediation can fix this.

2. Caveat on tengu_saffron_lattice in my previous comment

I reported it as {"enabled": true, "planLimitsEndDate": "2026-07-20T07:00:00Z"}. About twenty minutes later, with no restart or action on my part, the same key read {"enabled": false} with no date, then reverted again after the restart above. It oscillates across server refetches the same way the additionalModelOptionsCache suffix does. The match with #79341's timestamp still looks meaningful when the value is present, but it is not stable per-account state, and §2 above should be read with that caveat.

3. The consent path is unreachable at $0.00 credits

Correcting an assumption from earlier in the thread: my uniform choice: "cancelled" records are not me taking the focused decline default. With zero credits the dialog's affirmative action is a "set up usage credits" purchase flow that opens a browser. There is no option that proceeds on Fable, so cancelled is the only reachable terminal outcome and fableOverageConsentV2 is never written.

This may explain the variance across reporters: accounts holding credits can consent once, record the flag, and get served; zero-credit accounts hit an unconditionally terminal gate.

4. The in-product workaround does not work

The billing page reached from that dialog currently reads:

Fable 5 is still included with your Max plan. If you see a prompt to set up usage credits for it, restart Claude Code.

That text has been shown all week on my account. I have restarted many times and upgraded across several versions (now 2.1.220) in that window and the gate persists. Given §1, a restart cannot help, since the rejection originates server-side.

Account context

Max 5x, subscription OAuth, no ANTHROPIC_API_KEY, Claude Code 2.1.220 (npm-global), macOS 15.3 / Darwin 25.3.0 arm64, $0.00 usage credits, Fable weekly usage well under the 50% cap.

This is still happening today as of version 2.1.220:

<img width="780" height="228" alt="Image" src="https://github.com/user-attachments/assets/537d49d7-3999-4597-8973-e42af79ef04d" />

Max 5x plan, plenty of margin in both overall and Fable usage. At this point I've been unable to use Fable in Claude Code (the primary reason I'm a subscriber) for over a week, and have heard no response from Anthropic despite this being a commonly-reported issue.