OpenAI-compatible API providers, ranked by what the base URL swap really buys you.

Groq is unusually honest about its compatibility gaps, which is what you want from a drop-in endpoint. It also fails loudly: an unsupported field returns a 400 instead of being quietly dropped, which is the opposite of the failure mode that costs teams a week elsewhere on this list. The gap list is short and mostly affects evaluation tooling rather than production paths, so the swap is normally a same-day job. The real constraint is model selection: you are optimising around the models Groq serves, not the whole market.

Best for: Low-latency chat, autocomplete-style experiences, classification, support drafts, and anything where a slow token stream is a UX defect.

Documented gaps: logprobs, logit_bias, top_logprobs and messages[].name are unsupported and return a 400 error if supplied, rather than being silently ignored; N must be 1 if supplied; a temperature of 0 is converted to 1e-8; audio vtt and srt formats are unsupported.

Caveat: If your evaluation harness reads logprobs or leans on logit_bias, those calls will not port. Confirm rate limits and production status before moving critical traffic.

If the reason you want an OpenAI-compatible API is that your codebase already calls four different OpenAI endpoints, Together is the shortest migration on this list. The main thing that breaks is anything built on Assistants, Threads, and Runs, plus the flat model-name assumption in your config.

Best for: Apps that use more than chat — embeddings, vision, images, or audio — and want one OpenAI-shaped client for all of it.

Documented gaps: Assistants, Threads and Runs are not implemented — build the agent loop yourself with function calling. The OpenAI-shaped Batch and Files APIs, moderations.create, and OpenAI-format fine-tuning are not supported. Model IDs are namespaced, such as openai/gpt-oss-20b, and OpenAI model strings like gpt-4o or text-embedding-3-large return a 404.

Caveat: Namespaced model IDs mean every model string in your codebase changes even though the client does not. Budget for a config sweep.

Fireworks is the operational pick rather than the headline-price pick. Being able to keep one OpenAI-shaped client while moving the workload from shared serverless to dedicated GPUs is the part that matters once traffic is real.

Best for: Open-model products that start serverless and later need dedicated deployments, higher rate limits, or fine-tuned variants behind the same client.

Documented gaps: Compatibility is centred on completions and chat completions. When a request exceeds the context window, Fireworks truncates by default rather than returning an error, configurable through context_length_exceeded_behavior.

Caveat: The silent truncation default is the one behaviour to change before launch — an over-long prompt fails quietly instead of loudly.

DeepSeek is the reference point most teams use to find out how much they are overpaying. Compatibility is genuinely broad — it speaks both the OpenAI and Anthropic shapes, on separate base URLs — so the switch is usually a config change plus an evaluation run. The number worth modelling is the cache-hit input rate: at $0.007 per 1M tokens it is roughly thirty times cheaper than a cache miss, so prompt structure moves the bill more than the endpoint does.

Best for: Budget-sensitive extraction, summarisation, classification, and bulk text generation where you can benchmark quality prompt family by prompt family.

Documented gaps: DeepSeek's own example sets base_url without a /v1 suffix, and the model catalogue is DeepSeek-specific, so model strings never carry over unchanged.

Caveat: Prices move with peak windows and cache behaviour, so a spot-price comparison against your own traffic pattern is worth more than a table. If your traffic lands inside the weekday peak windows, budget for double.

The Gemini compatibility layer covers more than chat, which puts it ahead of most vendor-run shims. Treat the beta label seriously though: silently ignored parameters are the failure mode that costs you a week, because nothing errors — the output just quietly stops matching what you asked for.

Best for: Teams that want mainstream vendor stability, long context, and Google ecosystem fit without rewriting an OpenAI-shaped client.

Documented gaps: Google states support for the OpenAI libraries is still in beta while it extends feature support. Unlisted parameters are silently ignored by the compatibility layer, and batch file upload and download are not supported — use the genai client for those.

Caveat: Log the parameters you send and diff them against what actually affected the output before you trust the layer with production traffic.

