Compatibility
Exactly which OpenAI request fields are supported, translated, ignored, or dropped.
The API speaks two OpenAI interfaces — Chat Completions and the Responses API — nothing else. There is no embeddings, audio, image generation, moderation, or realtime endpoint. If your integration only needs chat, the base-URL swap in the quickstart is the whole migration.
"OpenAI-compatible" still leaves a lot unstated, and a field that is silently
ignored rather than rejected is the kind of thing that only shows up in
production. This page is the precise contract for Chat Completions
(POST /v1/chat/completions), sourced directly from the request schema the
server validates against, not from prose that can drift out of sync with it.
Supported as-is
These map straight onto the model's sampling parameters, unchanged:
model, messages, stream, max_tokens, max_completion_tokens
(OpenAI's o-series alias for max_tokens), temperature, top_p, n, stop,
presence_penalty, frequency_penalty, seed.
messages roles
Only system, user, and assistant are accepted. There is no tool role
and no developer role (the o-series alias for system) — see
No tool calling below.
Translated
The shape differs from OpenAI's because the underlying serving engine's parameters differ — the request is accepted in OpenAI's shape and converted:
| Field | OpenAI shape | What happens |
|---|---|---|
logprobs / top_logprobs | logprobs: bool + top_logprobs: int | Combined into a single top-k count |
logit_bias | string keys (stringified token ids) | Converted to integer token ids |
response_format | {"type": "json_object"} or {"type": "json_schema", ...} | json_object maps to guided decoding. json_schema is best-effort — complex schemas may not be enforced exactly |
Accepted, no effect
Present in the request schema so SDKs don't error, but nothing on the serving path reads them:
user, store, metadata, stream_options.
store and stream_options do nothing here
These matter on OpenAI's own API and on Telluvian's Responses
endpoint — but on Chat
Completions specifically, they are accepted and ignored. Usage always
arrives on the final stream chunk regardless of stream_options; see
Usage is always on the last chunk.
Not in the schema — silently dropped
Anything not listed above or on the include_scores
page is not rejected. The request still succeeds;
the unrecognized field is dropped before the request reaches the model.
Concretely, that includes:
No tool calling
tools, tool_choice, functions, function_call, and parallel_tool_calls
are all silently dropped. There is no tool/function-calling support, and no
tool message role to carry a result back — sending a tool-calling request
gets you back a plain text completion as if tools had never been set.
No vision / multimodal input
Every model is text-in, text-out. A content array with an image_url part
is dropped rather than translated; only content as a plain string is read.
Anything else not listed above
logit_bias beyond the translation noted, reasoning-effort style fields,
service_tier, and any other field not in the tables above — same rule:
accepted request, field ignored.
Check the response, not just the request you sent
A silently dropped field is the single easiest way to lose hours: your code
looks correct, the request succeeds, and the behavior you expected just
never happens. If a feature you're relying on doesn't seem to work, confirm
it's actually in the tables above before debugging anything else — the same
advice as verifying include_scores.
Probe extensions
Two fields exist only on this API, layered on top of the OpenAI shape:
include_scores— turns the hallucination probe on or off. See the dedicated page.tokens/scoreson the response — the probe's output. See Reading the scores.
The Responses API
/v1/responses is a separate, stateful interface built on
the same underlying model. The same "no tool calling, no multimodal input"
limits apply there too — the constraint is the model and probe pipeline, not
which endpoint you call.