The LLM Parameter Cheat Sheet (Every Provider, One Page)

TL;DR: Every generation parameter across OpenAI, Anthropic and Google, checked against each vendor's own API reference on August 26, 2026. The headline: Anthropic has deprecated temperature, top_p and top_k, and non-default values return a 400 on Claude Opus 4.7 and later. OpenAI never exposed top_k at all. Only Google still ships the full classic set.

What is an LLM parameter cheat sheet?

An LLM parameter cheat sheet is a single-page reference listing every generation parameter each provider exposes, with its range, its default, and the specific API it belongs to. It exists because the three major vendors have diverged far enough that a cheat sheet written for one of them is actively wrong about the other two.

Most writing on this topic assumes one API shape: temperature, top_p, top_k, frequency_penalty, max_tokens. That era is over. Anthropic has deprecated the sampling parameters. OpenAI runs two APIs whose parameter sets do not match each other. Google renamed everything into camelCase inside a generationConfig object and added controls the other two lack.

Every cell below was checked against the vendor's own published reference on August 26, 2026.

Print that, then read the sections below for the parts that will bite you.

Which sampling parameters can you still set on Claude?

Effectively none of them. This is the single most out-of-date fact in circulation, so it goes first.

Anthropic's Messages API reference still lists temperature, top_p and top_k as request fields, and all three now carry a deprecation notice. The wording is parameter-specific, so read it exactly rather than paraphrased:

• temperature — "Deprecated. 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 doubled "of" is Anthropic's typo, not mine.)
• top_p — "Deprecated. Models released after Claude Opus 4.6 do not support setting top_p. A value >= 0.99 will be accepted for backwards compatibility, all other values will be rejected with a 400 error."
• top_k — "Deprecated. Models released after Claude Opus 4.6 do not accept top_k; any value will be rejected with a 400 error."

The Claude Opus 5 migration guide states the same thing at the model level, and adds the detail that catches people out in code review: "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. The Python SDK (v1.0 and later) does not define them, and passing them raises a TypeError."

Note that the failure mode differs by SDK. Anthropic says "most SDKs still define these fields for compatibility with earlier models, so code that sets them type-checks even though the API rejects the request," so you get a runtime 400. In Python you do not get that far, because you hit a TypeError at the call site. And temperature=0 is gone as a determinism trick, which Anthropic notes was never one: "If you were using temperature = 0 for determinism, note that it never guaranteed identical outputs on prior models."

What are the actual ranges and defaults for temperature, top_p and top_k?

Only OpenAI publishes hard numeric bounds for all of them. Google publishes a range for temperature and defers the rest to the model. Anthropic's are now academic.

Three things in that table deserve a sentence each.

OpenAI's temperature ceiling is 2, not 1. The spec reads: "What sampling temperature to use, between 0 and 2 ... We generally recommend altering this or top_p but not both."

OpenAI has no top-k. The published OpenAI OpenAPI specification, version 2.3.0, contains zero occurrences of the string top_k in the entire 2.97 MB document. This is not a documentation gap; the parameter does not exist on either API.

Google's defaults are per-model, not global. The v1beta discovery document (revision 20260823) says the default "varies by model, see the Model.temperature attribute." Google also warns, in its prompt design strategies guide: "Although you can modify these parameters, we strongly recommend keeping them at their default values for Gemini 3.x models."

If you want the mechanics of what happens when top-p and top-k are both active, that is a separate question with a non-obvious answer, and post 93 works through it with the arithmetic. If you want the beginner-level explainer of what these three do at all, post 48 covers that — though note it predates the Anthropic deprecation, so treat its Claude advice as historical.

How do you cap output length on each provider?

Four field names for one idea, and two of them belong to the same vendor.

• OpenAI Responses API: max_output_tokens, minimum 16, "including visible output tokens and reasoning tokens."
• OpenAI Chat Completions: max_completion_tokens. The older max_tokens is flagged deprecated: "now deprecated in favor of max_completion_tokens, and is not compatible with o-series models."
• Anthropic: max_tokens, required on every request. One useful edge: "Set to 0 to populate the prompt cache without generating a response."
• Google: maxOutputTokens inside generationConfig, defaulting to the model's output_token_limit.

The trap: on OpenAI and Anthropic the cap includes reasoning tokens. Set it too low on a reasoning model and the model can spend the entire budget thinking and return nothing usable. Anthropic recommends "starting at 64k tokens and tuning from there" when running Opus 5 at xhigh or max effort.

Stop sequences, seed, and the penalties: who still has them?

This is where the two OpenAI APIs stop agreeing with each other, and it is the most common source of confusion in the whole reference.

