Gemini

Google’s thinking models, and the most used language models on the platform.

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. Gemini and Gemma honour different settings, so they are documented separately. 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. Every language model on this platform runs behind automatic failover, so 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. Measured on 2026-09-03, an in-range frequency_penalty that Gemini refuses outright came back as an ordinary answer written by the failover model, with nothing in it to say so. 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": {
          "maxTokens": 250,
          "max_completion_tokens": 2000,
          "stop": [
            "\n\n"
          ],
          "reasoning_effort": "low"
        }
      }
    }
  }
}

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.

max_completion_tokens: The raw form of maxTokens, for overriding the limit on a single call. max_tokens is accepted as a synonym and measured identical. Measured on gemini-3.6-flash and gemini-3.7-flash, a limit of 0 is read as no limit rather than refused, and 1 returns an empty turn, so a limit smaller than the thinking costs you the reply rather than shortening it.

stop: Generation halts the moment a sequence appears, and the sequence itself is not spoken. Verified live: asking the model to count to six with stop set to four returned one two three. Choose something a caller could never make the assistant say, or it will cut a reply mid-sentence. LiveKit publishes no limit on how many sequences these models take, and the four-sequence cap it does publish belongs to the xAI table, so do not carry that figure across. The real cap is five, and Google names it in the refusal: measured on gemini-3.6-flash and gemini-3.7-flash on 2026-09-03, six sequences were refused outright and the message named five as the maximum. Five itself was never sent, so five is the number Google states rather than a count a call has passed. Matching is exact, too: four stopped the count where Four did not.

reasoning_effort: Genuinely changes how much these models think, and how many tokens a turn costs. LiveKit publishes the three levels as thinking budgets of 1024, 8192 and 24576 tokens. Treat those as labels rather than as ceilings, because measured spends do not respect them: low cost 1,651 tokens on gemini-3.5-flash against a published 1024. What does hold is the shape, so size the token limit from the measurements below rather than from the published figures, and remember the budget has to cover the thinking before there is anything left over for the reply. The value itself is not checked, so a misspelling is accepted and quietly leaves the model on its own default.

Models this page covers#

gemini-3-flash, gemini-3.5-flash, gemini-3.6-flash, gemini-3.7-flash, gemini-3.1-flash-lite and gemini-3.1-flash-lite-preview. All six take the same settings on the same route, which is why one page covers them.

Two of those names deserve a word of warning. LiveKit publishes gemini-3.1-flash-lite and publishes no -preview form of it at all, so prefer gemini-3.1-flash-lite and treat gemini-3.1-flash-lite-preview as a name this platform still accepts rather than one the gateway is known to serve. LiveKit likewise publishes gemini-3-flash-preview rather than gemini-3-flash. If a model in this family stops answering and failover starts covering for it, check the id against the current published list before anything else.

The If invalid column holds for all six. gemini-3.6-flash and gemini-3.7-flash were swept on 2026-09-03 with out-of-range values on every key in the table except maxTokens, and both behaved as the four older models do. Nothing has ever sent one of these models a maxTokens it could not use, so that row is the one to treat as advice.

The two settings to leave alone#

frequency_penalty and presence_penalty are published for these models with a default of 0 and a range of -2.0 to 2.0, and they are refused at every value, which is why neither is in the table above. Measured on gemini-3.6-flash and gemini-3.7-flash on 2026-09-03, 2.0 on either key was refused with Google explaining that its supported range stops just short of 2 rather than at it, 5 and -5 were refused for being outside it, and frequency_penalty: -2.0 was refused with Penalty is not enabled for this model. There is no value that works.

Two things make this worth reading twice. LiveKit's own inference reference points the other way, marking a parameter a reasoning model does not support as stripped from the request rather than refused, so the published contract would have you expect a setting that quietly does nothing. And the refusal does not surface: failover answers that turn from another model, so the reply arrives looking ordinary. An assistant carrying one of these two from an OpenAI model, where they are accepted, runs every turn on a model nobody chose.

What the six do not share is how much thinking each does, and on a phone call that is the difference that decides the token budget, so the thinking budget below is per model.

gemini-3.6-flash and gemini-3.7-flash are the newest of the six. The difference that matters on a call is when each one thinks. gemini-3.7-flash thinks on every turn, and gemini-3.6-flash does not think at all until you ask it to. Read the thinking budget below before picking between them, because that difference decides how much token headroom each one needs.

What these models ignore#

temperature and top_p are each published with a default of 1, and each is accepted on all six and range checked on none of them, so a value outside the published range is taken without complaint.

