"Few-shot prompting" (also called multishot) is the practice of including worked examples in your prompt: here's an input, here's exactly the output we want, now do the same for the real input. It sounds almost too simple to be a technique, but it's one of the most reliable levers in Anthropic's official prompting guidance — and one of the easiest to get subtly wrong.
What examples do that instructions don't
Instructions describe the target; examples are the target. An instruction like "summarize the ticket in a professional tone with a category label" leaves open a dozen small decisions: how long, label before or after, what counts as professional, what to do with profanity in the source. A single example answers all of them at once, unambiguously. Examples are especially strong at conveying things that are hard to verbalize — rhythm, level of hedging, how much detail to keep — which is why they pair so well with tone and style control.
The official recipe
Anthropic's best-practices documentation gives specific, concrete guidance:
- Include 3–5 examples for best results. More rarely helps; past a point you're paying tokens for repetition.
- Make them relevant — examples should look like the real inputs your system will see, not idealized textbook cases.
- Make them diverse — cover the shapes of input that matter: a normal case, a messy case, an edge case where the right answer is "flag for a human." Five near-identical examples teach less than three varied ones.
- Wrap them in tags — each pair inside an
<example>tag, the set inside<examples>, so Claude can cleanly separate demonstration from instruction. See XML structuring.
Choosing examples like an engineer
The examples that earn their place are usually the ones that disambiguate. Before adding one, ask what decision it settles that the instructions leave open. Good candidates: an input where two output categories are plausible (show which one wins), an input containing irrelevant content (show it being ignored), and an input that should be refused or escalated (show the refusal format). If an example doesn't settle anything, cut it.
One caution: examples constrain as well as teach. If every example shows a three-sentence summary, Claude will produce three-sentence summaries even for inputs that deserve ten. When variable-length output matters, either include examples of different lengths or state explicitly that length should track the input.
Paying for examples once, not every time
Examples add input tokens on every request, but prompt caching largely neutralizes the cost. Keep the example block static, place it with the system prompt before any per-request content, and mark the boundary with cache_control: cached reads are billed at one-tenth of the base input price, and caching works on all four third-party platforms (on Amazon Bedrock, via explicit breakpoints only). The trap to avoid is dynamically selecting or reordering examples per request — caching is a strict byte-level prefix match, so a rotating example set silently pays full price every time.
from anthropic import AnthropicVertex
client = AnthropicVertex(project_id="my-proj", region="global")
resp = client.messages.create(
model="claude-sonnet-5",
max_tokens=1024,
system=[{
"type": "text",
"text": RULES + "\n\n" + STATIC_EXAMPLES + "\n ",
"cache_control": {"type": "ephemeral"},
}],
messages=[{"role": "user", "content": ticket_text}],
)When to skip examples entirely
Not every task needs demonstration. For tasks Claude already does well from instructions alone — straightforward Q&A, well-specified extraction — examples add cost without lift, and rigid JSON structure is better enforced by structured outputs than by demonstration. The decision framework is the subject of zero-shot vs. few-shot.
Where to go next
Measure whether your examples actually help with prompt A/B testing, and see the quickstart if you're setting up your first calls.