Every "Absent" cell is a real absence in the CreateResponse schema, not an oversight in my reading. Port code from Chat Completions to Responses and six parameters have nowhere to go.

Stop sequences. OpenAI caps them at 4 and adds "Not supported with latest reasoning models o3 and o4-mini." Google caps them at 5: "the API will stop at the first appearance of a stop_sequence. The stop sequence will not be included as part of the response." Anthropic publishes no count cap, and documents that a triggered stop sets stop_reason to "stop_sequence" and echoes the matched string back.

Seed. Google's is cleanest: "Seed used in decoding. If not set, the request uses a randomly generated seed." OpenAI's carries two warning labels at once, marked deprecated and Beta, with the note that "Determinism is not guaranteed." Anthropic does not expose one.

The penalties. OpenAI's are symmetrical: both run −2.0 to 2.0, default 0, frequency scaling with repetition count and presence triggering on first appearance. Google's presencePenalty is "binary on/off and not dependant on the number of times the token is used," with frequencyPenalty as the proportional one. Google publishes no numeric range for either, and warns that large negative frequency penalties "will cause the model to start repeating a common token until it hits the max_output_tokens limit."

How does structured output differ across the three?

All three now enforce a JSON schema for structured output. All three call the field something different, and all three moved it within the last year.

• OpenAI, Chat Completions: response_format, set to { "type": "json_schema", "json_schema": {...} }. The older { "type": "json_object" } mode still works but the spec labels it "Not recommended for gpt-4o and newer models."
• OpenAI, Responses API: the same configuration moved under text.format. There is no response_format field on CreateResponse at all.
• Anthropic: output_config.format, shaped {"type": "json_schema", "schema": {...}}. The docs note that "the output_format parameter has moved to output_config.format, and beta headers are no longer required," and that the Python SDK v1.0 and later "does not accept output_format={...} ... and raises a TypeError."
• Google: responseMimeType: "application/json" plus either responseSchema (an OpenAPI 3.0 schema subset) or responseJsonSchema (real JSON Schema). With the latter, "response_schema must be omitted, but response_mime_type is required."

Anthropic's schema support has documented gaps worth knowing before you design around it: no recursive schemas, no external $ref, no numerical constraints such as minimum or maximum, no string length constraints, and array minItems supporting only 0 and 1.

Deciding whether to enforce a schema at the API level or just ask for JSON in the prompt? Post 42 covers the prompt-side version.

What are the tool_choice values on each provider?

Same four tool use intents, three vocabularies, and Google has a fifth mode nobody else has.

Google's VALIDATED mode is the interesting one: the model still chooses between a function call and a natural-language reply, but "will validate function calls with constrained decoding." Anthropic reaches the same guarantee from another direction, with strict: true on the tool definition to "guarantee schema validation on tool names and inputs."

Reasoning effort versus thinking budget: what is the difference?

Effort is an enum. A budget is a token count. Every provider now has at least one of them, and the two are not interchangeable.

Anthropic is explicit that effort is not a budget: "Effort is a behavioral signal, not a strict token budget." It also reaches further than thinking. The docs say effort "affects all tokens in the response," including tool calls, so lower effort means fewer tool calls, not just shorter reasoning.

Three gotchas, each worth a debugging session:

Anthropic's thinking budget is gone on current models. The thinking.budget_tokens field still exists in the API reference with a minimum of 1,024, but the Opus 5 migration guide states that thinking: {type: "enabled", budget_tokens: N} "is no longer supported on Claude Opus 4.7 or later models and returns a 400 error." The replacement is adaptive thinking plus effort. On Opus 5 adaptive thinking is on by default, and thinking: {type: "adaptive"} is equivalent to omitting the field. Combining thinking: {type: "disabled"} with effort xhigh or max also returns a 400.

high means "leave it alone" on Anthropic and "turn it up" on OpenAI. Anthropic's default is high, and the docs confirm that "setting effort to "high" produces exactly the same behavior as omitting the effort parameter entirely." OpenAI's default is medium. The same string signals opposite intent depending on which API you call.

Google's thinkingLevel is Gemini 3 and later only. The discovery document: "Recommended for Gemini 3 or later models. Use with earlier models results in an error."

Streaming, logprobs, candidates and caching

The last four rows, in one pass.

Streaming. OpenAI and Anthropic both take a boolean stream field, defaulting to false on OpenAI. Google does not: streaming is a separate endpoint, :streamGenerateContent, taking the identical GenerateContentRequest body. There is no stream: true anywhere in Gemini's parameter list.

