What Is an OpenAI-Compatible API? How It Works, Who Offers It, and Its Limits (2026)

On October 15, 2026, we ran one Python script against four providers to show what "compatible" looks like in practice. The results are below.

What "compatible" covers

The OpenAI API defined a de facto standard for calling language models:

A provider is "OpenAI-compatible" when it implements that contract, usually for Chat Completions. Most stop there. Support for the newer Responses API (/v1/responses) is much less common, which matters because tools like Codex CLI now require it.

One script, four providers

The official openai Python library, with only the base URL and model name changing per provider:

from openai import OpenAI

PROVIDERS = {
    "OpenAI":    ("https://api.openai.com/v1",                               "gpt-6-luna"),
    "Anthropic": ("https://api.anthropic.com/v1/",                           "claude-haiku-5-5"),
    "Gemini":    ("https://generativelanguage.googleapis.com/v1beta/openai/", "gemini-3-flash"),
    "api.foo":   ("https://api.foo/v1",                                      "gpt-6.1-sol"),
}

for name, (base_url, model) in PROVIDERS.items():
    client = OpenAI(api_key="YOUR_KEY_FOR_THIS_PROVIDER", base_url=base_url)
    r = client.chat.completions.create(
        model=model, messages=[{"role": "user", "content": "hi"}]
    )
    print(name, r.choices[0].message.content)

To see how each one behaves at the edges, we ran it with a deliberately invalid key (openai 3.31.0). Every request reached the right service, and every service rejected the key in its own way:

The request format is the same everywhere, but the error contract isn't. Gemini returns 400 for a bad key, not 401, so code that only treats 401 as an auth failure will misreport it. If you handle errors programmatically, branch on the status code and the error body, and test against each provider you support.

Who offers an OpenAI-compatible endpoint

What doesn't carry over

"Compatible" rarely means identical. The gaps that cause real bugs:

1. Ignored parameters. Anthropic's layer, for example, silently ignores response_format, seed, logprobs, presence_penalty, frequency_penalty, reasoning_effort and the strict flag on tools. Your request succeeds, but you don't get guaranteed JSON or schema-valid tool calls. Anthropic notes that most unsupported fields are ignored rather than rejected, so nothing warns you.

2. Provider-specific features. Prompt caching isn't available through Anthropic's OpenAI layer, nor are PDFs, citations or extended thinking. Use the native Claude API for those. Gemini's thinking controls arrive through a mapping of reasoning_effort, not 1:1.

3. Message handling. Anthropic's layer moves every system or developer message into a single top-level system prompt, wherever it appeared in the conversation.

4. Errors and limits. As the table above shows, status codes and error bodies differ, and so do rate-limit headers.

5. Model names. model must use each provider's own IDs, and gateways sometimes rename models.

6. Endpoints beyond chat. Embeddings, images, audio and the Responses API are hit-and-miss. Check each one you need.

Rule of thumb: use the OpenAI-compatible layer to switch and compare quickly. Once a provider becomes core to your product, use its native API for production, especially with Claude, where native prompt caching cuts the cost of repeated input by 90% or more (see Claude API pricing).

Where LLM gateways fit

An LLM API gateway is a service between your app and many providers. It usually exposes one OpenAI-compatible API (sometimes Anthropic- and Gemini-native ones too) and adds:

• One key and one bill for many providers, instead of an account per vendor.
• Routing and failover: if one upstream fails, retry another.
• Usage tracking and budgets per key, user or team.
• Format translation, so an OpenAI-format request can reach a model whose native API is different.

You can self-host one, for example with the open-source LiteLLM proxy, when you need full control and already have provider accounts. Or you can use a hosted gateway when you'd rather not manage provider accounts and payments yourself. api.foo, which publishes these docs, is a hosted gateway. It serves OpenAI Chat Completions and Responses, the Anthropic Messages API and the Gemini API from one key, so Claude Code, Codex and Gemini CLI can each use their native format.

Checklist before you rely on a "compatible" provider

1. Which endpoints? Chat Completions only, or also /responses, /embeddings and /models?
2. Streaming: does it stream, and does it send usage in the final chunk if you need token counts?
3. Tool calling and structured output: are tools, tool_choice and response_format honored or ignored?
4. Vision and files: are image inputs supported for the models you use?
5. Errors: which status codes and error bodies does it return for auth, quota and rate limits?
6. Model IDs: what are the exact names, and do they change?

Ten minutes with these questions and a test key saves debugging later.

Related

• OpenAI API alternatives compared
• OpenAI API pricing
• Claude API pricing
• Cherry Studio guide: custom providers and URL rules
• Install Codex CLI (Responses API providers)