Provider Settings Compared (OpenAI vs Anthropic vs Google)

TL;DR: This is an api settings comparison of the sampling and generation controls (temperature, top_p/top_k, penalties, seed, max-token caps, stop sequences) across OpenAI, Anthropic and Google, checked against each vendor's own reference on September 3, 2026. The short version: Anthropic has deprecated most of these on its newest models, OpenAI split them unevenly across three separate APIs, and Google now runs two APIs that disagree with each other about which of them still exist.

What's actually in scope here?

Three vendors, one job: turning a probability distribution over the next token into an actual choice, over and over, until the response stops. Six parameter families do that job: temperature, top_p and top_k, frequency and presence penalties, seed, the max-token output cap, and stop sequences. That's the whole scope of this page.

Two adjacent, easily confused topics are deliberately out of scope. Where a provider puts its persistent instructions is a different question, answered in full at post 506, System Prompts in the API (still in draft as of this writing, so that link will resolve once it ships). How each provider prices and expires a cached prompt prefix is answered at post 620, Prompt Caching Parameters Across Providers. Neither caching nor system-prompt placement changes a single token's probability, so neither belongs on this page.

For the raw reference table (every parameter, every range, every default, in one sitting) go to post 114, the LLM parameter cheat sheet. This page assumes you've either read that or don't need it yet, and instead asks a narrower question: given that these six families now behave differently by vendor, what actually changes about your output, and what should you touch versus leave alone? If you want the conceptual explainer of what temperature, top_p and top_k actually are first, that's post 48; if you specifically want how top_p and top_k interact with each other, that's post 93.

Why did the three vendors stop agreeing on this?

Each vendor got here by a different route, and the route matters more than any single number.

OpenAI runs three separate chat-shaped surfaces with three separate parameter sets: the legacy Completions endpoint (where most of this vocabulary was born), Chat Completions (the current mainstream surface), and the newer Responses API. The Responses API is not a superset of the other two. It quietly drops stop, seed, and both penalties entirely, keeping only temperature, top_p, and max_output_tokens.

Anthropic made the opposite move: instead of splitting parameters across APIs, it deprecated most of them on newer models within one API. Its Messages API reference states that models released after Claude Opus 4.6 reject non-default temperature, top_p, and top_k outright, with a 400 error.

Google now runs two live APIs that don't expose the same knobs. The classic generateContent endpoint still has the full 2023-era set: temperature, top_p, top_k, both penalties, and seed. The newer Interactions API drops temperature, top_p, top_k, and both penalties completely, but keeps max_output_tokens, seed, and stop_sequences under a generation_config object, renamed to snake_case.

Temperature: same word, three different postures

OpenAI documents temperature identically across Completions, Chat Completions, and the Responses API: "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." Default is 1. The same field description adds a direct recommendation: "We generally recommend altering this or top_p but not both."

Anthropic ranges its (deprecated, on newer models) temperature from 0.0 to 1.0, not 0 to 2, with a default of 1.0. On models released after Claude Opus 4.6, only a value of exactly 1.0 is accepted; anything else returns a 400. On the models that still take it, Anthropic's own guidance is unusually blunt about temperature 0 not helping as much as people assume: "even with temperature of 0.0, the results will not be fully deterministic."

Google documents temperature identically to OpenAI's 0–2 range on generateContent, but its Gemini 3 developer guide goes further than either competitor and tells you to stop touching it. Fetched directly on September 3, 2026: "For all Gemini 3 models, we strongly recommend keeping the temperature parameter at its default value of 1.0." The same page: "Changing the temperature (setting it below 1.0) may lead to unexpected behavior, such as looping or degraded performance, particularly in complex mathematical or reasoning tasks." If you're migrating old code, Google's own migration note says to just remove the parameter rather than tune it down.

Whether temperature 0 is actually deterministic depends on which Google page you read. Google Cloud's Gemini Enterprise Agent Platform parameter guide (the current name for what used to be branded as Vertex AI's generative-AI docs) hedges rather than promises: "A temperature of 0 means that the highest probability tokens are always selected. In this case, responses for a given prompt are mostly deterministic, but a small amount of variation is still possible." That's closer to Anthropic's position than to a flat claim that temperature 0 is deterministic, and it's worth knowing which Google surface you're citing before you repeat either version.

