[BUG] Fable 5 gated behind usage credits dialog on Max when authenticated via claude setup-token (inference-only scope cannot read entitlements)

Workaround from codex lol

Claude-Code-Fable-OAuth-Fix.md

will it be fixed in next release?

Workaround from codex lol Claude-Code-Fable-OAuth-Fix.md

It cannot work on a Ubuntu Linux server

> Workaround from codex lol > Claude-Code-Fable-OAuth-Fix.md It cannot work on a Ubuntu Linux server

Claude-Code-Fable-OAuth-Fix-Linux.md

Use claude 4.8 to find the patch code for Linux

Opus 4.8 made the workaround working also on 2.1.217
thx for sharing @maxamly

FWIW, another workaround is to just tell Opus/Sonnet to spawn Fable and it "works".

Man. This sure is a bummer. I built a whole tool around setup-token and now it's just hosed. According Opus this is because inference tokens that you get from claude setup-token don't have the right to ask the Claude server what you're entitled to so the client fails closed as if you weren't paying $200/month and instead offers you Fable on usage credits and Sonnet. Cool cool cool.

[edit] (Oh, I guess the OP already gave us this analysis.)

I also face this issue. Please fix it！

See also https://github.com/anthropics/claude-code/issues/81015

Workaround that keeps the setup-token (no /login required) — relevant to everyone here on the inference-only-scope path. Credit @vzellmeister (#79597): the interactive gate reads subscriptionType from an env var when a token is set, so you can just declare it. Add these next to your CLAUDE_CODE_OAUTH_TOKEN export:

export CLAUDE_CODE_SUBSCRIPTION_TYPE=max
export CLAUDE_CODE_RATE_LIMIT_TIER=default_claude_max_20x   # or default_claude_max_5x — your tier

Start a fresh session → /model fable selects cleanly, and the header flips "Claude API" → "Claude Max". Confirmed on Max 20x / 2.1.220 (Linux).

SUBSCRIPTION_TYPE=max is the lever; RATE_LIMIT_TIER only affects /upgrade text — and don't read your tier from the setup-token's ~/.claude.json, it's stale under token auth (mine wrongly said 5x when I'm 20x). @gigamonkey — this should un-hose the setup-token tool.

Workaround that keeps the setup-token (no /login required) — relevant to everyone here on the inference-only-scope path.

You amazing human, this works great

Very nice work, thank you for the solution!

The only thing remaining now is /usage 😂

@AndrewLuebke nice!

@folknor glad it worked! On /usage — worth clarifying, since it trips people up:

• If you mean the dollar figure: that's a notional number, not a bill. It's what those tokens would have cost pay-as-you-go, but $0 is actually charged — Fable (and everything else) is covered by your Max plan's weekly limits. Claude Code's own docs call the /usage cost an estimate that "may differ from your actual bill," and under a subscription it isn't billed per-token at all. The panel just never says "$0 charged," so it reads like an invoice when it's really a "value consumed against your plan" meter.
• If you mean the missing plan-limit bars: that's the setup-token's inference-only scope — it can't read the profile/entitlement endpoint (the same user:profile 403 behind this whole bug), so /usage can't draw your gauge bars. Read your real limits from claude.ai → Settings → Usage instead; they're account-wide, so any logged-in surface shows the same numbers.

Either way it's cosmetic — nothing is actually being charged to credits.

@AndrewLuebke Thank you, yes I'm aware of how to check the usage on claude.ai. The problem is I dont have daily access to the email that pays for this subscription. That's also why I use setup-token.

Fair point — and honestly that's the strongest argument for fixing this properly rather than routing around it: people reach for a setup-token because they don't have interactive access to the owning account, so "just check claude.ai" isn't actually available to them. The token is their only handle on the plan, and right now it can't read the entitlement/limit endpoint (the same user:profile 403 behind this whole issue), so /usage can't draw the limit bars.

So +1 to a real fix: give setup-token auth a server-side way to read entitlements/limits (one that doesn't require user:profile), so /usage surfaces the plan gauges locally for exactly the delegated-access case setup-tokens exist to serve.

Thanks for the unusually thorough report — the root-cause analysis is correct.

What I could verify on 2.1.233 (Linux): claude setup-token requests an inference-only authorization, and tokens minted that way cannot read plan/entitlement information. Sessions authenticated with such a token therefore don't know the account's plan tier, so the plan-inclusion check that a normal /login session refreshes on restart can never succeed there, and the client falls back to the usage-credits prompt as the conservative default. That matches exactly what you're seeing, including why restarting fixes /login sessions but never setup-token sessions. (I couldn't run the full end-to-end repro here since it needs a Max-account setup-token, so this is confirmed by analysis rather than reproduction.)

Classifying as a bug: a recent release (see the changelog, 2.1.227) fixed the sibling case where flags were evaluated without the subscription tier on an expired login, but inference-only tokens structurally never have tier info, so that fix doesn't cover this path. We're looking at either letting these tokens read plan inclusion or not gating them client-side and letting the server decide billing.

Workaround for now: use interactive /login on affected machines.

🤖 Generated with Claude Code

@bcherny thank you — confirming the root cause and classifying it as a bug is exactly what this thread needed. Your two candidate fixes both address it; one note on which is more complete, plus a client-side workaround for people who land here before either ships.

Why "let the server decide billing" (b) is the stronger fix than "let inference-only tokens read plan inclusion" (a): the same user:profile 403 that blocks the plan-inclusion check also blocks the /usage limit gauges under a setup-token (they never draw). Option (b) sidesteps the profile fetch entirely for the entitlement decision; option (a) only fixes the Fable gate unless it also exposes limits. And the population this bites hardest is delegated access — people use a setup-token precisely because they don't have interactive account access (see @folknor upthread: the account is owned by an email they can't check daily). For them, the "use interactive /login" workaround isn't available, and neither is "check claude.ai."

Client-side workaround that unblocks the picker without /login or re-auth — since the gate reads subscriptionType and the resolver builds it from an env var when CLAUDE_CODE_OAUTH_TOKEN is set, declaring it in ~/.claude/settings.json clears the wall:

"env": {
  "CLAUDE_CODE_SUBSCRIPTION_TYPE": "max",
  "CLAUDE_CODE_RATE_LIMIT_TIER": "default_claude_max_20x"
}

Truthful for a Max account, client-side only, no auth or billing change (headless -p already worked). Match RATE_LIMIT_TIER to your real tier; SUBSCRIPTION_TYPE has to be the literal max for the check regardless of plan. On a couple of 2.1.224+ builds Fable then disappears from /model instead of showing the wall (@jatingartan upthread) — if that happens, adding ANTHROPIC_CUSTOM_MODEL_OPTION / _NAME / _DESCRIPTION restores the picker row.

Durability data point (Linux, Max 20x, setup-token): with just the two env vars above, Fable has stayed selectable and ungated continuously across 2.1.222 → 2.1.226 → 2.1.235 — no re-auth, and I've never needed the custom-model-option add-on on this box. So the env workaround holds on current builds; it's a stopgap, not a substitute for the server-side fix, which is still owed for the reason above — the delegated-access case setup-tokens exist to serve.