How Many Examples Does a Prompt Need?

Three to five, in most cases. But the count is the least interesting part of the answer, because two well-chosen examples routinely beat eight similar ones. How many examples a prompt needs depends almost entirely on how much of the problem's variety those examples cover.

Here is how to pick them, and how to find out when you have enough.

How many examples does a prompt need for your task?

There is no universal number, but there is a reliable way to find yours, and a reliable way to choose well before you count. Start with why the count matters less than you would expect.

Why more examples stop helping

Examples teach by demonstrating a mapping from input to output. The first example establishes the shape. The second establishes which parts of the first were essential and which were incidental. The third usually settles the edge the first two disagreed on. After that, each additional example is mostly repeating a lesson already learned, while adding tokens, cost, and latency.

Worse, a run of similar examples actively narrows the model. Feed it five short, friendly customer replies and it will write a short, friendly reply to the furious one too. The examples became the whole world.

Choose for coverage, not for quantity

Lay out the ways your inputs actually vary, then pick one example per axis. For a support-ticket classifier, the axes might be:

Four examples, four distinct lessons, no redundancy. Compare that with eight clear billing questions, which teach one lesson eight times and quietly tell the model that everything is billing.

The single most valuable example is almost always the fourth row: the case the model currently gets wrong. If you have a failure you can reproduce, that failure is your best example, because it is the only one carrying information the model does not already have.

Include a negative, carefully

One example of an output you do not want, clearly labelled, is often worth two positive ones. It has to be labelled, or you have just demonstrated the thing you are trying to prevent. The mechanics are in prompt AI with an example of what you don't want.

Good output:
{"category": "billing", "urgency": "low"}

Bad output, do not produce this:
{"category": "billing and maybe technical", "urgency": "medium-ish"}
Reason it is bad: category must be a single value; urgency must be one of low, medium, high.

Find your number with an add-one test

You do not have to guess. The test takes about twenty minutes and it is the only way to get an answer specific to your task.

1. Build a check set of 15 to 20 real inputs with known correct outputs. Real ones, from your actual data. Invented inputs are too tidy and will tell you the prompt works when it does not.

2. Run the prompt with zero examples. Score it. This is your baseline and sometimes it is already fine.

3. Add one example. Re-run the whole check set. Score it again.

4. Keep adding one at a time, scoring the full set each time.

5. Stop when two consecutive additions do not improve the score. Drop back to the last count that did.

Score the same way every round, or the test means nothing. The scoring discipline, including how to avoid grading your own homework generously, is in how to prompt AI to grade work against a rubric. The broader version of this method is how to test whether a prompt change improved output.

Most teams running this honestly land between three and five. Some land at one. A few, usually with genuinely strange output formats, keep improving to eight or nine.

When zero examples is the right answer

If the task is common, the output is prose, and the format is unremarkable, examples add cost and nothing else. Summarise this, translate that, rewrite this more plainly: these need instructions, not demonstrations. The decision between the two modes is covered in few-shot vs zero-shot prompting.

Examples earn their tokens when the output format is specific, when your house conventions differ from the obvious default, or when there is a judgement call the model keeps getting wrong. Otherwise, describe and move on.

Watch the cost

Examples sit in the prompt on every single call. Five examples at 150 tokens each is 750 tokens added to every request forever, which at volume is a real line item. How to estimate tokens for an AI task gives the arithmetic. If your examples are stable across calls, this is exactly the shape of prompt that benefits from caching.

The test above gives you the number where quality stops improving. The token count tells you what each one costs. Pick the smallest set that passes, not the largest set you can afford. Examples are one lever among several, and prompt engineering fundamentals covers where they sit relative to the others.

FAQ

Is more examples always better in a prompt?

No. Improvement typically flattens after three to five, and a set of similar examples narrows the model so it handles unusual inputs worse.

Should the examples be real or made up?

Real, wherever possible. Invented examples are tidier than your actual inputs and will make a prompt look more reliable than it is.

Does example order matter?

Sometimes. Models weight recent context more heavily, so put the example closest to your hardest case last and check whether the result changes.

How many examples for a classification task?

Cover each category at least once, plus one ambiguous case that sits between two categories. That usually means slightly more examples than a generation task needs.