Comparison
Few-shot vs zero-shot prompting
Examples improve format compliance and are billed on every request. When two or three earn their tokens, and when instructions alone are enough.
The short answer
Start zero-shot and add examples only when the failure is format or ambiguity. Modern instruction-tuned models handle a great deal with instructions alone, and every example is billed on every request forever. Two or three well-chosen examples covering the boundary cases beat both a page of instructions and a dozen examples of the obvious case.
At a glance
| Few-shot | Zero-shot | |
|---|---|---|
| Prompt cost | Higher — examples on every request | Lower |
| Format compliance | Better | Depends on the instruction |
| Ambiguous boundaries | Much better | Weaker |
| Maintenance | Examples drift out of date | One instruction to update |
| Risk | Model copies example specifics | Model invents a shape |
When to choose which
Choose Few-shot when
- The output format is unusualShowing the shape is more reliable than describing it. This is what examples are best at.
- The task boundary is genuinely ambiguousWhere reasonable people would classify a case differently, an example settles it in a way instructions rarely do.
- You need a specific voiceTone is hard to specify and easy to demonstrate.
Choose Zero-shot when
- The task is common and well-specifiedSummarise, translate, extract named fields. Models do these without examples, and adding them is pure cost.
- A structured output mode is availableIt enforces the schema rather than demonstrating it, which removes the main reason to include examples at all.
- The prompt is already largeExamples are the most expensive part of a prompt per unit of instruction. At volume, the cost of three examples on every request is a real recurring line.
What it costs either way
Examples are billed on every request forever. Three examples at a hundred tokens each is three hundred tokens on every call — at a million calls a month, a real annual figure for text that never changes.
That makes them a permanent decision rather than a prompt tweak, and worth pricing before adopting.
A fine-tune moves examples into the weights and removes them from the prompt, which is one of the clearer economic cases for fine-tuning at high volume.
The mistake people make
Adding examples of the case that already works
The instinct is to show the model what a good answer looks like, so people add three examples of the obvious case. Those teach almost nothing — the model already handled it. The examples that earn their tokens are the ambiguous one and the one that should be refused. Coverage of the boundary beats volume every time, and it costs less.
How to decide
- 1Try zero-shot with a precise output-format section first.
- 2If it fails, look at whether the failures are format or judgement. Format may be solved by a structured output mode instead.
- 3Add two or three examples covering boundaries: one clear, one ambiguous, one that should be refused.
- 4Price them at your request volume, and check whether removing one changes anything.
Price it yourself
- Few-Shot Example FormatterPairs in, formatted examples out. Four formats, priced.
- Structured Prompt BuilderDeterministic, not AI-generated. Six sections, live token cost, copy as plain text or XML tags.
- Prompt Diff and Token ComparisonBefore and after, with the token delta priced. The missing half of every prompt rewrite.
Frequently asked questions
- How many examples is optimal?
- Two or three for most tasks. Beyond five the return flattens while the cost keeps rising, and the examples start competing with each other for attention.
- Should examples go before or after the instruction?
- After the instruction and before the input. The model needs to know what it is being asked before the examples mean anything.