Most articles on few-shot prompting will tell you that examples help and that you should use them. Almost none will give you a number, which is the only thing you actually wanted.
So: two to five. Below two the model has nothing to generalise from. Above five the improvement flattens while the cost keeps climbing. If you take nothing else, take three and move on.
The rest of this is when to deviate from that, and what to do with the examples once you have chosen how many.
Zero, one, few, in one table
| Approach | What it looks like | Use when |
|---|---|---|
| Zero-shot | Instruction only. “Classify the sentiment of this review.” | The task is common, the output is obvious, and the format is simple. |
| One-shot | One input/output pair before the real input. | You need to demonstrate a format and nothing more. Risky: one example is a template, and the model will copy it closely. |
| Few-shot | Two to five pairs covering different cases. | The task has edge cases, a house style, or an output shape that is hard to describe in words. |
| Many-shot | Dozens or hundreds of pairs. | Rarely worth it in a prompt. At that volume you are describing a training set, not a prompt. |
Where the number comes from
The gain from examples is steep and then it is not. The first example teaches the format. The second tells the model the first was not a one-off, and that the pattern generalises. The third establishes the boundaries of the category. By the fifth, most of what an example can teach has been taught, and each additional pair mostly adds tokens.
This shape holds across the published guidance from the major providers and the standard prompting references, which converge on the same small range rather than on “more is better”.
There is a second reason to stop early that has nothing to do with diminishing returns. Every example is sent on every call. Ten examples of 60 tokens each is 600 tokens attached to every single request, forever. At any real volume that is a recurring bill for a benefit you stopped receiving around example four.
Quality beats count
Three well-chosen examples outperform ten similar ones, reliably. The reason is that examples do not teach the task so much as define its edges, and similar examples define nothing.
If all three of your examples are clear-cut positives, you have taught the model that this task involves clear-cut positives. The ambiguous case will be forced into that mould.
Pick examples that disagree with each other:
// Weak - three of the same thing
"Terrible product" -> negative
"Awful, waste of money" -> negative
"Really bad experience" -> negative
// Strong - three that map the space
"The battery dies in 2 hours." -> {"issue":"battery","sentiment":"neg"}
"Fast shipping, screen arrived cracked." -> {"issue":"damage","sentiment":"mixed"}
"Works fine." -> {"issue":null,"sentiment":"pos"}The second set does four things the first cannot. It shows a mixed case, so mixed is available as an answer. It shows a null value, so the model knows the field can be empty rather than guessing a category. It shows a terse input getting a terse treatment. And it demonstrates the exact JSON shape, which is worth more than any sentence describing it.
A useful test: if you can delete one example and the remaining ones still cover the same ground, it was not earning its tokens.
How many, by task
| Task | Examples | What they need to cover |
|---|---|---|
| Classification, small label set | 1 per label, up to 5 | One clean case per class, plus the boundary between the two that get confused. |
| Structured extraction | 3–4 | A full record, a record with a missing field, an edge value, an input that yields nothing. |
| Format conversion | 2 | A typical case and an awkward one. Format is easy to demonstrate. |
| Tone and style matching | 3–5 | The style is the hard part. More examples genuinely help here. |
| Summarisation | 1–2 | Mostly to fix length and register. More examples bias the content. |
| Reasoning tasks | 0–2 | Current models rarely need them. Test zero-shot first. |
Structured extraction is the case where examples pay off most dramatically. Describing a JSON schema in prose is possible; showing three filled-in records is unambiguous. This is why few-shot is usually the first fix when structured output is unreliable, as covered in how to get clean JSON out of an AI model every time.
Where the examples belong
If your examples are the same on every call, they go in the system prompt. They are constant, they sit in a stable prefix, and on platforms with prompt caching that prefix can be billed at a fraction of the normal rate after the first call.
If you select examples per request, retrieving the three most similar past cases, they go in the user turn because they change. You lose the caching benefit and gain relevance, which is usually the right trade for hard tasks and the wrong one for simple ones. The full split is in system prompt vs user prompt: what goes where.
Either way, mark the boundary clearly. Examples that run into the real input without a visible break invite the model to treat your last example as part of the question.
Building the set in fifteen minutes
A procedure that works better than picking examples by feel.
- Collect twenty real inputs. Not curated ones. Whatever actually arrives, typos included.
- Write the correct output for each by hand. Tedious, and it is where you discover your own spec is ambiguous. If you cannot decide what the right answer is for input eleven, the model has no chance.
- Sort them into groups by what makes them different. Usually you find three or four clusters and a couple of oddities.
- Take one from each cluster, plus the oddity that worries you most. That is your example set, and it will usually land between three and five without you aiming for it.
- Keep the other fifteen as your test set. They are now doing double duty: they built the prompt and they will catch the next change that breaks it.
Step five is the one people skip and later wish they had not. The inputs you did not use as examples are the most honest test you will ever have, because the prompt has never seen them.
What this looks like in practice
An invoice extraction prompt, zero-shot, against fifty real invoices:
| Setup | Typical result |
|---|---|
| Zero-shot, schema described in prose | Fields mostly correct. Date formats inconsistent. Missing values sometimes omitted, sometimes filled with “N/A”, sometimes with an empty string. |
| One example added | Format now consistent. Everything shaped like the example. Invoices unlike it handled poorly. |
| Three varied examples | Format consistent, missing values handled the same way every time, unusual layouts survive. |
| Eight examples | Indistinguishable from three, at roughly triple the prompt cost. |
The jump from one to three is where the value sits, and it comes entirely from the examples being different from each other. The one-example version is not undertrained; it is overfitted to a single shape. Adding two more that disagree with it is what turns a template into a specification.
When examples beat an instruction
Some things are far cheaper to show than to describe.
- Output shape. Two hundred words describing a nested structure, or one example of it.
- Tone. “Professional but warm, not stiff” means something different to everyone. Three sentences in the voice you want does not.
- Edge cases. “If there is no data, return null” is often ignored. An example where the answer is null is not.
- Length calibration. “Be concise” is relative. An example that is eleven words long is absolute.
When examples hurt
Three failure modes, all common enough to watch for.
Overfitting to the surface. If every example input is a single short sentence, a three-paragraph input may get treated as if it were one sentence. Vary the shape of your inputs, not just their content.
Recency bias. The last example carries more weight than the first. If your final example is unusual, expect that flavour to leak into the answers. Put the most representative case last.
Label imbalance. Four positive examples and one negative teaches the model that positives are four times more likely, and it will lean that way on genuinely ambiguous inputs. Balance the examples unless the imbalance is real and intentional.
All three are invisible if you test by hand on two inputs. They show up when you run a fixed set of cases, which is the argument for testing a prompt before it reaches real users.
Frequently asked questions
How many examples is too many?
Past five you are usually paying for tokens rather than accuracy. The exception is style matching, where the pattern is genuinely hard to convey and a few more can help. If you are past ten, the question is not how many examples but whether the task needs fine-tuning instead.
Should the examples go in the system prompt or the user prompt?
System prompt if they are fixed, because they are constant and cacheable. User prompt if you select them per request based on the input. Fixed examples in the user turn is the worst of both: no caching benefit, no relevance benefit.
Do the examples need to be real data?
They need to be realistic, not real. Invented examples that reflect actual input shapes work fine, and avoid putting customer data into a prompt that lives in your codebase. What matters is that the messiness is representative: real inputs have typos, missing fields and odd lengths, and examples that are all tidy will not prepare the model for that.
Why does the model copy my last example too closely?
Recency. The nearest example to the actual question exerts the strongest pull. If it is atypical, that shows up in the answers. Reorder so the most representative example is last, and check whether your examples are varied enough that any of them could sit in that position.
Is few-shot still needed with reasoning models?
Less often for the reasoning itself, and just as much for format and style. Newer models are better at working out what you want and no better at guessing the exact JSON keys you have in mind. Test zero-shot first; add examples for the parts that come back wrong.
The shift that makes it click
Stop thinking of examples as encouragement and start thinking of them as a specification written in a different notation. Three examples that disagree with each other define a task more precisely than three paragraphs of description, because they show the boundaries rather than asserting them.
Choose them the way you would choose test cases: not the three that are easiest to write, but the three that would catch the most mistakes.
The AI Prompt Engineering Mini-Course works through building an example set one exercise at a time, and the 7 Mistakes listicle covers the example-selection errors that cost the most.