Zero-Shot, One-Shot, and Few-Shot: The Example-Count Spectrum

A Separate Dial From Wording

Separate from how carefully a prompt's instructions are worded is a different lever entirely: how many worked examples the prompt includes. This is the zero-shot / one-shot / multi-shot (few-shot) spectrum, and it's a distinct knob from prompt clarity or system/user placement -- you can have a beautifully clear instruction that still under-specifies the exact output shape, and examples are often what closes that gap where more prose can't.

• Zero-shot: the instruction and no examples at all. You describe the task and ask for the result directly.
• One-shot (single-shot): one worked example -- an input paired with the exact output you want -- added alongside the instruction.
• Multi-shot / few-shot: several such worked examples.

The examples are not training data and don't persist beyond the call -- they sit in the prompt itself, showing the model the precise shape of a correct answer rather than describing that shape in words. A paragraph of prose describing a formatting convention often fails to pin it down as reliably as one clean example of it.

What Adding Examples Costs

Each example is prompt content like any other: it costs input tokens on every single call, not once. A few-shot prompt with three long worked examples pays for those three examples' worth of tokens on every request that uses the prompt, for as long as that prompt is in production. This is the direct tradeoff against the benefit -- examples buy reliability on format/edge-case behavior, and that reliability is purchased with a permanent per-call token tax.

Choosing a Point on the Spectrum

The general discipline is the same one that runs through this whole domain: add the smallest amount of prompt -- including the smallest number of examples -- that produces a reliable result. One or two well-chosen examples usually fix a persistent structural problem faster than another paragraph of instructions describing the same thing.

Interaction With Model Choice

Prompting mode (how many examples) and model tier are related, composable levers rather than independent ones. A pricier, more capable tier will frequently nail a task with zero examples where a cheaper, smaller one needs a couple of worked examples before it hits the same structure -- which means that in practice, adding a few examples is often the cheaper fix, letting the lower tier reach parity with the higher tier instead of upgrading. The two decisions are worth tuning together: start from the simplest model and the fewest examples that clear your eval bar, and add capability (a higher tier) or examples (more shots) only where the eval shows you actually need it.

Common exam traps

• Assuming more examples always help -- if the instruction already fully specifies the desired behavior (or the model already gets it right zero-shot), extra examples cost tokens on every call with no quality benefit to show for it.
• Treating few-shot examples as training data that permanently changes the model, rather than prompt content re-sent (and re-billed) on every call.
• Reaching for a bigger model tier to fix a structural output problem when one or two well-placed examples on the current tier would fix it at lower cost.