Few-Shot vs Zero-Shot Prompting: When to Use Each

Zero-shot prompting means you describe the task and let the model handle it with no examples. Few-shot means you show two or three worked input-output pairs first, then ask for the real one. Neither approach is better by default. Zero-shot wins when the task is common and your instructions are precise, because every example you add costs tokens and can subtly bias the output toward your sample data. Few-shot earns its cost when the model understands the task but keeps getting the same formatting, structure, or tone wrong despite clear instructions. The real question isn't "few-shot vs zero-shot prompting" in the abstract. It's whether your model is failing to understand what you want, or failing to reproduce it consistently.

What each one is actually doing

Zero-shot prompting relies entirely on the model's training and your written instructions. You describe the task, the constraints, and the desired output, and the model generalizes from everything it already knows.

Few-shot prompting works through in-context learning: the model conditions its response on examples sitting right there in the prompt, with no retraining and no fine-tuning involved. You're not teaching it a new skill. You're showing it the exact shape of an answer you already know it's capable of producing. Anthropic's prompt engineering guidance recommends three to five examples for most tasks, wrapped clearly so the model can tell examples apart from instructions.

That distinction matters because it tells you what few-shot can and can't fix. It's very good at pinning down format, structure, and label conventions. It's weaker at fixing genuine reasoning failures. A widely cited prompting reference notes that few-shot examples often still fail on multi-step math and logic problems, because the model tends to pattern-match the shape of the demonstrations rather than learn the underlying reasoning steps. If your task involves multi-hop logic, more examples usually isn't the fix.

When zero-shot prompting is the right call

Skip the examples when:

• The task is common and well represented in training data (classification, summarization, straightforward extraction, translation).

• Your instructions can fully specify the output on their own (a fixed list of categories, an explicit word limit, "reply with only X").

• You're only running the prompt a handful of times, so there's no accuracy gain worth chasing.

• You've already tried tightening the instructions and the failures were about ambiguity, not format. Fix the wording before you reach for examples. That's a different problem with a different fix, covered in how to fix a bad AI prompt.

When to use few-shot prompting

Reach for examples when:

• The model understands the task in plain language but keeps varying the output structure between runs.

• You need a specific, non-obvious format that isn't the model's default choice (a particular field order, a house style, an unusual label scheme).

• You've tightened the zero-shot instructions and the same failure mode keeps showing up anyway.

• The task is going into an automated pipeline where inconsistent output breaks downstream parsing.

Worked example 1: a zero-shot prompt that already works

Some tasks don't need examples because the instructions can carry the entire load.

You are sorting incoming customer support emails into exactly one category.

Categories (pick exactly one, no others):
- billing
- technical_issue
- feature_request
- account_access
- other

Email:
"Hey, I tried logging in this morning and it says my password is wrong,
but I definitely reset it two days ago and got the confirmation email.
Can someone check my account?"

Reply with only the category name, nothing else.

Output: account_access

This works zero-shot because the label set is closed, the case is unambiguous, and "reply with only the category name" already kills the main failure mode, extra commentary wrapped around the answer. Adding three examples here wouldn't improve accuracy. It would just add tokens to every call for no measurable benefit.

Worked example 2: where few-shot fixes a real formatting failure

Here's a task where the instructions alone don't produce a consistent output, and a small number of examples fixes it.

Zero-shot prompt:

Extract the action items from these meeting notes. For each one, list who
owns it and when it's due.

Notes:
"Sarah's going to update the pricing page by Friday. We agreed marketing
needs to send the survey out sometime next week, probably Tuesday. James
is still blocked on the API keys from the vendor, no timeline yet on that
one, and Priya said she'd loop back on the contract by end of month."

Typical zero-shot output:

1. Sarah - Update pricing page - Friday
2. Marketing team needs to send out the survey next week, likely Tuesday
3. James is blocked on API keys, no date given
4. Priya will follow up on the contract before the end of the month

The problem: items 1 and 3 look like clean fields, items 2 and 4 are full sentences. Dates are formatted four different ways. There's no consistent structure to parse, so if this feeds a task tracker or a JSON payload, half the records break the parser.

Few-shot prompt, with two examples added:

Extract action items from meeting notes into this exact format:
- owner: <name>
- task: <short description>
- due: <date or "unspecified">

Example 1
Notes: "Mike will send the invoice to accounting tomorrow."
Output:
- owner: Mike
- task: Send invoice to accounting
- due: tomorrow

