What Calling a Model Takes

base_url, model name, and API key. Why everyone is compatible with the OpenAI format.

You don't need to write code, but you should know what the engineers are saying. A model call needs surprisingly little: where to send it, which model, whose bill. Just those three.

Signs you'll recognize:

• An engineer says "switching models is fast" and you're not sure whether to believe it.
• One morning the results and the bill both change, and nobody touched the code.
• You see someone putting an API key in a frontend page and don't know how bad that is.

The three essentials

base_url—where to send it. The address of the model service. Fill in the official one if you're using the provider directly, the cloud platform's if you're going through a cloud, or your own gateway if you run one.

Model name—which one. An identifier that selects which model handles this request. One address usually offers dozens.

API key—whose bill. A secret string that is both your identity credential and your billing attribution. Whoever holds it can spend your quota.

Beyond that, it's just the content you're sending (prompt, conversation history) plus some call parameters. Integration itself isn't complicated. What's complicated is everything after integration: controlling cost, handling failures, and accepting quality.

Why everyone speaks the same format

The most convenient fact when integrating: almost every model platform is compatible with the same interface format—informally called the "OpenAI-compatible format." Claude's API is REST-based too, authenticating with an x-api-key header, with the same overall shape. claude-api

The reason is easy to understand. This format came first and has the largest tool ecosystem. Any newcomer that invented its own format would force customers to rewrite code to migrate—nobody wants that barrier, so everyone chooses compatibility.

Practically, this means switching providers often requires changing only two fields: base_url and the model name. So when an engineer says "switching is fast," usually it's not an exaggeration.

But chase two caveats. First, prompts need re-tuning. A connected API doesn't mean identical behavior; different providers respond to the same prompt differently, so expect adjustments. Second, non-standard features aren't guaranteed to transfer. Tool calling, structured output, and caching details differ; the deeper you use them, the higher the migration cost.

So the real advice: from day one, wrap model calls in your own layer. Business code calls only your interface; which provider sits behind it is decided in that layer. Switching, adding a fallback, and degrading gracefully all change one place.

Pitfalls in model names

A model name looks like a plain string, but a few things are worth watching.

Version and date suffixes. Many model names carry a specific version or date—say, the July 2026 build of a model. Pinning to an exact version makes behavior stable. OpenAI's text generation docs recommend the same: pin production to a specific snapshot, like gpt-5.5-2026-04-23. openai-textgen

Beware aliases like -latest. They point at the newest version of a family; the moment the vendor ships a release, your calls switch over automatically. Sounds convenient, but it means one morning your quality, latency, and bill can all change while you changed nothing.

That's a real product headache, because it's hard to debug: everyone is sure "we didn't touch anything."

The advice: pin production to an exact version and treat upgrades like a normal release—run your fixed sample set first, and only switch when there's no regression. Use latest in test environments to see what the next version brings early.

The key rule

This one has no room for negotiation: API keys must never live in the frontend.

Browser JavaScript and app bundles are things users can open up. Putting a key there is equivalent to publishing it. Anyone who grabs it can run up your quota at your expense—and these incidents can burn a lot of money within hours.

The correct setup: keys live only on your backend. The frontend calls your API; your backend calls the model. This middle layer is mandatory, no exceptions.

As a bonus, that layer gives you useful things for free: rate limiting (stop one user from draining your quota), usage tracking (which feature spends how much), audit logs (something to check when things go wrong), and unified fallback (auto-switch to a backup when the primary model is down). Every product needs these eventually.

Two more rules to remember together: keys must be revocable and reissuable (the moment you suspect a leak, rotate it; don't hesitate), and use different keys per environment (a test-env leak shouldn't affect production).