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

Zero-shot prompting asks a model to do a task from instructions alone, no examples. Few-shot prompting adds a handful of worked examples before the model runs, to anchor format, tone, or edge-case handling. The few-shot vs. zero-shot prompting decision comes down to this: default to zero-shot for well-understood tasks and reasoning-heavy work, and add few-shot examples only when the output format is ambiguous or narrow enough that a few examples can define it without smuggling in bias.

I get asked which one to default to almost every time a team writes a new prompt. Neither is universally better. Zero-shot keeps a prompt short and lets a modern model reason from instructions. Few-shot spends tokens to remove ambiguity an instruction cannot fully close. Pick the wrong one and you either waste tokens or ship inconsistent output nobody can predict.

Key takeaways

• Zero-shot is the right default for reasoning models and well-understood tasks. OpenAI's own reasoning best-practices guide tells developers to try zero-shot first, because examples can push a reasoning model toward pattern-matching instead of reasoning.
• Few-shot prompting earns its token cost on format control, classification, and brand-voice consistency. A worked example removes ambiguity a written instruction cannot fully close.
• Three to five diverse examples beat twenty. Anthropic's own prompting documentation recommends three to five examples for best results; more adds tokens without reliably adding accuracy.
• Few-shot prompting has a quiet failure mode: example bias. A model can learn the incidental shape of your examples instead of the task itself, and the order you present them in changes accuracy on the same set.
• The right process is zero-shot first, few-shot only when it fails. Add examples to fix a specific, observed failure, not as an opening move.

What zero-shot prompting actually is

Zero-shot prompting is asking a model to complete a task using only a natural-language instruction, no worked examples. The model draws entirely on what it learned during pretraining and whatever reasoning it does at inference time. You describe the task, the constraints, and the output format in words, and the model infers the rest.

This is the default mode of almost every conversation with a chat model. "Summarize this contract in three bullets" is zero-shot. "Classify this support ticket as billing, bug, or feature request" is zero-shot, right up until the model starts guessing what "billing" means in your specific product. That is exactly where the technique runs out.

Zero-shot works because large models carry enormous prior exposure to the kinds of tasks people ask for. A model that has seen millions of summaries and classifications during training does not need you to show it one more; it needs you to say precisely what you want. The original GPT-3 paper is where this baseline got its name: the zero-shot condition is the model performing a task from a description alone, no examples, no weight updates (Brown et al., 2020).

What few-shot prompting actually is

Few-shot prompting is zero-shot plus a handful of worked examples, shown before the real input, so the model sees the pattern instead of reading a description of it. Each example pairs a sample input with the exact output you want, in the same format the model should produce for the live case. One-shot prompting is the special case with exactly one example, useful when a single example removes the ambiguity and you want to spend the fewest tokens doing it.

The mechanism is called in-context learning: the model conditions its output on the examples in the context window, without any weight update. Brown et al. showed this scales sharply with model size. At 175 billion parameters, in-context examples produced large accuracy jumps; at 1.3 to 13 billion parameters, they helped far less (Brown et al., 2020). The payoff depends on the model doing the learning, not just on the examples you hand it.

Picture a prompt that extracts line items from vendor invoices. Told "extract every line item as JSON," a model guesses at field names, guesses how to handle a discount row, guesses what to do with a partial shipment. Shown two examples, one clean invoice and one with a discount line, it copies the schema instead of inventing one. That is few-shot doing what a zero-shot instruction alone could not.

When zero-shot wins: reasoning models and well-understood tasks

Zero-shot is the right default for two situations: tasks a model already understands well, and reasoning-heavy tasks handed to a reasoning model. OpenAI's reasoning best-practices guide is explicit about the second case: try zero-shot first, then few-shot if needed, because reasoning models like the o-series and GPT-5-class models often do not need examples to produce good results (OpenAI's reasoning best practices).

The reason is mechanical, not stylistic. A reasoning model spends inference-time compute working through the problem before answering. Three examples can anchor it to their surface pattern, the phrasing, the length, the edge cases you happened to pick, instead of letting it reason through the actual input. On a well-understood task, that anchoring is a tax with no offsetting benefit.

The same logic holds for tasks that are common, not reasoning-heavy. Summarization, translation, self-evident classification, standard code-review comments: a frontier model has seen enough of these that a clear instruction gets you most of the accuracy a few-shot prompt would, at a fraction of the token cost and none of the bias risk.

When few-shot wins: format control, classification, and brand-voice consistency

Few-shot earns its cost when the task is narrow enough that three to five examples can fully define it, and when the failure mode of getting it wrong is inconsistency, not wrong reasoning. Three cases show up constantly in production work.

• Format control. When you need an exact schema, field names, nesting, a specific delimiter, describing it in prose leaves room to drift. Showing it removes the ambiguity in one shot.
• Classification with fuzzy boundaries. When your label set has categories that overlap in real inputs, two or three labeled examples show exactly where the line falls better than a written definition ever will.
• Brand-voice and tone consistency. "Write in a warm, confident, no-hype voice" means something different to every reader of that sentence. Two examples of the actual voice do more work than a paragraph of adjectives.

I have watched a support-ticket classifier stall on a zero-shot prompt, with category definitions written as clearly as I could manage, still misreading tickets that straddled two categories. Adding four examples, one per label, chosen to cover exactly those ambiguous cases, closed most of the gap without touching the instructions. The examples closed an ambiguity the words alone could not.

Most teams get this wrong not because they picked the wrong technique, but because nobody decided which one to try first. That decision belongs in the same conversation as the rest of the system design. ViitorCloud's technology consulting engagements settle this early, before a framework or an agent gets built, because the zero-shot-versus-few-shot call sets token cost and failure mode for every request that follows.

