feat(models): add direct Fable 5.1 selection

[shenlvkang-collab]

Summary

• add claude-fable-5-1 to the new-session picker and task-routing selectors
• represent Fable 5.1 as a 1M-by-default model, without creating an invalid [1m] identifier
• document and structurally test the model-picker contract

Validation

• npm test -- test/app-settings-structure.test.ts
• npm run check:frontend-syntax
• npm run typecheck
• npm run build

[Ark0N]

Thanks for this, and the gap it points at is real: claude-fable-5-1 is in Claude Code's baked-in model catalog (display name "Fable 5.1", June 2026 cutoff), and there was no way to pin it from App Settings without hand-editing a case's .claude/settings.local.json.

Two things stopped me merging it as written.

1. The premise does not hold: Fable 5 is natively 1M too

The PR treats "1M included rather than switchable" as what separates 5.1 from 5. The CLI's hand-maintained catalog (2.1.258) says otherwise. Both entries carry the same context block:

{id:"claude-fable-5",   family:"fable", display_name:"Fable 5",   knowledge_cutoff:"January 2026", ... context:{window:1e6,native_1m:!0,supports_1m_beta:!0} ...}
{id:"claude-fable-5-1", family:"fable", display_name:"Fable 5.1", knowledge_cutoff:"June 2026",    ... context:{window:1e6,native_1m:!0,supports_1m_beta:!0} ...}

(That is readable straight out of the CLI binary: grep -aob 'claude-fable-5-1' ~/.local/share/claude/versions/<ver>, then dd around the offset.)

So data-ctx-default, the third description branch and the disabled switch all encode a difference the models do not have. For the same reason claude-fable-5-1[1m] is a perfectly valid string: the CLI accepts it exactly like claude-fable-5[1m], neither prints the unrecognized_model warning that a made-up id does.

2. Force-checking the switch writes to a persisted setting

_applyModelSelection() is a render function, but this line makes it a writer:

if (defaultContext && contextSwitch) contextSwitch.checked = true;

saveAppSettings() persists opusContext1mEnabled straight off that checkbox, and the accompanying disabled = true means the user cannot put it back while Fable 5.1 is selected.

Measured on this branch, fresh instance and isolated data dir:

STEP1  pin Opus, switch explicitly OFF, save   ->  opusContext1mEnabled=false  claudeModel="opus"
STEP2  click the Fable 5.1 card                ->  switchChecked=true  switchDisabled=true
STEP3  save                                    ->  opusContext1mEnabled=true   claudeModel="claude-fable-5-1"
STEP4  real user click on the switch           ->  still true, the click is inert
STEP5  go back to "Default (CLI setting)"      ->  opusContext1mEnabled=true   claudeModel=""

That last row is where it bites. opusContext1mEnabled is OR'd against the per-case toggle in session-ui.js:

const useOpus1m = caseSettings.opusContext1m || globalSettings.opusContext1mEnabled;
const modelOverride = globalSettings.claudeModel || (useOpus1m ? 'opus[1m]' : '');

so a case where the user had deliberately turned 1M off now starts on opus[1m], because they once looked at Fable 5.1.

The smaller version

I have opened #372, which adds Fable 5.1 the way Fable 5 is already added and nothing more: a base option carrying data-ctx="1" plus its claude-fable-5-1[1m] companion row, in the model select and the five task-routing selects. The cards and the 1M switch are built from those options (_buildModelCards folds the [1m] rows away, data-ctx="1" keeps the switch live), so there is no settings-ui.js logic to change at all and 5.1 behaves identically to its sibling. 3 files, +28/-3.

Your PR is what surfaced the gap, so thank you for it. The feature ships either way.

[Ark0N]

Superseded by #372, which shipped in v1.24.5 just now: Fable 5.1 is selectable in App Settings and available in the task-routing selects. The release notes credit you for surfacing the gap.

Closing this one. Thanks again for the report, and please do keep them coming.