What temperature does to an AI's answer

You asked for a birthday message, decided the first one was almost right, and pressed for another. What comes back is recognisably the same idea with different wording: a clause has moved, one adjective is warmer, a joke has been swapped for a different joke. Nothing went wrong the first time. Nothing was fixed the second time. A machine that assembles sentences one word at a time was asked to do the same job twice, and it made different choices on the way through.

The setting that governs how freely those choices are made is called temperature. OpenAI, Google and Anthropic all document it in their developer references, which is the audience for it: people building on the models. We do not hand it to you, and this article is partly about why that is a defensible position.

It is worth understanding anyway. Once you know what moves between two runs of the same question, ordinary variation stops reading as a malfunction, and you start noticing the distinction that matters: whether the wording moved, or whether the substance did.

One word at a time

The fragments it picks from are smaller than words. At each step the model produces a spread of probabilities over what could come next, and something has to pick one of them. That choosing step is called sampling, and temperature is the number that reshapes the probabilities before the choice is made. Turn it down and the distribution sharpens, so the likeliest continuation wins almost every time. Turn it up and the distribution flattens, so continuations the model rated as merely plausible get a real chance of being picked.

The vendors describe it in near-identical terms. OpenAI's API reference, read on 2 October 2026, defines the parameter this way: "What sampling temperature to use, between 0 and 2. Higher values like 0.8 will make the output more random, while lower values like 0.2 will make it more focused and deterministic. We generally recommend altering this or top_p but not both" (OpenAI API reference, read 2 October 2026). Google's reference for the same parameter is terser, calling it a control on "the randomness of the output" with values that "can range from [0.0, 2.0]" (Gemini API reference, read 2 October 2026).

Two things in that language repay attention. The first is that it is comparative throughout: the documentation promises more randomness or more focus, never an identical answer twice. A low setting narrows the spread of possible answers without abolishing it. The second is what happens when nobody sets the parameter at all. Google's reference notes only that the default varies by model, so a request carrying no temperature hands that decision to the model's maker and asks for nothing in particular.

Low, middle and high, described

Because the parameter is standardised across providers, its effects can be described in general terms. The table below is about what the setting does in the API where it is exposed, not about anything you will find in our interface.

The row that misleads people is the last one. What rises with the number is the willingness to pick an unlikely word, and near the top of the range that willingness costs coherence, which is why nobody sensible runs a factual question at 1.8. Moving the dial up buys no extra cleverness, and moving it down buys no extra accuracy. A model that is confidently wrong at 1.0 will be confidently wrong at the bottom of the scale, in tidier prose, and the tidiness can read as authority it has not earned. That failure has its own mechanics, covered in our piece on why models invent facts.

Three runs of the same question

Take a question with both a factual spine and a lot of room in the phrasing: how to get red wine out of a wool jumper. Ask it, read the answer, then ask the identical question twice more in fresh chats.

Across three runs, most of the substance will hold. Every answer will tell you to act quickly, to blot rather than rub, to work from the outside of the stain inward, and to use cool water rather than hot. Those are the points the model rates as overwhelmingly likely, and no realistic sampling setting is going to route around them. What moves is everything else. One run may arrive as six numbered steps and another as three short paragraphs. One mentions salt, one mentions bicarbonate of soda, one skips both and goes straight to a proprietary stain remover. One closes by warning that wool felts if it is agitated in warm water, and the other two never raise it. Line the three up and the honest summary is that you received one answer, dressed three ways, with a different optional extra attached each time.

Now look for the case that is worth acting on. Suppose the second run says cool water and the third says warm. That one carries information. It means the model's own probabilities were close to evenly split at that point, and the sampler broke the tie differently, which is a signal that the model is not confident about a detail it stated confidently in both runs. Asking twice is therefore a cheap and rather good confidence test, on the one condition that you read the difference correctly: moved wording is noise, and a moved fact is a flag to go and check a real source.

One caveat on running that experiment here: on the models that accept the parameter, MultiChats holds the three answers closer together than a developer API left at its default would, and on the rest it does not. The next section says why.

What we set, and what you can see

