The Socket Other Models Plug Into

The same move runs through Codex. A comment on a DeepSeek setup says DeepSeek supports the OpenAI Responses API format and that Codex CLI can point at any compatible endpoint, so the arrangement checks out. The point of such a setup is that the front end stays while the model underneath changes. One developer who ran out of Pro-plan usage had moved to DeepSeek in another tool, said they were missing Codex, and built a Mac menu bar app that switches the Codex app's model provider with a single click.

Local-model tools are described in the same terms. One commenter explaining remote access says vllm and llamacpp servers use the OpenAI API standard. The remark comes in parentheses, as a point needing no argument. Someone building a gateway puts the underlying problem plainly: each provider has its own SDKs, authentication, billing and model names, which makes switching harder than it should be, so the gateway offers a single OpenAI-compatible endpoint and key for several model families. The pitch rests on the format: the providers differ, and the endpoint they are all reached through speaks OpenAI's.

The shared format does not carry everything. One comparison of tools that can take DeepSeek rates the Codex route as good but notes that, because DeepSeek is not a native OpenAI model, not every Codex feature behaves identically. Matching the interface gets a model into the tool, and what the tool does with it is a separate matter.

Compatibility settles the plumbing, not the price, and the week's money questions are about the price. One developer deciding how to run a production app weighs paying the API's per-token usage against authenticating through a ChatGPT subscription and spending its allowance, which they say could be significantly cheaper and already works. The appeal is plain: the subscription's allowance in place of metered usage. Another person wants API automation at a cost reasonably close to what a monthly Plus subscription gives them for a workflow they run by hand in ChatGPT with reasoning set to high. Both are comparing the API's metering with what a monthly subscription buys.

Some people run into the border between ChatGPT and the API. One reply to a question about credits says that buying them in ChatGPT and adding them on the platform's page are different altogether. The ChatGPT login and the platform look like one company's door and behave like two, and a compatible format does nothing for that seam. A developer setting up accounts for client work says the platform refused to add credits with a card that ChatGPT had accepted, and asks whether OpenAI hates getting paid.

The API also reaches people through Azure, where the complaints turn into questions about hosting. A user on Foundry reports slow response times from gpt-5.6 deployments through the OpenAI Responses API in one region, and says it seems limited to the gpt-5.6 models. Elsewhere a user is disappointed that only Global Standard deployments are on offer and none in the DataZone EU, adding that the original OpenAI API had been usable some days earlier with more quota. In one account the trouble is speed, and in the other it is which deployments are on offer and how much quota comes with them. Neither complaint is about the shape of the interface.

One thread shows what the API leaves to the builder. A user whose coding agent ends its turn and waits for a typed "Continue" gets a reply that the API itself has no "keep going until blocked" mode, so any fix is an external loop that checks state and fires the next call. The reply describes a primitive: calls, not sessions. In that account, a model that fits the shape gets calls, and anything more continuous is something the developer builds around them.

A format that other tools are built to speak becomes a promise as well as a convenience. It makes the API a standard OpenAI shares with the builders who rely on it, not only a product it sells.