Pular para o conteúdo principal

Porting Prompts Across Models

Intermediário

You have a prompt that works beautifully on one model. Now you need it on another — a client lives in GPT, a cost target pushes you to an open model, or you're A/B-testing Claude against Gemini. The good news, repeated across every provider's own docs: the bones of a good prompt are universal. What changes is a thin layer of surface conventions. This page separates the two so you can move a prompt without rewriting it, and gives you a repeatable migration workflow plus a portable template.

What you'll learn
  • Know which parts of a prompt transfer cleanly between Claude, GPT, Gemini and open models
  • Know which parts need per-model adjustment — and why
  • Run a repeatable migration workflow instead of trial-and-error rewriting
  • Keep a portable, model-neutral prompt template you can specialize per target

The mental model: structure transfers, conventions don't​

Think of any prompt as two layers:

  • The reasoning layer — what you're asking, the context you supply, the examples, the output you want. This is about communication, and it transfers almost unchanged across models.
  • The convention layer — how this particular model wants that communication packaged: where the system prompt goes and how hard it's followed, whether it prefers XML or Markdown, the exact tool-call schema, its default chattiness and refusal posture, which generation parameters exist.

Porting a prompt is almost never a rewrite of the reasoning layer. It's a re-fit of the convention layer. Get that distinction right and migration becomes mechanical instead of mysterious. (For the provider-neutral way to pick a target in the first place, see Choosing a Model.)

What transfers cleanly​

These hold on Claude, GPT, Gemini, and the major open models alike — each provider's own best-practices docs independently recommend them:

  • A clear role + task + explicit instructions. "You are X. Your job is Y. Follow these rules." Every provider documents a persona/role construct and rewards specific, unambiguous instructions over vague ones.
  • Concrete examples (few-shot). Showing 2–5 input→output pairs teaches a pattern more reliably than describing it. All three major providers explicitly recommend few-shot examples; Gemini's docs go as far as recommending you almost always include them.
  • A specified output format. "Return a Markdown table with columns X, Y, Z" or "JSON only, no prose" works everywhere. The instruction transfers even when the strict-mode mechanism differs (covered below).
  • Chain-of-thought / "reason before answering." Asking for step-by-step reasoning on hard tasks improves results across models. One caveat that is per-model: dedicated reasoning/thinking models often do this internally, so explicit "think step by step" can be redundant or even counterproductive — see the adjust list.
  • Grounding / RAG. "Use ONLY the context below; if the answer isn't there, say you don't know." The discipline of supplying retrieved context and constraining the model to it is universal — every provider documents RAG-style grounding as the way to reduce hallucination.
  • Putting long context first, the question last. Lead with the documents/data, end with the instruction. This ordering helps across models and is called out explicitly in Gemini's guidance.

If you've internalized Prompting Basics, you already own the portable 80%.

What needs adjusting per model​

This is the convention layer — the part that genuinely differs. Re-fit these when you move:

AspectWhat changes across modelsWhat to do
System-prompt handling & weightEvery model has a system/developer message, but how strongly it overrides the user turn varies. Some weight a dedicated developer/system role above user instructions; others blur the line.Don't assume your system prompt is followed with the same force. Re-test that constraints actually hold; promote critical rules higher if they slip.
XML vs Markdown vs delimitersClaude parses XML tags especially well for separating instructions/context/examples; GPT and Gemini accept XML but also lean on Markdown headings and delimiters.Keep some explicit structure; swap the flavor to the target's preference. Matching your prompt's format to the desired output also nudges output style.
Tool / function-calling JSON shapeThe loop (declare tools → model requests a call → you execute → return result) is identical everywhere; the wire format is not — field names, how calls/results sit in the message list, and strict-mode options differ.Never copy raw tool JSON across providers. Re-map to the target schema. See Tool Use.
Default verbosityNewer models trend terse by default and expect you to ask for detail; older ones were chattier.If you ported a prompt and answers got shorter/longer, set verbosity explicitly rather than blaming the prompt.
Refusal / safety postureEach model has its own threshold for refusing or hedging on borderline requests, and these are re-tuned every release.Re-test edge cases after porting. A prompt that never triggered refusals on one model may need re-framing on another.
Prefilling the answerPutting words in the assistant's mouth to force a format is a classic Claude-era lever — but newer Claude models (4.6+) reject a prefilled final assistant turn, and support varies elsewhere entirely.Replace prefill with a direct instruction ("respond without preamble"), an output schema, or tool calling.
Stop sequences & max tokensAll expose a length cap and most expose stop sequences, but parameter names, defaults, and caps differ — and some thinking-budget knobs are being deprecated in favor of effort/max_tokens.Re-check the parameter names and ceilings on the target; don't assume your old values port.