Temperature is decided in one place in our system: on the server, in the code that builds the request to the provider. A model can declare whether it accepts the parameter, and saying nothing there counts as yes; a second flag records whether it is a reasoning model. If either answer is no, we send no temperature at all. Of the 59 active models across 17 providers, 41 reason, and one further entry refuses the parameter on its own account, which brings the count to 42 that never receive a temperature from us. The other 19 all get the same fixed value on every request our apps make: the most predictable setting the parameter offers, the same for your account as for anybody else's.

There is no slider, no dropdown and no advanced panel, on the website or in the iOS and Android apps. We are also not going to print the number we use, for the straightforward reason that you cannot see it anywhere in the product, and a figure you cannot check in the app is trivia rather than information. What you can rely on is the behaviour it produces, which is that repeated runs of one question on one model stay close to each other.

The reasoning models are the interesting exception, and the reason sits with the providers. Anthropic's documentation on thinking, read on 2 October 2026, states that on its current thinking models non-default temperature, top_p or top_k values return a 400 error on every request, regardless of whether thinking is used, and that on the older generation temperature is incompatible with thinking while thinking is switched on (Anthropic thinking documentation, read 2 October 2026). Of the three references read for this article, only Anthropic's documents that restriction, so for the other reasoning models the honest version is our own rule: our code treats the reasoning flag as meaning no temperature. On the models Anthropic lists, a value sent anyway would fail the request instead of steadying the prose.

So for those 42 models the provider's own default applies, and as Google's reference says, that default varies by model. Those defaults sit above the value we ask for on the models that accept the parameter, and OpenAI's reference shows 1.0 in its own example responses. The practical consequence is small but real, and knowing it saves you from a wrong conclusion: a reasoning model in the picker may show slightly more run to run movement in its prose than a non-reasoning model sitting next to it, and that difference reflects which parameters the provider accepts rather than anything about either model's quality.

Effort is a different knob

The control you can actually move is reasoning effort, and it does something else entirely. It sets how much private working out the model does before it starts writing the answer you see. The 41 models that reason are the ones that offer it. The menu offers Default, Auto, Low, Medium and High, with an added Off on models that can turn reasoning off altogether. Auto leaves the depth to the model for that message, and nothing in the menu changes which model answers. It is a subscriber control: where the button appears, a free account gets it dimmed, and pressing it offers an upgrade instead of a level.

Where the button lives depends on which app you are in, and on the website the answer surprises people. The effort button is drawn only when Intent Detection is switched off, and Intent Detection is on by default for every account. With it on, the app reads each message and decides for itself how much effort the question deserves, along with whether to search the web or generate an image. To get the button back, open Settings, then the Tool Preferences tab, and turn Intent Detection off. The phone apps have no such toggle and show the effort button on every model that reasons.

Hold the two dials next to each other and they are clearly doing different work. Temperature acts at the moment each word is chosen, on the models that accept it, and changes how a conclusion gets expressed. Effort acts before any of the answer exists, on the models that reason, and changes how much thinking goes into what the conclusion is. Raise effort on a hard question and the answer can genuinely arrive somewhere else, because more work went into it. Raise temperature on the same question and you get the same destination by a more scenic route, until the route gets scenic enough to lose the destination. People reach for one and mean the other, then conclude the setting did nothing.

Getting a second answer on purpose

If you want to compare two runs, it helps to know which button preserves the first one, because the labels do not match across our own apps. On the website, "Try Again" under an answer copies the conversation up to that point into a new thread and runs it there, so the original answer survives in the original thread. "Re-generate" replaces the answer where it stands. On the phone the two words sit the other way round: "Try again" replaces the answer in place, and "Branch here" is the route that keeps the original. There is no side by side view anywhere in the product, so comparing means moving between two threads rather than reading two columns.

The other thing that changes between an early run and a late one is the conversation itself. Ask the same question twenty messages into a thread and it is no longer the same request, because everything above it is part of what the model reads. That is a bigger lever on the answer than any sampling parameter, and it is worth understanding on its own terms if you work in long threads, which is the subject of our piece on what a context window is.

All of this makes variation readable rather than alarming. A second answer whose wording has drifted has told you nothing and cost you a few seconds. A second answer whose facts have drifted has told you something valuable, which is that the model was less sure than it sounded, and that the claim is now yours to verify. Two models disagreeing with each other is a separate question with separate causes, and it deserves its own treatment. One model disagreeing with itself is mostly just a machine picking words, and the skill is knowing when it is doing more than that.