What 'OpenAI-compatible' actually means (and why it's the most important spec in AI)

When you read that an API gateway like JJAPI is “OpenAI-compatible,” it sounds like marketing fluff. It isn’t. It’s the single most useful property an AI API can have — and it’s worth understanding why.

The wire format is the API

The OpenAI REST API has, at this point, become a de facto standard. Every major hosting service — Together, Anyscale, Groq, Mistral, Fireworks, and yes JJAPI — implements POST /v1/chat/completions with the same JSON shape:

{
  "model": "gpt-4o",
  "messages": [
    {"role": "system", "content": "..."},
    {"role": "user", "content": "..."}
  ],
  "temperature": 0.7,
  "stream": false
}

…and returns:

{
  "id": "chatcmpl-...",
  "choices": [
    {
      "message": {"role": "assistant", "content": "..."},
      "finish_reason": "stop"
    }
  ],
  "usage": {"prompt_tokens": 12, "completion_tokens": 8}
}

Because of this convergence, the OpenAI SDK works as the universal client. Set base_url to any compatible provider and your code keeps running.

Why this matters for you

1. Zero migration cost. Move from OpenAI to a cheaper provider by changing one variable.
2. Compose vendors. Use Claude for hard reasoning and DeepSeek for cheap labor — same SDK call, different model string.
3. Tooling inheritance. LangChain, LlamaIndex, Vercel AI SDK, Continue, Cursor, Cherry Studio — every tool that knows how to talk to OpenAI also knows how to talk to JJAPI.
4. No lock-in regret. Years from now when GPT-7 is the dominant model, your code already supports it.

What’s NOT covered by “OpenAI-compatible”

A handful of recent features are vendor-specific even within the OpenAI ecosystem:

• Assistants API (/v1/assistants, threads, etc.) — heavyweight, stateful, slow to converge across providers.
• Realtime API (WebSocket-based) — fast-evolving; JJAPI supports a compatible subset but expect rough edges.
• Files API — uploads vary by provider; we mirror the OpenAI semantics where the upstream supports it.

For 95% of production code (chat, embeddings, image generation, transcription), OpenAI-compatible is enough.

How JJAPI implements compatibility

We translate non-OpenAI payloads (Claude’s tool format, Gemini’s parts list, DeepSeek’s reasoning chunks) into and out of the OpenAI shape transparently. Streaming SSE is normalized to OpenAI’s event format regardless of upstream wire protocol.

The upshot: you write OpenAI-flavored code and JJAPI handles the impedance mismatch.