Integration guides · 2026-09-11

Moving from the OpenAI SDK to a compatible gateway without rewriting your app

Switching language model providers is usually a two-line change: the base URL and the key. What stays the same, what has to be pinned by model identifier, and what to check before you go to production.

Diagram of a migration from the OpenAI SDK to a compatible gateway showing the base URL change, the key and the model identifier.

What changes is two lines

An OpenAI-compatible gateway exposes the same API surface you are already calling. In practice that means the SDK stays as it is and the migration comes down to pointing the base URL somewhere else and using a different key.

The rest of your code — message construction, tools, streaming, error handling — is untouched, because the request and response shapes are the same.

OpenAI client pointed at a compatible gateway

from openai import OpenAI

client = OpenAI(
    base_url="https://llmtr.com/v1",
    api_key="YOUR_API_KEY",
)

response = client.chat.completions.create(
    model="provider/model-identifier",
    messages=[{"role": "user", "content": "Summarise this contract in five points."}],
)

print(response.choices[0].message.content)

Pin the model by identifier, not by alias

A convenient alias of the model-latest kind is pleasant during development and unpleasant in production: the model underneath can change without your code noticing, and cost, latency and behaviour change with it.

The alternative is to pin the full identifier with its version and treat a model change for what it is: a deployment. When a provider retires a model, what you want back is an explainable error naming the successor, not a different answer from a model you never chose.

Keys and spend control

A migration is a good moment to fix something that is almost always wrong from day one: the key lives in the client, or in a repository, or in both.

The key belongs on the server. Browser and mobile talk to your backend, and the backend talks to the gateway. Besides preventing the leak, that gives you the one place where per-user limits can be enforced, usage recorded, and a spend leak stopped without shipping a new app version.

Before you go to production

Five checks that take an afternoon and prevent the expensive surprises.

  • Run your evaluation set against the new model before switching, not after.
  • Verify that streaming and tool calls behave the same way in your specific case.
  • Confirm what the API returns when the chosen model is no longer available.
  • Check the usage record: months later you should still be able to tell which model served a request.
  • Leave the previous provider configured until the new one has a week in production.

Frequently asked questions

Do I have to change SDK?

No, provided the gateway exposes the OpenAI-compatible surface. The official client keeps working once the base URL and key change.

Do model prices change when they go through a gateway?

At LLMTR model prices stay exactly as listed in the catalog. The platform margin applies only to credit top-ups, never to a model's per-token price.

Can I still use streaming and tool calls?

That depends on the model and the provider behind it, not on the gateway in the abstract. Check it for the specific model you intend to use before migrating.

Related posts