[Bug] /advisor silently omits Fable 5 when ANTHROPIC_BASE_URL is set, despite first-party OAuth login and cached Fable entitlement

Summary

/advisor silently omits Fable 5 when ANTHROPIC_BASE_URL points at a self-hosted relay,
even though the session is authenticated with a first-party OAuth login and the account's
own cached model-options payload lists Fable as available and not disabled. The advisor
picker itself opens normally and lists the other models; only Fable is absent. No error,
warning, or hint is shown.

What I observed

We run an internal relay that forwards to https://api.anthropic.com unchanged, pointed at
via ANTHROPIC_BASE_URL with ANTHROPIC_CUSTOM_HEADERS for its own routing headers. The
session itself is a plain OAuth login — no ANTHROPIC_API_KEY, no ANTHROPIC_AUTH_TOKEN,
not Bedrock or Vertex. Everything else works through the relay: messages stream normally,
and the advisor server tool itself works. Only the /advisor model picker drops Fable.

Why it looks like a bug rather than a policy

Two things point at the picker's gating logic rather than at entitlement or transport.

1. The entitlement data on this machine already says Fable is available. The cached
model-options payload in ~/.claude.json reads:

[{"value": "claude-fable-5[1m]", "label": "Fable",
  "description": "Fable 5 · Most capable for your hardest and longest-running tasks"}]

The entry is present and carries no disabled flag, so it is enabled. This cache is
populated on a machine that has the relay configured — the model list arrives intact and
is then discarded locally at display time.

2. A purely local override restores it, with the relay still in place. Setting

{ "env": { "ANTHROPIC_DEFAULT_FABLE_MODEL": "claude-fable-5" } }

in ~/.claude/settings.json makes Fable appear in /advisor again and the advisor runs on
it normally — same relay, same account, same network path, nothing changed server-side.
That isolates the cause to a client-side availability check rather than to the account or
to the relay.

From the observed behaviour, provider classification and base-URL classification appear to
disagree for this configuration:

• the provider kind resolves to first-party (this is an OAuth login, not a third-party

gateway)

• the base-URL check appears to compare the host for equality against api.anthropic.com,

which is false here

The Fable availability gate then rejects exactly the combination "first-party provider AND
non-default base URL". A relay user is therefore treated neither as first-party nor as a
gateway — they fall through both branches.

Expected behaviour

Either treat an OAuth-authenticated session as first-party regardless of
ANTHROPIC_BASE_URL, or surface the reason in /advisor, so that the user is not left
diagnosing an account-permission problem that does not exist. The silent omission is the
costly part: from the user's side it is indistinguishable from "your plan does not include
Fable", which sent us down an entitlement investigation that turned out to be a dead end.

Environment

• Claude Code 2.1.234, macOS (arm64)
• Auth: OAuth login (/login), personal Claude Max plan
• ANTHROPIC_BASE_URL set to an internal relay; ANTHROPIC_CUSTOM_HEADERS set;

no ANTHROPIC_API_KEY, no ANTHROPIC_AUTH_TOKEN

• advisorModel: "fable" in settings

Note on similar reports

This looks distinct from the existing Fable/advisor reports: #80851 and #73333 concern the
/model picker and feature-gate state on accounts with no custom base URL, and the large
"advisor unavailable" cluster (#67609, #76199, #73923, …) is about the advisor call failing
at request time. Here the advisor call works fine — Fable is simply never offered as a
choice, and only when ANTHROPIC_BASE_URL is set.