Fable 5 Model Lacks Support

[rubberduck-lgtm]

I saw that #760 was closed.

The root problem here is in setSessionConfigOption() in the ACP bridge: it validates the model value against initializationResult.models and throws for any ID not in that list. For users of ACP-based editors like Zed, this means the model (claude-fable-5) is completely inaccessible — there's no way to specify a model that isn't in the initialization response.

The issue is that initializationResult.models and what Claude Code actually accepts are two different views, and they're not always in sync. We verified this: claude-fable-5 is already accepted by Claude Code today — when the model ID is passed through to query.setModel(), it works correctly.

We also verified that invalid model IDs are handled properly end-to-end. When we specified claude-fable-6 (a nonexistent model), Claude Code returned a clean model_not_found error that the bridge correctly surfaced to Zed:

message: "Internal error: There's an issue with the selected model (claude-fable-6). It may not exist or you may not have access to it.",
data: { errorKind: 'model_not_found' }

This demonstrates that Claude Code is already the authoritative validator for model IDs. The bridge's own validation against initializationResult.models is redundant — and in the case of claude-fable-5, it blocks a model that already works while providing no useful error signal that Claude Code wouldn't provide itself.

One possibility for a fix is straightforward: when a model ID isn't present in initializationResult.models, pass it through to query.setModel() rather than throwing at the bridge layer.

if (!validValue) {
    if (params.configId === "model") {
        validValue = { value: params.value, name: params.value, description: "" };
    } else {
        throw new Error(`Invalid value for config option ${params.configId}: ${params.value}`);
    }
}

This could potentially be opt-in. I would like to make a patch to Zed so that users can provide their own user-specified model names, but allowing this requires that the Claude Agent ACP allow models that Claude Code supports but which are not yet in the model list.

[dmeehan1968]

This seems to make Fable unusable via ACP. configOptions model includes Fable as a selectable model, but when submitted it appears to fall back to Opus 4.8. I only figured this out by using ccusage which shows no consumption for Fable model, yet when I use Fable directly from Claude CLI it does show consumption.

[rubberduck-lgtm]

Fable has not been a selectable model. Did that recently change? I still do not see Fable on standard builds:

I wonder if it shows up conditionally based on Athropic servers detecting that you have used Fable recently?

The point of this proposal is to allow one to pass a model that claude code natively supports, even if it isn't shown in initializationResult.models. So I do not understand what you are saying @dmeehan1968. It seems you are suggesting that by making it possible to specify other models, that an official Fable option doesn't work? That's not my experience; please see the linked Zed PR.

@kurt-rhee that is unrelated to this issue.

[dmeehan1968]

@rubberduck-lgtm This is from my own ACP client - I'm just presenting the options given in the config options, and it includes Fable. I'm using 0.44.0 of claude-agent-acp.

When I select Fable, the task appears to get processed by Opus 4.8 instead, despite the agent reporting Fable back to me in response to the model selection. I only know its Opus 4.8 because ccusage reports the consumption against that model, but if I use Clause CLI ccusage does show it as Fable consumption.