AI Temperature Settings by Task (2026 Reference Table)

TL;DR: The universal temperature table is dead. AI temperature settings now differ by vendor in kind, not just in number: Anthropic's current models reject the parameter with a 400, DeepSeek accepts it and ignores it, Google tells you to leave it alone, and only Alibaba and DeepSeek still publish per-task values, which disagree with each other by a factor of four.

Search for AI temperature settings and you will find the same table on twenty sites. Zero-point-two for code, zero-point-seven for chat, one-point-two for creative. It is confidently written, it is usually undated, and on four major vendors it now describes behaviour that no longer exists.

This page gives you the reference table you came for, scoped honestly per model, with not applicable, not published and deprecated as first-class cells. Every one of them was read at the vendor's own documentation on 27 August 2026, with the URL. Where a vendor publishes no recommendation, the cell says so. That is a statement about their docs, not a guess about their model.

What does temperature actually do?

It is a sampling control, not a creativity control. At each step the model produces a probability distribution over its whole vocabulary. Temperature reshapes that distribution before a token is drawn from it.

Alibaba's documentation puts the mechanism plainly: "A higher temperature flattens the token probability distribution, making less likely tokens more probable and increasing output randomness. A lower temperature sharpens the distribution, making high-probability tokens even more likely and reducing output randomness." That is the entire effect. Nothing in it knows what a poem is.

This matters because the popular framing sets a false expectation. Raising temperature does not make a model more imaginative, it makes it more willing to pick its second-best guess. Sometimes that reads as inventive. Sometimes it reads as an error, or as a hallucination. Cohere's own page describes both failure directions: "If the model starts repeating itself this is a sign that the temperature may be too low," and if it "starts going off topic, giving nonsensical outputs, or failing to ground properly, this is a sign that the temperature is too high."

One consequence almost nobody publishes, and Cohere does: the right value depends on prompt length. "As sequences get longer, the model naturally becomes more confident in its predictions, so you can raise the temperature much higher for long prompts without going off topic. In contrast, using high temperatures on short prompts can lead to outputs being very unstable." A single number per task cannot encode that.

The temperature settings reference table, per model

Every row verified at the vendor's own documentation on 27 August 2026.

Which vendors still publish a per-task temperature table?

Two, and they contradict each other. Here is every published per-task recommendation, side by side, quoted from vendor pages and dated.

Look at the translation row. DeepSeek publishes 1.3. Alibaba publishes 0.3. Those are not two opinions about the same setting, they are two settings that happen to share a name. Creative writing splits the same way: 1.5 against 0.9, with Mistral's own schema capping the entire parameter at 1.5 and recommending you stay at or below 0.7.

Both vendor tables are real and current in the sense that both are live on vendor domains today. Only one of them is current in the sense that matters.

DeepSeek's table is an orphan. The page at api-docs.deepseek.com/quick_start/parameter_settings returns HTTP 200 and reads, verbatim: "The default value of temperature is 1.0. We recommend users to set the temperature according to their use case listed in below." Its last-modified header is Friday, 17 April 2026, seven days before DeepSeek's V4 preview. It does not appear in api-docs.deepseek.com/sitemap.xml, and it is not linked from the Quick Start navigation. It also contradicts the two pages DeepSeek did update: the API reference, modified 26 August 2026, which documents a plain 0-to-2 range with no per-task guidance, and the thinking-mode guide, modified the same day, which says the parameter does nothing.

Alibaba's table is current. The Model Studio text generation overview, last updated 14 July 2026, ships this block as a runnable code sample:

# Recommended parameter settings for common scenarios
SCENARIO_CONFIGS = {
    # Creative writing
    "creative_writing": {"temperature": 0.9, "top_p": 0.95},
    # Code generation
    "code_generation":  {"temperature": 0.2, "top_p": 0.8},
    # Factual Q&A
    "factual_qa":       {"temperature": 0.1, "top_p": 0.7},
    # Translation
    "translation":      {"temperature": 0.3, "top_p": 0.8},
}

One caveat that page does not resolve: Alibaba's separate deep-thinking documentation contains no occurrence of the word temperature as of 27 August 2026. Whether these scenario values survive enable_thinking: true on a Qwen 3.7 model is not published, and I am not going to infer it.

Why did Anthropic remove temperature entirely?

Anthropic has not published a rationale, so what follows is what it published, not why.

The Messages API reference marks temperature Deprecated with this text: "Models released after Claude Opus 4.6 do not support setting temperature. A value of 1.0 of will be accepted for backwards compatibility, all other values will be rejected with a 400 error." The typo is Anthropic's. The same page marks top_p deprecated with a mirror rule, accepting any value at or above 0.99, and marks top_k deprecated with a stricter one: "any value will be rejected with a 400 error." Note the asymmetry. Two of the three have a tolerated legacy value. top_k has none.

The Opus 5 migration guide widens it to a family rule: "Setting temperature, top_p, or top_k to any non-default value on Claude Opus 4.7 or later models, including Claude Opus 5, returns a 400 error." It adds that "the Python SDK (v1.0 and later) does not define them, and passing them raises a TypeError," and that the safest path is to remove the parameters from your payloads.

