Model-Specific Formatting Cheat Sheet (2026)

TL;DR: In 2026 the eight major model families disagree on prompt formatting. Claude wants XML tags and rejects temperature. Gemini accepts XML or markdown and wants your question last. OpenAI's API skips markdown unless you ask. Llama needs raw special tokens. This cheat sheet lists each vendor's documented rule, with source links.

What does a model-specific formatting cheat sheet cover in 2026?

Five things, because those are the five that actually differ between vendors: how instructions are structured, whether XML tags or markdown help, how system and user messages are separated, where long context goes, and which sampling parameters you are still allowed to set.

Everything else in prompt engineering travels fine. Be specific, give examples, state the output format — that advice works on all eight families and always has. The parts that break when you move a prompt are mechanical: a tag style the model was not trained to look for, a system role that does not exist, a parameter that now returns a 400.

Every cell below comes from the vendor's own documentation, accessed August 26, 2026. Where a vendor does not publish something, the cell says "not documented" rather than guessing. Full source table at the end.

How should you structure instructions for each model family?

There are three schools, and knowing which school your model belongs to saves more time than any individual tip.

The three schools are not arbitrary. Anthropic's case for XML is a parsing argument: a tag is an unambiguous boundary, so the model never has to guess whether a line is an instruction or part of the data you pasted. Google's position is looser, and the operative word in their guidance is consistently — mixing <task> tags with ## Task headings inside one prompt is worse than either style used cleanly. OpenAI's suggested structure is the outlier. It is flat, labelled prose with no wrapper syntax at all, and it reads as a deliberate simplification: their own migration advice for GPT-5.6 tells you to remove obsolete scaffolding and repeated instructions rather than add more.

The practical read: write your prompt once as labelled blocks, then re-wrap. The content of a good Role/Task/Context/Constraints/Format prompt does not change between Claude and GPT. Only the packaging does.

What actually breaks when you move a prompt between models?

Not the wording. In practice, four things break, and all four are structural.

The first is the system layer. Code that sets {"role": "system", ...} and sends it to Anthropic will not error — the message just gets folded into the conversation instead of sitting above it, and your instructions lose their privileged position. The second is prefill. If you relied on seeding an assistant turn to force a JSON opening brace, that pattern is dead on Claude 4.6 and later and alive on DeepSeek's beta endpoint, so the same trick either works or returns a 400 depending on which way you ported.

The third is sampling. A temperature=0.2 that produced tight, deterministic output on a 2024 model is now a 400 on Claude, a documented anti-pattern on Gemini, and silently inert on DeepSeek in its default mode. Nothing tells you; the output just gets less like what you expected.

The fourth is the tag vocabulary itself. XML tags are not magic on any model — they work because the model was trained on documents that use them that way. Wrapping a prompt in <context> tags for a model whose vendor publishes nothing about tags is a reasonable experiment, not a technique. Treat it as untested until you test it.

Do XML tags, markdown, or delimiters actually help?

For Claude, Gemini and Mistral, yes, and each vendor says so in writing. For the other five, the honest answer is that nobody at the vendor has published a claim either way, so any confident number you read about it came from someone's blog, not a lab.

The interesting split is markdown, and it runs the opposite direction to what most people assume.

Two copy-paste skeletons cover most of the field. Claude, Gemini and Mistral:

<role>
You are a senior technical editor.
</role>

<constraints>
- Never invent a citation.
- If a claim is unsupported, say so instead of softening it.
</constraints>

<context>
{{PASTE_SOURCE_MATERIAL_HERE}}
</context>

<task>
Rewrite the context above for a developer audience. Return markdown with H2 sections only.
</task>

And OpenAI's own suggested shape, which is deliberately not XML:

Role: Senior technical editor for a developer blog.
Personality: Direct, concise, no hedging.
Goal: A publishable rewrite of the supplied draft.
Success criteria: Every claim traceable to the draft; no new facts introduced.
Constraints: Markdown only where semantically correct (inline code, code fences, lists, tables).
Tools: None. Do not browse.
Output: H2 sections, 3–6 sentences each.
Stop rules: If the draft is under 100 words, ask for more input instead of expanding it.

