Few-Shot Prompting

Showing beats describing

Describing an output format takes a paragraph and still leaves room for interpretation. Showing two of them takes less space and leaves almost none.

Anthropic puts examples near the top of what works:

Examples are one of the most reliable ways to steer Claude's output format, tone, and structure. A few well-crafted examples (known as few-shot or multishot prompting) improve accuracy and consistency.

The names are interchangeable. Few-shot, multishot, and "just put some examples in" are the same technique. Zero-shot is the same prompt without them.

How many

Anthropic's guidance is specific: include 3–5 examples for best results.

That range is worth respecting from both directions. One example is a pattern the model may read too literally, copying incidental details. Twenty examples cost tokens on every request, and tokens spent on examples are tokens not spent on the actual input, which the context window has a fixed amount of.

Three properties that decide whether they help

The documentation names them, and each has a failure mode behind it.

Relevant. Mirror your actual use case closely. Examples drawn from a tutorial teach the model to answer tutorial questions.

Diverse. Cover edge cases, and vary enough that the model does not pick up unintended patterns. This is the one that quietly goes wrong. If all four of your examples happen to be short, you have taught the model to be short. If all four resolve in the customer's favour, you have taught it to say yes. The pattern you did not intend to teach is still a pattern, and it is the mechanism behind the skew bias and fairness describes as introduced by your own system.

Structured. Wrap examples in <example> tags, and multiple examples in <examples> tags, so they can be told apart from instructions. Without a boundary, a long example reads as more prompt.

<examples>
  <example>
    <input>My order hasn't arrived and it's been two weeks.</input>
    <output>{"category": "shipping", "urgency": "high", "refund_eligible": true}</output>
  </example>
  <example>
    <input>How do I change the email on my account?</input>
    <output>{"category": "account", "urgency": "low", "refund_eligible": false}</output>
  </example>
</examples>

Where examples earn their tokens, and where they do not

Worth it when the output has a shape you care about: a classification into your own categories, a tone that matches your product, a structure with conventions a schema cannot express. Examples are the cheapest way to convey a house style.

Not worth it when a schema already does the job. If what you need is valid JSON with three known fields, structured output enforces that and examples only suggest it. Use examples for the parts of the output a schema cannot describe: which category is right, how long an answer should be, what register to write in.

Actively harmful when they are stale. Examples are part of the prompt and they age like the rest of it. An example showing a field you renamed teaches the old name on every request until somebody notices.

The cost is per request, forever

Examples are input tokens. Three good examples might be 400 tokens, and you pay for them on every call whether or not they change the answer.

That makes them a strong candidate for the cached prefix. They are stable by nature, they sit near the front, and prompt caching charges a fraction to read a prefix back. Putting your examples above the variable part of the prompt and marking the boundary is usually the difference between examples being free and examples being a line on the bill.

It also means examples should be reviewed like code. A set nobody has looked at in six months is a set nobody knows the model is still learning from.

Further reading

• Anthropic, Prompting best practices: the 3–5 range, and the relevant / diverse / structured properties.
• Prompt engineering: where examples sit among the other techniques.
• Structured output: what a schema enforces so your examples do not have to.
• Prompt caching: making a stable example block cost a tenth of what it otherwise would.