Default Parameter Values by Provider

TL;DR: If you never touch a sampling field, OpenAI defaults temperature to 1 and top_p to 1, Anthropic defaults temperature to 1.0 but requires max_tokens outright, with no default to fall back to, and Google leaves most defaults to whichever model you called. Checked against each vendor's own API reference on September 3, 2026.

What actually happens when you leave a parameter alone?

Three different things, depending on the vendor, and the difference matters more than any single number does.

Sometimes 'default' means a documented constant: OpenAI's temperature field ships with default: 1 written directly into its published OpenAPI schema, so a request that omits it behaves exactly as if you had sent 1. Sometimes it means 'ask the model': Google's reference for the same field states plainly that the default varies by model and has to be read off the model object itself, not off the parameter. And sometimes there is no default at all, because the field is required. Anthropic's max_tokens falls into this bucket, so omitting it isn't a fallback to some sensible number; it fails validation instead.

A fourth case shows up once you leave the classic generationConfig shape entirely: a field can be missing from the schema altogether, meaning the concept of a default doesn't apply because there is nothing to default. That is where Google's newer Interactions API lands for every sampling parameter, and it is the least-documented case of the four.

This page walks through temperature, top-p and top-k, the four different token-cap field names spread across three vendors, stop sequences, and the frequency and presence penalties, one parameter family at a time, default first. For the full range on every parameter rather than just its default, post 114's cheat sheet is the wider reference.

What is the default temperature on each provider, and does it actually apply to you?

OpenAI's field description reads: "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." The schema attaches a literal default: 1 to that field, and the same default applies on both Chat Completions and the Responses API, since both inherit the same property definition. The field description adds a habit worth keeping: "We generally recommend altering this or top_p but not both."

Anthropic publishes a default too: "Defaults to 1.0. Ranges from 0.0 to 1.0." That description sits directly underneath a deprecation notice that changes what the field means in practice: "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 own typo, not a transcription error here.) So on any model released after that boundary, the documented default is the only legal value: you can send 1.0 or omit the field, and both do the same thing, while anything else returns a 400.

Google's generateContent reference is the most honest about not having one number: "Optional. Controls the randomness of the output." It follows this immediately with "Note: The default value varies by model, see the Model.temperature attribute of the Model returned from the getModel function." The published range is "[0.0, 2.0]." There is one place Google does commit to a specific figure, and it's easy to miss because it lives in a migration guide rather than the parameter reference: developers moving off Gemini 2.5 are told, "If your existing code explicitly sets temperature (especially to low values for deterministic outputs), we recommend removing this parameter and using the Gemini 3 default of 1.0 to avoid potential looping issues or performance degradation on complex tasks." That is Google's own vendor-stated default for its current flagship, even though the general reference page won't commit to it.

If you need per-task guidance rather than the raw default (what to actually set temperature to for code versus copywriting versus classification), that's post 212's job, not this page's.

What about top_p and top_k defaults?

OpenAI's top_p carries the same shape as temperature: "An alternative to sampling with temperature, called nucleus sampling, where the model considers the results of the tokens with top_p probability mass. So 0.1 means only the tokens comprising the top 10% probability mass are considered." It ships with a schema default of 1 on a 0 to 1 range, and the reciprocal recommendation: "We generally recommend altering this or temperature but not both." top_p has no equivalent on the deprecation front: it stays live on every current OpenAI model.

top_k doesn't have a default on OpenAI, because it doesn't have a field. A direct search of the complete published OpenAI OpenAPI specification (87,410 lines, checked September 3, 2026) returns zero occurrences of the string top_k anywhere in the document. It has never been part of either OpenAI API.

Anthropic exposes top_k but its default is academic on current models: "Deprecated. Models released after Claude Opus 4.6 do not accept top_k; any value will be rejected with a 400 error." Unlike temperature and top_p, no backwards-compatible value works here: any value, default or not, returns a 400.

Google's topK reference states that its default varies by model, which is consistent with the rest of the page. One detail looks like a copy-paste error inside Google's own documentation, though: the field description for topK itself says its default value is specified by the Model.top_p attribute, not Model.top_k. It's the same sentence structure used on the neighboring topP field, and it reads as though it was copied across without swapping the attribute name.

What is the default token cap, and why does the field name change four times?

This is the one place where the word provider isn't even the right unit: one vendor uses three different field names for the same idea, across three separate endpoints.

• OpenAI Chat Completions: the current field is max_completion_tokens; the older max_tokens is marked deprecated. Neither carries a numeric default in the schema. Leave it out, and the model can generate until it hits its own context limit.
• OpenAI Responses API: max_output_tokens, with a schema minimum of 16 and, like Chat Completions, no stated default.
• OpenAI's legacy Completions endpoint: a third, separate max_tokens field, and this is the one exception with an actual number baked in: default: 16, minimum: 0.
• Anthropic: max_tokens, and Anthropic's own description is unambiguous: "The maximum number of tokens to generate before stopping." There is no default listed anywhere in the field's documentation, and unlike every field above, it isn't optional. Anthropic's reference marks it a plain required number, not an "optional number" like every other sampling field on the same page.
• Google: maxOutputTokens, described the same way as temperature: "Optional. The maximum number of tokens to include in a response candidate." The same field description adds: "Note: The default value varies by model, see the Model.output_token_limit attribute of the Model returned from the getModel function."

Every one of these caps output only, never the prompt. On OpenAI and Anthropic the cap counts reasoning tokens against the same ceiling as visible text. Set it too low on a reasoning-capable model and you can burn the entire budget on thinking with nothing left to show for it. Google tracks thinking tokens under a separate counter and does not state as plainly whether maxOutputTokens can be exhausted the same way; treat that specific interaction as unconfirmed rather than assume it behaves like OpenAI's.

