grok-4.6

xAI's Grok model, and one of the two language models on the platform that demonstrably read temperature, alongside gemma-4-31b-it. It changes the reply here, and a value below 0 comes back refused with xAI explaining why rather than quietly swallowed. The catch is at the top of the range. OnCore caps temperature at 1.5 on this model, because the 2 LiveKit publishes as the ceiling returns nothing at all, so a higher value gets you 1.5 rather than an error.

It thinks before it answers. reasoning_effort moves that spend, and it moves it down rather than up: a turn costs less with low set than with the key left out.

Reached through the LiveKit Inference gateway.

temperature and maxTokens are set on the model catalogue entry rather than in a provider body; everything else here is sent to the gateway exactly as written, so these use the upstream spelling. There is no list of permitted settings on this route, so a name that is not a chat-completions parameter at all is not caught by OnCore: it fails inside the client LiveKit calls the provider with, before any request goes out, and automatic failover answers that turn instead, so the reply comes from a different model than the one you selected. A value the provider refuses ends the same way, and that is what the If invalid column means on this page. A refused setting never reaches the caller as an error: another model answers that turn on its own settings, and the reply reads perfectly normally. There is a section on that below. Send only the settings listed here.

Settings#

Every setting is optional. Leave one out and OnCore sends nothing for it, so the Default applies. If invalid is what the provider does with a value it does not accept.

Overriding on a single call#

Return this from your assistant-request webhook to apply these settings to one call. This is the only route that carries them. A model in your catalogue stores the model id, temperature and maxTokens, and nothing else, so every other setting on this page is sent per call or not at all.

{
  "data": {
    "overrides": {
      "model": {
        "settings": {
          "temperature": 0.8,
          "maxTokens": 250,
          "top_p": 0.9,
          "max_completion_tokens": 2000,
          "reasoning_effort": "low",
          "tool_choice": "auto"
        }
      }
    }
  }
}

Send only the keys you want. A key you leave out is not sent at all, so the Default applies rather than a stored value. Add "id" beside "settings" to swap the whole model for another one from your catalogue at the same time.

temperature: This model reads temperature, which most of the catalogue does not. Measured on 2026-09-03: 0 returned the same answer three times out of three, and 0.2 cut a 302 character reply to 245. OnCore caps it at 1.5 and lowers anything higher rather than sending it, because at 2, the top of the range LiveKit publishes, the request returned no content at all in three samples out of three and the caller hears dead air until it times out. Above the cap you get 1.5 rather than an error, and that holds however high you go: 5 is lowered too rather than sent. Below 0 nothing intervenes and xAI answers for itself, refusing -1 with the message that temperature must be positive. Sent straight to xAI rather than through a call, 5 is refused the same way, with the message that temperature must be less than 2.

top_p: An alternative to temperature for controlling variation. Set one or the other, not both. This is the one key on this model whose range is enforced while its effect is not: 5 and -1 are both refused outright, with xAI naming the bound each time, and yet 0.01 left the spread of answers exactly where the baseline had it over six samples. So keep it in range, and do not count on it changing anything.

max_completion_tokens: The raw form of maxTokens, for overriding the limit on a single call. LiveKit documents this limit as covering reasoning tokens as well as the spoken reply, and this model reasons before it answers, so a tight limit costs you words: at 30 the reply came back 150 characters long and cut mid-sentence, against 302 characters unlimited. A limit of 0 was sent and read as no limit rather than refused, which is the opposite of what the Allowed column would suggest; a negative limit was never sent. maxTokens above is the same limit reached by a different route, and the two rows carry different guards only because different things were tried on each.

reasoning_effort: Genuinely moves the spend here, and downward: low cost 107 tokens and 108 on a repeat, high cost 165, against 392 with the key left out. Send one of the three and nothing else. Measured on 2026-09-03, none, banana and a number were each refused outright, which is the opposite of the Gemini models, where an unrecognised level is accepted and quietly ignored. minimal, the level Google's own thinking control takes, is the exception: this model accepts it without complaint, and its single sample spent as much as low did, so nothing separates the two. xAI's own parameter table does not list this key for the model at all, so treat the levels as measured behaviour rather than a published contract.

tool_choice: auto lets the model decide, required forces it to call a tool, and none turns tools off for that call, which on an assistant that depends on one is a turn where it invents an answer instead of looking it up. Send none only deliberately, and required too: measured on 2026-09-03 it forced a tool call on a question the tool had nothing to do with, inventing the argument to satisfy it. All three strings work as written. A fourth value is not checked and behaves as auto. Send the plain string and nothing else: the object form that names a function, which LiveKit publishes as an accepted shape, is refused outright by xAI on this route.

Sampling controls, one proven and one not#

temperature reaches this model, which is worth stating because it is not the norm on this platform: the Gemini models accept it and give no sign of reading it.