How many examples you actually need: three to five, not twenty

Anthropic's own prompting documentation, which calls the technique multishot prompting, is specific here: include three to five examples for best results, chosen to be relevant, diverse, and structured clearly enough that the model can tell them apart from instructions (Anthropic's prompting best practices). More examples does not reliably mean more accuracy. It reliably means more tokens, and past a handful, the marginal example usually teaches the model nothing it hadn't already learned from the first three.

The number that matters is not the count. It is the diversity. Three examples that each show a genuinely different case, a simple input, an edge case, a case that should be rejected, do more work than ten minor variations on the same case. If every example looks alike, the model has learned one pattern well and nothing about the boundaries around it.

Twenty examples covering twenty near-identical invoices teach the model almost nothing that three well-chosen ones don't. They do add tokens on every call, forever, for a task that runs at production volume.

The failure mode: order sensitivity and example bias

Few-shot prompting trades one failure mode for another. Zero-shot's failure is vagueness: the model guesses when the instruction leaves a gap. Few-shot's failure is subtler and more dangerous, because it looks like it is working right up until it isn't.

The first problem is pattern leakage. If your three examples all pull exactly four items from a source document, the model learns that this task returns about four items, not the rule you meant to teach. Feed it a real input with eleven items and it truncates, confidently, with no error. You will not catch this by checking the examples you wrote the prompt around. You catch it only by testing inputs your examples never covered.

The second problem is order sensitivity. Research on in-context learning has found that large language models are sensitive to the sequence in which few-shot examples are presented, with some orderings producing strong results and others severely degrading accuracy on the identical example set (Xu et al., 2023). Nothing about the content changed between a good ordering and a bad one. Only the sequence did.

Put together, these two failure modes are the honest trade-off of few-shot prompting. You are not trading vagueness for certainty. You are trading a failure you can usually see, a vague zero-shot answer that is obviously wrong, for one you cannot see without deliberately testing multiple example sets and orderings against inputs your examples never covered.

A decision framework: zero-shot first, add examples only when it fails

The process that holds up in production is simple to state and easy to skip under deadline pressure.

• Start zero-shot. Write the clearest instruction you can. State the task, the constraints, and the output format explicitly.
• Run it against a real evaluation set, not three inputs you picked because they looked easy.
• Diagnose the specific failure. Wrong reasoning means better instructions or a better model. Inconsistent format or fuzzy classification means few-shot is worth trying.
• Add three to five diverse examples, chosen to cover the failure cases you actually observed, not generic ones.
• Test order and coverage, not just accuracy on your original examples. Shuffle the order and run held-out inputs your examples don't resemble.

This is the same discipline I write about in prompt engineering techniques that hold up in production: precision before cleverness, and every technique earning its token cost through a measured result, not a hunch.

How this changes with GPT-5-class reasoning models

Reasoning models shift the default further toward zero-shot than the field has fully absorbed. Earlier-generation models leaned on few-shot prompting partly because the examples doubled as chain-of-thought demonstrations, showing the reasoning steps as well as the output. A reasoning model does that reasoning internally, at inference time, without an example walking it through the steps.

That changes what few-shot is for. It is no longer a substitute for reasoning ability, just a format and consistency tool, useful for the same narrow cases, schema, classification boundaries, tone, and counterproductive when used to teach a model how to think through a problem it is already equipped to reason through on its own.

This is a version of the same shift I cover in context engineering vs. prompt engineering: as models get better at reasoning over what they are given, leverage moves from how you phrase an instruction toward what you put in front of the model at all. Every example you add spends part of a fixed budget.

Context engineering is the discipline of managing that budget deliberately: instructions, tools, memory, retrieved documents, and yes, few-shot examples, so the model sees what it needs and nothing that competes with it. Few-shot vs. zero-shot is one decision inside that larger discipline, not separate from it.

Frequently asked questions

Is few-shot prompting still worth it with GPT-5 and other reasoning models?

Yes, for a narrower purpose than before. It is worth it for format control, classification boundaries, and tone consistency, not for teaching the model how to reason. OpenAI's reasoning best-practices guidance recommends trying zero-shot first and adding examples only when the zero-shot result actually falls short (OpenAI's reasoning best practices).

How many examples should I use for few-shot prompting?

Three to five, chosen for diversity rather than volume. Anthropic's prompting documentation recommends three to five relevant, diverse examples for best results; more examples add tokens without reliably adding accuracy (Anthropic's prompting best practices).

Can too many examples make an LLM prompt worse?

Yes. Past roughly five examples, extra ones mostly add token cost, not accuracy, and if they are too similar they can teach the model an incidental pattern, a fixed item count, a narrow phrasing, rather than the task itself. That pattern leakage is the honest trade-off of few-shot prompting: it fixes vagueness by introducing a subtler failure you have to test for deliberately.

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

One-shot prompting uses exactly one worked example; few-shot uses several, typically three to five. One-shot is the right call when a single example removes the ambiguity and you want to spend the fewest tokens doing it. Few-shot is worth the extra tokens when one example cannot cover the range of cases the model will actually see.

Zero-shot vs. few-shot is a five-minute decision that determines whether every request costs extra tokens for no accuracy gain, or ships inconsistent output nobody trusts. Default to zero-shot, measure the failure, and add three to five examples only when the measurement says so. If you want the deeper discipline, versioning prompts, building the harness that catches pattern leakage before a customer does, turning a prompt that worked once into a pipeline you can run at 3am, I wrote From Prompt to Pipeline on exactly that gap.