feat: add Claude Fable 5.1

[emaadshamsi]

Summary

• make claude-fable-5-1 the canonical Fable model while retaining claude-fable-5 as an explicit legacy pin
• advertise both Fable versions through /v1/models with Max 1M context metadata and pricing coverage
• bump the bundled Claude Code dependency to 2.1.257 because earlier builds reject Fable 5.1

Validation

• npm run build
• bun test src/__tests__/openai.test.ts src/__tests__/proxy-health-build.test.ts src/__tests__/proxy-env-stripping.test.ts src/__tests__/explicit-model-pins.test.ts src/__tests__/pricing-unit.test.ts (173 passed)
• live Claude Max qualification through Meridian succeeded for claude-fable-5-1; legacy claude-fable-5 still succeeds

Known unrelated test issue

• the full npm test run still has the existing proxy-stale-uuid-retry.test.ts expectation mismatch (expected 500, received 499)
• reproduced the same failure on a clean origin/main worktree at 1ea97d0

[OpenSource03]

Why is this hardcoded at the first place?

I'm almost sure it is possible to fetch models dynamically...

[rynfar]

Thanks for this — the core of it shipped in #928 and you're credited as co-author on the merge commit.

To explain why this PR is being closed rather than merged directly: main requires signed commits, so fork PRs sit at mergeStateStatus: BLOCKED with every check green and no visible reason. That's not something you could fix from your side. The standard path here is to cherry-pick the contribution onto a local branch, which re-signs it while preserving you as the commit author.

Your diagnosis and the CLI bump were both correct — I verified that claude-fable-5-1 genuinely doesn't exist in the 2.1.198 binary but does in 2.1.259, so the bump was required, not incidental.

Three things were added on top:

• bun.lock/bun.nix — this repo's real lockfile is bun.lock (CI runs bun install); package-lock.json is secondary. The claude-code bump hadn't reached the lockfile CI uses.
• flake.lock — the new floor outpaced the claude-code in the pinned nixpkgs, breaking flake evaluation. Notably check-claude-code and the nix build key off bun.lock/flake changes, so neither ran on this PR — which is why it showed green.
• Pricing keys and routing tests for claude-mythos-5-1, which rides the fable tier.

Verified live on Max: real Fable 5.1 generation, correct fable[1m] routing, and explicit claude-fable-5 still returns Fable 5 with no substitution.

[rynfar]

@OpenSource03 — fair question. The short answer is there's no upstream endpoint to fetch it from on this transport.

1. No API key. Meridian routes through the Claude Agent SDK / Claude Code CLI on a Claude Max OAuth subscription — it never calls the Messages or Models API. The only api.anthropic.com calls in the codebase are the OAuth usage endpoint, a WebFetch hostname safety check, and the Design proxy. GET /v1/models needs an API-key credential Meridian doesn't hold.

2. The list is bounded by the bundled CLI, not by what Anthropic serves. This PR is the proof: claude-fable-5-1 isn't in the 2.1.198 binary but is in 2.1.259 — hence the CLI bump. A dynamic fetch would have advertised Fable 5.1 while the pinned CLI still rejected it, turning "model not offered" into a confusing runtime failure.

3. Part of each entry is Meridian policy, not upstream data. context_window is 1M or 200k depending on whether the subscription includes extended context — Anthropic's Models API can't tell you that; it's the same routing decision mapModelToClaudeModel makes when choosing fable[1m] vs fable.

So it's a deliberate compatibility surface for OpenAI-style UI pickers, pinned to what the vendored CLI can actually service.