The article details 12 specific areas where the OpenAI-compatible API standard diverges across different inference engines and hosted providers, causing silent failures or unexpected behavior. While core request shapes and basic streaming work reliably, subtle differences in parameter handling, error responses, and feature support can break applications.
- Unknown parameters are often silently dropped rather than rejected with a 400 error.
- Reasoning models may require `max_completion_tokens` instead of `max_tokens`, with inconsistent acceptance.
- Token usage statistics are frequently absent from streaming responses unless explicitly requested via `stream_options`.
- Tool calling support varies significantly, with many servers lacking native parallel calls or strict schema adherence.
- JSON mode implementations differ between basic object validation and constrained decoding with schemas.
- Context overflow handling ranges from hard 400 errors to silent truncation of system prompts.
- `finish_reason` values include provider-specific additions beyond the standard stop, length, and tool_calls.
- Error envelopes and rate limiting responses (429, 503, or 200 with body errors) are inconsistent.
- Temperature settings on reasoning models may be ignored internally despite being accepted.
- Multimodal input handling varies in size caps, MIME types, and the `detail` parameter.
- Embedding endpoints lack portability due to differing dimensionality and normalization.
- Idempotency keys are rarely supported, and request-ID headers use inconsistent naming.
The author recommends using a probe script to test provider conformance for these specific behaviors, as model versions change frequently and silent failures can be difficult to debug in production.