At 0.2 a 302 character reply came back as 245 characters and its token spend fell from 392 to 174, and at 0 it returned the same answer three times out of three. A model that answers identically at 0 is a model that reads the key, which is exactly the signal the Gemini models do not give: the same test there returns three different answers.

The top of the published range does not work, so OnCore caps this one at 1.5. LiveKit publishes 0 to 2. At 2 the request returned no content at all in three samples out of three, and the caller hears dead air until it times out rather than a short reply or an error. A value above 1.5 is lowered to 1.5 on the way out rather than forwarded, so the highest temperature you can actually get on this model is 1.5, and asking for more is not an error. That applies at any height, so 5 is lowered rather than refused from here, though sent straight to xAI it comes back refused with the message that temperature must be less than 2. Below 0 nothing intervenes: -1 is forwarded and xAI refuses it for not being positive.

top_p is the mirror image: the range is enforced and the effect is not. 5 and -1 are both refused outright, with xAI naming the bound each time, which is a model reading the number. And yet 0.01, which should collapse the model onto its likeliest token, left the spread of answers exactly where the baseline had it across six samples. Keep it in range because the range bites, and do not count on it doing anything.

Thinking budget#

Measured on one ordinary two-sentence request:

Leaving the key out is the most expensive option here rather than the cheapest, so low buys back both tokens and the pause the caller waits through.

That clean ordering belongs to an ordinary turn. On a genuinely hard question the three levels stop separating: the spend runs into the thousands of tokens, medium and high overlap sample to sample, and one high sample spent more than 8,000 tokens thinking. So treat the table as the shape of an ordinary call rather than a budget you can hold the model to.

A tight token limit truncates the reply on this model rather than removing it. Asked for the same two sentences with max_completion_tokens set to 30, it returned 150 characters cut mid-sentence, against 302 characters with no limit, so the caller hears a sentence that stops rather than a silent turn. The failure where the thinking consumes the whole budget and nothing is spoken at all was measured on gemini-3.7-flash, not here.

xAI's own parameter table does not list reasoning_effort for this model. The gateway forwards it and the model acts on it, so the levels above are measured behaviour rather than a published contract. Re-test on a call after changing one.

Two different failures, and neither one ends the call#

The two are easy to confuse, because both are described as a rejection.

A name that is not a chat-completions parameter at all never reaches xAI, and the guard is not OnCore's. There is no list of permitted language-model settings on this route: OnCore forwards what you send to LiveKit, LiveKit passes it into the chat-completions client it calls xAI with, and a name that client has no parameter for fails there, before any request goes out. Automatic failover answers that turn instead, so the caller gets a reply from a different model than the one you chose, which is worse than an error because nothing about the call looks wrong. That much is measured, here and on the Gemini models alike: an invented key cost the turn every time.

A value the model refuses is a plain failure from xAI, and that is what the If invalid column describes. top_p: 5 is the measured case, refused with xAI naming the bound.

Neither one reaches the caller as an error, and that is the part worth planning around. Every language model on this platform runs behind automatic failover, so a refused name and a refused value both end the same way: a different model answers that turn, and the reply comes back looking perfectly normal. Measured on 2026-09-03, an in-range frequency_penalty on a Gemini model, which that model refuses outright, returned an ordinary answer written by the failover model instead. Nothing in the response says so. So a setting you got wrong does not announce itself: it quietly swaps the model your assistant is running on, along with its pricing and its behaviour. Check a new setting on a test call and read the reply rather than assuming silence means success.

The same failover fires on a slow turn, and this model is slow often enough to notice. The platform gives each model five seconds to start answering before the failover model takes the turn. Measured on live calls on 2026-09-04, grok-4.6 missed that window on 4 of 15 attempted turns, each logged only as a timed-out request, and the turns that did get through started answering after a median of just over four seconds, with none faster than three. gemma-4-31b-it missed it 0 times across 53 turns in the same session and started answering after a median of one and a half. Every one of those turns was answered by the failover model, sounded normal, and was billed and behaved as a different model. If your assistant is on this model, expect a share of turns to be served by the failover, and keep prompts and tool results short so the first token arrives sooner.

Settings this page does not cover#

Each of these is published for this model and carried to the gateway on this route, so sending one is not the rejected-key case above and none of them costs you the turn. All six were measured on 2026-09-03, and not one of them did anything. The middle column is LiveKit's published contract and the right-hand column is what a call showed.

That whole column is what the published silent-ignore contract looks like from the outside. LiveKit's inference parameter reference says a parameter a model does not support is stripped from the request rather than refused, and on this model, for these six keys, that is exactly what happens: no error, no effect, nothing to tell you. Two things are worth taking from it. The first is that temperature and top_p are not in that column, because both are refused when they go out of range, so this model is reading some keys and not others rather than ignoring the lot. The second is that the same contract does not hold on the Gemini models, where the two penalties are refused outright instead of being ignored. The published note is a poor guide either way; the measurement is the guide.

Next steps#

• OpenAI: language from OpenAI.
• Providers introduction: per-call overrides, and how a wrong value behaves across providers.