Structuring prompts for Claude vs GPT-4

Claude and GPT-4-class models can follow the same brief. They do not prefer the same scaffolding. OpenAI's GPT-4.1 and GPT-4o families, the models people still mean when they say GPT-4 in a loose conversation, respond reliably to markdown headings: Role, Task, Context, Constraints, Output. Anthropic's prompting guidance has for years asked people to wrap the parts in XML-style tags, so the instruction, the document, and the example are separate elements. As of late 2026 the model names on Anthropic's list include the Sonnet and Opus lines, with Sonnet 5.5 as a current workhorse. The tag habit did not retire when the version numbers moved. Check the current guide before you standardize a company template, and do not treat a blog's memory as the manual.

The mistake is to treat the scaffold as the strategy. A muddy task inside perfect tags is still muddy. A clear task under plain headings usually works on both families. The scaffold matters when the prompt contains a document that could be mistaken for instructions, or when you are maintaining two clients and you want each request to look like the examples in that provider's own documentation. Match the provider's documented shape so a future reader of your code recognizes it. Do not invent a third house style that matches neither.

Here is one brief in the markdown shape the optimizer emits, which is a comfortable GPT-4-class layout.

# Role
You edit shipping replies for a small shop.

# Task
Rewrite the draft so it answers the customer's question.

# Context
Draft: Your parcel is on the way.
Customer: Which carrier, and when does it arrive?

# Constraints
Do not invent a carrier or a date. If the draft does not say, ask the warehouse in one sentence.

# Output format
Respond with markdown. Two short paragraphs. No preamble.

The same brief in the tagged shape Claude's docs have favored:

<role>You edit shipping replies for a small shop.</role>
<task>Rewrite the draft so it answers the customer's question.</task>
<draft>Your parcel is on the way.</draft>
<customer>Which carrier, and when does it arrive?</customer>
<constraints>Do not invent a carrier or a date. If the draft does not say, ask the warehouse in one sentence.</constraints>
<output>Markdown. Two short paragraphs. No preamble.</output>

Read them side by side and you can see they carry the same information. The tag version makes the draft and the customer message impossible to confuse with the task, which is the actual point of the tags. The heading version does the same job if you keep the draft under a Context heading and you do not let it sprawl into the constraints. Both fail the same way if you write "be helpful" where the constraint should be. Switching families will not supply the carrier you refused to look up.

A few differences are worth respecting even when the content matches. Claude's guides have long suggested putting the document in tags and the question after the document, so the instruction that says what to do with the document is near the end, where it is harder to forget. GPT-4-class models are more tolerant of a heading at the top, and they still benefit from a short reminder of the output shape after a long context. If your context is a few hundred tokens, the position barely matters. If your context is a contract, repeat the output line after the contract on both families. Long context is where structure stops being style and starts being recall.

Tokenizers differ, so do not copy a cl100k count onto a Claude budget. The counter on this site estimates cl100k_base. A Claude bill uses Anthropic's tokenizer. English prose is often in the same neighborhood. Code, markup, and the tags themselves are not free. Every <constraints> and </constraints> is tokens. So is every "# Constraints". On a short prompt the difference is noise. On a template you send a million times, count the scaffold in the tokenizer you will actually be billed on. The structural advice transfers. The integer does not. The cl100k note explains what the integer on this site includes.

System prompts are a related split. Both providers let you send a system (or equivalent top-level) instruction separately from the user turn. Put stable rules there: the role, the constraints you never want dropped, the output shape. Put the ticket, the draft, and the document in the user turn. Do not paste the same constraint in both and then let them drift. Two copies will diverge the first time someone edits one. The system-versus-user note is the longer version of that rule. It applies to both families. The wire format of the field names does not.

Examples should use the same scaffold as the real call. If production uses tags, the few-shot pairs should use tags. If production uses headings, the pairs should use headings. A model that sees three markdown examples and then a tagged request has to guess which pattern you want continued. This sounds fussy until you watch a model emit a heading inside a JSON value because the examples were markdown and the format line was JSON. Keep one pattern per route.

What not to do is a short list. Do not wrap every sentence in a tag. A tag is a fence around a block, not a part of speech. Do not use headings as decoration inside the customer's text. If the customer used markdown, fence their message so their headings are data. Do not maintain two completely different task wordings for the two providers. Maintain one task and two thin wrappers if you truly send to both. Divergent wording is how you get divergent incidents and no idea which sentence caused them.

Test the wrapper on the failures you already have, not on a demo sentence. Take ten prompts that went wrong on GPT-4.1 and send the tagged version to Sonnet, and the reverse. If the tagged version fixes a "the model followed the document instead of the task" failure, keep the tags for document-heavy routes on Claude. If both versions fail because the constraint was missing, stop adjusting brackets and write the constraint. Scaffold is a fix for ambiguity about where the pieces are. It is not a fix for a missing piece.

Prices are not a reason to pick a scaffold. Sonnet 5.5's published input list price in October 2026 was $2 per million tokens, in the same band as GPT-4.1's input list price, with output at a different rate. Choose the model for the replies you checked. Choose the scaffold for the documentation your next editor can recognize. Then count the request you actually send, in the tokenizer that model uses, before you clone it across a batch.

If you only remember one practice, remember this: the customer's words, the source document, and the assignment are three objects. Headings can separate them. Tags can separate them. A single paragraph cannot, once the document is longer than the assignment. Pick the separator your provider documents, use it on every call in that route, and stop there.