Every parameter: honoured or refused

On /v1/chat/completions a parameter can end up in two ways:

• it reaches the engine and does what its name says;
• it is refused with a 400 that names it and says what to use instead.

That is the rule, and it is the most useful one on this page: if the request comes back 200, what you wrote has been applied. Today it has exceptions, and they are all here:

• with "stream": true, two parameters are accepted and do not do in a stream what they do without it: stream_options, and logprobs with top_logprobs. n above 1 is refused. See With stream: true;
• on the models served by Ollama, tool_choice is not applied. See Models served by Ollama.

The rule is for this endpoint. What other endpoints accept, refuse or ignore is in What works where.

Why we write it so explicitly#

Because until 18 August 2026 it was not true. The gateway accepted seven parameters and dropped them without saying so: max_completion_tokens, stop, n, seed, logprobs, top_logprobs, parallel_tool_calls. It also accepted an eighth, top_p, which was even in the table of this documentation. The response came back 200 and looked right.

The worst case was n. The gateway forwarded it, the engine generated the requested answers and billed all of them, and we returned the first one and threw away the others: you paid for tokens you never saw. Worse than ignoring the parameter.

The most expensive case was max_completion_tokens, the new name OpenAI recommends for the token cap. Whoever used it had no cap at all, and found out on the invoice.

It was reported by the team building a Swiss business application on top of this API, with the sentence that decided how the fix is made: "an error is found during development, an ignored cap is found on the invoice".

Honoured#

Tested on the engine one by one on 18 August 2026, then through the public gateway.

Reasoning#

Each engine has its own switch, and we translate the field for it:

Reasoning tokens are output tokens: they count against max_tokens and are billed at the output price.

The token cap, and its two names#

max_tokens and max_completion_tokens are the same cap. If you send one, that one applies. If you send both with the same number, fine. If you send both with different numbers we answer 400: two different caps in the same request mean that whoever wrote it believes in one of them, and guessing which is how a customer ends up paying for our guess.

user, and where it ends up#

The user field is stored with the usage record of the request. It is for you, to separate your users, departments or customers within a single invoice. It is a string you give us, kept as it is: we do not link it to anything and do not use it for anything else.

It is stored the same way with stream: true. One limit today: the dashboard does not show it yet, so ask info@daikolab.ch for an extract.

If you are looking for an X-Siati-User header, it is gone: it was documented and never implemented. Use user, which is the OpenAI name and works with the libraries you already have.

Models served by Ollama#

The models served by vLLM apply every parameter above. Some models are served by Ollama instead: today the qwen2.5 models, where the catalogue has them. On those:

• n above 1, logprobs, top_logprobs, logit_bias and parallel_tool_calls get a 400 naming the parameter and saying on which models it works, not a 502 and not silence. n: 1 is accepted;
• tool_choice is accepted and not applied: the model decides by itself whether to call a function;
• response_format is applied with and without stream, and {"type": "text"} gives free text;
• function calls arrive in OpenAI's shape, as on the other models: Ollama writes them in its own, and we rewrite them, see What we change in responses.

With stream: true#

Everything else behaves in a stream as it does without one, response_format and tools included, on the models served by Ollama too.

Refused, with the reason#

Any other parameter#

In a JSON body, which is what the SDKs send, a name we do not recognise gives 400 and is named. That includes typos, which is the most useful part: tempreature used to go through, the temperature stayed at the default and there was no way to notice it from the answer.

The answer names the field:

{
  "error": {
    "message": "Unrecognized request argument supplied: 'tempreature'. We refuse what we do not know instead of ignoring it: an argument accepted and dropped does not show in the answer. Accepted: …",
    "type": "invalid_request_error",
    "param": "tempreature"
  }
}

Transcription: timestamp_granularities#

This field follows the same rule. timestamp_granularities: ["word"] returns per-word timings in words, with start, end and probability of each. Until 18 August the field was accepted and not forwarded, so only segments came back.

Timings exist only inside response_format: "verbose_json": the other two forms have nowhere to put them, and asking for them without verbose_json gives 400 instead of an answer without timings, which could not be told apart from audio in which the words could not be heard.

curl https://api.aitokens.ch/v1/audio/transcriptions \
  -H "Authorization: Bearer $API_KEY" \
  -F file=@note.wav \
  -F model=whisper-1 \
  -F response_format=verbose_json \
  -F "timestamp_granularities[]=word"

How we avoid repeating the mistake#

The cause was not someone's distraction: request validation returned only the fields it listed, and everything else vanished without an error and without a log line. A defect like that is not found by rereading the code, because there is nothing to see.

Now the list of parameters lives in one place, and an automated test fails if a field is validated without ending up either at the engine or among the refused. We checked it by deliberately adding a forgotten parameter: the test named it.

It does not protect us from not supporting something you need. It protects us from pretending to support it, which is what costs you the most.