Constraints

Saying what you want, not what you fear

The most reliable change you can make to a badly behaved prompt is to turn a prohibition into an instruction. Anthropic puts it first among the ways to steer formatting:

Tell Claude what to do instead of what not to do

• Instead of: "Do not use markdown in your response"
• Try: "Your response should be composed of smoothly flowing prose paragraphs."

A prohibition describes the space of wrong answers, which is large, and leaves the right one unspecified. An instruction names the target. The second version is also easier to check, because you can read an answer and say whether it is flowing prose; "did not use markdown" is a property of what is absent.

Four ways to control format, in order of payoff

Describe the output you want. As above. This handles most cases on its own.

Use a format indicator. Ask for the part you care about inside a tag: "Write the prose sections of your response in <smoothly_flowing_prose_paragraphs> tags." A named container is easier for the model to satisfy than an adjective.

Match your prompt's style to the output's. The documentation notes that the formatting of your prompt influences the formatting of the response, and removing markdown from your prompt can reduce markdown in the output. If you are writing a heavily bulleted prompt and asking for prose, you are working against yourself.

Spell it out when you need precision. For real control over markdown, Anthropic's own sample instruction runs to a full paragraph inside a named tag, specifying what to use lists for and what to do instead.

Constraints are model-specific, and they expire

The long formatting block above comes with a warning that matters more than the block:

Claude Fable 5.1 already formats less than earlier models, so on that model a block like this can suppress structure the content needs.

The same applies to verbosity. Current models are described as less verbose by default, which makes an instruction to be concise redundant. Claude Opus 5 is called out as the exception: its responses run longer, and it needs the instruction. And Fable 5.1 writes fewer progress updates during agentic work, so the fix there is to ask for more and to remove any instruction telling it to be brief.

So a constraint tuned on one model can, on the next, do nothing, do the opposite, or suppress something you wanted. This is the same trap chain of thought describes for reasoning instructions. When you change model, read your constraints as candidates for deletion rather than as settings to carry over.

Explaining the constraint makes it generalise

A constraint with a reason attached survives cases you did not think of. The documentation's example is about ellipses:

• "NEVER use ellipses", a rule with no scope
• "Your response will be read aloud by a text-to-speech engine, so never use ellipses since the text-to-speech engine will not know how to pronounce them", a rule the model can extend

Given the second, a model can work out that the same problem applies to em dashes, to emoji, and to ASCII tables. Given the first, it knows about ellipses.

The line between a constraint and a guarantee

Everything above shapes output. None of it guarantees anything, and the distinction is the one worth leaving with.

A prompt constraint is a request the model will probably honour. A schema is a shape the response has to satisfy. A check in your code is the only thing that holds when neither did.

Some outputs have consequences: a refund amount, a category that routes a ticket, a field that reaches a database. For those, the prompt is where you ask and the code is where you enforce. Constraining inputs and outputs covers that boundary, including the case where a value satisfies the schema exactly and is still invented.

Use prompt constraints for the things no schema can express: tone, length, register, what to do when the answer is not in the context. Use enforcement for the rest.

Further reading

• Anthropic, Prompting best practices: the four formatting techniques, and the model-specific warnings.
• Structured output: the shape a response has to satisfy rather than one it is asked for.
• Constraining inputs and outputs: where a rule has to live to be enforced.
• Chain of thought: an instruction that stopped paying when the models changed.