Few-Shot vs Zero-Shot Prompting: When to Use Each
Adding examples to a prompt can transform the output — or waste tokens. Here's how zero-shot, one-shot and few-shot compare, and when to reach for each.
Ask a model to "sort these support tickets by urgency" and it will do something. Whether that something matches the exact format your dashboard expects is a different question. The gap between a vague instruction and a reliable one often comes down to whether you showed the model any examples. That single choice, examples or no examples, is the difference between zero-shot and few-shot prompting, and knowing which to reach for saves you a lot of trial and error.
The three flavors of shot
The word "shot" here just means an example. A shot is one demonstration of the task, usually written as an input paired with the output you want back.
- Zero-shot gives the model no examples. You describe the task in plain language and trust the model to already know how to do it. Most of what you type into a chat window is zero-shot.
- One-shot includes a single example before your real request. That one demonstration anchors the format and tone.
- Few-shot stacks several input-to-output pairs, usually two to five, so the model can infer the pattern from the demonstrations themselves.
Few-shot is sometimes called in-context learning because the model "learns" the task from examples inside the prompt, without any retraining. Nothing about the model's weights changes. You are simply steering it with a pattern it can copy. This idea comes straight from the research that showed large models can pick up new tasks from a handful of demonstrations alone.
A zero-shot prompt looks like this:
A few-shot version of the same task shows the pattern first:
Notice the model now has a template to imitate. It sees one-word labels, so it returns one word.
Where zero-shot falls apart
Zero-shot is fine until you need consistency. The failure you will hit most often is format drift: the model answers correctly but wraps the answer differently every time. Say you want product data pulled from messy descriptions into clean rows. A zero-shot attempt might produce this on the first call:
The Acme Pro weighs 2.3 kg and costs 49 dollars.
...and this on the next:
- Name: Acme Pro
- Price: $49
- Weight: 2.3kg
Both are "right." Neither is parseable by the same script. When you are feeding output into a spreadsheet, a database, or another prompt, that variation is a bug.
Few-shot fixes it by removing the guesswork. Show three examples in exactly the format you want, and the fourth answer falls in line:
The model returns Acme Pro | 49 | 2.3 every time because you left it no room to improvise. That is the whole trick: examples constrain the output space.
Choosing between them
Reach for zero-shot first. It is faster to write, cheaper to run, and for common tasks the model has seen thousands of times, examples add nothing. Summarizing an article, answering a factual question, translating a sentence: these rarely need demonstrations.
Move to few-shot when one of these is true:
- You need a specific output format. Fixed columns, a particular JSON shape, a controlled vocabulary of labels. Examples pin it down faster than a paragraph of instructions.
- The task is unusual or domain-specific. Classifying legal clauses by risk tier, or tagging chemistry notes, is not something the model has strong priors for. Show it what "high risk" looks like in your world.
- Zero-shot is already inconsistent. If you ran the prompt five times and got three different structures, that is your signal. Add examples of the structure you actually want.
One-shot sits in the middle. Use it when a single example is enough to lock the format but the task itself is easy. It costs almost nothing and often clears up format drift on its own. If the good foundations of a clear zero-shot prompt are new to you, the prompt engineering fundamentals guide covers the instruction-writing habits that make examples even more effective.
Making your examples earn their keep
Bad examples teach the model bad patterns, so the quality of your demonstrations matters more than the quantity. A few rules keep them useful:
- Make them representative. Pick examples that mirror the real inputs you expect, including the awkward ones. If half your data has missing fields, show an example with a missing field and how to handle it.
- Keep them diverse. Three near-identical examples teach the model one narrow case. Spread them across the range of outcomes so it sees positive, negative, and edge cases rather than three variations of the same answer.
- Freeze the formatting. Every example should use identical structure: same labels, same spacing, same punctuation, same casing. Inconsistency in your examples becomes inconsistency in the output. This is where most few-shot prompts quietly go wrong.
- Order with intent. Models can weight the last example more heavily, so put your cleanest, most typical case near the end.
Watch the token bill
Every example you add rides along in the prompt on every single call. Ten demonstrations might quadruple the size of a request, and you pay for those tokens each time whether the task needed them or not. On a high-volume job, that adds up fast.
Two to five examples is usually the sweet spot. Past that you tend to see diminishing returns: the model already grasped the pattern by example three, and examples four through ten mostly cost money. Test with a small set, and only grow it if accuracy is genuinely lagging. If you find yourself pasting the same demonstrations into prompt after prompt, save them somewhere reusable like a prompt library instead of retyping them, and lean on a prompt optimizer to trim any examples that are longer than they need to be.
Combining shots with reasoning
Few-shot really shows its range when you pair it with reasoning. Instead of showing plain input-to-output pairs, you show the model examples that include the reasoning steps between the question and the answer. That is the bridge to chain-of-thought prompting, where each demonstration walks through the logic before landing on a result. The model copies not just your format but your way of thinking through the problem, which is why few-shot chain-of-thought handles multi-step math and logic far better than either technique alone.
Once you are comfortable stacking examples and reasoning together, the advanced prompt engineering guide goes deeper into structuring these hybrid prompts for reliability at scale. Start simple, add examples only when the task asks for them, and let the output tell you when you have enough.
