Claude Code v2.1.126 Finally Trusts Your Model Gateway

Lachlan Reed

Welcome to the show. James, [pauses] 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.

James Turner

[excited] 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." [chuckles] And then you had to know the exact model ID by hand.

Lachlan Reed

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.

James Turner

[questioning tone] 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.

Lachlan Reed

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.

James Turner

[laughs] "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.

Lachlan Reed

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.

James Turner

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... [short pause] but obvious in hindsight is still a meaningful fix.

Lachlan Reed

[reflective] 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.

James Turner

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?

Lachlan Reed

[matter-of-fact] 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.

James Turner

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.

James Turner

[calm] 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.

Lachlan Reed

"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?"

James Turner

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.

Lachlan Reed

[laughs] 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.

James Turner

[skeptical] 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.

Lachlan Reed

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.

James Turner

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. [long pause] Silent fallback. That means you might think integration is working when really you just slipped back to the old hardcoded behavior.

Lachlan Reed

[responds quickly] 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.

James Turner

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.

Lachlan Reed

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.

James Turner

[reflective] 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.

Lachlan Reed

[warmly] 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.

James Turner

See you.