Fable in Claude: the extension appears to have failed
ClaudeFableVS Code
Fable was not disabled; the extension likely failed
I would not call this a subscription change yet: according to user reports on September 15, 2026, Fable continued to work for other paid-plan subscribers. The issue appeared locally in the Claude extension for VS Code: the model was available earlier in the day, then stopped launching, while Opus kept working.
The available information includes no Anthropic announcement that Fable was being removed from subscriptions. Anthropic’s documentation on Fable describes a more nuanced arrangement: some higher-tier plans include an allowance, while Pro and Team Standard may consume usage credits from the first message at API rates. A separate usage meter therefore does not prove that access suddenly became entirely paid.
A similar class of failures also surfaced in Claude Cowork. One participant spent several hours investigating an egress proxy issue: the harness ignored settings and blocked connections, but the problem disappeared after an update the previous day. This is a user report rather than an official fix list, yet the symptom closely matches known complaints about proxy settings being passed between Claude, the shell, and VS Code.
My first check would be unglamorous but useful: compare access through another interface, inspect usage, and explicitly set proxy parameters in the extension settings. If Fable works for users on the same plan and the failure is limited to one client, the theory of an abrupt billing change becomes much less convincing.
Why these failures resemble plan changes
The main problem is not the error itself but how the agent harness conceals it. The user sees one unavailable model and an available Opus, without knowing whether authentication, routing, a usage limit, or subscription policy has failed. Several distinct causes collapse into one vague symptom.
For production work, this is a real risk: the model may be available on the service side while a particular extension effectively stops the workflow. I would primarily watch whether the error repeats across interfaces and whether VS Code inherits proxy environment variables. Switching to an API key or explicitly configuring HTTPS_PROXY can sometimes bypass authentication and network issues, but that is a workaround, not proof of the cause.
The Fable story ended without a dramatic subscription change: participants confirmed that the model worked for them, and the original author acknowledged a likely extension lag. But until the client clearly distinguishes limits, billing, and network failures, every bug like this will look like a sudden product decision.