How to Prompt the Top AI Models

The same prompt does not produce the same quality of output across model families. Claude, GPT, Gemini, and the open-weight challenger models were trained on different data pipelines, tuned with different RLHF objectives, and shipped with different default behaviors for reasoning, tool calls, and formatting. A system prompt that works well on one can quietly underperform — or actively misfire — on another. If you're copy-pasting one prompt across providers, you're leaving quality on the table.

This is a living comparison hub. It now covers Claude (Anthropic), GPT (OpenAI), Gemini (Google), and the open-source and challenger field (Meta's Llama, DeepSeek, Mistral, Alibaba's Qwen, and xAI's Grok); more model families will be added as their own guides go live.

Why prompting isn't portable across models

Four structural differences drive most of the divergence:

• System-prompt conventions. Claude takes a single system field that sits outside the conversation. OpenAI's GPT-5 series uses a developer role inside a formal instruction hierarchy (Root → System → Developer → User → Guideline), which changes how conflicting instructions get resolved.
• Reasoning/thinking modes. Both families now expose how hard should I think as an API parameter, but the mechanics differ — Claude's adaptive thinking versus GPT's reasoning.effort dial — and prompting each into the right depth uses different levers.
• Formatting preferences. Claude was trained to respond well to XML-tag scaffolding (<instructions>, <example>); GPT's newest guidance pushes the opposite direction — leaner prompts, less scaffolding, outcome-first instructions.
• Tool-calling formats and defaults. Schema strictness, parallel tool use, and preamble conventions before a tool call all differ enough that a tool-use harness built for one model needs real adjustment for the other, not just a model-string swap.

The rest of this guide compares all four head-to-head, then links out to a full prompting guide for each.

Claude vs. GPT vs. Gemini vs. open/challenger models: a prompting comparison

Dimension	Claude (Opus 5 / Sonnet 5 / Haiku 4.5, Fable 5)	GPT (GPT-5 series)	Google Gemini (Gemini 3 series)	Open / Challenger (Llama 4, DeepSeek V3/R1/V4, Mistral Large 3, Qwen3, Grok 4.5)
System/role setup	Single system field, separate from the conversation; Claude Opus 5 and Fable 5 also support appending a role: "system" message mid-conversation without breaking the cached prefix — Sonnet 5 and Haiku 4.5 do not.	Formal instruction hierarchy — Root, System, Developer, User, Guideline — with API callers writing at Developer authority via the developer role (replacing the legacy system role).	Dedicated system_instruction field, separate from the contents turns — similar shape to Claude's.	No shared convention: OpenAI-style system/user/assistant roles at the serving layer (vLLM, HF, Ollama), but DeepSeek-R1's own guidance says to skip the system role entirely and fold instructions into the user turn.
Preferred structure & formatting	Responds well to XML tags (<instructions>, <example>) and clear Markdown headers for long, structured prompts.	Newest guidance (GPT-5.6) favors lean, outcome-first prompts — state the goal and stopping conditions, cut redundant steps and repeated rules the model already follows.	XML tags or Markdown headers (pick one, stay consistent); put long context first and the instruction last; Gemini 3's own docs warn it can over-analyze overly elaborate prompt-engineering scaffolding.	No cross-vendor standard — each family ships its own chat template (Llama 4, Qwen3, Mistral); a template mismatch at the serving layer silently degrades quality more than it would on a hosted API.
Reasoning / thinking mode	Adaptive thinking (thinking: {type: "adaptive"}) plus an effort parameter (low–max); thinking content is summarized or omitted, never raw.	reasoning.effort dial spanning none/minimal up through low, medium, high, xhigh, to max on the newest models (exact range is model-dependent) — decoupled from output length; OpenAI recommends testing one level lower than your prior model's setting.	thinking_level dial (minimal/low/medium/high) replacing the legacy token-based thinking_budget; on by default and dynamically adjusted per prompt — don't mix the two params in one request.	Handled per-model, not per-vendor: Qwen3.x toggles an enable_thinking flag per call (emitting a <think> block), DeepSeek-R1 returns chain-of-thought separately via a reasoning_content field, and Mistral's Magistral line is a dedicated reasoning model rather than a togglable mode.
Structured output (JSON/schema)	output_config.format with a JSON schema, or strict: true on individual tool definitions.	Structured Outputs with strict: true — schema adherence is guaranteed, recommended as the default for any function whose output must parse.	Native JSON Schema response support (Pydantic/Zod-compatible out of the box); Gemini 3 can combine structured output with built-in tools (Search grounding, code execution) in the same call.	Mostly a serving-layer feature rather than a single vendor API — grammar-constrained decoding (vLLM, outlines) is common; native JSON-mode exists on some hosted APIs (e.g., Mistral's), but strictness and adherence vary by model and host.
Tool / function calling	JSON-schema tool defs; parallel tool calls by default; tool_choice (auto/any/tool/none) controls invocation.	Function calling with strict schemas; OpenAI's agent guidance recommends a short preamble before major tool calls and a TODO-style tool for tracking multi-step progress.	FunctionDeclaration-based tool defs; built-in tools (Search grounding, code execution, URL context) can be mixed with custom functions in a single request.	Formats diverge by family — Qwen3.x/Qwen-Agent's Hermes-style template, Llama 4's native tool-call format, Grok's OpenAI/Anthropic-compatible calling; JSON/schema adherence is generally less consistent than Claude or GPT, so plan on validation and retries.
Long context & caching	Up to a 1M-token context window on current models; automatic prefix-match prompt caching via cache_control breakpoints.	Multi-hundred-thousand-to-million-token context on current models; implicit/automatic prompt caching is the default on GPT-5.6, with optional explicit prompt_cache_breakpoint control for variable-content prompts.	1M-token input context across the Gemini 3 lineup (64K-token output cap); explicit, vendor-managed Context Caching is supported.	Varies widely by model and host, with vendor-side caching on hosted APIs: DeepSeek's V4 line is ~1M tokens, Grok 4.5 is ~500K; self-hosted models (Llama, Qwen, Mistral) depend on the serving stack's own prefix caching rather than a managed cache.
Verbosity / steering	Verbosity is prompted directly (respond concisely, length instructions); aggressive imperative language (CRITICAL, MUST) tends to overtrigger tool use on recent Claude models.	A dedicated text.verbosity parameter separates answer length from reasoning depth, so you can think hard and still answer tersely.	No dedicated verbosity/tone parameter — Gemini 3 is direct and terse by default, and steering it toward a more conversational, detailed, or different-toned response is done entirely through prompt instructions.	No single dedicated verbosity control across the group; steer with explicit instructions and stop sequences. Reasoning-first models (DeepSeek-R1, Magistral) tend to do best with minimal, direct prompts rather than heavy scaffolding.
Biggest pitfall	Overly forceful tool-use instructions cause overtriggering; editing the system prompt mid-session (instead of appending) silently invalidates the prompt cache.	Long, over-specified, or conflicting system/developer instructions tend to hurt rather than help — leaner, outcome-first prompts are what OpenAI's own guidance now recommends.	Overriding default sampling params — Google explicitly warns against moving temperature off its default of 1.0 — or over-engineering the prompt itself can trigger looping or degraded output on Gemini 3.	Fragmentation: prompt structure, thinking-mode toggles, and tool-call formats aren't portable across providers or serving stacks, and JSON/tool-call adherence typically needs more validation than Claude or GPT require.

A few of these deserve unpacking rather than a table cell.

System prompts mean structurally different things

On Claude, the system field is a single block of instructions the model treats as a persistent frame for the conversation — durable, but a single tier. On GPT-5-series models, the developer role sits inside a five-level authority hierarchy (Root, System, Developer, User, Guideline) that the model was explicitly trained to enforce, which is part of why GPT-5 models resist prompt-injection attempts more reliably than earlier generations: a user message can't out-rank a developer instruction no matter how it's phrased. If you're writing prompts that need to survive adversarial user input, that hierarchy is worth designing around explicitly rather than assuming both APIs treat system the same way. This distinction — and when to put an instruction in the system layer versus the user turn — is covered in more depth in System Prompts vs. User Prompts.

Reasoning depth is a dial, not a switch, on both — but tune it differently

Neither vendor treats thinking as binary anymore. Claude's adaptive thinking lets the model decide when reasoning helps, with effort as the depth control; GPT's reasoning.effort is a more explicit dial that OpenAI's own GPT-5.6 guidance says most teams should turn down one notch from whatever they used previously, since each generation reasons more efficiently per token. Cranking effort to maximum by default on either model is usually the wrong instinct — it burns latency and cost without a proportional quality gain on easy tasks. The general principles for working with reasoning-mode models rather than against them are in How to Prompt Reasoning Models Without Getting in Their Way.

Formatting philosophy has actually diverged over time

Anthropic's documentation still recommends XML-tag scaffolding for complex prompts. OpenAI's most recent GPT-5.6 prompting guidance pushes the opposite direction: internal evaluations reportedly showed leaner, outcome-first system prompts outperforming heavily scaffolded ones by 10–15%, while cutting tokens by 40–65%. That's a real, documented divergence — not a stylistic preference — so a prompt migrated from GPT to Claude (or vice versa) without restructuring is fighting the model's own training rather than working with it.

Claude: prompt for a collaborator you give context to

Claude's prompting philosophy centers on giving it a clear frame — role, constraints, and structured context — and trusting it to reason within that frame rather than issuing a rigid step-by-step script. It responds especially well to explicit XML structure in long or multi-part prompts, and to adaptive thinking left on with the effort level tuned to task difficulty rather than maxed by default. Recent Claude models — Fable 5 and Opus 5 at the top of the lineup, down through Sonnet 5 and Haiku 4.5 — are also unusually sensitive to imperative language like CRITICAL: you MUST — that phrasing, which was needed to get older models to reliably use tools, now overtriggers on newer ones and should be dialed back to plain, direct instructions. The full breakdown of system-prompt patterns, thinking-mode tuning, and tool-use conventions for each Claude tier is in How to Prompt Claude: Opus, Sonnet, and Haiku.

GPT: prompt for outcomes, not procedures

The current GPT-5 generation's own documentation argues for less prompt, not more: define the destination and the stopping condition, then let the model find its own route, rather than prescribing every intermediate step. That's a meaningful shift from earlier GPT prompting conventions, and it pairs with two API-level controls — reasoning.effort and text.verbosity — that let you independently tune how hard the model thinks and how much it says, instead of conflating the two. For tool-heavy and agentic workflows, OpenAI's function-calling guidance recommends brief preambles before consequential tool calls, strict: true schemas by default, and a TODO-style tracking pattern for multi-step tasks. The complete walkthrough — developer-role setup, effort and verbosity tuning, structured outputs, and agentic tool patterns — is in How to Prompt OpenAI's GPT Models.

Gemini: prompt for direct answers, don't over-engineer

Gemini 3's own guidance is unusually blunt about a failure mode the other labs don't call out as directly: heavily scaffolded, over-engineered prompts can make the model worse, not better, causing it to over-analyze instructions instead of just answering. The model is direct and fairly terse by default, so getting a conversational or more detailed response takes an explicit instruction in the prompt itself, and Google's docs specifically warn against nudging temperature off its default — doing so risks looping or degraded output rather than the creativity boost you'd expect on other models. Gemini's thinking_level dial and native, tool-combinable structured output are its other two defining levers. The full pattern set — system-instruction placement, thinking-level tuning, and grounding/function-calling conventions — is in How to Prompt Google's Gemini Models.

Open & challenger models: prompt for the model, not the vendor

Llama, DeepSeek, Mistral, Qwen, and Grok don't share a single prompting convention the way Claude/GPT/Gemini each do internally — because they aren't one product, they're a field, often run through different serving stacks (a hosted API, vLLM, Ollama) that each shape the effective prompt format. The starkest example: DeepSeek-R1's own guidance recommends skipping the system role and putting everything in the user turn, the opposite of best practice everywhere else, while Qwen3 exposes an explicit enable_thinking toggle and Mistral ships a separate dedicated reasoning line (Magistral) rather than a per-request dial. Tool-call and JSON-schema adherence across this group is generally less reliable than on the closed frontier models, so validation and retries earn their keep. The model-by-model breakdown — including where each family's tool-calling format and chat template diverge — is in How to Prompt Open-Source and Challenger Models.

Which to reach for

If you're deep in an XML-and-context-heavy workflow, building on Claude's adaptive thinking, or need the instruction-following precision of a system prompt Claude respects closely, stay there. If you're running lean, outcome-first agentic loops where you want independent control over reasoning depth and answer length — or you're leaning on OpenAI's structured-outputs guarantee for a strict downstream schema — GPT-5-series models are built for that. Reach for Gemini when the task is grounding-heavy (Search, code execution) and benefits from a huge context window with native, tool-combinable structured output, and keep its prompts leaner than you'd write for Claude. Reach for the open and challenger models when self-hosting, cost, data residency, or a specific model's benchmark edge (agentic coding, multilingual, reasoning) outweighs the convenience of a single unified prompting convention — and budget extra time for validation, since format adherence is the group's weak point. In practice, most teams building anything non-trivial end up maintaining prompts per model, because prompt engineering increasingly means prompt engineering, per model rather than one prompt that travels everywhere.

For the underlying principles that hold across every model family — instruction clarity, examples, output constraints, iteration — see the pillar guide: The Complete Guide to Prompt Engineering in 2026.