A migration workflow​

Treat porting as a short, disciplined loop, not a guess-and-check rewrite.

Guided walkthrough1 of 6
  1. Read your existing prompt and mentally split it: reasoning layer (role, task, context, examples, output spec) vs convention layer (XML/Markdown choices, prefill, tool JSON, parameters). You will keep the first and re-fit the second.

:::tip Don't rewrite from scratch If you find yourself rebuilding the role, task, or examples, stop — that's the portable layer. A clean port changes packaging, not meaning. :::

A portable prompt template​

Write your prompt in a model-neutral shape, then specialize only the convention layer per target. This core uses light, universally-understood structure (it reads cleanly as Markdown, and the tags convert easily to XML for Claude):

Model-neutral prompt core — specialize the convention layer per target

# ROLE
You are {role}.

# TASK
{One clear sentence describing the single goal.}

# RULES
- Use ONLY the information in CONTEXT below. If the answer is not there, say "I don't know" — do not guess.
- Be concise. Respond directly, with no preamble like "Here is..." or "Based on...".
- {Any other hard constraints.}

# OUTPUT FORMAT
{Exact format — e.g. "A Markdown table with columns Name, Value, Source." or "JSON only matching this schema: {...}".}

# EXAMPLES
Input: {example input 1}
Output: {ideal output 1}

Input: {example input 2}
Output: {ideal output 2}

# CONTEXT
{Retrieved documents / data go here — long content first.}

# REQUEST
{The actual user question, last.}

Per-target tweaks to layer on top:

  • Claude — move the section markers into XML tags (<role>, <rules>, <context>, <request>); it parses those especially cleanly. Don't use a prefilled assistant turn on current models; rely on the "no preamble" rule or a tool/schema instead.
  • GPT — put RULES in the system/developer message so they carry more weight; Markdown headings are fine; use structured-output/strict JSON mode rather than only describing the schema in prose.
  • Gemini — pass ROLE + RULES + OUTPUT FORMAT via the system-instruction field, keep the prompt direct (newer Gemini can over-interpret verbose prompts), and keep CONTEXT first with the REQUEST last.
  • Open models (Llama/Mistral/Qwen, etc.) — follow the model's published chat template exactly, and lean harder on explicit few-shot examples and format constraints, since instruction-following is usually less robust than the frontier closed models.

Quick check​

Check yourself

0/3
  1. You're moving a working Claude prompt to GPT. Which part should you expect to keep essentially unchanged?
  2. Your ported prompt suddenly produces much shorter answers on the new model. Most likely cause?
  3. What is true about tool/function calling when porting between providers?
Porting cheat-sheet
Pressione Enter ou Espaço para virar o cartão. Use as setas esquerda e direita para navegar entre os cartões.Termo exibido.
1 / 6
Key takeaways
  • A prompt is a reasoning layer (transfers) plus a convention layer (re-fit per model) — port the second, keep the first.
  • Clear role/task/instructions, few-shot examples, output-format specs, chain-of-thought, and RAG grounding transfer across Claude, GPT, Gemini and open models.
  • Adjust system-prompt weight, XML vs Markdown structure, tool-call JSON, default verbosity, refusal posture, prefill, and length parameters per target.
  • Run a tiny eval set on real inputs before/after; fix conventions before touching the reasoning.
  • Keep a model-neutral template plus per-target tweaks in version control so switching is cheap.
  • Specific behaviors drift every release — verify parameters and limits at each provider's current docs, never from memory.

Sources & further reading​

Next​