The two pages word the boundary differently. The API reference says "after Claude Opus 4.6"; the migration guide says "Opus 4.7 or later." Those describe the same line, and I have used the API reference's wording throughout because it is the reference.

One current Anthropic model still takes the parameter: Claude Haiku 4.5, released 15 October 2025, which predates the cutoff. Its migration guide adds a constraint worth knowing, because it makes the temperature and top-p interaction an actual error rather than a piece of folklore: "Use only temperature OR top_p, not both. Setting both returns a 400 error on Claude Haiku 4.5."

What is OpenAI's position on temperature for reasoning models?

Less settled than you would expect, and the gap is documented rather than inferred.

OpenAI's public API specification defines temperature on the shared ModelResponseProperties schema used by both Chat Completions and Responses, as a number from 0 to 2 with a default of 1, described exactly as it has been for years. There is no reasoning-model exclusion on the field.

The exclusion lives one level up, in the Chat Completions endpoint description: "Parameter support can differ depending on the model used to generate the response, particularly for newer reasoning models. Parameters that are only supported for reasoning models are noted below. For the current state of unsupported parameters in reasoning models, refer to the reasoning guide."

That referral is where it breaks down. OpenAI's reasoning guide, fetched at developers.openai.com/api/docs/guides/reasoning.md on 27 August 2026, contains zero occurrences of "temperature", "top_p" or "sampling". So does the models index. So does the GPT-5.6 model page, which lists endpoints, features and tools but no parameters. So does the prompt-engineering guide. The spec tells you to consult a page for the current state of unsupported sampling parameters, and that page does not discuss them.

What OpenAI does document heavily is reasoning.effort, with values none, low, medium, high, xhigh and max, and per-model defaults rather than a universal one. That is the dial it wants you to turn. It is not a randomness control, and treating it as a temperature substitute is a category error.

Why does the same temperature give different outputs on different models?

Four reasons, and only the last one is about model weights.

The scales are not the same. OpenAI, xAI and DeepSeek document 0 to 2. Alibaba documents [0, 2), excluding the endpoint. Mistral's chat schema caps at 1.5. Anthropic's caps at 1.0. DeepSeek's own recommendation of 1.3 for translation is mid-range on its API and simply invalid on Anthropic's, where it would have been rejected as out of range even before the deprecation.

The defaults are not the same, and two vendors decline to publish one. Mistral's spec says "The default value varies depending on the model you are targeting. Call the /models endpoint to retrieve the appropriate value." Google's API reference says the same in different words, pointing you at the Model.temperature attribute returned by getModel. If you copy a number from a blog without knowing the default it is displacing, you do not know which direction you moved.

The same vendor can disagree with itself. Mistral's own OpenAPI file caps temperature at 1.5 in ChatCompletionRequest and at 1.0 in CompletionArgs, the schema its Agents surface uses. One file, one vendor, two ceilings.

And the distribution being reshaped is different. Temperature is a transform applied to whatever probabilities the model produced. Two models given the same prompt do not produce the same distribution, so the same transform lands somewhere else. This is the part no table can fix.

Why does temperature interact with top-p?

Because they are two filters on one draw, applied in sequence, and Google is unusually explicit about the order: "Tokens are then further filtered based on topP with the final token selected using temperature sampling." Google also states the default topP value is 0.95.

That ordering explains why stacking them produces surprises. A tight top-p can leave so few candidates that raising temperature has almost nothing to redistribute across. A loose top-p with high temperature opens the long tail wide. Every vendor that documents both says the same thing in the same words: "We generally recommend altering this or top_p but not both." Anthropic went further on Haiku 4.5 and made setting both a 400. Alibaba words it as a method rather than a rule: "To isolate the effect of each parameter, adjust only one at a time."

If you want the mechanics rather than the settings, we broke both down in Temperature, Top-P, Top-K explained and in Top-p vs Top-k.

What do you use instead where the parameter is gone?

Two things, in this order: the vendor's reasoning-effort dial for how hard the model works, and explicit prompt-level instructions for everything the temperature table was actually trying to buy you.

Be precise about what effort is. Anthropic's effort documentation states: "Effort controls thinking volume, not visible response length: on Claude Opus 5, changing effort does not reliably shorten responses, so prompt for length instead." Anthropic's Opus 5 migration guide is blunter about the replacement for sampling: "Prompting is the recommended way to guide model behavior on Claude Opus 5."

So the instructions below are not a workaround. On four of the surfaces in the table above, they are the documented interface. Paste them into a system prompt or the top of a user message.

1. Deterministic-feeling factual answers (replaces temperature 0.0–0.1)

Answer only from the material provided. If the answer is not in the material,
reply exactly: "Not stated in the source." Do not infer, estimate, or fill gaps
from general knowledge. Quote the specific line you relied on for each claim.

2. Code generation without invention (replaces temperature 0.2)

Use only APIs, functions, and fields that appear in the code or docs I pasted.
If you need something that is not there, stop and list what is missing instead
of inventing a plausible name. Do not modify code outside the function I named.

