Quick answer: Zero-shot prompting asks the model to do a task with no examples, just instructions. Few-shot prompting includes a handful of worked examples in the prompt to show the model exactly what you want. Few-shot helps most when the task is unusual, the output format is strict, or the instructions alone are ambiguous. For clear tasks on capable models, zero-shot often works fine and costs less.
Deciding between them is one of the most common questions in day-to-day prompting, and the answer is not "always add examples." Let me break down when each wins.
The Core Difference
Both are ways of framing a request. The difference is whether you show or just tell.
Zero-shot gives instructions only:
Classify the sentiment of this review as positive, negative, or neutral.
Review: "The battery lasts forever but the screen scratches easily."
Sentiment:
Few-shot shows examples first, then the real input:
Classify the sentiment of each review as positive, negative, or neutral.
Review: "Best purchase I've made all year."
Sentiment: positive
Review: "It broke after two days. Waste of money."
Sentiment: negative
Review: "Does what it says. Nothing special."
Sentiment: neutral
Review: "The battery lasts forever but the screen scratches easily."
Sentiment:
The few-shot version demonstrates the exact labels, the exact format, and how to handle a mixed review. The model pattern-matches on those examples.
When Examples Help
Examples earn their token cost in specific situations.
| Situation | Why few-shot helps |
|---|---|
| Strict output format | Examples show the exact shape better than describing it |
| Unusual or domain-specific task | The model may not infer your intent from instructions alone |
| Ambiguous edge cases | Examples resolve "how do I handle X?" by demonstration |
| Consistent style needed | The model mimics the tone and structure of your examples |
| Subtle label definitions | "Neutral" means different things in different contexts; examples pin it down |
The common thread: few-shot helps when telling is not enough and showing removes ambiguity. If you cannot describe the task cleanly in words, examples often carry the meaning that instructions cannot.
When Zero-Shot Is Enough
On the flip side, examples are dead weight when:
- The task is common and well-understood (summarize this, translate that).
- The instructions are already unambiguous.
- The model is capable and follows instructions well.
- You are cost-sensitive, since every example is input tokens you pay for on every request.
Modern models are strong instruction-followers. Many tasks that needed few-shot examples a couple of years ago now work zero-shot. Reaching for examples reflexively can waste tokens and, in some cases, actually hurt by over-anchoring the model to your specific examples.
A Worked Before and After
Say you are extracting structured data and the zero-shot version keeps returning inconsistent formats.
Zero-shot (inconsistent results):
Extract the company name and funding amount from this text.
Text: "Northwind raised $12M in a Series A led by Acme Ventures."
The model might return prose, or JSON with different keys each time, or include the investor when you did not ask for it.
Few-shot (locked-down format):
Extract the company name and funding amount as JSON.
Text: "Bluefin closed a $5M seed round."
Output: {"company": "Bluefin", "amount_usd": 5000000}
Text: "Meridian secured 30 million dollars in Series B funding."
Output: {"company": "Meridian", "amount_usd": 30000000}
Text: "Northwind raised $12M in a Series A led by Acme Ventures."
Output:
Now the model knows the exact keys, that amounts should be normalized to a number, and that the investor is not part of the output. Two examples did what a paragraph of instructions struggled to.
How Many Examples to Use
More is not better. A few well-chosen examples usually beat many mediocre ones.
- Start with two or three. This is enough to establish format and handle the obvious cases.
- Add examples that cover edge cases, not more of the same. If the model already nails positive and negative reviews but fumbles mixed ones, add a mixed example, not another clearly-positive one.
- Stop when accuracy plateaus. Each example adds tokens (cost and context pressure). Past a handful, returns diminish fast.
How to Pick Good Examples
The quality of your examples matters more than the count.
- Make them correct. An example with a mistake teaches the model the mistake. This sounds obvious and is violated constantly.
- Cover the variety you expect. If real inputs are messy, include a messy example. Clean examples produce a model that breaks on real data.
- Match the real distribution. Do not use only easy cases if your production traffic is hard.
- Keep formatting identical. Every example should use the exact same structure you want the model to output. Inconsistency in your examples produces inconsistency in the output.
The Tradeoffs
Few-shot is not free.
- Tokens. Every example is input you pay for on every single request. For high-volume workloads this adds up. If you go this route, keep the examples tight, and read token optimization: feeding web data to LLMs for how to keep prompt bloat under control.
- Drift. Too many examples, or examples that are too similar, can over-anchor the model. It starts copying surface patterns from your examples instead of generalizing, which hurts on inputs that do not look like your examples.
- Maintenance. Examples are code. When your task changes, stale examples steer the model wrong.
Why Newer Models Need Fewer Examples
Here is a shift worth internalizing. As models get better at following instructions, the value of few-shot examples drops for many tasks.
Older models often needed examples to understand even straightforward requests. Newer models frequently handle those same requests zero-shot, because instruction-following improved. This means a prompt you wrote a while ago, stuffed with examples, may now perform just as well (and cheaper) with the examples removed.
The practical move: when you upgrade to a newer model, retest your few-shot prompts with the examples stripped out. You may find zero-shot now matches or beats your old few-shot setup at a fraction of the token cost. Do not assume yesterday's example count is still optimal.
A Simple Decision Rule
When you sit down to write a prompt, try this order:
- Write the clearest zero-shot instruction you can.
- Test it on real, varied inputs.
- If it fails on format or edge cases, add two or three targeted examples that fix exactly those failures.
- Stop adding examples the moment accuracy stops improving.
This gives you the reliability of few-shot without paying for examples you do not need. For the broader craft of writing effective prompts, see what is prompt engineering.
The Bottom Line
Zero-shot and few-shot are not a hierarchy where more examples are always better. They are tools for different jobs. Zero-shot is lean and often sufficient for clear tasks on capable models. Few-shot is your answer when a task is unusual, the format is strict, or instructions alone leave room for interpretation. Start zero-shot, add examples only to fix specific failures, and retest whenever you change models.
Building prompts that pull in live web data? link.sc gives your LLM one API to fetch and search the web in clean, model-ready formats. Start free.