How does each family handle system vs user messages?

This is where portable prompt code breaks quietly. Three vendors do not have a system role in the message array at all, and one of them will not tell you — it just behaves differently.

If you are still reasoning about this as one generic system prompt versus one user prompt, the split is worth reading properly — system prompt vs user prompt covers what each layer is actually for before you start juggling four vendor spellings of it.

Two more sharp edges worth knowing. Anthropic removed assistant prefill: starting with Claude 4.6 models, a request whose last message is a partial assistant turn returns a 400. DeepSeek kept prefill, but only on its beta base URL, with prefix: True on the final assistant message. Same technique, opposite direction, same year.

Where should long context go in the prompt?

This is the one axis where the vendors agree, which makes it the safest rule in the sheet: context first, question last.

Anthropic also publishes a multi-document wrapper worth stealing wholesale, because it gives the model something to cite back to:

<documents>
  <document index="1">
    <source>annual_report_2026.pdf</source>
    <document_content>{{ANNUAL_REPORT}}</document_content>
  </document>
  <document index="2">
    <source>competitor_analysis_q2.xlsx</source>
    <document_content>{{COMPETITOR_ANALYSIS}}</document_content>
  </document>
</documents>

Based on the documents above, identify strategic advantages and recommend Q3 focus areas.
Quote the specific lines you relied on before drawing each conclusion.

Note that xAI's version of this rule comes from its caching documentation, not its prompting documentation. The motive is different — a stable prefix is a cacheable prefix — but the instruction lands in the same place. Front-loading your context window is both a quality move and a cost move on Grok.

Which sampling parameters are still exposed in 2026?

This is the section that has changed most, and the one most likely to break code you wrote last year. The direction of travel across the whole industry is the same: vendors are taking temperature away and giving you a reasoning-effort dial instead.

The reason is worth understanding, because it tells you which way the remaining cells will move. Reasoning models are tuned as a whole system — the sampler settings are part of what the lab evaluated, not a knob left over for you. Google says this almost explicitly, warning that dropping temperature below 1.0 "may lead to unexpected behavior, such as looping or degraded performance, particularly in complex mathematical or reasoning tasks." Anthropic went further and simply removed the option. What replaced it is a control at a higher level of abstraction: instead of telling the model how randomly to pick each token, you tell it how much work to do, and the lab handles the sampling. Anthropic's effort documentation makes the trade explicit — it affects "all tokens in the response", including tool calls, which a temperature setting never could.

So read the table below as a snapshot of a migration in progress. Four families still hand you temperature. Two of those four tell you not to touch it.

Two conflicts inside the vendors' own documentation deserve flagging, because you will hit them.

DeepSeek publishes a temperature table that its default mode ignores. Their parameter-settings page recommends 0.0 for coding and maths, 1.3 for conversation and translation, 1.5 for creative writing. Their thinking-mode page states that thinking mode "does not support the temperature, top_p, presence_penalty, or frequency_penalty parameters." Thinking is enabled by default. So that table only applies if you have explicitly turned thinking off.

OpenAI documents temperature but does not document how reasoning models treat it. The Responses API reference lists it with a 0–2 range. The reasoning guide never mentions it, and steers you to reasoning.effort instead. That is a gap in the documentation, not an answer — treat the effect on GPT-5.6 as unverified rather than assuming your old value still does what it did.

If the underlying mechanics are fuzzy, temperature, top-p and top-k explained covers what each dial does, and top-p vs top-k covers the specific mess you get from setting both. Worth reading before you tune anything on the four families that still let you.

What is not documented, and how should you treat it?

Roughly a third of the cells in a complete version of this table would read "not documented", and that is the most useful thing on the page.

Meta publishes Llama 4's exact token layout and a general prompt-engineering guide, and no sampling recommendations at all — reasonable, since Llama is open-weight and your serving stack owns sampling. xAI publishes no formatting guidance for its text models. DeepSeek and Qwen publish examples and parameters but not prompt style.