What happened to top_p and top_k?

OpenAI still ships top_p everywhere temperature exists, at the same 0–1 range, default 1, with the same recommendation not to change both at once. It has never shipped top_k on any surface, at any point in the OpenAPI spec's history that's checkable today.

Anthropic deprecated both on its newest models. top_k's field description states plainly that models released after Claude Opus 4.6 "do not accept top_k; any value will be rejected with a 400 error." top_p gets a slightly softer landing: a value of 0.99 or higher is still accepted for backwards compatibility, everything else 400s.

Google is the only vendor that still ships a fully documented top_k on its classic API, but with a wrinkle worth knowing before you rely on it: "An empty topK attribute indicates that the model doesn't apply top-k sampling and doesn't allow setting topK on requests." In plain terms, some Gemini models have no top_k dial at all, and the API won't complain if you try to set one; it just won't do anything. On the Interactions API, top_k is gone entirely for sampling purposes (the only top_k field left in that spec belongs to a document-retrieval tool, not decoding).

Do frequency and presence penalties survive on every provider?

OpenAI documents both on a matching -2.0 to 2.0 range, default 0, on Chat Completions and the legacy Completions endpoint. Neither field exists on the Responses API. Whether either penalty does anything at all on the o3/o4-mini reasoning models is, per OpenAI's own reasoning guide, simply undocumented either way: fetched directly, that guide contains zero occurrences of the word penalty.

Anthropic doesn't have this concept at all. Its Messages API reference contains zero occurrences of frequency_penalty or presence_penalty, under any name.

Google exposes both, presencePenalty and frequencyPenalty, inside generationConfig, with an asymmetry OpenAI doesn't document: presence penalty is binary, described as applying "if the token has already been seen in the response" regardless of how many times, while frequency penalty scales with repeat count and, at large negative values, can push the model into looping on one token until it hits the output cap. Neither publishes a numeric range or default, and neither survives onto the Interactions API.

Seed: who actually offers reproducibility, and how much

OpenAI only exposes seed on Chat Completions, and the field's own description hedges hard, in three separate moves: "This feature is in Beta." It adds that "our system will make a best effort to sample deterministically," and later states plainly that "Determinism is not guaranteed". It's also marked deprecated: true in the current spec, meaning it's simultaneously beta and on its way out. It isn't present on the Responses API, and its cousin field on the legacy Completions endpoint carries none of that hedging, so the same parameter name means different things depending which OpenAI endpoint you call.

Google is the only vendor with seed on both of its live APIs. The classic API's description is a plain sentence: "Seed used in decoding. If not set, the request uses a randomly generated seed." The Interactions API's generation_config.seed reads almost the same: "Seed used in decoding for reproducibility." Google Cloud's separate Gemini Enterprise Agent Platform docs add the same caveat everyone else gives: "Deterministic output isn't guaranteed." That surface additionally flags the whole feature as "This is a preview feature."

Anthropic doesn't have it. Zero occurrences of seed anywhere in the current Messages API reference.

The mechanism behind all this hedging is worth knowing if you're troubleshooting inconsistent output. Thinking Machines' engineering blog (Horace He, September 2025) argues the popular explanation, that concurrent GPU kernels race nondeterministically, is mostly wrong; individual forward passes are typically deterministic on their own. The real driver is batch-invariance: your output can shift depending on which other requests happen to be batched alongside yours on the server at that moment. A fixed seed can't fix that on any provider, because seed controls sampling, not server-side batching.

Capping output: four names across three vendors

Every vendor caps output length, and no two use exactly the same field name.

• OpenAI Chat Completions: max_completion_tokens is current; max_tokens still exists but is deprecated in favor of it and explicitly incompatible with the o-series reasoning models.
• OpenAI Responses API: max_output_tokens, with a documented minimum of 16.
• OpenAI legacy Completions: max_tokens again, a third meaning under the same string, defaulting to 16.
• Anthropic: max_tokens, and unlike every other field on this page, it's required, not optional, on every Messages API request. One genuinely useful quirk buried in the same field description: setting it to 0 lets you pre-warm a prompt cache without generating any response at all.
• Google: maxOutputTokens on the classic API, max_output_tokens on the Interactions API, camelCase versus snake_case for the same idea on two APIs from the same company.