Logprobs. OpenAI's Chat Completions takes logprobs as a boolean plus top_logprobs as an integer from 0 to 20. The Responses API drops the boolean and exposes them through include: ["message.output_text.logprobs"] alongside top_logprobs. Google mirrors the pair as responseLogprobs and logprobs, also capped at 20. Anthropic does not expose logprobs at all — a hard constraint on provider choice if your eval pipeline needs token-level probabilities.

Multiple candidates. OpenAI's n runs 1 to 128 on Chat Completions and is absent from Responses; the spec advises "keep n as 1 to minimize costs." Google's candidateCount defaults to 1. Anthropic has no equivalent, so you send N requests.

Prompt caching. Here the three designs differ most.

Anthropic publishes the most detail, and the numbers matter. Minimum cacheable prefix is 512 tokens on Opus 5, Fable 5 and Mythos 5; 1,024 on Opus 4.8 and Sonnet 5; 2,048 on Opus 4.7; 4,096 on Opus 4.6, Opus 4.5 and Haiku 4.5. Below the threshold, "requests to cache fewer than this number of tokens will be processed without caching, and no error is returned" — a silent no-op. Pricing is 1.25× base input for a 5-minute cache write, 2× for a 1-hour write, 0.1× for a read.

One easy miss: Anthropic warns that changing the effort level between requests invalidates your cached prefix, "so vary effort across workloads rather than within a conversation that relies on cache hits."

Copy-paste: the same request in all three APIs

Same job, a JSON-schema-constrained response with a capped output length, written the way each provider actually wants it as of August 26, 2026.

# OpenAI — Responses API. No top_k, no stop, no seed, no penalties here.
curl https://api.openai.com/v1/responses \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.6-terra",
    "input": "Summarise this incident report.",
    "max_output_tokens": 2048,
    "temperature": 1,
    "reasoning": { "effort": "medium" },
    "text": {
      "format": {
        "type": "json_schema",
        "name": "summary",
        "schema": {
          "type": "object",
          "properties": { "headline": { "type": "string" } },
          "required": ["headline"],
          "additionalProperties": false
        }
      }
    },
    "prompt_cache_key": "incident-summariser-v1"
  }'

# Anthropic — Messages API. NO temperature, top_p or top_k. max_tokens is required.
curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-5",
    "max_tokens": 2048,
    "messages": [{ "role": "user", "content": "Summarise this incident report." }],
    "output_config": {
      "effort": "medium",
      "format": {
        "type": "json_schema",
        "schema": {
          "type": "object",
          "properties": { "headline": { "type": "string" } },
          "required": ["headline"]
        }
      }
    }
  }'

# Google — Gemini API. Everything lives inside generationConfig, in camelCase.
curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.7-flash:generateContent" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "contents": [{ "parts": [{ "text": "Summarise this incident report." }] }],
    "generationConfig": {
      "maxOutputTokens": 2048,
      "stopSequences": ["END"],
      "seed": 42,
      "responseMimeType": "application/json",
      "responseSchema": {
        "type": "OBJECT",
        "properties": { "headline": { "type": "STRING" } },
        "required": ["headline"]
      },
      "thinkingConfig": { "thinkingLevel": "MEDIUM" }
    }
  }'

Swap the model IDs for whatever is current when you read this. The parameter shapes are the durable part; model names churn every few months.

So what should you actually set?

Four rules that survive the churn.

1. On Claude, set nothing but max_tokens and output_config.effort. The sampling levers are gone, and Anthropic says plainly that prompting is the intended control surface now.
2. On OpenAI, know which API you are on before copying a parameter. Responses and Chat Completions are not interchangeable. Six parameters exist on one and not the other.
3. On Gemini, leave temperature, topP and topK alone on 3.x models. Google asks you to, warning that changes "can cause unexpected behavior, such as looping or degraded performance, particularly in complex mathematical or reasoning tasks."
4. Reach for structure before you reach for a knob. Every vendor spent the past year moving control away from decoding parameters and toward schemas, effort levels and prompting. That direction of travel is not subtle.

Sources and access dates

Every claim above traces to a primary document, all accessed August 26, 2026:

• OpenAI: the published OpenAPI specification, openapi.yaml, info.version 2.3.0 — read directly rather than through the rendered docs, because the spec is what the API validates against.
• Anthropic: the Messages API reference, the Claude Opus 5 migration guide, the effort guide, the structured outputs guide, and the prompt caching guide.
• Google: the Gemini API v1beta discovery document, revision 20260823, and the prompt design strategies guide.

Parameter surfaces change on the order of months. Two of the biggest facts here, Anthropic's sampling deprecation and OpenAI's Responses/Chat split, did not exist eighteen months ago. Check the spec before trusting any cheat sheet, including this one.

For the prompting-side companion, post 49 is the prompt engineering cheat sheet, and post 47 covers when to reach for RAG or fine-tuning instead.