Example 2
Notes: "We still need someone to review the vendor contract, no owner
assigned yet."
Output:
- owner: unassigned
- task: Review vendor contract
- due: unspecified

Now extract from these notes:
"Sarah's going to update the pricing page by Friday. We agreed marketing
needs to send the survey out sometime next week, probably Tuesday. James
is still blocked on the API keys from the vendor, no timeline yet on that
one, and Priya said she'd loop back on the contract by end of month."

Fixed output:

- owner: Sarah
- task: Update pricing page
- due: Friday

- owner: marketing
- task: Send out survey
- due: Tuesday next week

- owner: James
- task: Get API keys from vendor
- due: unspecified

- owner: Priya
- task: Follow up on contract
- due: end of month

Every record now has the same three fields in the same order, and "unassigned" or "unspecified" fill the gaps instead of the model inventing a placeholder on the fly. The zero-shot instruction ("list who owns it and when it's due") described the goal but left the model to invent its own structure each time. Two in-context learning examples pinned the exact shape down. If you need this as strict JSON rather than bullet fields, that's a related but separate fix, walked through in how to get JSON output from AI.

The token cost tradeoff

Examples aren't free. Every input token you send gets billed and counts against your context window, and few-shot examples are pure input token overhead added to every single call. Three or four examples for a moderately involved task can easily add a few hundred tokens per request. If you want the mechanics of how that's counted, see what a token actually is.

At low volume, that overhead is irrelevant. At production volume, it adds up: a support workflow processing tens of thousands of requests a month pays that few-shot overhead on every single call, plus the added latency of a longer prompt.

A few rules of thumb:

• One-off or low-volume tasks: optimize for correctness, don't worry about the extra tokens from examples.

• High-volume production tasks: test whether two tighter examples get you most of the accuracy gain of five, then cut the rest.

• If your provider supports prompt caching, the fixed few-shot portion of the prompt can often be cached across repeated calls, which reduces the effective cost of keeping examples in.

• If the failure is a wording problem, not a formatting problem, fixing the instructions costs zero extra tokens and should come first. See how to prompt AI without getting generic answers.

A short decision framework

Before you reach for examples, work through this in order:

1. Tighten the zero-shot instructions first. State the exact format, the constraints, and what "done" looks like.

2. If the model understands the task but the output format, tone, or structure is inconsistent, add two to three few-shot prompting examples that show the exact shape you want. Don't add more than that on a hunch, more examples rarely help past a certain point and just cost tokens.

3. If the failure is a reasoning problem (multi-step math, multi-hop logic), few-shot examples alone often won't fix it. That calls for a different technique, not more demonstrations.

4. If the prompt runs at scale, weigh the added token cost against the accuracy gain, and test whether fewer, tighter examples get you there cheaper.

5. Treat the shot count as one lever inside the broader discipline of prompt engineering, not the whole solution. The best few-shot examples still sit inside a well-structured prompt, not instead of one.

Frequently asked questions

Does few-shot prompting always work better than zero-shot?

No. Few-shot only helps when the model understands the task but keeps varying the output format, structure, or tone. If your zero-shot instructions are already precise and the task is common, adding examples usually adds token cost without improving accuracy.

How many examples should I use in a few-shot prompt?

Most guidance settles on two to five examples. Anthropic's own prompt engineering documentation recommends three to five for most tasks. More examples past that point rarely add accuracy and just add token overhead, so start small and only add more if the format is still inconsistent.

Is few-shot prompting more expensive than zero-shot?

Yes, on a per-call basis. Every example you add is extra input tokens billed on every request. At low volume that cost is trivial. At high production volume, running the same few-shot prompt thousands of times a day, the added tokens become a real recurring cost, so it's worth testing whether fewer, tighter examples get you the same result.

Can few-shot prompting fix a model that ignores your instructions?

Sometimes, but not always. Few-shot is strong at fixing formatting and structural inconsistency because it shows the model the exact output shape. It's weaker at fixing multi-step reasoning failures, where the model tends to copy the surface pattern of the examples rather than the underlying logic.

What's the difference between few-shot prompting and fine-tuning?

Few-shot prompting shows examples inside the prompt itself, with no change to the model. Fine-tuning actually retrains the model's weights on a larger example set so the behavior is baked in permanently. Few-shot is faster to test and reverse; fine-tuning is a bigger commitment reserved for patterns you need consistently across many prompts.