What Claude expects vs what GPT-4 expects (and why it matters)

Pattern: Before/After with compiled output examples

Keywords: prompt template for Claude, GPT-4 prompt format

Priority: P1 (month 2-3)

Length: 1,500-2,000 words

Thesis: Claude responds best to XML tags. GPT-4 prefers Markdown headers. Gemini wants uppercase labels. Using the wrong format doesn't break anything — it just makes everything 20% worse.

Outline:

Platform formatting isn't optional — it's quality engineering
Claude: XML tags, <thinking>, constraints duplication
GPT-4: Markdown, verbosity guidance, anti-pattern lists
Gemini: uppercase labels, precise and direct
Side-by-side: same prompt compiled three ways
CTA: try compilation in prompt-x

Draft

title: What Claude expects vs what GPT-4 expects (and why it matters)

slug: claude-vs-gpt4-prompt-formatting

description: Each AI platform has formatting preferences that affect output quality. Learn what Claude, GPT-4, and Gemini actually expect.

keywords: prompt template for Claude, prompt template for GPT-4, multi-platform prompt engineering, prompt compilation engine, multi-platform prompt compilation author: Mariano date: 2026-04-13

Platform formatting isn't decoration — it's quality engineering.

Claude responds best to XML tags. GPT-4 prefers Markdown headers. Gemini wants uppercase labels. Using the wrong format doesn't break anything. It just makes everything measurably worse. This matters because most teams treat prompt engineering as format-agnostic. It isn't.

Each model was trained on different distributions of structured text. That training shapes how the model interprets instructions. A prompt written in Claude's native format will parse more reliably, follow structure more consistently, and produce higher-quality output than the same prompt rendered in GPT-4's preferred style. The difference isn't subtle. It's measurable.

The problem: most teams write prompts once and hope they work everywhere. They don't.

Claude's expectations: XML tags and explicit structure

Claude's training data includes heavy representation of XML. The model learned to parse <tag>content</tag> as semantic structure. When you write a Claude prompt with XML tags, you're speaking the model's native language.

Claude expects explicit section boundaries:

<role>
You are a senior code reviewer with 15 years of experience in Python and distributed systems.
</role>

<context>
You're reviewing pull requests for a fintech platform handling high-frequency trading.
Security and performance are equally critical. Code is written for clarity over brevity.
</context>

<task>
Review the attached code for:
1. Security vulnerabilities
2. Performance bottlenecks
3. Code clarity and maintainability issues

For each issue found, explain the risk and propose a fix.
</task>

<constraints>
- Focus on issues that matter. Skip style preferences.
- Explain reasoning, don't just list problems.
- If something works but is unconventional, call it out as a pattern choice, not an error.
</constraints>

Claude also handles extended thinking through <thinking> blocks effectively. When you need the model to reason through complexity before responding, Claude interprets the thinking tag as a signal to engage deeper reasoning.

The structure matters because Claude doesn't just recognize XML syntactically — it treats tagged sections as instruction priority. The model weights explicit structure more heavily than prose prose.

GPT-4's expectations: Markdown headers and anti-patterns

GPT-4 was trained on web content, documentation, and Github-style READMEs. Markdown is the model's native language.

GPT-4 interprets Markdown hierarchy as instruction priority. A # Role header signals primary context. A ## Context header signals secondary context. This hierarchy shapes how the model weights instructions.

GPT-4 also responds well to explicit anti-pattern lists — telling the model what not to do often produces better results than listing what to do:

# Role
You are a senior code reviewer with 15 years of experience in Python and distributed systems.

## Context
You're reviewing pull requests for a fintech platform handling high-frequency trading.
Security and performance are equally critical. Code is written for clarity over brevity.

## Task
Review the attached code for:
1. Security vulnerabilities
2. Performance bottlenecks
3. Code clarity and maintainability issues

For each issue found, explain the risk and propose a fix.

## Anti-patterns to avoid
Do NOT: Just list style violations
Do NOT: Suggest rewrites without explaining why
Do NOT: Criticize unconventional patterns without understanding the intent
Do NOT: Assume the code is wrong — assume it's intentional and ask why

## Constraints
- Focus on issues that matter
- Explain reasoning thoroughly
- Recognize pattern choices as legitimate engineering decisions

GPT-4 treats anti-patterns as higher-priority instructions than positive statements. "Do NOT respond with X" lands harder than "Always respond with Y."

Gemini's expectations: Uppercase labels and direct instruction

Gemini was trained on different source material. The model responds best to simple, direct, uppercase labels without nested structure:

ROLE: You are a senior code reviewer with 15 years of experience in Python and distributed systems.

CONTEXT: You're reviewing pull requests for a fintech platform handling high-frequency trading. Security and performance are equally critical. Code is written for clarity over verbosity.

TASK:
Review the attached code for:
1. Security vulnerabilities
2. Performance bottlenecks
3. Code clarity and maintainability issues

For each issue found, explain the risk and propose a fix.

CONSTRAINTS:
- Focus on issues that matter, skip style preferences
- Explain reasoning, don't just list problems
- Recognize pattern choices as legitimate engineering decisions

Gemini expects precision and directness. Filler language, rhetorical setup, and nested structure add noise. Uppercase labels act like visual anchors that guide the model's attention. The training distribution for Gemini favors flat, labeled structure over hierarchical nesting.

Side-by-side: The same prompt, three platforms

Here's the "senior code reviewer" prompt compiled for each platform. Same content, different formatting, measurably different structure:

Claude version (XML):

<role>
You are a senior code reviewer with 15 years of experience in Python and distributed systems.
</role>

