Follow Discord
Sweep 22 Sep 2026 · 17:19Z Build v2.1.280 501 read Stable v2.1.267 Latest v2.1.280 Next v2.1.280 Feeds RSS JSON llms.txt Unofficial
Claude Code v2.1.260 ·

Fable model visibility now gated by a server-verified entitlement probe

A hidden Fable model only appears once a server-side entitlement probe accepts your account.

TierNothing to try yethow much it should matter to you
Useful4my rating, 1 to 5
Signal4worth watching, 1 to 5
AreaModelswhat it touches
KindIn Developmentin v2.1.260,
Group of 2 Nothing to try yet Notable No documentation found

A hidden Fable model only appears once a server-side entitlement probe accepts your account.

The function deciding fable-model eligibility changed hL(oK) to hL(SO) || Iwt() in two branches. Iwt() returns true only when awt() === "accepted", and awt() reads a fableEntitlementProbe (fableEntitlementProbeAccount, fableEntitlementProbeModel) cached on the provider state (Rr().providerCache), populated by an async probe/acceptance flow keyed to the current account.

The model-picker logic (koe) now conditionally injects an extra model option ($G(o, pQr(pq(), e))) into the list before the usual custom/alias model handling, gated through the same Iwt() check; absent an accepted probe result the function returns undefined/false. This means a session can become fable-eligible purely via the probe's cached 'accepted' result even when the existing hL provider-list check fails. Related identifiers claude-fable- and the alias fable51 show this is a codenamed model whose visibility depends on a server-verified entitlement rather than a local flag; it isn't fully traced what sets the probe to 'accepted', so how often this path fires isn't known.

Read from
Names in the bundlefable51

See this entry in the whole of v2.1.260 →

Feedback