Prompt Engineering Tips for the Claude API

Getting good results from the Claude API is less about clever tricks and more about giving the model clear structure, unambiguous instructions, and enough context to do the job correctly on the first try. If your outputs are inconsistent, too verbose, or ignore formatting instructions, the fix is almost always in how the prompt is organized — not in swapping models or adding retries.

This article covers concrete, testable techniques you can apply directly to messages calls: system prompt design, XML tagging, few-shot examples, prefilling responses, and controlling output format for downstream parsing.

Separate instructions from content with a system prompt

Claude responds well to a clear split between "how you should behave" (system prompt) and "what you're working on" (user message). Cramming both into one block of text makes it harder for the model to distinguish persistent rules from task-specific data.

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-sonnet-4-5",
    "max_tokens": 500,
    "system": "You are a support ticket classifier. Respond only with valid JSON matching the schema: {\"category\": string, \"priority\": \"low\"|\"medium\"|\"high\"}. Do not include any other text.",
    "messages": [
      {"role": "user", "content": "My invoice charged me twice this month."}
    ]
  }'

Put stable rules — role, output format, constraints — in the system prompt. Put the variable data — the actual ticket, document, or query — in the user message. This alone fixes a large share of "the model ignored my formatting instructions" complaints.

Use XML tags to separate sections

Claude is trained to pay close attention to XML-style tags, and they're a reliable way to mark boundaries between instructions, reference material, and examples without ambiguity.

<document>
{{long_text}}
</document>

<question>
What was the total revenue mentioned in the document?
</question>

Answer using only information inside <document>. If the answer isn't there, say "not found".

This matters most with long inputs: contracts, transcripts, logs. Tags make it explicit which text is source material to quote from versus which text is the instruction to follow, which reduces the model blending the two.

Show, don't just tell — use few-shot examples

For tasks with a specific output format (classification labels, a particular JSON shape, a house writing style), two or three examples usually outperform a longer written description of the rules.

Classify the sentiment as positive, negative, or neutral.

Text: "Shipping was fast and the product works great."
Sentiment: positive

Text: "It arrived broken and support never replied."
Sentiment: negative

Text: "It's fine, does what it says."
Sentiment: neutral

Text: "{{new_input}}"
Sentiment:

Keep examples diverse — cover edge cases, not just the easy ones — and keep the format identical across all of them. Inconsistent formatting in your examples is a common source of inconsistent output from the model.

Prefill the response to lock in format

You can seed the start of Claude's reply using an assistant message. This is one of the most underused techniques for forcing structured output without extra parsing logic.

{
  "messages": [
    {"role": "user", "content": "Extract the name and email from: John Doe, john@example.com"},
    {"role": "assistant", "content": "{"}
  ]
}

Starting the assistant turn with { makes it far more likely the entire response is a clean JSON object rather than JSON wrapped in explanation text. This works well combined with stop_sequences if you want to cut off the response right after a closing brace or delimiter.

Give the model room to think before answering

For tasks involving reasoning, comparison, or multi-step logic, instructing Claude to work through the problem before giving a final answer usually improves accuracy — especially compared to demanding the answer immediately.

First, list the relevant facts from the input.
Then reason step by step about which option is correct.
Finally, output your answer on its own line starting with "ANSWER:".

If you need machine-parseable output but still want reasoning, ask for the reasoning inside one tag and the final answer inside another (<reasoning>...</reasoning><answer>...</answer>), then parse only the <answer> block downstream.

Be explicit about what "done" looks like

Vague instructions like "summarize this" produce inconsistent length and structure across runs. Specify constraints directly: word count, number of bullet points, required fields, tone, what to exclude.

Summarize the article in exactly 3 bullet points.
Each bullet must be under 20 words.
Do not include names of people, only the events.

The more precisely you define the acceptable output space, the less variance you get across requests — which matters a lot once you're running the same prompt at scale in production.

Iterate with real inputs, not just one example

A prompt that works on your first test case can fail on the fifth. Before shipping a prompt into production, run it against a handful of realistic and edge-case inputs — the shortest input you expect, the longest, the one with weird formatting — and adjust based on where it breaks. Version your prompts like you version code, and change one variable at a time so you know what actually caused an improvement or regression.

Where this fits with the API layer

Prompt engineering controls quality; the API layer controls how that quality gets delivered to your product. If you're already calling the Claude API directly and want to expose it internally as a stable HTTPS service — with your own application keys, streaming, and usage visibility per key — SubToAPI turns your existing Claude access into an API your team or app can call without managing raw provider credentials. See the quickstart or the messages endpoint docs for the request shape, which mirrors the examples above.

questions

Do system prompts actually change output quality, or just formatting? Both. A well-scoped system prompt reduces off-topic responses and enforces format, but it also narrows the model's interpretation of ambiguous requests, which improves substantive accuracy on classification and extraction tasks.

How many few-shot examples should I use? Start with two or three covering distinct cases. More examples help with tricky formatting but add latency and token cost — test whether the third or fourth example actually changes output before keeping it.

Should I use XML tags even for short prompts? For short, single-purpose prompts it's optional. For anything involving long reference text, multiple sections, or examples mixed with instructions, tags reliably reduce ambiguity and are worth the small overhead.