<context>
You're reviewing pull requests for a fintech platform handling high-frequency trading.
Security and performance are equally critical. Code is written for clarity over brevity.
</context>

<task>
Review the attached code for:
1. Security vulnerabilities
2. Performance bottlenecks
3. Code clarity and maintainability issues

For each issue found, explain the risk and propose a fix.
</task>

<constraints>
- Focus on issues that matter. Skip style preferences.
- Explain reasoning, don't just list problems.
- Recognize pattern choices as legitimate engineering decisions.
</constraints>

GPT-4 version (Markdown):

# Role
You are a senior code reviewer with 15 years of experience in Python and distributed systems.

## Context
You're reviewing pull requests for a fintech platform handling high-frequency trading.
Security and performance are equally critical. Code is written for clarity over brevity.

## Task
Review the attached code for:
1. Security vulnerabilities
2. Performance bottlenecks
3. Code clarity and maintainability issues

For each issue found, explain the risk and propose a fix.

## Do NOT
- Just list style violations
- Suggest rewrites without explaining why
- Criticize unconventional patterns without understanding intent
- Assume the code is wrong — assume it's intentional

## Constraints
- Focus on issues that matter
- Explain reasoning thoroughly
- Recognize pattern choices as legitimate decisions

Gemini version (uppercase labels):

ROLE: You are a senior code reviewer with 15 years of experience in Python and distributed systems.

CONTEXT: You're reviewing pull requests for a fintech platform handling high-frequency trading. Security and performance are equally critical. Code is written for clarity over brevity.

TASK:
Review the attached code for:
1. Security vulnerabilities
2. Performance bottlenecks
3. Code clarity and maintainability issues

For each issue found, explain the risk and propose a fix.

CONSTRAINTS:
- Focus on issues that matter
- Explain reasoning clearly
- Recognize pattern choices as legitimate

The content is identical. The structure is different. The output quality will be measurably different across platforms.

What happens when you use the wrong format

Using the wrong format doesn't throw an error. It just degrades quality in specific, predictable ways.

Claude given Markdown headers instead of XML tags: Claude renders the # characters literally instead of parsing them as structure markers. The result: instructions feel like content rather than commands. Claude still processes them, but with lower confidence and more interpretation.

GPT-4 given XML tags instead of Markdown: GPT-4 renders the XML tags as literal text in the output. You get a response that begins with <role> appearing in the middle of sentences, or the model treating the tags as content to be echoed back. The hierarchical instruction priority is lost.

Gemini given either XML or Markdown: Gemini processes it, but the label anchors are gone. Instructions compete for attention at the same weight. Secondary context gets weighted equally to primary context.

In practice the output is consistently worse — not catastrophic, just a quiet, steady tax on quality.

The compilation approach: write once, compile everywhere

The solution isn't to memorize three prompt formats and manually switch between them. That's error-prone and doesn't scale.

The solution is compile-time architecture: store prompts in a canonical format that's platform-agnostic, then compile to each platform's native format at delivery time.

You write once. The system compiles to Claude format, GPT-4 format, and Gemini format automatically.

This works because prompt-x uses a 9-field semantic anatomy that's independent of formatting. Every prompt has defined roles, context, task, constraints, examples, and output format. The fields are the same across platforms. Only the rendering changes.

When you save a prompt:

Canonical storage: The prompt is stored in a normalized format that contains the fields and their content, without platform-specific markup.
Compile on delivery: When you copy the prompt for Claude, the system renders it in XML. For GPT-4, it renders Markdown. For Gemini, uppercase labels.
Quality preserved: Each compiled version respects the model's training distribution and formatting preferences.

This is analogous to how a compiler works for code. You don't write different source code for different CPU architectures. You write once, compile for each target.

Lovable and Raw: Expanding the target palette

The compilation engine handles five target platforms:

Claude compiles to XML tags and extended thinking blocks.

GPT-4 compiles to Markdown headers and anti-pattern lists.

Gemini compiles to uppercase labels and direct instruction.

Lovable compiles to natural prose format. Lovable is built for conversational context, so prompts render without rigid structure — more like instruction within a conversation thread. The fields map to narrative flow instead of labeled sections.

Raw compiles to plain text concatenation. No markup, no headers, no structure beyond line breaks. Raw is for systems that consume prompts as flat text, or for when you want to paste a prompt directly into a notebook or document without any formatting interference.

Each target has different assumptions about what structured text looks like. The anatomy is the same. The rendering adapts.

Why this matters for team consistency

When teams write prompts manually without a compilation engine, different team members use different formatting conventions.

One engineer writes Claude prompts in XML. Another writes them as numbered lists. A third uses prose. Same product, three different prompt formats, three different output quality profiles.

With compilation, all Claude prompts render identically — same tags, same structure, same quality. Team consistency becomes automatic.

Changes propagate across all instances. If you discover that a particular tag structure improves Claude's performance, you update the compiler. Every prompt that uses that field automatically benefits from the improvement.

The reality: formatting is not cosmetic

Most platforms treat prompt formatting as a presentational choice. It isn't. Formatting is instruction encoding.

Each model was trained on different distributions of structured text. That training created preferences. Claude's preference for XML isn't arbitrary — it reflects the model's training data and attention patterns. The same is true for GPT-4's Markdown preference and Gemini's uppercase labels.

Respecting these preferences isn't following rules. It's working with the model's actual capabilities.

The prompt that works best for Claude won't be the same as the prompt that works best for GPT-4, because the models have different semantic expectations for structure. The content stays the same. The form changes. The output quality changes with it.

prompt-x compiles prompts for Claude, GPT-4, Gemini, Lovable, and Raw from a single canonical source. Write once, compile everywhere. Try it free.

Related reading