The temptation is to fill those gaps from a blog post. Don't. An unsourced claim about Grok's XML handling is a guess with a confident font. The correct move is to run a five-prompt A/B on your own task, which takes twenty minutes and produces a result that is actually true for your workload. A/B test your prompts walks through the method.

There is also a difference between "not documented" and "documented elsewhere". Qwen is the clearest example: nothing on their model cards discusses prompt style, but the cards are unusually generous about everything else, publishing exact per-mode sampling values that most closed vendors keep internal. Open-weight labs tend to document the inference contract precisely and the prompting advice barely at all, because the community writes the second half. Closed labs invert it. Neither is hiding anything — they are documenting the surface they control.

One more note on where these facts live. Qwen's official readthedocs site still describes the Qwen3 generation, while the current model cards on Hugging Face cover Qwen3.8. When a vendor's guide and its model card disagree on a version, the model card is the one shipped alongside the weights, and it wins.

The one-page version

Save this block. It is the whole sheet in the form you would actually paste into a team wiki.

PROMPT FORMATTING CHEAT SHEET — verified against vendor docs, 26 Aug 2026

STRUCTURE
  Claude ......... XML tags. <instructions> <context> <input>. Nest, name consistently.
  GPT-5.6 ........ Labelled sections: Role / Goal / Success criteria / Constraints / Output / Stop rules.
  Gemini 3 ....... XML tags OR markdown headings. Pick one per prompt.
  Mistral ........ Markdown and/or XML tags.
  Llama 4 ........ <|header_start|>system<|header_end|> ... <|eot|>  (self-hosted only)
  Grok / DeepSeek / Qwen ... no vendor formatting guidance published.

SYSTEM LAYER
  Claude ......... top-level `system` param. No system role in messages.
  OpenAI ......... `instructions` param, or role: "developer" (not "system").
  Gemini ......... `systemInstruction`, text only.
  Grok ........... role: "system", or `instructions` (not with previous_response_id).
  Llama .......... system header block. Roles: system|user|assistant|tool.
  DeepSeek/Mistral/Qwen ... role: "system" in messages.

ORDER
  Long documents FIRST. Question LAST. Anchor with "Based on the above...".
  Documented by Anthropic, Google, OpenAI and xAI. Not contradicted by anyone.

SAMPLING
  Claude ......... temperature/top_p/top_k DEPRECATED. Non-default = 400. Use output_config.effort.
  OpenAI ......... temperature 0-2 documented; reasoning.effort none..max; text.verbosity low/med/high.
  Gemini 3 ....... keep temperature at 1.0 (vendor's own advice). thinking_level, not thinking_budget.
  Grok ........... temperature 0-2. reasoning_effort low..xhigh, cannot disable. No stop/penalties.
  DeepSeek ....... temperature IGNORED in thinking mode (on by default). Penalties silently inert.
  Mistral ........ temperature 0.0-0.7 recommended. random_seed for determinism.
  Qwen 3.8 ....... thinking: temp 1.0 / top_p 0.95 / top_k 20 / min_p 0
                   instruct: temp 0.7 / top_p 0.80 / top_k 20 / presence_penalty 1.5

BROKEN IN 2026
  Claude: assistant prefill removed (4.6+). budget_tokens = 400 on 4.7+.
  Grok: presence/frequency penalty and stop = error on reasoning models.
  DeepSeek: presence/frequency penalty accepted and ignored.
  Docs moved: docs.claude.com -> platform.claude.com; llama.com/docs -> developer.meta.com/ai/docs.

The structure inside your prompt is the part that transfers. Role, task, context, constraints, output format — that skeleton works on all eight families, and it is what our own enhancer produces before you paste anywhere. What Prompt Architects does not do, and no browser extension can, is set your API sampling parameters. The bottom half of this sheet is server-side work. If you want the general version of the top half, the ultimate prompt engineering cheat sheet is the model-agnostic companion to this page, and how to write better ChatGPT prompts is the framework underneath both.

Sources

Every claim above, with the page it came from. All accessed August 26, 2026.