Migrating an [OI] SDK App to a Multi-Model Gateway in One Afternoon

Most teams assume switching LLM providers means a rewrite: new SDK, new auth, new response shapes, new error handling. If the target gateway is [OI]-compatible, it's closer to a config change.

What actually changes

One line of config. Point the base URL at the gateway and keep your API key handling. Your existing client code — chat completions, streaming, embeddings — keeps working because the request and response shapes are unchanged.

Model ids. This is the only place you touch code. Swap the model string to route to a different family: GPT-class, Claude-class, Gemini-class, DeepSeek or an open-source model. Everything downstream stays identical.

A safe migration sequence

1. Shadow traffic. Send a copy of production requests to the new endpoint and diff outputs. No user impact.
2. Route one endpoint. Pick a low-risk feature — summarisation, classification — and switch it fully. Watch latency and cost for a week.
3. Compare effective cost. Not list price: actual spend divided by actual tokens, including retries and cache behaviour.
4. Expand gradually. Move the next endpoint only after the first one's numbers look right.

Why the pricing page matters here

A gateway that publishes per-token input, output and cache rates lets you predict the cost delta before you migrate, instead of discovering it at month-end. Our full table is public: compare [OI] API pricing.

Because the SDK stays the same, a rollback is also one line. That asymmetry — cheap to try, cheap to revert — is what makes the migration worth testing at all.