LLM API Parameter Compatibility Reference - Anthropic, OpenAI, Google Gemini, and Amazon Bedrock
First Published:
Last Updated:
1. Introduction
This page is a single, cross-provider reference for the request parameters of the four LLM APIs that most multi-provider applications target: the Anthropic Messages API, the OpenAI Chat Completions and Responses APIs, the Google GeminigenerateContent API, and the Amazon Bedrock Converse API. If you build an abstraction layer, an agent framework, or a model router that has to speak to more than one provider, you keep re-checking the same facts: what range does temperature accept here, what is the field called that caps output length, how is a stop sequence specified, how do I ask for JSON. The goal here is to keep those official facts in one place and to make the same-name-different-meaning differences explicit, because that is where portable code breaks.Facts in this article were verified against the official API references as of 2026-07-24. Because each provider's API changes quickly - new parameters appear, old ones are deprecated, and accepted ranges shift between model generations - the official reference linked in each section is always authoritative. Treat this page as a map, not a substitute for that reference, and check the current documentation before you rely on a specific value.
Scope of this edition. This page covers request-side parameters grouped by area: request shape, sampling, length and stop controls, system prompts and conversation structure, streaming, structured output, tool use, reasoning controls, log probabilities, prompt and context caching, and the compatibility pitfalls that follow from all of the above. It does not cover pricing, rate limits, or benchmark scores; per-model exhaustive default tables; SDK-language-specific syntax; or a comparison of proxy or gateway products. Where a provider exposes two API surfaces - OpenAI's Chat Completions and Responses APIs - both are shown in the OpenAI column, labelled CC (Chat Completions) and R (Responses) where they differ.
A note on the Gemini column. Google now offers two surfaces as well, and they are at different stages. The comparison tables document
generateContent, which is what nearly every existing Gemini integration calls and which Google states remains fully supported. Google has, however, designated generateContent legacy and recommends its newer Interactions API - generally available since June 2026 - for all new projects, and says future models and capabilities will launch there first. Rather than blur the two into one column, section 12 maps the Interactions API against generateContent field by field, so you can see exactly what a migration changes.The First Published and Last Updated dates above indicate the currency of this page. Companion references on hidekazu-konishi.com:
- Amazon Bedrock Converse API Deep Dive - the Bedrock side of this page, in depth.
- Anthropic Claude API Errors Reference - what happens when a parameter is out of range or unsupported.
- Anthropic Tool Use Schema Builder and Validator - build and validate tool input schemas.
- LLM Token Counter and Context Budget Planner - size prompts against context and output budgets.
- AI Model Deprecation and Lifecycle Calendar - the sister living reference, for model lifecycle dates.
2. Request Shape Overview
Before comparing individual parameters, it helps to see how differently the four requests are shaped. The most consequential structural difference is where the system prompt lives (a top-level field in three of the four, a message role in OpenAI) and how provider-specific parameters are passed. Amazon Bedrock is a special case: its Converse API defines a unified set of inference parameters that work across every model it hosts, and routes anything model-specific through a separate field.| Parameter / aspect | Anthropic (Messages API) | OpenAI (Chat Completions / Responses) | Google Gemini (generateContent) | Amazon Bedrock (Converse API) |
|---|---|---|---|---|
| Primary text endpoint | POST /v1/messages | POST /v1/chat/completions (CC); POST /v1/responses (R) | POST /v1beta/models/{model}:generateContent (legacy per Google; successor POST /v1beta/interactions - see section 12) | Converse (and ConverseStream) |
| System prompt placement | Top-level system field | system / developer message in messages (CC); instructions field (R) | Top-level systemInstruction field | Top-level system field |
| Conversation container | messages[] | messages[] (CC); input + optional previous_response_id (R) | contents[] | messages[] |
| Turn roles | user, assistant | system/developer, user, assistant, tool | user, model | user, assistant |
| Server-side state | Stateless (resend history) | Stateless (CC); optional via previous_response_id + store (R) | Stateless (optional context caching via cachedContent) | Stateless |
| Base inference params | Top-level request fields | Top-level request fields | generationConfig object | inferenceConfig object |
| Model-specific params | Top-level request fields | Top-level request fields | generationConfig fields | additionalModelRequestFields (JSON passed to the model) |
Official sources: Messages - Anthropic API, Create chat completion - OpenAI / Create response - OpenAI, Generating content - Gemini API, Converse - Amazon Bedrock API Reference.
3. Sampling Parameters
Sampling controls how the next token is chosen. The most important compatibility fact is thattemperature does not share a range across providers: Anthropic accepts 0.0-1.0, while OpenAI and Gemini accept 0.0-2.0. A value of 1.5 is valid on OpenAI and Gemini and out of range on Anthropic. All three of Anthropic, OpenAI, and Gemini recommend adjusting either temperature or the nucleus (top_p) parameter, not both. Note also that top_k is not universal, and that Amazon Bedrock's Converse API keeps only temperature, topP, maxTokens, and stopSequences in its base inferenceConfig - anything else, including top_k and penalties, must go through additionalModelRequestFields. The larger caveat is that the sampling parameters are being retired outright at the frontier: on Claude Opus 4.7 and later (including Opus 4.8 and Opus 5), Claude Sonnet 5, and Claude Fable 5, a non-default temperature, top_p, or top_k returns a 400 and Anthropic's guidance is to omit them (they remain available on Claude Opus 4.6, Sonnet 4.6, and earlier). In addition, as of July 2026 Google has deprecated temperature, top_p, and top_k on the Gemini API starting with Gemini 3.6 Flash and Gemini 3.5 Flash-Lite - the API ignores these parameters on those models, and future model generations are expected to reject them (see the Gemini API changelog and section 12).* You can sort the table by clicking on the column name.
| Parameter / aspect | Anthropic (Messages API) | OpenAI (Chat Completions / Responses) | Google Gemini (generateContent) | Amazon Bedrock (Converse API) |
|---|---|---|---|---|
| temperature | temperature, range 0.0-1.0, default 1.0 (removed on newest models - see section 13) | temperature, range 0-2, default 1 | generationConfig.temperature, range 0.0-2.0, default varies by model (deprecated on Gemini 3.6 Flash / 3.5 Flash-Lite and later - see section 13) | inferenceConfig.temperature, range set by the underlying model |
| nucleus (top-p) | top_p (removed on newest models — see section 13) | top_p, range 0-1, default 1 | generationConfig.topP | inferenceConfig.topP |
| top-k | top_k (supported; removed on newest models — see section 13) | Not supported (no top_k) | generationConfig.topK (supported; some newer models reject it) | Via additionalModelRequestFields (not in base inferenceConfig) |
| presence penalty | Not supported | presence_penalty, -2.0 to 2.0, default 0 (CC only) | generationConfig.presencePenalty | Via additionalModelRequestFields (if the model supports it) |
| frequency penalty | Not supported | frequency_penalty, -2.0 to 2.0, default 0 (CC only) | generationConfig.frequencyPenalty | Via additionalModelRequestFields (if the model supports it) |
| seed (determinism) | Not supported | seed (CC only; marked deprecated in the current schema) | generationConfig.seed | Via additionalModelRequestFields (if the model supports it) |
| number of candidates | Not supported (one response) | n, 1-128, default 1 (CC only) | generationConfig.candidateCount, default 1 | Not supported (one response) |
Official sources: Messages - Anthropic API, Create chat completion - OpenAI, Generating content - Gemini API, Inference request parameters and response fields - Amazon Bedrock.
4. Length and Stop Controls
Two things are easy to get wrong when porting code: the name of the field that caps output length, and whether it is required. On the Anthropic Messages APImax_tokens is a required field. OpenAI has renamed its cap - max_tokens is deprecated in Chat Completions in favor of max_completion_tokens, and the Responses API uses max_output_tokens; on reasoning models these caps count hidden reasoning tokens as well as visible output, so a low value can be spent entirely on reasoning before any text is produced. Gemini and Bedrock keep the cap optional. Stop sequences also differ in field name and in how many are allowed.| Parameter / aspect | Anthropic (Messages API) | OpenAI (Chat Completions / Responses) | Google Gemini (generateContent) | Amazon Bedrock (Converse API) |
|---|---|---|---|---|
| Max output tokens - field | max_tokens | max_completion_tokens (CC; max_tokens deprecated); max_output_tokens (R, minimum 16) | generationConfig.maxOutputTokens | inferenceConfig.maxTokens |
| Required? | Required | Optional | Optional (default per model) | Optional |
| Counts reasoning tokens? | Thinking counts against max_tokens | Yes - the cap includes reasoning tokens on reasoning models | Thinking counts against maxOutputTokens | Per the underlying model |
| Stop sequences - field | stop_sequences (array) | stop (string or array, up to 4; not on the latest reasoning models) (CC) | generationConfig.stopSequences (up to 5) | inferenceConfig.stopSequences (array) |
Official sources: Messages - Anthropic API, Create chat completion - OpenAI / Create response - OpenAI, Generating content - Gemini API, Converse - Amazon Bedrock API Reference.
5. System Prompts and Conversation Structure
A system prompt is delivered as a top-level field on Anthropic, Gemini, and Bedrock, but as a message role on OpenAI - and OpenAI has, on its o1 and newer models, introduced adeveloper role that takes the place of the older system role. Multi-turn shape also differs: Anthropic, Gemini, and Bedrock are stateless (you resend the whole history), while OpenAI's Responses API can keep state server-side via previous_response_id. Gemini uses model (not assistant) for the assistant turn, and has no system role inside contents at all.| Parameter / aspect | Anthropic (Messages API) | OpenAI (Chat Completions / Responses) | Google Gemini (generateContent) | Amazon Bedrock (Converse API) |
|---|---|---|---|---|
| System prompt delivery | Top-level system (string or content blocks) | system or developer message in messages (CC); instructions string (R) | Top-level systemInstruction (a Content, text only) | Top-level system (array of blocks) |
| System as a message role? | No - it is a field (a system message can be appended mid-conversation on some newer models) | Yes - a message role; developer supersedes system on o1 and newer | No - separate field; no system role in contents | No - it is a field |
| Multi-turn container | Full messages[] resent | Full messages[] resent (CC); input + optional previous_response_id (R) | Full contents[] resent | Full messages[] resent |
| Assistant turn role name | assistant | assistant | model | assistant |
| Server-side conversation state | No (stateless) | No (CC); yes via previous_response_id + store - store defaults to true on the Responses API (R) | No (optional prompt reuse via cachedContent) | No (stateless) |
Official sources: Messages - Anthropic API, Create response - OpenAI, Generating content - Gemini API, Carry out a conversation with the Converse API operations - Amazon Bedrock.
6. Streaming
Anthropic and OpenAI stream from the same endpoint by setting a boolean flag. Gemini and Bedrock stream through a separate operation or endpoint: Gemini's:streamGenerateContent (add ?alt=sse for Server-Sent Events) and Bedrock's ConverseStream.| Parameter / aspect | Anthropic (Messages API) | OpenAI (Chat Completions / Responses) | Google Gemini (generateContent) | Amazon Bedrock (Converse API) |
|---|---|---|---|---|
| How to stream | stream: true (same endpoint) | stream: true, plus stream_options (same endpoint) | Separate endpoint :streamGenerateContent (append ?alt=sse) | Separate operation ConverseStream |
| Transport | Server-Sent Events | Server-Sent Events | Server-Sent Events (with alt=sse) | Event stream |
Official sources: Streaming Messages - Anthropic API, Create chat completion - OpenAI, Generating content - Gemini API, ConverseStream - Amazon Bedrock API Reference.
7. Structured Output
There is an important distinction inside "structured output": a JSON mode that guarantees syntactically valid JSON but enforces no schema, versus a schema-enforced mode that constrains the response to a specific JSON Schema. Every provider now offers the schema-enforced form, but the field names and nesting differ, and both Anthropic and Gemini have renamed the field recently (Anthropic'soutput_format is superseded by output_config.format; Gemini's responseSchema is superseded by responseJsonSchema).| Parameter / aspect | Anthropic (Messages API) | OpenAI (Chat Completions / Responses) | Google Gemini (generateContent) | Amazon Bedrock (Converse API) |
|---|---|---|---|---|
| JSON mode (valid JSON, no schema) | Use the schema form below | response_format: {type: "json_object"} (CC); text.format json_object (R) | generationConfig.responseMimeType: "application/json" | Use the textFormat form below |
| Schema-enforced output | output_config.format: {type: "json_schema", schema: ...} | response_format: {type: "json_schema", json_schema: {...}} (CC); text.format (R) | responseJsonSchema with responseMimeType: "application/json" (responseSchema is deprecated) | outputConfig.textFormat (with a structure) |
| Strict-adherence flag | Tool strict: true; output_config.format constrains the response | strict: true inside json_schema (default false) | Constrained decoding driven by the schema | Driven by textFormat.structure |
Official sources: Structured outputs - Anthropic API, Create chat completion - OpenAI / Create response - OpenAI, Structured output - Gemini API, Converse - Amazon Bedrock API Reference.
8. Tool Use
Tool use (also called function calling) follows the same loop everywhere - you declare tools, the model emits a structured call, your code executes it and returns the result - but the parameter names and, especially, thetool_choice vocabulary differ. "Let the model decide" is auto / AUTO everywhere; "force the model to call some tool" is any on Anthropic and Bedrock, required on OpenAI, and ANY on Gemini. Gemini also nests its tool controls under toolConfig.functionCallingConfig and adds a VALIDATED mode.| Parameter / aspect | Anthropic (Messages API) | OpenAI (Chat Completions / Responses) | Google Gemini (generateContent) | Amazon Bedrock (Converse API) |
|---|---|---|---|---|
| Tool definition container | tools: [{name, description, input_schema}] | tools: [{type: "function", function: {...}}] (functions deprecated) | tools: [{functionDeclarations: [{name, description, parameters}]}] | toolConfig.tools: [{toolSpec: {name, description, inputSchema.json}}] |
| Choose / force a tool | tool_choice: {type: "auto" | "any" | "tool" | "none"} | tool_choice: "none" | "auto" | "required" or a named tool (function_call deprecated) | functionCallingConfig.mode: "AUTO" | "ANY" | "NONE" | "VALIDATED" (+ allowedFunctionNames) | toolChoice: {auto | any | tool} |
| Parallel tool calls | On by default; opt out with disable_parallel_tool_use | parallel_tool_calls, default true | Supported (model-driven) | Supported (model-driven) |
| Argument schema format | JSON Schema (input_schema) | JSON Schema | OpenAPI-subset Schema, or parametersJsonSchema | JSON Schema (inputSchema.json) |
Official sources: Tool use with Claude - Anthropic API, Create chat completion - OpenAI, Function calling - Gemini API, Use a tool to complete a model response - Amazon Bedrock.
9. Reasoning Controls
Reasoning (or "thinking") controls are the fastest-moving area of these APIs - the exact set of effort levels, thinking budgets, and per-model support changes with almost every model release. The table below maps the mechanism each provider exposes; for current level names, budgets, and which models support them, the official reference is the only reliable source. On Amazon Bedrock, reasoning controls are not part of the baseinferenceConfig - they are passed through additionalModelRequestFields in the shape the underlying model expects.| Parameter / aspect | Anthropic (Messages API) | OpenAI (Chat Completions / Responses) | Google Gemini (generateContent) | Amazon Bedrock (Converse API) |
|---|---|---|---|---|
| Enable reasoning | thinking: {type: "adaptive"} (older models: {type: "enabled", budget_tokens: N}) | reasoning_effort (CC); reasoning object (R) | generationConfig.thinkingConfig | Via additionalModelRequestFields (provider-specific) |
| Depth control | output_config.effort (levels low through max) | reasoning_effort level; reasoning.effort (R) | thinkingConfig.thinkingBudget (token budget) or thinkingLevel (newer models) | Per the underlying model's own fields |
| Expose the reasoning | thinking.display: "summarized" | "omitted" | reasoning.summary (R) | thinkingConfig.includeThoughts | Per the underlying model |
Official sources: Extended thinking - Anthropic API, Reasoning - OpenAI, Thinking - Gemini API, Inference request parameters and response fields - Amazon Bedrock.
10. Log Probabilities
Log probabilities expose, for each generated token, how likely the model considered it (and optionally the most likely alternatives at each position) - useful for classification confidence scores, answer ranking, and debugging. This is one of the most asymmetric areas on this page: two providers offer it under different parameter names and shapes, one has no such parameter at all, and one delegates it to model-specific pass-through fields.* You can sort the table by clicking on the column name.
| Parameter / aspect | Anthropic (Messages API) | OpenAI (Chat Completions / Responses) | Google Gemini (generateContent) | Amazon Bedrock (Converse API) |
|---|---|---|---|---|
| enable log probabilities | Not supported (the Messages API has no log-probability parameter) | CC: logprobs, boolean. Responses: no boolean - add "message.output_text.logprobs" to the include array | generationConfig.responseLogprobs, boolean | Not in the base inferenceConfig; model-specific, via additionalModelRequestFields (if the model supports it) |
| top alternatives per position | Not supported | top_logprobs, integer 0-20 (on CC, logprobs must be true for it to apply) | generationConfig.logprobs, integer 0-20 (only valid if responseLogprobs is true) | Model-specific (if the model supports it) |
Two dependency chains are easy to miss: on OpenAI Chat Completions,
top_logprobs is only honored when logprobs is set to true, and on Gemini, the integer logprobs field is only valid when responseLogprobs is true - in both cases, setting the count alone silently does nothing. Note also that the two providers happen to share the same 0-20 range but attach it to differently named and differently placed fields, and that the OpenAI Responses API changes the enabling mechanism (an include entry) relative to Chat Completions within the same provider.For portable code, treat log probabilities as a non-portable, provider-gated feature: an abstraction layer should expose it as an optional capability that is absent on Anthropic and model-dependent on Bedrock, rather than assuming it exists everywhere.
Official sources: Messages - Anthropic API, Create chat completion - OpenAI, Create response - OpenAI, Generating content - Gemini API reference, Converse API operations - Amazon Bedrock.
11. Prompt and Context Caching
All four providers now offer a way to reuse a repeated prompt prefix (long system prompts, tool definitions, shared documents) across requests, but the request surfaces differ more here than in any other area of this page: three providers use in-request breakpoint markers with different names and shapes, and one uses a separate server-side resource that requests then reference.* You can sort the table by clicking on the column name.
| Parameter / aspect | Anthropic (Messages API) | OpenAI (Chat Completions / Responses) | Google Gemini (generateContent) | Amazon Bedrock (Converse API) |
|---|---|---|---|---|
| automatic / implicit caching | Opt-in only; a top-level cache_control can auto-place the marker on the last cacheable block | Automatic by default (no parameter; minimum 1,024-token prefix on older generations); newer models add explicit controls | Implicit caching enabled by default on Gemini 2.5 and newer (minimum input token count varies by model) | Opt-in only (no caching without a cachePoint block) |
| explicit breakpoint marker | cache_control: {"type": "ephemeral"} on a content block in system, messages, or tools | prompt_cache_breakpoint: {"mode": "explicit"} on a content part, with top-level prompt_cache_options (newer models) | None in the request itself - explicit caching creates a separate cachedContents resource, referenced via the top-level cachedContent field (cachedContents/{id}) | {"cachePoint": {"type": "default"}} as an element of messages[].content, system, or toolConfig.tools |
| TTL | ttl: "5m" (default) or "1h" | prompt_cache_options.ttl, default 30m (currently the only supported value); prompt_cache_retention is deprecated in its favor | ttl (Duration) or expireTime on the cachedContents resource; defaults to 1 hour | ttl: "5m" (default) or "1h"; supported TTLs vary by model |
| breakpoint limit | Up to 4 per request (the automatic top-level marker shares the same 4 slots) | Up to 4 written per request; cache matching considers up to the latest 80 breakpoints in the conversation | Not applicable (resource-based) | Up to 4 cache checkpoints per request |
| minimum cacheable size | Model-dependent minimum prefix (from 512 to 4,096 tokens depending on the model) | 1,024-token minimum prefix for automatic caching | Model-dependent minimum input token count | Model-dependent minimum tokens per checkpoint, evaluated across tools + system + messages together |
| cache identity / routing | Prefix match on the rendered request | prompt_cache_key, string (replaces the user field for cache routing) | The named cachedContents/{id} resource; cached content can only be used with the model it was created for | Prefix match; checkpoints are processed in tools → system → messages order |
Structurally, Anthropic's
cache_control, Bedrock's cachePoint, and OpenAI's prompt_cache_breakpoint are the same idea - an in-request marker that says "the reusable prefix ends here" - expressed with three different names, placements, and TTL vocabularies. Gemini is the outlier: its explicit cache is a first-class server-side resource with its own lifecycle (create, expire, delete), and the generation request merely points at it.Two behaviors are worth calling out for multi-provider code. First, invalidation is order-sensitive: Bedrock documents that checkpoints are processed in
tools → system → messages order, so changing a tool definition invalidates the cached system and message segments after it - the same render-order logic that governs Anthropic's prefix matching. Second, none of the four marker shapes are cross-compatible, and the TTL vocabularies do not line up (5m/1h versus a fixed 30m versus a free-form Duration), so a provider-abstraction layer should treat caching as a per-provider adapter concern rather than a common parameter. Caching also affects how requests are billed; per this page's scope, amounts and rates are left to the official pricing pages.Official sources: Prompt caching - Anthropic API, Prompt caching - OpenAI, Context caching - Gemini API, Caching - Gemini API reference, Prompt caching for faster model inference - Amazon Bedrock.
12. Google's Interactions API - the Successor to generateContent
Every Gemini column in the tables above describesgenerateContent, the endpoint that virtually all existing Gemini integrations use. That endpoint is no longer the one Google steers new work toward, and a cross-provider reference that ignored the change would be a map of the wrong territory.Google's own wording is unusually direct. Its documentation describes the Interactions API as generally available since June 2026 and recommended for all new projects, and applies the word "legacy" to
generateContent while confirming that it remains fully supported.[G1] Two consequences follow for anyone building an abstraction layer. generateContent is not going away and is safe to keep using - Google says so explicitly. But Google also states that new models, multimodal capabilities, tools, and agentic features will launch on the Interactions API going forward,[G1] so the two surfaces will diverge in capability over time rather than stay in step.Structurally the Interactions API is closer to OpenAI's Responses API than to
generateContent: a single stateful resource per turn, an optional server-managed history, and a typed timeline of execution steps instead of a candidates[] array. The request is posted to POST https://generativelanguage.googleapis.com/v1beta/interactions, and the reference marks the surface as Beta at the /v1beta/ path even though the API itself is generally available.[G2]| Parameter / aspect | Gemini generateContent (legacy) | Gemini Interactions API (recommended) |
|---|---|---|
| Endpoint | POST /v1beta/models/{model}:generateContent | POST /v1beta/interactions |
| Conversation container | contents[] (client-managed history) | input (required); optional server-side history via previous_interaction_id |
| System prompt | systemInstruction | system_instruction (top level) |
| Output-length cap | generationConfig.maxOutputTokens | generation_config.max_output_tokens |
| Stop sequences | generationConfig.stopSequences | generation_config.stop_sequences |
| Sampling controls | temperature, topP, topK, penalties, candidateCount (deprecated on the newest models - see section 13) | Not present in the published GenerationConfig schema; the documented fields are max_output_tokens, seed, stop_sequences, thinking_level, thinking_summaries, and tool_choice |
| Reasoning control | generationConfig.thinkingConfig | generation_config.thinking_level (minimal / low / medium / high) and thinking_summaries (auto / none) |
| Structured output | generationConfig.response_mime_type + response_schema | Top-level response_format (array); the text form carries mime_type and schema |
| Streaming | Separate endpoint :streamGenerateContent | stream: true on the same endpoint (SSE, typed step events) |
| Response shape | candidates[].content.parts[] | steps[] timeline (thought, function_call, model_output, ...) plus SDK convenience properties such as output_text |
| Statefulness | Stateless | Stores requests by default (store=true); opt out with store=false, which also disables background execution and previous_interaction_id |
| Long-running work | Not offered | background: true, with a cancel endpoint at POST /v1beta/interactions/{id}/cancel |
Three points deserve emphasis for portable code. First, the sampling gap is not a documentation oversight: the published
GenerationConfig schema for the Interactions API simply has no temperature, top_p, top_k, penalty, or candidateCount fields,[G2] which is the same direction as the July 2026 deprecation of those parameters on generateContent (section 13). An abstraction layer whose Gemini adapter always sets temperature has nowhere to put it on the newer surface. Second, previous_interaction_id carries only the conversation history: tools, system_instruction, and generation_config are interaction-scoped and must be re-sent on every turn.[G1] Third, statefulness is the default rather than an opt-in, which is a data-handling decision as much as an API one - Google documents retention of stored interactions and an explicit store=false escape hatch.[G1]For a router that must speak to Gemini today, the pragmatic reading is that
generateContent remains the correct target for parity with the other three providers in this reference, and the Interactions API is where Gemini-only capabilities will accumulate. That is a portability trade-off worth making deliberately rather than by default.Official sources: [G1] Interactions API - Gemini API, [G2] Gemini Interactions API reference, Migrating to the Interactions API.
13. Compatibility Pitfalls
This section collects the differences most likely to break code that is ported or shared across providers. It is the single most useful part of this page for anyone building an abstraction layer.1. The temperature ceiling differs (1.0 vs 2.0). Anthropic accepts
temperature only in 0.0-1.0; OpenAI and Gemini accept 0.0-2.0. A value such as 1.5 is valid on two providers and rejected on the third. Portable code should stay within 0.0-1.0 or clamp per provider.2. The newest Anthropic and Gemini models retire the sampling parameters entirely. On Claude Opus 4.7 and later (including Opus 4.8 and Opus 5), Claude Sonnet 5, and Claude Fable 5, setting
temperature, top_p, or top_k to a non-default value returns a 400 error, and Anthropic's migration guidance is to omit these parameters entirely; they remain available on Claude Opus 4.6, Sonnet 4.6, and earlier. Google is moving in the same direction: as of July 2026, temperature, top_p, and top_k are deprecated on the Gemini API starting with Gemini 3.6 Flash and Gemini 3.5 Flash-Lite - the API currently ignores them on those models, and future generations are expected to return an error (source: Gemini API changelog). Code that always sets temperature will fail against the newest models unless the parameter is omitted; check each provider's current model documentation before relying on sampling parameters.3. The output-length cap is named differently and is required only on Anthropic. Anthropic requires
max_tokens; OpenAI uses max_completion_tokens (Chat Completions) or max_output_tokens (Responses) and has deprecated the old max_tokens; Gemini uses maxOutputTokens; Bedrock uses inferenceConfig.maxTokens. On OpenAI reasoning models these caps also count hidden reasoning tokens, so a cap that is too low can be consumed by reasoning before any visible text appears.4.
top_k is not universal. OpenAI has no top_k at all. On Amazon Bedrock, top_k is not part of the base inferenceConfig; it must be sent through additionalModelRequestFields. For provider-agnostic code, prefer top_p.5. The system prompt is a field on three providers and a role on one. Moving a "system message" between OpenAI and the others means moving it between the
messages array and a top-level field (system / systemInstruction). Gemini additionally uses the role name model for the assistant turn and has no system role inside contents. On OpenAI's o1 and newer models the developer role supersedes system.6. Bedrock's unified layer only covers four parameters. The Converse API's
inferenceConfig gives one consistent shape for temperature, topP, maxTokens, and stopSequences across every model it hosts - but anything else (top_k, penalties, reasoning settings) goes through additionalModelRequestFields, and the accepted ranges are the underlying provider's. For example, a Claude model on Bedrock still caps temperature at 1.0, exactly as on the Anthropic API.7. The
tool_choice vocabulary is not shared. "Force the model to call a tool" is any (Anthropic, Bedrock), required (OpenAI), or ANY (Gemini). "Let the model decide" is auto / AUTO. A router must translate these values, not pass them through.8. OpenAI's two API surfaces diverge.
presence_penalty, frequency_penalty, n, logit_bias, seed, stop, and the boolean logprobs exist in Chat Completions but not in the Responses API. Migrating from Chat Completions to Responses silently drops these unless you account for them.14. Frequently Asked Questions about LLM API Parameters
- Is temperature the same across LLM APIs?
- No. The accepted range differs: Anthropic accepts
0.0-1.0, while OpenAI and Gemini accept0.0-2.0(see the Sampling Parameters table). Defaults also differ, and Anthropic's newest models - Claude Opus 4.7 and later (including Opus 5), Claude Sonnet 5, and Claude Fable 5 - reject non-defaulttemperaturevalues with a400error, so the parameter should simply be omitted on those models. Portable code should stay within0.0-1.0and treat sampling parameters as optional. - How do I specify structured output in each API?
- Anthropic uses
output_config.formatwith ajson_schema; OpenAI usesresponse_format(Chat Completions) ortext.format(Responses), each supporting ajson_object(JSON only) orjson_schema(schema-enforced) variant; Gemini usesresponseMimeType: "application/json"together withresponseJsonSchema; and Amazon Bedrock usesoutputConfig.textFormat. The exact shapes are in the Structured Output table above. - What is the Bedrock Converse API equivalent of max_tokens?
- It is
inferenceConfig.maxTokens. The Converse API keepsmaxTokens,temperature,topP, andstopSequencesin its unifiedinferenceConfigobject, and the maximum you can request depends on the underlying model. See the Length and Stop Controls table. - Which sampling parameters work everywhere?
temperature(within0.0-1.0to stay in range for every provider) andtop_pare the safest cross-provider choices.top_kis absent on OpenAI and only reachable throughadditionalModelRequestFieldson Bedrock; penalties andseedare not offered by Anthropic. When writing provider-agnostic code, limit yourself totemperature,top_p, and the output-length cap, and treat everything else as provider-specific.- Is prompt caching portable across providers?
- No. All four providers offer prefix caching, but the request surfaces are incompatible: Anthropic uses
cache_controlblocks, Bedrock usescachePointblocks, OpenAI uses automatic caching plusprompt_cache_optionsandprompt_cache_breakpointon newer models, and Gemini uses a separatecachedContentsresource referenced bycachedContent. TTL values differ as well (5m/1h versus 30m versus a free-form Duration). Treat caching as a per-provider adapter concern; the full comparison is in section 11.
15. Summary
Every major LLM API exposes the same conceptual controls - sampling, length, stop sequences, system prompts, streaming, structured output, tool use, and reasoning - but names them differently and, more dangerously, accepts different values for the same-looking parameter. The headline differences are thetemperature ceiling (1.0 on Anthropic vs 2.0 on OpenAI and Gemini), the removal of the sampling parameters on Anthropic's newest models, the several different names for the output-length cap (and that it is required only on Anthropic), the absence of top_k on OpenAI, and the system prompt being a field on three providers and a message role on OpenAI. Amazon Bedrock's Converse API adds a useful unifying layer - one shape for temperature, topP, maxTokens, and stopSequences across every model - while routing everything model-specific through additionalModelRequestFields at the underlying model's own ranges. The structural change to watch is on the Google side: Google has designated generateContent legacy in favour of the Interactions API, which drops the sampling parameters entirely, replaces candidates[] with a typed step timeline, and makes server-side conversation state the default (section 12).Because each provider's API moves quickly, this page is kept current and dated; always confirm a specific parameter's name, type, range, and availability against the official reference linked in each section before you rely on it. Related references on hidekazu-konishi.com:
- Amazon Bedrock Converse API Deep Dive
- Anthropic Claude API Errors Reference
- Anthropic Claude API Prompt Caching and Token Efficiency
- Anthropic Tool Use Schema Builder and Validator
- LLM Token Counter and Context Budget Planner
- Anthropic Claude Model Migration Guide
- Dynamic Model Routing with AWS AppConfig
- AI Model Deprecation and Lifecycle Calendar
16. References
Anthropic (Messages API)Messages - Anthropic API
Models overview - Anthropic API
Structured outputs - Anthropic API
Tool use with Claude - Anthropic API
Extended thinking - Anthropic API
Streaming Messages - Anthropic API
Prompt caching - Anthropic API
OpenAI (Chat Completions and Responses APIs)
Create chat completion - OpenAI API reference
Create response - OpenAI API reference
Reasoning - OpenAI
Prompt caching - OpenAI
Google Gemini (generateContent API and Interactions API)
Generating content - Gemini API reference
Structured output - Gemini API
Function calling - Gemini API
Thinking - Gemini API
Context caching - Gemini API
Caching - Gemini API reference
Release notes / changelog - Gemini API
Interactions API - Gemini API
Gemini Interactions API reference
Migrating to the Interactions API - Gemini API
Amazon Bedrock (Converse API)
Converse - Amazon Bedrock API Reference
ConverseStream - Amazon Bedrock API Reference
Carry out a conversation with the Converse API operations - Amazon Bedrock
Inference request parameters and response fields - Amazon Bedrock
Use a tool to complete a model response - Amazon Bedrock
Prompt caching for faster model inference - Amazon Bedrock
References:
Tech Blog with curated related content
Written by Hidekazu Konishi