There is a published explanation for the absence of an effect, and it is worth knowing because it is not specific to Gemini. LiveKit's inference parameter reference marks temperature and top_p as unsupported by reasoning models, and states that an unsupported parameter is stripped from the request rather than refused. These are reasoning models, and a stripped parameter is exactly what "accepted, no error, no effect" looks like from the outside. It does not hold everywhere, though: grok-4.6 reasons too, and temperature reaches xAI there and is refused when out of range.

On gemini-3-flash and gemini-3.5-flash they were also shown to have no effect. Asking each model for the same invented name six times gave the same spread of answers at temperature: 0 as at temperature: 2: 5 of 6 distinct either way on gemini-3-flash, 6 of 6 either way on gemini-3.5-flash. For comparison, gemma-4-31b-it went from 1 of 6 to 6 of 6 across the same test, which is what a setting that works looks like.

That six-sample test was never run on gemini-3.6-flash or gemini-3.7-flash. A three-sample version was: at temperature: 0 both returned three different answers, where grok-4.6 on the same test returned three byte-identical ones, and top_p: 0.01 left the spread of answers where the baseline had it. That is short of the six-sample result on the older two, so call the effect on these two unproven and pointing at none. What was also measured there is the absence of enforcement. temperature: 5, far outside the documented range, was taken without an error on both, and the reply came back as coherent as it was at 0.2. A model that reads temperature refuses that value instead, which is what grok-4.6 does: sent straight to xAI, 5 comes back refused with the answer that temperature must be less than 2, and -1 that it must be positive.

Two keys that work, and are not checked#

seed and tool_choice are both carried on this route, both do something, and neither has its value checked.

seed: 42 narrowed the spread of answers rather than fixing it: six samples came back with four of them byte-identical, against six distinct answers with no seed at all. That is the best effort Google publishes rather than the guarantee the word suggests. tool_choice behaves as published, with none producing no tool call across two samples and required forcing one even on a question the tool had nothing to do with, which is worth knowing before you set it. Neither value is validated: a nonsense seed is taken silently, and a nonsense tool_choice is taken silently and behaves as auto.

The thinking key this route does not take#

Google's own control for thinking on the Gemini 3 models is thinkingLevel, and it has four levels: minimal, low, medium and high. That is the name and the range LiveKit publishes for reaching Gemini through its own plugin, and it is not what this route takes. Here the key is reasoning_effort and there are three levels: low, medium and high.

Nothing stops you sending the wrong one, and the two mistakes fail differently. thinkingLevel is not a chat-completions parameter at all, so it costs you the turn exactly the way any invented key does. reasoning_effort: "minimal" is the quiet version of the same mistake: the key is real, the level is not, and an unrecognised level is accepted and leaves the model on its own default with nothing to say so. If you have read Google's thinking documentation and come here to apply it, translate the level rather than the key name.

Thinking budget#

These are thinking models, and reasoning_effort moves the spend. LiveKit publishes the three levels as thinking budgets of 1024, 8192 and 24576 tokens, and no row below lands on one of them: gemini-3.5-flash overshoots the 1024 published for low. Read the published figures as labels for the three levels rather than as limits, and size a budget from the measurements. Measured on one hard question:

Thinking is paid for out of the same budget as the reply and spent first, so allow at least 2000 tokens whenever reasoning_effort is set. That floor comes from the three models in the table above. Note that setting reasoning_effort at all roughly doubles the spend against leaving it unset.

The two newest models

gemini-3.6-flash and gemini-3.7-flash were measured on an ordinary two-sentence request rather than the hard question above, so compare these rows with each other rather than with the table above. Each low figure was measured twice:

On gemini-3.6-flash, sending reasoning_effort at all turns thinking on. An ordinary turn costs 62 tokens with the key absent and eight to nine times that with low set, so on that model the cheapest setting is no setting, and adding one is a deliberate trade of latency for reasoning rather than a dial you can nudge.

gemini-3.7-flash is the mirror image: it spends 573 tokens on the same turn with nothing set, and low brings that down, to 432 and 505 on the two samples. The key changes how much it thinks rather than whether it thinks, so there is no configuration on that model that gets you a turn without a thinking phase.

That has a sharp edge on a live call. Asked for the same two sentences with max_completion_tokens set to 30, gemini-3.6-flash returned a truncated but audible 131 character sentence, while gemini-3.7-flash spent the whole budget thinking and returned no visible output at all. A budget too small for the thinking does not shorten the reply on that model but removes it, so the caller hears silence rather than a short answer.

Next steps#

• Gemma 4 31B: the next Google model.
• Providers introduction: per-call overrides, and how a wrong value behaves across providers.