{
  "model": "claude-opus-5",
  "max_tokens": 1024,
  "messages": [{ "role": "user", "content": "Explain the difference between max_tokens and max_completion_tokens." }]
}

That request has no default to omit max_tokens toward. Leave it out and Anthropic's API rejects the call before it ever reaches the model.

What is the default stop-sequence behavior?

None set, on every provider. But the ceiling once you do set one differs, and one vendor documents an exception that the others don't.

OpenAI's spec is direct about both facts in one field description: "Not supported with latest reasoning models o3 and o4-mini. Up to 4 sequences where the API will stop generating further tokens. The returned text will not contain the stop sequence." That reasoning-model carve-out is worth knowing where it actually lives: it appears only in OpenAI's OpenAPI spec, not in the prose reasoning guide, so a search that only checks the guide will come back empty.

Google's stopSequences field is described as "Optional. The set of character sequences (up to 5) that will stop output generation." That's one more than OpenAI allows, and Google states no reasoning-model exception anywhere on the page.

Anthropic's stop_sequences field reads: "Custom text sequences that will cause the model to stop generating." No count limit appears anywhere in that description or elsewhere in the Messages API reference. The closest thing to a cap is the array type itself, which permits any number of entries.

Whether the OpenAI-lineage penalties (below) or stop behavior change on reasoning models specifically is, in OpenAI's own case, only half-documented: the spec states the stop carve-out explicitly, but the reasoning guide has zero mentions of the word penalty, so whether frequency and presence penalties do anything on o3 or o4-mini is genuinely undocumented rather than confirmed either way.

Do frequency and presence penalties default to zero everywhere?

Only on the one endpoint that has them in the first place. OpenAI's Chat Completions defines both with matching schemas and a default of 0 each. frequency_penalty: "Number between -2.0 and 2.0. Positive values penalize new tokens based on their existing frequency in the text so far, decreasing the model's likelihood to repeat the same line verbatim." presence_penalty: "Number between -2.0 and 2.0. Positive values penalize new tokens based on whether they appear in the text so far, increasing the model's likelihood to talk about new topics." Neither field exists on the Responses API at all; there's no default to speak of there because the parameter doesn't exist.

Google exposes both frequencyPenalty and presencePenalty inside generationConfig, but publishes no numeric range and no default for either; don't invent one. Google's presencePenalty description does add a behavioral detail the OpenAI equivalent doesn't state as plainly: "Presence penalty applied to the next token's logprobs if the token has already been seen in the response." and "This penalty is binary on/off and not dependant on the number of times the token is used (after the first)." That's a genuinely different mechanic from frequency penalty, which scales with repeat count.

Anthropic's Messages API reference has zero occurrences of either field, confirmed by a direct search. There is nothing to default, because Anthropic exposes no penalty parameter at all.

Sampling parameters named similarly across ecosystems aren't always the same thing. Hugging Face's own transformers documentation describes a different, multiplicative parameter used by many open-weight model servers: "The parameter for repetition penalty. 1.0 means no penalty." That is the opposite convention from OpenAI's additive, 0-default penalties, where 0 is neutral and 1.0 is a strong effect.

Is reasoning switched on by default too?

Briefly, since post 510 owns the full breakdown of reasoning-effort defaults per vendor; one fact each is worth having here because it directly affects what an unconfigured request actually produces.

Google's thinking_level has four documented values: minimal, low, medium, high. Google states the fallback directly: "If thinking_level is not specified, Gemini 3 will default to high." One current model breaks that pattern: Gemini 3.1 Flash-Lite defaults to minimal instead, and Google adds a caveat that matters if you're relying on it to suppress reasoning entirely: "Note, minimal does not guarantee that thinking is off."

Google's own migration advice ties this back to prompting habits directly: 'If you were previously using complex prompt engineering (like chain of thought) to force Gemini 2.5 to reason, try Gemini 3 with thinking_level: "high" and simplified prompts.' Written-out step-by-step instructions are being replaced by a parameter default, not by a longer prompt.

That gap matters: parameter-tuning advice written against the classic generationConfig shape on generateContent does not carry over to the Interactions API, because the sampling controls it relies on aren't there.

What should you actually change from default?

Usually nothing, until you have a specific reason. Every default here exists because a vendor picked it as a reasonable general-purpose setting, and two of the three vendors now actively discourage overriding it: Anthropic rejects non-default values outright on its newest models, and Google recommends against changing temperature on Gemini 3.x even where the field still works.

The cases worth deviating from default:

• You need a hard stop on runaway output. Set an explicit token cap rather than relying on context-limit fallback, especially on a reasoning model, where an unset cap plus an unusually long thinking pass can consume far more than you expected before you see a token of visible output.
• You need deterministic-looking behavior for evaluation or testing. Lowering temperature toward 0 still narrows the distribution on OpenAI and (pre-deprecation) Anthropic models, but neither vendor calls this fully deterministic. Anthropic states plainly that even temperature of 0.0 does not guarantee identical outputs.
• You're building against Anthropic's newest models and inherited old code. Delete the temperature, top_p and top_k arguments rather than trying to tune them; they are rejected, not merely deprecated in effect.
• You want a system-prompt equivalent. That's a different field shape per vendor entirely, and post 506 compares the three rather than this page.

If a term above is unfamiliar rather than just a number you needed, the plain-English definitions live in the prompt engineering glossary; this page assumes you know roughly what temperature and a stop sequence are and just needed the current numbers.