Prompt engineering for Claude

What actually works when prompting Claude in 2026 — structure, XML tags, examples, thinking effort, tool use, and four production-ready prompt templates you can copy.

Good Claude prompts in 2026 are structured, not clever. Put the role and constraints in the system prompt, wrap distinct inputs in XML tags, place long documents before the instruction, and state the output format explicitly. What has changed is what you can no longer do: temperature, top_p and top_k now return a 400 error on current models, assistant prefill has been removed, and thinking is on by default — so several classic prompt-control techniques are simply obsolete.

This page covers what broke, the six parts of a working prompt, a technique-to-task decision table, the Claude-specific habits that measurably help, four complete copy-paste templates, and the prompt patterns that quietly waste money.

#What changed in 2026, and which techniques are now obsolete

Three breaking changes have quietly invalidated a large amount of prompt-engineering advice written for Claude 3 and Claude 4. If you are copying a technique from a 2024 or 2025 guide, check it against this table first.

The effort ladder replaces almost all of the old reasoning-control vocabulary. It runs low, medium, high (the default), xhigh, max, and it is soft guidance rather than a token guarantee. One trap on Opus 5: passing thinking: {"type": "disabled"} while effort is xhigh or max returns a 400. On Fable 5, thinking cannot be disabled at all. The mechanics are covered in full on how Claude's thinking modes work.

#The anatomy of a Claude prompt

Six components. Not every prompt needs all six, but if a prompt is underperforming, the fix is almost always a missing one rather than better wording.

System prompt versus user turn is a real distinction, not a stylistic one. Put the stable material — role, constraints, format, examples, tool definitions — in the system prompt, and the variable material in the user turn. That split is also what makes prompt caching work, since the cacheable prefix has to be identical across calls.

#Which prompting technique for which task?

Start at the top of this table and move down only when the simpler technique fails on a real example. Most production prompts land in the first three rows.

#Claude-specific advice that actually moves results

#XML tags work unusually well

Claude responds strongly to explicit delimiters. Tags remove the ambiguity between “this is the document” and “this is an instruction about the document”, which is the single most common cause of a model answering the wrong question. Use tag names that describe the content — <contract>, <style_guide>, <examples> — and reuse the same names in your instruction so the reference is unambiguous.

#Put long documents before the instruction

With a 1M-token context on Sonnet 5, Opus 5 and Fable 5, it is tempting to lead with the question. Do not. Place the material first and the instruction last, so the model reads the question with the material already in view. This also aligns with prompt caching, which caches a prefix: a stable document block followed by a variable question is exactly the right shape.

#Be explicit about output format, including the negative case

State the shape you want and what to do when the material does not support an answer. “If a field is not stated in the document, write Not stated — do not infer it” is worth more than any amount of instruction to be accurate.

#Know which model you are prompting

The current lineup does not behave identically. Haiku 4.5 uses extended thinking, not adaptive, so an explicit reasoning instruction still helps there. Fable 5 never returns a raw chain of thought and can decline a request with stop_reason: "refusal" returned as an HTTP 200 — a prompt-level detail that will bite an unattended pipeline. And models from Opus 4.7 onward, Sonnet 5 included, use a tokenizer that emits about 30% more tokens for the same text, so a prompt sized for an older model may now overrun max_tokens. The model comparison covers the trade-offs per task.

#Four prompt templates you can copy

#Template 1 — Document analysis with grounded citations

SYSTEM:
You are a careful analyst. You answer only from the material provided in
<document> tags. You never infer facts that are not written there.

When the document does not answer a question, write exactly: Not stated.
Quote at most 25 words at a time, and mark every quote with the section
heading it came from.

Output format:
## Summary
Three sentences maximum.

## Key findings
- Finding — supporting quote — section

## Open questions
Questions a reader would still need answered. Omit this heading if none.

USER:
<document>
{{FULL_DOCUMENT_TEXT}}
</document>

<question>
{{WHAT_YOU_ACTUALLY_WANT_TO_KNOW}}
</question>

Answer the question using only the document above.

The document goes in the user turn before the question, and the instruction comes last. If you are running this repeatedly over the same document, add a cache breakpoint after the document block. For attributed output, the API's citations feature ("citations": {"enabled": true} on a document content block) produces machine-checkable references instead of quoted strings, and cited text does not count toward your output tokens.

#Template 2 — Code review with a severity contract

SYSTEM:
You are reviewing a pull request. Report only defects you can point to a
specific line for. Do not comment on style unless it changes behaviour.
Do not suggest rewrites of code that is correct.

Rank findings by severity, most severe first:
- blocker — data loss, security hole, or a crash on a realistic input
- major   — wrong result in a plausible case
- minor   — correct but fragile, or missing a test for a real branch

For each finding give: severity, file:line, one sentence on the defect,
and one concrete failure case (inputs, then what goes wrong).

If you find nothing at a severity level, omit that level entirely.
Do not pad the review to look thorough.

USER:
<diff>
{{UNIFIED_DIFF}}
</diff>

<context files="surrounding code the diff depends on">
{{RELEVANT_SOURCE}}
</context>

Review the diff.

