Welcome to the show.
James, this one hit me right in the old copy-paste injury: in
Claude Code v2.
1.126, if you point ANTHROPIC_BASE_URL at some custom gateway,
the /model picker now calls GET /v1/models on THAT gateway instead of
showing a baked-in Anthropic-only list.v2.
1.126 is the whole
story here.
Because before 2.
1.126, if your company ran LiteLLM or a Bedrock proxy
or some Vertex AI adapter pretending to be Anthropic-compatible,
Claude Code would basically go,
"Cool, anyway, here's my old list." And then you had to know
the exact model ID by hand.
Yeah,
exactly.
And "exact model ID by hand" sounds small until you're typing some weird
internal alias at 11:40 p.
m.
like claude-sonnet-prod-us-east-1-whatever.
One typo and the whole thing falls over like a roo on roller skates.
The old flow was brittle in a VERY specific way.And
brittle for the worst reason: not because the model was unavailable,
but because the client UI was lying about what existed.
That's the part I hate.
If the gateway expects, say, a Bedrock-flavored name or a proxy alias,
the built-in picker isn't just unhelpful -- it's actively misdirecting
you.
Right.
So now the practical change is almost boring,
which is why it's good.
You open Claude Code, run /model,
and instead of a stale list shipped inside the app,
you see the IDs your own infrastructure actually advertises.
Self-documenting.
No wiki safari.
No Slack thread from March.
No "ask Priya, she knows the alias" energy."Ask Priya" as
infrastructure.
Every company has that.
But let me sharpen it: the /model picker and the --model flag both benefit,
right?
So it's not just interactive use.
Even if you're launching from the command line,
the tool is now grounded in GET /v1/models from the configured base URL.
Yep.
And I like this because it's one of those tiny changes that quietly removes
a whole category of pain.
It's the same feeling as stopping hardcoded API keys in a notebook and
pulling from env vars instead.
Same app, same job, but suddenly it behaves like it belongs in real
infrastructure
instead of a demo on someone's laptop.
That env-var comparison is good
because it captures the maturity jump.
Not glamorous, but real.
Once ANTHROPIC_BASE_URL can point at whatever your team actually runs,
the client has to stop assuming "Anthropic-only universe." Querying
/v1/models
is the obvious move...
but obvious in hindsight is still a meaningful fix.
And the reason it matters is that "Anthropic-compatible" never meant
"identical in every operational detail."
A reverse proxy can expose different names,
different availability, different routing rules.
So if Claude Code ships a fixed list and your gateway speaks a slightly
different dialect, you get that annoying gap between what the app suggests
and what the backend accepts.
Wait,
let me try to explain it back.
Old world: Claude Code sees ANTHROPIC_BASE_URL,
but still behaves like the only valid model names are the ones it already
knows.
New world: Claude Code sees ANTHROPIC_BASE_URL and asks that server,
specifically via GET /v1/models,
"What model IDs do YOU support?" That's the change?That's
it.
Not exactly magical discovery of capabilities everywhere -- just plain
old asking the endpoint for the list it advertises.
Which, honestly, is better engineering than guessing.
Fresh code can make even a kangaroo trip,
but this one lands on both feet.
And there's a subtle trust thing here.
When a picker shows me IDs straight from /v1/models,
I trust it more.
If an admin adds a new alias at the gateway,
that can surface without waiting for some client release cycle.
The UI becomes a view into infrastructure,
not a brochure.This is where it gets useful for teams.
Enterprise platform groups love gateways for three reasons: cost controls,
audit logging, and mixed model access.
One base URL can route traffic through the policy layer they want.
Before, developers had to memorize whatever alias names that layer exposed
like some kind of oral tradition.
Now the picker can just show the names.
"Oral tradition" is dead-on.
It's basically tribal knowledge with YAML.
And if the admin adds or removes models on the gateway side,
the list stays current without a Claude Code update,
without telling everyone to refresh local config,
without that classic moment where the dev says,
"Why is the picker lying to me?"That phrase -- "why is the picker lying to me?"
-- is memorable because every engineer has lived it.
A dropdown is supposed to reduce uncertainty.
When it shows stale options, it becomes worse than a text box.
At least a blank text box isn't pretending to know.A dishonest
dropdown is worse than no dropdown.
That's going on a T-shirt.
But here's the catch, and it's an important one: Claude Code passes the
selected model ID VERBATIM to the gateway.
So if /v1/models advertises a pretty ID that doesn't exactly match what
inference requests expect, the nicer picker won't save you.
It's lipstick on a misconfigured pig.Verbatim is the key
word.
No normalization, no translation layer in the client,
no "did you mean" cleanup.
So if the gateway returns model-a in /v1/models but actually expects
model_a or some longer internal alias when the inference call comes in,
you're still broken.
The front end can only be as truthful as the backend contract.
Exactly.
This is where teams can get lulled into a false sense of safety.
You see a neat dynamic list and think,
beauty, job done.
But the list has to match the actual request path expectations exactly.
If your gateway advertises junk,
Claude Code will faithfully send junk right back.
And there's another
edge case I think people should remember: if the gateway returns a malformed
or empty /v1/models response, Claude Code silently falls back to its built-in
list.
Silent fallback.
That means you might think integration is working when really you just
slipped back to the old hardcoded behavior.Silent
fallback
is the sneaky bit!
That's the one I'd tape above the monitor.
Because if you're testing a new LiteLLM setup or a Bedrock proxy and
/model suddenly looks "normal," that might not mean the gateway is healthy.
It might mean Claude Code gave up and showed its default list instead.
So
the move is simple: before trusting the picker,
hit the gateway yourself.
Do a quick curl to /v1/models.
If that response is empty or malformed,
you've found the problem upstream.
The client interface can look polished while the integration is still
busted underneath.
Yeah.
It's a bit like checking the fuel line instead of kicking the bike tyre.
The shiny bit isn't always the broken bit.
And for platform teams, that's actually good news,
because the debugging boundary gets clearer: is /v1/models correct,
and do those IDs match inference expectations?
If yes, Claude Code should behave.
If not, don't blame the picker.I also think this is
one
of those tiny enterprise-readiness signals.
Not flashy model benchmarks, not "look at this new agent feature." Just:
does the tool respect the gateway as the source of truth?
That's boring until you've supported a real team,
and then it's EVERYTHING.Yep.
The little quality-of-life fixes are often the ones that tell you a product's
growing up.
When the tool stops assuming your setup looks like the vendor's demo
and starts asking your infrastructure what it actually is...
that's when it becomes properly useful.
Anyway, give your /v1/models endpoint a squiz before you trust the pretty
menu.
Catch you next time.
See you.