Leaving the API is one line of code.

The meeting happens everywhere. Everyone in the room wants off the hosted API, pick the reason: the data that should not be leaving, the rate tier that will not survive the roadmap, the bill that scales with success. And then someone says the sentence that ends it: we're too integrated, it would be a rewrite. Six months later, same meeting, same sentence, one more retry-logic sprint in between.

The sentence deserves an audit, because the integration it describes is one config value deep.

The world standardized while you weren't looking

Something useful happened in the serving world over the past few years: the OpenAI API format became the de facto wire standard for talking to language models, and the open-source serving stacks adopted it on purpose. Same routes, same request format, same streaming protocol, for the widely used core of the surface: chat completions, streaming, embeddings. When we hand over a private endpoint, it speaks that dialect natively. Your SDK does not know it moved. If your app leaned on one vendor's proprietary extras, that is a short audit, not a rewrite, and we walk it with you: most extras have direct equivalents or thin shims.

- OPENAI_BASE_URL=https://api.vendor.example/v1
+ OPENAI_BASE_URL=https://inference.yourcompany.internal/v1
  OPENAI_API_KEY=****   # your key, issued by you, revoked by you

Prompts, streaming handlers, retry logic, tooling: untouched. That diff is the whole plumbing migration. Which is exactly why the rewrite budget deserves suspicion: it was priced for a world where every provider had its own wire format, and that world is gone.

What actually changes: the model

Now the honest half, because the one-line claim is only true about the plumbing. A different model is a different colleague. Ask it the same question and the answer comes back worded and structured differently; prompts tuned for one model may need adjustment; edge cases move around. This is real work. It is also bounded, testable, and cheap compared to what you budgeted: run your existing eval set (or build the small one you should have anyway) against the candidate model on your actual tasks, compare, decide. It happens before you commit, on an endpoint you can trial, not after a rewrite you cannot undo.

Notice what did not appear in that table: any claim that the open model is just as good. We do not make that claim, because it ages badly and because you should not take it from a vendor anyway. The eval run replaces the claim. Your tasks, both models, side by side, and the decision is yours with the evidence in front of you. That eval pass is part of our deployment, along with the sizing and the quantization trade-off (shown, not hidden), which is where a managed host earns the fee.

The line cuts both ways, on purpose

Everything above also describes leaving us. Open weights are portable files. The endpoint speaks the standard dialect. Your data lives on your machine and departs with you. If we stop deserving the workload, the migration away is the same one line, and we built it that way deliberately, for the same reason the rest of this company deleted meters and refuses exit taxes (the egress-fee argument is the same posture one layer down). Anti-lock-in you cannot exercise is a brochure word. Customers who can leave, and stay anyway, are the only reference worth having.

One more freedom rides along: once the model is yours, nobody retires it out from under your prompts, and the version that passed your evals stays the version answering until you decide otherwise. On a hosted API, that schedule belongs to someone else.

“The same line that lets you leave them lets you leave us. That's the point.”