Exactly which OpenAI request fields are supported, translated, ignored, or dropped.

The API speaks two OpenAI interfaces and nothing else: Chat Completions and the Responses API. 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. Every unrecognized field is accepted and ignored except where noted under Rejected, not dropped.

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, and 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.

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.

Rejected, not dropped

One shape is a hard error rather than a silent drop:

No vision / multimodal input

Every model is text-in, text-out. content must be a plain string. A content array, [{"type": "image_url", ...}], is rejected with a 422, not ignored like the fields above.

The 422 is not OpenAI-shaped

This error is raised by the model server's schema validation and passes through unchanged, so its body is {"detail": [...]} rather than the {"error": {...}} object every other status returns. Parse defensively if you handle it.

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.

Telluvian extensions

Four things exist only on this API, layered on top of the OpenAI shape:

include_scores enables verification when explicitly set to true; it defaults to false. See the dedicated page.
tokens / scores on the response carry the probe's output. See Reading the scores.
The -analyze model suffix scores text you already have instead of generating any. It is a suffix on model, so it passes through an unmodified OpenAI SDK untouched. See Scoring existing text.
The Model Select controls: xPerf, xPerfEffort, xLatency, modelZoo and sessionId. Unlike every other extra field on this page these are read rather than ignored, but only when model is telluvian/gallery-1. They are consumed by the choice and stripped before the model is called. xLatency is accepted and recorded but currently ignored. Sent with any other model they are ordinary unrecognized fields, and ignored. See Model Select.

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.

Compatibility