A prompt that works on GPT-5.5 can fail spectacularly on Claude. Not because Claude is worse. Because they read the same instructions differently. Change a model string and your output craters — not from bad prompting, but from invisible provider assumptions you never knew you were making. The fix isn’t writing better generic prompts. It’s knowing the five dimensions where providers actually diverge: structure format, temperature behavior, caching mechanics, how each model interprets your few-shot examples. This cheat sheet maps those differences and the five traps that burn teams during migration. For the full methodology, see our prompt engineering guide.
The 5-Dimension Quick-Reference Table
| Dimension | OpenAI (GPT-5.5) | Anthropic (Claude Sonnet 4) | Google (Gemini 3.1 Pro) | ⚠️ Migration Risk When Switching |
|---|---|---|---|---|
| Structure Preference | Markdown or XML — both work | XML is first-class. Claude follows XML-delimited instructions more reliably than flat text | Clear sections with consistent formatting — neither XML nor Markdown is privileged | Moving TO Claude without wrapping instructions in XML loses 10-15% instruction-following accuracy |
| Long-Context Strategy | Bookend. Place critical instructions at the start AND end of the context window. Middle gets diluted | Data first, query at the end. The last thing in context gets the most attention | Data first, query at the end. Similar to Anthropic’s pattern | Moving FROM OpenAI to Anthropic/Gemini: instructions at the end get ignored. Rewrite to put data first |
| Temperature Sensitivity | 0 = maximum determinism. Use for structured extraction | Default behavior is balanced. Lower temps increase determinism without side effects | ⚠️ Below 1.0 may cause looping or degraded reasoning. Keep at 1.0. Use schema constraints for determinism | Moving TO Gemini with temp=0 causes loops. Moving FROM Gemini: temp can be safely lowered |
| Structured Output | response_format + strict mode. Constrained decoding at the token level. 98%+ valid JSON | output_config.format. Cannot combine with native citations. 96-97% valid JSON | JSON Schema via GenerationConfig. Can combine with tools. Reliable at temp 1.0 | Moving FROM OpenAI: expect JSON valid rate to drop 2-4%. Add post-processing validation layer |
| Prompt Caching | Automatic for prompts >1,024 tokens with stable prefix. No configuration needed | Manual cache_control: {"type": "ephemeral"} markers on static blocks | Context Caching API. Separate create/update lifecycle for cached content | Moving FROM OpenAI: caching savings drop to zero until you add manual markers on Anthropic or configure Gemini’s separate API |
For a deep dive into how caching reduces costs across providers, see our prompt caching strategies.
Provider-Specific Traps
The Gemini Temperature Trap
The instinct: “set temperature=0 for deterministic outputs.” This is correct on OpenAI. It is actively harmful on Gemini 3. Below 1.0, Gemini can enter looping behavior where it repeatedly generates and discards tokens trying to satisfy constraints that reduced temperature makes harder to explore.
The fix: Keep Gemini at temperature 1.0. Use JSON Schema’s constrained decoding for output determinism. Schema guarantees structure. Temperature controls creativity. Don’t mix them.
Overprompting on Newer Models
GPT-5.5 and Claude Opus 4 are meaningfully more obedient than GPT-4 and Claude 3.5. Instructions that were necessary — “ALWAYS use the search tool before answering,” “NEVER respond without checking the knowledge base” — cause over-triggering. The model searches when it shouldn’t. It refuses requests it should handle.
The fix: Start with minimal constraints on newer models. Add restrictions only when eval data proves the model isn’t handling a case correctly. Trust the model’s judgment first. Constrain second.
Claude’s XML Dependency
Claude follows XML-delimited instructions more reliably than any other format. A prompt that says “Review this code for bugs” will work. A prompt that says <review_instructions>Review this code for bugs. Flag severity as CRITICAL, WARNING, or INFO.</review_instructions> will work measurably better — 10-15% higher instruction-following accuracy.
The fix: When writing prompts for Claude, wrap instructions in XML tags. It’s not about making the prompt look structured. It’s about Claude’s training data — the model was trained to treat XML-delimited content as high-authority instructions. This XML-first behavior is documented in Anthropic’s prompt engineering guide. For implementation details across all three providers, see the structured output strategies in the quick-reference table above.
GPT’s Markdown Sensitivity
GPT models use Markdown structure as semantic signals. A ## Heading tells the model “this is a new section with a distinct topic.” Bullet points tell it “these are discrete items of equal importance.” Exploit this. Structure your prompts with Markdown headings and lists — not for human readability, but because GPT uses Markdown as an attention-weighting signal. This Markdown sensitivity is documented in OpenAI’s prompt engineering guide.
Few-Shot Sensitivity by Provider
- Claude: Most sensitive to XML structure and instruction detail. Few-shot examples in XML format improve performance more than the same examples in plain text.
- GPT: Responds best to Markdown grouping and positive framing. Few-shot examples benefit from clear section separation.
- Gemini: Most sensitive to few-shot example COUNT and ORDERING. Removing examples degrades Gemini faster than GPT or Claude. Reordering examples can swing results by 5-8 points.
Cross-Provider Migration Template
Moving a prompt from provider A to provider B? Five steps, in order:
- Audit structure format. If moving TO Claude: wrap instructions in XML. If moving FROM Claude: remove XML wrappers and test whether structure quality degrades.
- Check temperature settings. If moving TO Gemini: ensure temperature ≥ 1.0. If moving FROM Gemini: temperature can be lowered for determinism.
- Re-test few-shot examples. Example ordering and count sensitivity varies by provider. Re-run your eval suite with the same examples in the same order — then with order randomized. If scores differ significantly, your prompt depends on example ordering that’s provider-specific.
- Verify caching behavior. Anthropic requires explicit markers. OpenAI caches automatically. Gemini uses a separate API. A prompt optimized for provider A’s caching may lose 60-90% cost savings when moved to provider B without restructuring.
- Run the full eval suite. Never assume a prompt migrates cleanly. The same prompt on a different provider can produce output that’s 10-20% worse on task-specific metrics. Measure. Don’t guess. For automating prompt evaluation across every model in your fallback chain, our CI/CD testing guide covers contract tests and regression detection.
When You Change One Model String: A Migration War Story
Tuesday, 10:17 AM. Sarah pushes a one-line change to config/models.yaml. chat_default: "gpt-5.5" becomes chat_default: "claude-sonnet-4-20250514". Cost reduction: 40%. Code review: approved in three minutes. Deployment: smooth.
Wednesday, 2:43 PM. The support queue has 47 tickets about “the AI giving weird recommendations.” Sarah pulls up the eval dashboard. Their recommendation accuracy metric dropped from 91% to 74%. The one-line model change destroyed 17 percentage points of accuracy. What happened?
The XML wrapper that GPT ignored. Sarah’s prompt template used XML tags — <system_context>, <user_profile>, <recommendation_rules> — because Claude responds well to XML. The prompt had always used XML. GPT-5.5 had read the XML tags as light formatting hints and executed the instructions anyway. Claude Sonnet 4 read them as authoritative delimiters and followed them precisely — including <recommendation_rules> that contained an outdated business rule Sarah’s team had stopped enforcing six months ago. GPT-5.5 had been “smart” enough to ignore the stale rule. Claude followed it exactly. The result: Claude was recommending products the merchandising team had delisted. It was being obedient to bad instructions that GPT’s leniency had masked.
The few-shot examples that changed meaning. The prompt template included three few-shot examples. Each showed a user query, a product catalog subset, and the correct recommendation. Example 1: “What’s a good running shoe?” → Nike Pegasus. This made sense when GPT-5.5 was the model — it learned the pattern (user request → product match) and generalized. Claude Sonnet 4 learned the specific content — it interpreted “running shoe → Nike Pegasus” as a hard rule. Users searching for trail running shoes were recommended Nike Pegasus. Users searching for walking shoes were recommended Nike Pegasus. Claude was pattern-matching the product, not the reasoning behind the match.
The temperature difference that nobody checked. Sarah’s config set temperature=0 — the universal “make it deterministic” setting. It worked on GPT-5.5. On Claude, it produced a subtler failure: the recommendations became too consistent. Every user with a similar profile got identical recommendations. The system stopped personalizing. Claude wasn’t broken — it was just being perfectly deterministic at a task where slight variation was the desired behavior.
What Sarah actually fixed (and what you should do before your next model change):
-
Audit every
<tag>in your prompt for stale rules. GPT masked bad instructions by being lenient. Claude executes them. The migration didn’t break because Claude was worse — it broke because Claude was better at following instructions that had rotted. -
Re-test few-shot examples for content-literal vs. pattern-learning behavior. The same three examples that produce great results on one model can encode unintended hard rules on another. Run your eval suite with the examples, then without them. If the score changes more than 5 points, your prompt depends on example content that doesn’t generalize across models.
-
Map temperature expectations per provider. “Deterministic” means different things on different architectures. GPT at temperature 0 returns the single highest-probability output. Claude at low temperature returns a narrow band of high-probability outputs. Neither is wrong. Both produce different results for the same prompt.
The migration took three minutes to deploy and two days to debug. The root cause wasn’t Claude. It was six months of GPT-5.5 silently compensating for prompt rot that Sarah’s team never noticed. The model change didn’t create the bugs — it revealed them. For preparing your prompt templates to survive the next model deprecation, our model deprecation survival guide covers the abstraction layer and migration runbook that make provider switches a config change.
FAQ
Which provider is most sensitive to prompt changes?
Claude. XML structure changes, instruction reordering, and detail level adjustments produce larger output variations on Claude than on GPT or Gemini. This is a double-edged sword: Claude gives you more control through prompt structure, but also requires more careful prompt engineering. GPT is more forgiving of prompt variations. Gemini sits between them.
Is there a “write once, run anywhere” prompt format?
For simple Q&A and basic classification: yes, ~90% portable. For structured extraction: ~80% portable. For complex multi-step agent tasks: ~60% portable. The strategy: write a core prompt in plain text with clear section breaks → test on all target providers → add provider-specific overlays only where eval data shows gaps. Don’t pre-optimize for one provider’s format preferences.
How do I quickly validate prompt compatibility when switching providers?
Run your eval suite. If you don’t have one, build a 50-case mini-suite before you migrate. Compare per-metric scores between the old provider and the new one. Any metric dropping more than 5 points needs investigation. Metrics within 3 points are noise — don’t over-optimize for differences that won’t survive your next model version bump. For common prompt debugging questions, see the FAQ section above.
My prompt works perfectly on Provider A. Can I assume it will work on Provider B if both claim “GPT-4-class performance”?
No. “GPT-4-class” is a marketing term, not a compatibility guarantee. Models in the same benchmark tier can differ by 10-20 points on your specific task while being within 2 points on MMLU or HumanEval. The only valid test is running your eval suite against the target model. If you don’t have an eval suite, build a 50-example mini-suite before migrating. The hour you spend building evals will save you the two days Sarah spent debugging prompt rot from a one-line model change.
How do I safely test a prompt across providers without affecting production traffic?
Shadow evaluation: copy a sample of production requests, route them to the new provider, log the outputs, compare them to the current provider’s outputs offline. No user sees the new provider’s results. Start with 100 queries. Compare for schema validity, content accuracy, and task completion. Increase to 1,000 once you’re confident. Full cutover only after shadow evaluation shows parity on your specific metrics — not on a benchmark leaderboard.
Before migrating prompts between providers, review API security and key management differences — rate limits, authentication, and data handling vary per platform.
Prompt portability isn’t about writing a magical universal prompt. It’s about knowing which dimensions differ by provider, testing those dimensions systematically, and applying provider-specific overlays surgically — only where the eval data says they’re needed.
Keep this cheat sheet bookmarked. The next time you change a model string and your output quality shifts, you’ll know which dimension to check first. For the full methodology behind these provider-specific rules, see our prompt engineering guide — linked in the introduction above.