Prompting ChatGPT vs Claude vs Gemini: What Carries Over

Most prompt engineering transfers between ChatGPT, Claude and Gemini: clear tasks, real context, explicit output formats, good examples and grounding in sources help on every major model. What differs is default style, how literally each model follows instructions, how it handles formatting and very long inputs, and the API features around the prompt. The reliable approach is to write prompts from principles, then test them on the specific model you ship with.

This article stays deliberately away from claims like "Model X is better at Y". Those claims age in weeks. The useful knowledge is which parts of a prompt are portable and how to find out quickly when they are not.

Key takeaways

• Principles transfer. Exact wording, length tuning and formatting quirks often do not.
• Each vendor publishes its own prompting guide; read the one for your model.
• A small test set beats any comparison article, including this one.
• Expect to retune prompts when you switch models, or when the same vendor updates its model.

#What transfers between models?

Nearly everything that is about information rather than phrasing.

Specific tasks and context. Every model does better when you say who the output is for, why it is needed and what good looks like. No model can guess your audience.

Explicit output format. "Return a table with these columns" or "JSON with these keys" works everywhere. All three vendors also offer API-level structured output features, which we cover in getting reliable JSON from LLMs.

Examples. Few-shot examples help all of them for style and format, and they cause the same side effects everywhere (copying length and phrasing, label bias). See zero-shot vs few-shot prompting.

Delimiting data. Separating instructions from pasted material, with tags, headings or quotes, reduces confusion on every model.

Grounding. "Answer only from these sources, cite them, say when the answer is missing" is the core of grounded prompting regardless of model.

Security limits. Prompt injection affects every model. None of them can be made safe by prompt wording alone.

If you write a prompt by getting these right, it will work reasonably well on any current frontier model. Usually not identically, but reasonably.

#What tends to differ?

#Default verbosity and style

Give the same open-ended request to three assistants and you will get different lengths, different amounts of markdown, different willingness to add caveats. A prompt tuned on one model to produce "about the right length" may produce noticeably longer or shorter answers on another. The fix is to stop relying on defaults: state the length ("under 150 words"), the structure ("no headings, two paragraphs") and the tone explicitly.

#How literally instructions are followed

Models differ in how much they infer beyond the literal instruction. Some lean toward doing exactly what was asked; others toward doing what they think you meant, adding extras. Vendors also shift this between versions. OpenAI, for example, has noted in its guidance for some newer models that they follow instructions more literally than predecessors, so prompts that relied on the model filling in intent needed to be made explicit.

The portable habit: be explicit about scope. If you want only the edited paragraph and not a rewrite of the whole email, say so. If you want the model to also fix anything else it notices, say that.

#Formatting conventions in the prompt

Anthropic's documentation recommends XML-style tags (<document>, <instructions>, <example>) to structure prompts for Claude, and Claude responds very well to them. OpenAI's and Google's guides show markdown headings, XML tags and other delimiters as valid options. In practice, XML-style tags work on all major models and are unambiguous about where a block ends, which makes them a reasonable default if you want one style everywhere.

#System prompt handling

All three APIs support some form of system or developer instructions, but they differ in naming, in how multiple instruction sources are prioritized, and in how much weight a system prompt carries against a persistent user. If your product depends on the system prompt holding under pressure, test that behavior specifically: off-topic requests, attempts to extract the prompt, a user insisting on a forbidden action. Background on that in how to write a system prompt.

#Long context behavior

Context window sizes differ and change often, so we will not list numbers. What matters more than the maximum is how well a model uses information inside a long input. Research such as "Lost in the Middle" (Liu et al., 2023) showed models used information at the start and end of long contexts better than in the middle. Vendors give somewhat different advice here: Anthropic suggests putting long documents near the top and the question at the end; OpenAI has suggested, for long-context prompts, placing key instructions both before and after the material. When you move a long-document prompt between models, the placement of instructions is one of the first things to test.

#Reasoning features

Each vendor offers models or modes that reason before answering, controlled through different API settings (effort levels, thinking budgets). The prompting advice for those modes is similar across vendors: describe the goal and constraints and avoid scripting the reasoning step by step. Explicit "think step by step" instructions that helped standard models often add little on reasoning modes.

#Tool calling formats

Function and tool calling work on the same idea everywhere (you describe tools with a name, description and JSON Schema parameters, and the model returns a structured call), but the request and response formats differ. Libraries and protocols such as the Model Context Protocol reduce the plumbing differences. The quality of your tool descriptions transfers completely.

#How do you test a prompt across models?

A method that takes an afternoon and saves weeks of arguing about which model is "better":

1. Collect 20 to 50 real inputs for the task. Include the hard ones: ambiguous requests, missing information, very long inputs, the off-topic message.
2. Write down what a good output looks like for each, or at least the rules it must satisfy (format valid, cites a source, under 100 words, says "not found" for the unanswerable ones).
3. Run the same prompt on each candidate model. Fix temperature or run each input several times, since outputs vary between runs.
4. Score against your rules, with code where possible (format checks, length, required strings) and by reading the rest.
5. Look at the failures, not the averages. One model might be slightly worse on average but fail gracefully; another might be better on average but occasionally invent facts. The second is often worse for a real product.
6. Tune the prompt per model if needed, then rerun everything.

Keep the test set. When a vendor ships a new version, rerun it before switching.

#Should you keep one prompt for all models or one per model?

For a personal workflow, one well-written prompt is usually fine; small differences do not matter when you are reading the output yourself.

For a product, plan for per-model variants of at least the formatting and length instructions, and keep the core content (task, context, rules, examples) shared. Store prompts in version control alongside the test results, so that "why does this line exist?" has an answer.

#Where do vendor prompting guides help most?

Each major vendor maintains prompt engineering documentation for its own models: OpenAI's prompt engineering guide, Anthropic's prompt engineering documentation for Claude, and Google's prompt design strategies for Gemini. They are free, kept fairly current, and written from the inside. Read the one for your target model before tuning, because it will tell you about features and preferences that no general article can track, including this one.

If you use several assistants day to day, the practical advice is shorter: write prompts that would make sense to a smart colleague who has never seen your project, and let each model's quirks show up in testing rather than in assumptions. The fundamentals topic covers the portable core, and how to write better ChatGPT prompts has a checklist that works across all three.