Two things make this work: the severity definitions are behavioural rather than adjectival, and the “omit that level entirely” rule gives the model permission to return a short review. Without it, a review prompt reliably invents minor findings to fill the shape. For repository-scale work this belongs in Claude Code rather than a single call — see Claude for developers.

#Template 3 — Structured extraction via a tool schema

This is the replacement for assistant prefill. Define the output as a tool, force the call, and read the arguments — the schema is enforced rather than requested.

import anthropic

client = anthropic.Anthropic()

extract_invoice = {
    "name": "record_invoice",
    "description": "Record the fields extracted from a single invoice.",
    "input_schema": {
        "type": "object",
        "properties": {
            "vendor_name": {"type": "string"},
            "invoice_number": {"type": "string"},
            "issue_date": {"type": "string", "description": "ISO 8601, or empty if absent"},
            "currency": {"type": "string", "description": "ISO 4217 code"},
            "total_amount": {"type": "number"},
            "line_items": {
                "type": "array",
                "items": {
                    "type": "object",
                    "properties": {
                        "description": {"type": "string"},
                        "quantity": {"type": "number"},
                        "unit_price": {"type": "number"},
                    },
                    "required": ["description", "quantity", "unit_price"],
                },
            },
            "confidence": {
                "type": "string",
                "enum": ["high", "medium", "low"],
                "description": "low if any required field had to be guessed",
            },
        },
        "required": ["vendor_name", "invoice_number", "currency",
                     "total_amount", "line_items", "confidence"],
    },
}

message = client.messages.create(
    model="claude-haiku-4-5",
    max_tokens=2048,
    system=(
        "Extract invoice fields exactly as written. Never normalise, correct "
        "or infer a value. If a required field is absent, use an empty string "
        "for text fields and 0 for numbers, and set confidence to 'low'."
    ),
    tools=[extract_invoice],
    tool_choice={"type": "tool", "name": "record_invoice"},
    messages=[{
        "role": "user",
        "content": "<invoice>\n" + invoice_text + "\n</invoice>",
    }],
)

data = next(b.input for b in message.content if b.type == "tool_use")

Note the confidence enum. Giving the model a legitimate way to signal uncertainty is far more effective than instructing it not to guess, and it gives your pipeline something to route on. Haiku 4.5 handles this class of task at $1/$5 per million tokens; submitted through the Batch API it halves again. Bulk patterns are on the automation page.

#Template 4 — Long-form drafting with a house voice

SYSTEM:
You are drafting for {{PUBLICATION_OR_TEAM}}. Match the voice defined in
<style>. Write for a reader who is competent but short of time.

Hard rules:
- No introductory throat-clearing. The first sentence carries information.
- No "in today's fast-paced world", no "delve", no "leverage" as a verb.
- Prefer the specific number over the adjective.
- State the counter-argument where one exists; do not straw-man it.
- Where a claim needs a source and none is supplied, mark it [needs source].

<style>
{{TWO_OR_THREE_PARAGRAPHS_OF_REAL_PUBLISHED_TEXT}}
</style>

<structure>
{{H2_OUTLINE_OR "propose one first and stop"}}
</structure>

USER:
<brief>
Audience: {{WHO}}
Purpose: {{WHAT_THEY_SHOULD_DO_OR_UNDERSTAND_AFTERWARDS}}
Length: {{WORD_COUNT}} words, plus or minus 10%
Must cover: {{NON_NEGOTIABLE_POINTS}}
Must not claim: {{THINGS_YOU_CANNOT_SUPPORT}}
</brief>

<source_material>
{{NOTES_QUOTES_DATA}}
</source_material>

Draft the piece.

The <style> block does the heavy lifting and should contain real published text, not a description of the voice you want. The [needs source] convention gives the model an alternative to inventing an attribution, which is the failure mode that matters most in drafting work. More writing-specific guidance is on using Claude as a writing assistant, and a library of shorter worked prompts is on the examples page.

#Prompts that waste money

Five patterns that cost real tokens for no benefit.

• High effort on trivial work. The default is high. On classification, routing and extraction, low or medium is usually indistinguishable and materially cheaper, because thinking tokens bill as output.
• Politeness padding. “Please take your time and think very carefully about this important task” adds tokens and changes nothing. Model behaviour is set by constraints, not by tone.
• A system prompt that changes every call. Prompt caching only fires on an identical prefix. Interpolating a timestamp or a user ID at the top of a system prompt destroys the cache — and cache reads cost 0.1× base input, so this is often the largest avoidable line on the bill.
• Prompts too short to cache at all. The minimum cacheable prompt is 512 tokens on Opus 5 and Fable 5, 1,024 on Sonnet 5 and Haiku 4.5. Below that, caching does nothing.
• Re-sending a whole document to ask a follow-up. Cache it once, or extract the structured facts in a first pass and query those instead.

The largest saving of all is usually a model swap rather than a prompt change: a well-specified prompt on Haiku 4.5 beats a vague one on Opus 5 at a fifth of the price. Per-token rates for every current model are on the pricing page, and the caching and batching mechanics are worked through on the Claude API page. If you are prompting in the apps rather than the API, most of this still applies — the exceptions are the API-only parameters, and the surface differences are covered on using claude.ai.

#Frequently asked questions