Few-Shot vs Zero-Shot Prompting: When to Use Each
Zero-shot prompting asks a model to perform a task from an instruction alone, with no worked examples included. Few-shot prompting shows the model a handful of example input-output pairs before asking it to handle a new case. The decision between them comes down to one question: does this task need a worked example to pin down the exact format, tone, or edge-case handling you want, or is a clear instruction enough on its own?
Zero-shot prompting is asking a model to complete a task from an instruction alone, with no worked examples of the desired input-output pattern included in the prompt.
Few-shot prompting is including a handful of example input-output pairs directly in the prompt before asking the model to handle a new, unseen case in the same pattern.
Zero-Shot Prompting
Zero-shot is the default starting point for a reason: it's the cheapest prompt to write and the cheapest to run, since there's no example content taking up space in the request. For a genuinely simple, well-defined task — summarize this paragraph, translate this sentence, answer this factual question — a clear instruction is usually enough. The model already has a broad sense of what a summary or a translation looks like, so it doesn't need you to show it one.
Zero-shot's failure mode shows up on tasks with more ambiguity than they look like they have. When the instruction alone doesn't pin down the exact format, tone, or level of detail you want, the model has to guess — and its guess is a reasonable-looking output that still isn't the specific shape you needed. That's the tell that a task has crossed from "zero-shot is fine" into "this needs an example": not that the output is wrong, but that it's plausible and still not what you asked for, because what you asked for was underspecified.
Few-Shot Prompting
A worked example teaches the model something an instruction alone often can't fully convey: the exact output format (a specific JSON shape, a particular heading structure, a consistent labeling scheme), the tone (formal vs. casual, terse vs. explanatory), and — critically — how to handle the edge cases and boundary conditions that a description tends to gloss over. An instruction can say "classify the sentiment as positive, negative, or neutral"; only an example can show the model exactly where you draw the line on a genuinely mixed or sarcastic review.
The number of examples that's typical is small — usually somewhere in the low single digits, enough to establish the pattern and cover the edge cases that matter, not an exhaustive catalog of every possible input. Each additional example is more prompt content, which means more tokens processed on every single call — a real, ongoing cost and latency trade-off, not a one-time authoring cost. Beyond a certain point, adding more examples has diminishing returns on quality while continuing to add cost on every call, so the goal is the smallest example set that reliably teaches the pattern, not the largest one you can fit.
Choosing Between Them
| Situation | Start with | Why |
|---|---|---|
| A simple, well-defined one-off request | Zero-shot | The task is unambiguous enough that a clear instruction fully specifies the desired output |
| A strict, specific output format (a particular JSON shape, a fixed heading structure) | Few-shot | An instruction can describe a format; only a worked example shows it unambiguously |
| A classification or labelling task with fuzzy boundaries | Few-shot | Boundary cases are exactly what a description tends to leave ambiguous — examples show where the line actually falls |
| A task where every relevant example would consume too much of the available context | Zero-shot, with the instruction sharpened instead | If the example set can't actually fit or would crowd out other needed context, invest in a more precise instruction rather than a truncated example set |
| A task the model already performs well on with just an instruction | Zero-shot | Adding examples the task doesn't need is pure token cost with no quality benefit |
Writing Few-Shot Examples That Hold Up
- Cover the edge case, not just the happy path. An example set that only shows the easy, unambiguous case teaches the model nothing about the boundary conditions where it actually needs guidance — include at least one example near the edge of the category, not only the obvious center.
- Keep every example mutually consistent. If one example's formatting, tone, or labeling convention contradicts another, the model has to guess which one is authoritative — inconsistent examples teach a blurrier pattern than no examples at all.
- Show the exact output format you want back, not a rough approximation of it. If the real output needs a specific structure, the example's output should already be in that exact structure — the model matches what it sees, not what you meant.
- Keep the example set small enough to stay affordable on every call. Since every token in every example is processed again on every single request, trim examples that aren't pulling their weight rather than accumulating them over time.
Managing Shot Count as a Team Problem
Few-shot prompting stops being a purely individual craft decision once a prompt is shared across a team, because the example set itself becomes something that needs to be maintained, reviewed, and kept consistent — not just written once and left alone.
PromptHub stores every edit to a prompt as a distinct version with a per-edit history, so changing an example set — adding an edge case, retiring a stale one, fixing an inconsistency between examples — is inspectable after the fact and reversible if a change turns out to make outputs worse rather than better. When the same example block is genuinely shared across several prompts, reusable prompt components let a team edit that shared block once rather than copy-pasting it into every prompt that needs it and then patching each copy separately when it needs a fix. For a prompt someone thinks needs sharper examples but isn't sure how to get there, AI-assisted improvement of an existing prompt gives a starting rewrite to react to rather than a blank page.
The cost trade-off from earlier in this post — more examples, more tokens, on every single call — is exactly what PromptHub's token-metered AI calls make visible rather than invisible: a longer few-shot prompt shows up as a measurable, trackable cost against the account's balance, not a hidden tax nobody notices until a bill arrives. And because a shared prompt's example set affects every team member who reuses it, the four-role access model — Admin, Components Editor, Prompt Creator, Viewer — governs who can actually change a shared prompt's examples versus who can only run it, so an example-set edit doesn't become an uncoordinated free-for-all on a prompt other people depend on.
Zero-shot and few-shot aren't a one-time choice, either — a prompt that starts zero-shot because the task looked simple often earns its first example the first time someone notices the output is plausible-but-wrong in a specific, repeatable way. For more on how prompt chains sequence multiple steps like this one together, see the complete guide to prompt chains; for how an AI agent differs from a fixed prompt or chain, see that definition; and for what a longer, example-heavy prompt actually costs across different models, see LLM pricing compared.