Every one of these caps output only, never the prompt, and on OpenAI and Anthropic it explicitly includes reasoning tokens, not just the visible reply. A tight cap on a reasoning-heavy request can consume the entire budget on thinking and return nothing visible at all. Google is the outlier: it tracks a separate thoughtsTokenCount, but its reference doesn't state whether thinking tokens can exhaust maxOutputTokens before any visible text appears. Treat that as genuinely unknown, not as working like the other two.

Stop sequences: 4, 5, or however many you want

OpenAI's StopConfiguration schema opens with an exclusion, then the mechanism: "Not supported with latest reasoning models o3 and o4-mini." Where it is supported: "Up to 4 sequences where the API will stop generating further tokens. The returned text will not contain the stop sequence." So the field exists, but not on every model.

Google's classic API allows one more: "The set of character sequences (up to 5) that will stop output generation." The Interactions API keeps a version of the same field, but under different wording: "A list of character sequences that will stop output interaction." That's the one place Google's newer API's wording diverges from its older one in a way that reads like a genuine rewrite rather than a rename.

Anthropic doesn't publish a documented count cap at all for stop_sequences, in either direction. If the model hits one, the response's stop_reason comes back as "stop_sequence" and the matched string is returned separately so you know which one fired.

Worth noting given the pattern in the rest of this page: stop sequences are one of the few fields that survived Google's move to the Interactions API even though temperature, top_p, top_k, and both penalties did not. Whatever Google is optimizing that newer surface for, sampling controls were the first casualty; hard stops were not.

At a glance: the classic REST surface for each vendor

So which of these should you actually touch?

Start from the vendor's own default and change one field at a time, in this order of how much it usually matters:

1. Set the output cap on every request, on every provider. It's cheap to get wrong, either truncated answers or wasted spend, and free to get right.
2. Use stop sequences for boundaries you control, like a closing delimiter you asked the model to emit, not for content you're hoping it won't say.
3. Leave temperature at its default unless you have a concrete reason to move it. On Gemini 3 or a post-Opus-4.6 Claude model, that's not optional; the vendor either warns against it or blocks it outright.
4. Change temperature or top_p, never both, where both still exist. That's OpenAI's own recommendation, and nobody publishes a case for combining them.
5. Treat seed as a nice-to-try, never a guarantee. Every vendor that documents it also documents that it isn't guaranteed, so don't build a reproducibility requirement on it alone.
6. Skip the penalties unless you have a specific repetition problem, and tune them per-provider since the ranges genuinely don't match.

A short comparison, showing only the fields that actually still exist on each vendor's current mainstream chat surface:

// OpenAI — Chat Completions
{ "temperature": 0.7, "top_p": 1, "max_completion_tokens": 800, "stop": ["\n\n"] }

// Anthropic — Messages (post-Opus-4.6 models: temperature/top_p/top_k all rejected unless default)
{ "max_tokens": 800, "stop_sequences": ["\n\n"] }

// Google — generateContent, everything inside generationConfig, camelCase
{ "generationConfig": { "temperature": 0.7, "topP": 1, "maxOutputTokens": 800, "stopSequences": ["\n\n"] } }

For the complete request bodies, every field, on every API discussed here, post 114 is the full reference; this was deliberately the short version.

Sources and access dates

Every claim above was checked directly, not from a search summary, on September 3, 2026:

• OpenAI: the published OpenAPI specification, openapi.yaml, fetched directly from raw.githubusercontent.com, and the reasoning models guide (zero occurrences of temperature, top_p, penalty, stop, or sampling, confirmed by direct fetch).
• Anthropic: the Messages API reference.
• Google: the Gemini API generate-content reference, the Interactions API reference, the Gemini 3 developer guide (which itself now carries a deprecation notice pointing to a newer Flash guide), and Google Cloud's Gemini Enterprise Agent Platform parameter-tuning guide, the current home for what used to be branded as Vertex AI's generative-AI parameter docs.
• Thinking Machines' engineering blog on nondeterminism (Horace He, September 2025), for the batch-invariance explanation, cited in paraphrase rather than quotation.

Every one of these pages can move again within weeks; three of the four vendor products discussed here changed shape since the last time anyone checked this exact set of fields. Verify against the live spec before you ship, including this one.