Cerebras is a straightforward swap for chat traffic. The one design constraint worth planning around is that JSON object mode and streaming are mutually exclusive, which matters if your UI streams structured output into a form as it arrives.

Best for: Interactive products on open-weight models where perceived speed is the differentiator and JSON-mode responses can be returned unstreamed.

Documented gaps: json_object is not compatible with streaming — stream must be set to false. service_tier priority is limited to dedicated endpoints, and queue_threshold and prompt_cache_key need private preview or account-level enablement.

Caveat: If you stream structured output today, either restructure the UI or use tool calling instead of json_object mode.

OpenRouter is the cheapest way to stop guessing. Because the client never changes, you can benchmark a dozen candidate models against real traffic and only then decide whether to integrate one of them directly.

Best for: Teams that want to compare models, add fallbacks, or avoid integrating five providers directly while keeping one OpenAI-shaped client.

Documented gaps: Actual parameter support depends on the upstream model — the docs tell you to check the model's provider section to confirm which parameters are supported — and a sampling parameter you omit is omitted upstream rather than defaulted.

Caveat: One endpoint does not mean one behaviour. Route, latency, parameter support, and data policy all vary underneath, so monitor per-route rather than per-endpoint.

The swap works and is well demonstrated, but the absence of a formal compatibility table is a real difference from Groq, Together, or Anthropic. Verify field by field against your own request payloads rather than assuming parity.

Best for: Products that specifically want Grok models and are happy to treat compatibility as example-led rather than contract-led.

Documented gaps: xAI publishes working OpenAI SDK examples rather than a formal blanket compatibility statement, and layers on non-standard fields — it describes its reasoning_effort as a non-standard field meant to ease user experience.

Caveat: Non-standard fields are convenient until you route the same payload to a second provider. Keep provider-specific extras behind a flag.

This is the most useful entry on the list for a reason that has nothing to do with ranking: Anthropic published the field-by-field table that everyone else should. Read it once and you will understand what OpenAI compatibility actually costs you at every other provider — the silently ignored parameters are the ones that hurt.

Best for: Benchmarking Claude against your existing OpenAI-shaped prompts before committing to a native integration.

Documented gaps: Anthropic states the layer is primarily intended to test and compare model capabilities and is not considered a long-term or production-ready solution for most use cases. response_format, seed, logprobs, logit_bias, presence_penalty, frequency_penalty and reasoning_effort are ignored, strict function calling is ignored, audio input is stripped, prompt caching is unsupported, n must be exactly 1, and system and developer messages are hoisted into a single leading system message.

Caveat: Vendor guidance is explicit that this is an evaluation path. If Claude wins your benchmark, move to the native API rather than shipping the shim.

The most under-rated answer to this query is that you can serve the OpenAI API yourself. vLLM covers more of the surface than most hosted shims, including batch and the Responses API, and the client code is identical to every hosted option above.

Best for: Regulated workloads, data-residency requirements, steady high-volume traffic where reserved GPUs beat per-token billing, and anyone who needs the endpoint to outlive a vendor.

Documented gaps: The suffix parameter is not supported on completions, the user parameter is ignored on chat completions, and parallel_tool_calls behaviour depends on the model.

Caveat: The compatibility is the easy part. Capacity planning, autoscaling, model updates, and on-call are the real cost, and they do not appear on any pricing page.

Ollama earns its place because it removes the reason most teams never test provider portability: they do not want to pay for a second endpoint. Point your test suite at localhost and portability becomes something you verify on every build instead of discovering during a migration.

Best for: Local development, CI test doubles, offline demos, and privacy-sensitive prototyping against the same client code you ship.

Documented gaps: Image URLs are not supported — base64 encoded images only. Tool choice is unsupported, logprobs are unavailable, /v1/responses has no previous_response_id or conversation support, and the /v1/completions prompt field currently only accepts a string.

Caveat: Local model quality will not match a hosted frontier model. Use it to test the plumbing, not to sign off on output quality.