Zero-shot prompting gives a model instructions with no examples; few-shot prompting adds a handful of worked input/output examples so the model can copy the pattern. Start with zero-shot for common, well-defined tasks, and switch to few-shot when the output format must be exact, the labels or tone are specific to you, or zero-shot results are inconsistent. Anthropic’s documentation suggests three to five examples, and they should be relevant, varied and clearly separated from the instructions.
Below you will find a side-by-side comparison, one task prompted both ways, a test you can run to decide which one your task needs, and the mistakes that make examples backfire.
Definitions
Zero-shot prompting describes the task in words only. “Summarize this article in three bullet points” is zero-shot: the model relies on what it already learned about summaries and bullet points.
Few-shot prompting (Anthropic also calls it multishot prompting) includes several example inputs paired with the outputs you want, followed by the real input. One-shot is the special case with a single example. The model’s weights do not change; it picks up the pattern from the prompt itself, which is why this is also called in-context learning. The term became widely known through the 2020 GPT-3 paper, Language Models are Few-Shot Learners, which applied the model to tasks with demonstrations given only as text and no fine-tuning.
Zero-shot vs. few-shot at a glance
| Zero-shot | Few-shot | |
|---|---|---|
| What you provide | Instructions only | Instructions plus example input/output pairs |
| Effort to write | Low | Higher: examples must be chosen and maintained |
| Prompt length and cost | Shorter | Longer on every request (examples are re-sent each time unless cached) |
| Best for | Common tasks the model already does well: general writing, brainstorming, explanation, simple Q&A | Exact formats, house style or brand voice, custom labels, fuzzy category boundaries, unusual output structures |
| Main risk | Output format and judgment calls drift between runs | Model copies surface details of the examples (length, wording, topic) |
| Easiest to change | Edit a sentence | Edit or swap examples, then re-test |
Neither is “more advanced”. Current models follow instructions well, so many tasks that once needed examples now work zero-shot. Examples still win when it is easier to show what you want than to describe it.
One task, prompted both ways
Consider an illustrative task: classifying incoming support tickets for an internal platform team into four queues and an urgency level. The categories are specific to this team, and the boundary between “access” and “outage” is fuzzy.
Zero-shot version
Classify the support ticket below.
Categories:
- access: login, permissions, SSO, API keys
- outage: a service is down or failing for multiple users
- request: new resources, quota increases, configuration changes
- question: how-to questions with nothing broken
Urgency: P1 (production impact now), P2 (degraded or blocking one team),
P3 (everything else).
Return one line in the format: category | urgency | reason (max 12 words)
<ticket>
{{TICKET_TEXT}}
</ticket>This is a solid starting point: categories are defined, urgency is defined, and the format is explicit. For clear-cut tickets it will often be enough. Where it tends to wobble is the borderline case, such as “SSO is failing for everyone in the finance team”. Is that access or outage? P1 or P2? The definitions do not decide it, so the model decides, and it may decide differently on similar tickets.
Few-shot version
Classify the support ticket in <ticket> using the categories and urgency
levels below. The examples show how our team handles borderline cases.
Categories: access, outage, request, question (definitions as above)
Urgency: P1, P2, P3 (definitions as above)
Format: category | urgency | reason (max 12 words)
<examples>
<example>
<input>SSO login fails for every user in the finance team since 09:10.</input>
<output>outage | P2 | Identity service failing for a whole team, not one user</output>
</example>
<example>
<input>My API key returns 403 after I rotated it this morning.</input>
<output>access | P3 | Single user credential issue after rotation</output>
</example>
<example>
<input>Checkout service is returning 500s for customers. Revenue impact.</input>
<output>outage | P1 | Customer-facing production failure</output>
</example>
<example>
<input>Can we raise the vCPU quota in the staging subscription to 64?</input>
<output>request | P3 | Quota increase in non-production</output>
</example>
</examples>
<ticket>
{{TICKET_TEXT}}
</ticket>What the examples add, line by line:
- Example 1 settles the fuzzy boundary: a login failure affecting a whole team counts as an outage, and internal-only impact is P2, not P1. That is a team policy no model could guess.
- Example 2 shows the contrast case, so the model learns that one user’s credential problem stays in “access”.
- Example 3 anchors what P1 means in practice: customer-facing and production.
- Example 4 covers a different category so the set does not imply every ticket is about failures.
- Tags (
<example>,<input>,<output>) keep the examples separate from the real ticket. Anthropic’s prompting best practices recommend exactly this, so the model can tell examples apart from instructions.
Notice that the instructions stayed. Few-shot works best as instructions plus examples, not examples instead of instructions. For a fuller version of this use case, see AI prompts for triaging support tickets.
How to decide: a five-step test
The reliable way to choose is to try zero-shot first on real inputs and add examples only where it fails. This sequence keeps the prompt as short as the task allows.
- Collect 15 to 30 real inputs, including the awkward ones. Write down the output you would accept for each.
- Run the zero-shot prompt on all of them and mark each result right or wrong.
- Look at the failures and group them. If they share a cause you can describe in a sentence (“it treats team-wide login failures as access”), add that sentence to the instructions and re-run. Many problems end here.
- If failures remain and are hard to describe in words (tone, a judgment call, a format with many small rules), add examples that cover exactly those cases.
- Re-run the whole set, not just the failures, because new examples can break cases that were working.
Keep the test set for later. When you change models or edit the examples, re-running the same inputs tells you whether anything regressed.
How many examples, and which ones
Anthropic’s guidance is three to five examples for best results, with three properties: relevant (mirroring your real use case), diverse (covering edge cases and varying enough that the model does not learn unintended patterns), and structured (wrapped in tags). OpenAI’s prompt engineering guide similarly advises showing a diverse range of inputs with the desired outputs, and suggests placing examples in their own section of the developer message.
Research helps explain what examples actually teach. A 2022 study, Rethinking the Role of Demonstrations, found that on classification and multiple-choice tasks, randomly replacing the correct labels in the examples barely hurt performance. What mattered more was that the examples showed the label space, the kind of input text to expect, and the format. The practical takeaway is not that labels are irrelevant (your examples should still be correct), but that format and coverage carry much of the weight. Choose examples to show the shape of the task and its boundaries.
A useful selection checklist:
- At least one example per category or output type that matters.
- At least one borderline case, with the answer your team would actually give.
- Varied length and wording in the inputs, so the model does not tie a category to a phrase.
- Outputs in exactly the format you want back, including punctuation and capitalization.
- No real customer data or secrets: examples are sent with every request and may end up in logs.
Mistakes that make few-shot worse than zero-shot
Examples are a strong signal, and a strong signal pointing the wrong way does damage. These are the usual causes:
- Copying surface details. If every example output is two sentences long, outputs will be two sentences even when the input needs more. If all example emails are about invoices, the model may drift toward invoice language. Vary everything you do not want copied.
- Skewed label balance. Four “P3” examples and one “P1” can nudge borderline cases toward P3. Balance categories, or at least avoid an accidental majority.
- Examples that contradict the instructions. If the instructions say “max 12 words” and an example reason has 20, the model has to pick one. Check examples against your own rules.
- Examples that are too easy. Showing only obvious cases teaches nothing the instructions did not already say. Spend examples on the hard calls.
- Too many examples. Past a handful, each additional one costs tokens on every call and gives the model more surface details to latch onto. Add more only when testing shows it helps.
- Stale examples. When categories or policies change, old examples quietly keep teaching the old rule. Treat them as part of the prompt’s version history.
Few-shot with reasoning models and chain-of-thought
Models that reason before answering change the trade-off somewhat. OpenAI’s guide says reasoning models do better with high-level direction, while its faster GPT models benefit from more explicit instructions, so a reasoning model may need fewer examples to get a judgment task right. Examples are still useful for pinning down output format.
Anthropic notes that examples also work with extended or adaptive thinking: worked examples shape how Claude approaches similar problems in its own reasoning, and it suggests presenting each as a problem, the method to apply, and the expected answer. That is the few-shot form of chain-of-thought prompting. There is also a zero-shot form, where you simply ask the model to reason through the problem before answering, with no examples at all.
Combining both in one prompt
Most production prompts are hybrids. A practical layout is: role and goal, then rules written as instructions, then a short examples section covering only the cases the rules did not settle, then the input. You can also give an example for one part of the output (say, the exact JSON shape) while leaving the content judgment zero-shot. If you use a system prompt, stable examples often fit there, and with long example sets, prompt caching can reduce the cost of re-sending them; see prompt caching explained.
Few-shot prompting vs. fine-tuning
Few-shot prompting teaches by example at request time and changes nothing permanently; fine-tuning trains on many examples and updates the model’s weights. Few-shot is faster to try and to change, needs no training pipeline, and works with any model you can prompt. Fine-tuning makes sense when you have hundreds or more high-quality examples, a stable task and enough volume that a shorter prompt saves real money. The trade-offs, including where retrieval fits, are covered in fine-tuning vs. prompting and RAG.
