The reference shape comes from the OpenAI API ecosystem, but each implementation documents its own supported subset.
What does compatibility cover?
It commonly covers endpoint paths, authentication headers, message objects, and response fields. It can reduce the adapter code needed to try another inference provider. Streaming, tool calls, structured outputs, multimodal inputs, and error formats may still differ.
API compatibility is not model compatibility.
How should teams use it safely?
Treat it as a transport convenience and test every capability the application relies on. Contract tests should cover successful output, streaming, tools, limits, and errors for each provider. Keep provider-specific features behind a clear adapter or LLM gateway. That supports practical model portability without pretending all models are interchangeable.
Where does compatibility usually break?
Differences often appear in tool-call schemas, streaming events, structured outputs, model names, token limits, error bodies, and unsupported request fields. Even a request that is accepted can produce different behavior or ignore an option. Teams should run contract tests against every provider and pin the capabilities the application actually uses. OpenAI-compatible describes an interface family, not identical semantics. Keep provider-specific exceptions visible in a small adapter and record the actual route through LLM observability so production failures can be traced correctly.
OpenAI’s API reference is the authoritative baseline for the interface that other providers describe as compatible.