Swapping Across 25 Models With One Line

Picking a model usually feels like a decision you have to live with. You install that provider's SDK, wire in its key, learn its quirks, and the choice is baked into your code. Switching later is a small migration, so most teams pick one model and stick with it even when a cheaper or better one would suit a given task.

Through an AI gateway, the model is just a string in the request. The gateway exposes around 25 models across OpenAI, Anthropic, and Google, and moving between any of them is a one-token change with the same code and the same credential. That matters more than convenience, because the catalog spans a roughly 100x price range. When swapping is free, model choice stops being a one-time architecture decision and becomes a per-task cost lever. This post shows the swap, the price spread that makes it worth caring about, and a real run across several models. The repo is at the end.

TL;DR

• Through the gateway, changing model is changing the model string. Same code, same credential, roughly 25 models across three providers.
• The catalog spans about 100x in price, from cheap small models to flagship ones, so which model you pick is usually your biggest cost knob.
• The move is to route by task: a cheap model for classification and extraction, a strong one for hard reasoning, all behind one call.
• Same code does not mean same output. Swapping is trivial; validating that a cheaper model is good enough for your prompt is the actual work.

Prerequisites

• A Neon project with the AI gateway enabled (us-east-2)
• Familiarity with chat-completions requests

The swap is one line

Every model is the same request; only the model field changes:

// Same function, same credential. The model is data.
await callGateway('gpt-5-nano', prompt, maxTokens);       // OpenAI, cheapest
await callGateway('gemini-2-5-flash', prompt, maxTokens); // Google
await callGateway('claude-haiku-4-5', prompt, maxTokens); // Anthropic
await callGateway('claude-opus-4-5', prompt, maxTokens);  // Anthropic, flagship

Because the chain is data, the model can come from config, a per-tenant setting, or a routing decision made at request time. Nothing about the integration changes when you pick a different one.

Why the swap is worth caring about: the price spread

Convenience alone would be a footnote. The reason to actually use this is that the models are priced across a huge range, so the same request can cost wildly different amounts depending on which one you send it to.

Output tokens on the flagship run about 60x the cheapest small model. So a high-volume, low-difficulty workload, classifying support tickets, extracting fields, tagging content, that you route to a flagship out of habit is potentially a large bill for no benefit, and routing it to a small model is a one-word change.

The proof: one prompt, several models

I sent the same question through several models on the deployed function. Same code, same credential, just a different model each time, with the real token counts the gateway returned.

For a trivial prompt like this, all three give the same answer, which is exactly the point: when a small model is good enough, the swap is the whole optimization. The harder your task, the more the model matters, and the gateway lets you find where the line is by trying, cheaply, on your own prompts.

How to actually use it

• Default cheap, escalate deliberately. Send the common case to a small model; route the genuinely hard requests to a bigger one. Because the split is a string per request, the policy is easy to change.
• Benchmark on your prompts. The only way to know a cheaper model holds up is to run your real prompts through it. Swapping being free is what makes that measurement cheap.
• Keep the choice in config. Put the model per task or per tenant in config so you can retune without a deploy.

The repo

The function that makes the model a request field is here:

Wrapping up

The gateway turns model choice from an architecture decision into a request parameter, and the 100x price spread across the catalog is what makes that worth using rather than just neat. Route each task to the cheapest model that is good enough, escalate the hard ones on purpose, and keep the policy in config so you can retune as prices and models move. The swap is one line; the work that pays off is measuring, cheaply now, which line to draw.