Claude API Few-Shot Prompting Examples That Work
Few-shot prompting means showing Claude a handful of input/output examples before asking it to handle a new case. Instead of describing the task in the abstract, you demonstrate it — and Claude pattern-matches the format, tone, and reasoning style from your examples rather than guessing at your intent.
This matters most when you need consistent structure (a specific JSON shape, a fixed label set, a particular writing voice) that's hard to pin down with instructions alone. Below are working examples you can adapt directly, plus the message structure that makes them effective in the Claude API.
How few-shot examples fit into the message structure
Claude's API takes a messages array of alternating user and assistant turns. The most reliable way to do few-shot prompting is to encode each example as a user/assistant pair, then end with the real input as the final user message:
{
"model": "claude-sonnet-4-5",
"max_tokens": 200,
"messages": [
{"role": "user", "content": "Classify sentiment: 'This laptop is amazing, best purchase ever.'"},
{"role": "assistant", "content": "positive"},
{"role": "user", "content": "Classify sentiment: 'The screen cracked after one week.'"},
{"role": "assistant", "content": "negative"},
{"role": "user", "content": "Classify sentiment: 'It works, nothing special.'"},
{"role": "assistant", "content": "neutral"},
{"role": "user", "content": "Classify sentiment: 'Shipping took forever but the product itself is solid.'"}
]
}This works better than cramming all examples into a single string in one user message, because the alternating turns mirror a real conversation and Claude treats each assistant reply as the exact target output — no ambiguity about where the example ends and the instruction begins.
If you're testing this against your own Claude access, you can send the same structure through SubToAPI's endpoint (see /docs/messages):
curl https://api.subtoapi.app/v1/messages \
-H "Authorization: Bearer $SUBTOAPI_KEY" \
-H "content-type: application/json" \
-d '{
"model": "claude-sonnet-4-5",
"max_tokens": 200,
"messages": [
{"role": "user", "content": "Classify sentiment: \"This laptop is amazing.\""},
{"role": "assistant", "content": "positive"},
{"role": "user", "content": "Classify sentiment: \"It works, nothing special.\""}
]
}'Example: structured data extraction
Few-shot prompting is especially good at locking in a JSON schema without writing a formal schema definition:
{
"messages": [
{"role": "user", "content": "Extract name, role, company from: 'Jane Lin, VP of Engineering at Acme Corp, spoke at the summit.'"},
{"role": "assistant", "content": "{\"name\": \"Jane Lin\", \"role\": \"VP of Engineering\", \"company\": \"Acme Corp\"}"},
{"role": "user", "content": "Extract name, role, company from: 'We heard from Marcus Webb, our new CTO, on stage yesterday.'"},
{"role": "assistant", "content": "{\"name\": \"Marcus Webb\", \"role\": \"CTO\", \"company\": null}"},
{"role": "user", "content": "Extract name, role, company from: 'Sara Ito, lead designer at Northwind, presented the mockups.'"}
]
}Note the second example deliberately includes a missing field (company: null). Showing Claude how to handle incomplete input is often more useful than showing three "perfect" examples — it teaches the edge case, not just the happy path.
Example: matching a specific tone or voice
For content generation, few-shot examples transfer voice better than adjectives like "friendly" or "professional":
{
"messages": [
{"role": "user", "content": "Write a one-line changelog entry for: fixed a bug where exports failed on large files."},
{"role": "assistant", "content": "Fixed: large file exports no longer time out. You're welcome."},
{"role": "user", "content": "Write a one-line changelog entry for: added dark mode."},
{"role": "assistant", "content": "Added: dark mode. Your retinas thank us."},
{"role": "user", "content": "Write a one-line changelog entry for: improved search result ranking."}
]
}Claude will infer the wry, casual tone from the pattern rather than from an instruction, and it generalizes to inputs you didn't demonstrate.
Example: multi-step reasoning format
If you want consistent chain-of-thought formatting (for audits or debugging), demonstrate the exact structure you want reasoning to follow:
{
"messages": [
{"role": "user", "content": "Should we approve a refund for order #1042 (item damaged in transit, within 30-day window)?"},
{"role": "assistant", "content": "Reasoning: Item damaged in transit → covered by policy. Within 30-day window → eligible.\nDecision: Approve."},
{"role": "user", "content": "Should we approve a refund for order #2091 (customer changed mind, 45 days since delivery)?"},
{"role": "assistant", "content": "Reasoning: Change of mind → covered only within window. 45 days exceeds 30-day limit → not eligible.\nDecision: Deny."},
{"role": "user", "content": "Should we approve a refund for order #3310 (wrong item shipped, 10 days since delivery)?"}
]
}This keeps outputs auditable and machine-parseable without a rigid schema, which is useful when you're logging decisions downstream.
Practical tips for tuning few-shot prompts
- Use 2–5 examples. Below 2 there's often not enough signal; beyond 5–6 you're usually burning tokens without meaningfully improving quality. Test with your actual data.
- Cover edge cases, not just typical cases. One example with missing data, ambiguity, or an unusual format teaches Claude more than three clean examples.
- Keep the output format identical across examples. Inconsistent formatting in your examples (extra whitespace, different key ordering) leaks into Claude's output.
- Put the most similar example last, if your examples vary in relevance to different input types — recency in the context window has a mild influence on output style.
- Combine with a system prompt for constraints, and few-shot for pattern. Use the system prompt to state hard rules ("never invent phone numbers"); use examples to show format and tone. See /docs/quickstart for how system prompts and messages interact.
- Measure token cost. Each example adds to every request's input tokens. If you're running this at volume, check usage metadata per request — SubToAPI surfaces token counts per call in the dashboard so you can see whether your few-shot prompt is worth its overhead (details in /docs).
When few-shot isn't the right tool
If the task is genuinely simple (translate this sentence, summarize this paragraph), zero-shot with a clear instruction usually performs the same as few-shot and costs fewer tokens. Few-shot earns its keep when the output format is non-obvious, the domain has quirky edge cases, or you need consistency across thousands of calls where instruction-only prompts drift.
questions
How many examples should I include in a few-shot prompt for Claude? Start with 2–3 and add more only if outputs are inconsistent. Diminishing returns set in fast — 4–5 well-chosen examples usually outperform 10 similar ones, and each example adds input tokens to every request.
Should few-shot examples go in the system prompt or the messages array? Put them in the messages array as alternating user/assistant turns — this is more reliable than a single block of text in the system prompt, because Claude treats each assistant turn as a literal example of the target output.
Does few-shot prompting increase API costs? Yes — every example is counted as input tokens on each request. If you're calling the same few-shot prompt repeatedly, check per-request token usage (available via /docs/messages or your SubToAPI dashboard) to confirm the quality gain is worth the extra tokens.