3. Translation with a fixed register (replaces temperature 0.3 or 1.3, depending whose table you read)

Translate into <language>. Preserve register, sentence count, and paragraph
breaks. Do not localise names, units, or currency. Where a term has no direct
equivalent, keep the source term and add a one-line translator's note beneath
the paragraph. Return only the translation and the notes.

4. Extractive summarisation (replaces "low temperature for summaries")

Summarise using only sentences and figures that appear in the source. Every
number must be traceable to a line in the input. Do not introduce comparisons,
conclusions, or adjectives that are not in the text. Maximum 150 words.

5. Controlled divergence (replaces temperature 1.2+ for creative work)

Give me 6 options that differ from each other structurally, not just in wording.
No two may share an opening move, a metaphor family, or a sentence rhythm.
After the list, name in one line what makes options 1, 3, and 5 different in
kind. Do not rank them.

6. Deliberate variety across runs (replaces "raise temperature for fresh output")

Before answering, list 3 framings you could take. Pick the one you consider
least obvious, say why in one sentence, then answer using only that framing.

7. Conciseness (Anthropic's own published wording)

Keep responses focused, brief, and concise. Keep disclaimers and caveats short,
and spend most of the response on the main answer. When asked to explain
something, give a high-level summary unless an in-depth explanation is
specifically requested.

8. The end-of-prompt reminder that pairs with it (also Anthropic's)

<tone_preference>
Keep outputs reasonably concise.
</tone_preference>

9. Longer, deeper output (replaces nothing — effort will not do this)

Target 900–1,100 words. Spend at least half of it on the second and third
sections. Do not summarise at the end. If you find yourself writing a
transition sentence, replace it with a concrete example instead.

10. Suppressing repetition where frequency_penalty is unavailable

Do not reuse any noun phrase of three or more words more than once. Do not
begin two consecutive paragraphs with the same part of speech. Before you
return the answer, scan it once for repeated phrasing and rewrite the repeats.

11. Closed-set classification (replaces temperature 0 for classifiers)

Classify into exactly one of: [A, B, C, D]. Return only the label. If the input
matches none of them, return "UNCLASSIFIED". Never create a new label, never
return two, never explain.

12. Strict structured extraction (replaces low temperature plus JSON mode)

Return a JSON object with exactly these keys: <list>. Use null for any value
not present in the source. Do not add keys. Do not reformat values. Do not
return prose before or after the object.

13. Grounded generation that will not drift (replaces "lower temperature for RAG")

Every sentence must be supported by the retrieved passages. Mark each sentence
with the passage id you used, like [p3]. If a sentence cannot be marked, delete
it rather than softening it.

14. Recovering from a refusal or a canned non-answer

That response did not address the question. Restate the question in your own
words, name the specific constraint that blocked you, and then answer the part
that is not blocked. Do not repeat the disclaimer.

Google's prompting page suggests a parameter for this last case: "If the model responds with a fallback response, try increasing the temperature." On a model where you cannot, the instruction above is what is left.

How do you check your own model in two minutes?

Do not trust this page in six months. Do this instead.

1. Open the vendor's API reference and search the page for temperature. Read the field description, not a summary of it. If it carries a Deprecated badge or a 400 warning, you are done.
2. Search the same docs for a thinking or reasoning guide and check whether that mode has its own parameter rules. This is where DeepSeek's answer lives, and it is not on the parameter page.
3. Check whether that mode is on by default. DeepSeek's is, at high effort. Anthropic's is, on Opus 5. A parameter that only applies with thinking disabled is a parameter that does not apply to most of your traffic.
4. Note the range and the default. If the docs say the default varies by model, query the models endpoint before you assume you know which way you moved the dial.
5. Send one request with a deliberately out-of-range value. A 400 tells you the parameter is enforced. A 200 with unchanged output tells you something more useful and much harder to notice.

Step five is the one people skip, and it is the only one that catches the silent case.

What this means for how you keep prompts

The premise behind every task table is that a prompt is text plus a settings row, and that the settings row travels. For a large share of current models it no longer does, and the failure is quiet rather than loud.

A prompt stored as "summarise this contract" plus temperature: 0.2 is portable in the first half and worthless in the second. Move it to Opus 5 and the second half is a 400. Move it to DeepSeek and the second half does nothing at all while your evaluation reports a clean run. Move it to Gemini 3.x and you have done precisely what Google's own prompting guide advises against.

The durable version of that prompt is one where the constraint is written down in words. "Use only sentences from the source, do not add conclusions, cap at 150 words" survives every one of those moves, because it is instruction rather than configuration. That is also why the copy-paste blocks above are longer than a number: they encode what the number was standing in for.

If you are rebuilding a library on that basis, our 200 ready-to-copy ChatGPT templates and the 100+ prompt template collection are written that way already, and the LLM parameter cheat sheet covers the rest of the request body.

None of this makes temperature useless. On Alibaba's models, on Mistral, on Cohere, on DeepSeek with thinking off, it is a real dial with published guidance behind it. It just is not a universal one any more, and the tables that pretend otherwise were last correct some time in 2024.