What is one-shot prompting?

One-shot prompting means giving the model exactly one example of the task before asking for the real thing. It sits between zero-shot prompting, which gives no examples, and few-shot prompting, which gives several. “Shot” here just means example, and it’s one of the basic shapes of example-based prompting.

The interesting part is that a single example changes the output quite a lot, and for a reason that isn’t the obvious one. Most people add an example thinking they’re teaching the model how to do the task. That isn’t really what happens. What the example does best is show what the answer should look like.

Why one example goes so far

Here’s how you’d ask without an example:

Extract the customer name and order total from this email. Reply in JSON with the fields name and total. The total must be a number, no currency symbol. If you can’t find it, use null.

And with one:

Extract the customer name and order total.

Email: “Hi, this is Marina Costa, I’d like to confirm the order for $1,240.50.” Output: {"name": "Marina Costa", "total": 1240.50}

Email: “…”

The second is shorter and leaves less open. You didn’t have to say the total comes without a currency symbol, or that the decimal separator is a period, or that the JSON shouldn’t be wrapped in a code fence. The example showed it.

This is what gets called in-context learning, and it’s worth being precise about what it isn’t: the model didn’t learn anything permanent. Its weights didn’t change. On the next call, without the example, it goes back to its previous behaviour. The example only took up room in that one request’s context window.

What the example actually teaches

A single example carries three pieces of information at once, and they don’t carry equal weight.

Output format is what an example conveys best. JSON shape, paragraph length, whether there’s markdown, whether the answer starts directly or with a framing sentence — the example settles all of it without you describing anything.

The space of possible answers comes second. If your example labels a ticket as billing, the model infers that there’s a closed set of categories, even though you never listed them.

Language register rides along whether you wanted it to or not. A terse example produces terse answers. An example with emoji produces answers with emoji. This one is usually an unintended side effect.

There’s a result here worth knowing, and it runs against intuition. A 2022 paper tested what happens when you scramble the labels in your examples — deliberately pairing the wrong input with the wrong output — and performance drops far less than you’d expect¹. The reasonable reading is that the model uses the example more to calibrate format and answer space than to learn the mapping itself.

That isn’t permission to ship a wrong example. It’s a hint about where to spend attention: half an hour picking the most semantically representative example buys less than making sure its format is exactly how you want the answer.

When one example isn’t enough

One-shot fails in a few predictable ways.

When there’s an ambiguous boundary. If you’re sorting tickets between billing and finance, one example shows one side of the line. It doesn’t show where the line is. You need at least one example from each side, and you’ve left one-shot behind.

When the normal case and the edge case need different handling. If the email sometimes has no total at all, and your one example has a total, the model will invent a number rather than return null. It learned that answers always have a number in them.

When the task is about reasoning, not format. For a problem that takes several steps, what helps is showing the reasoning, not the answer. That’s chain-of-thought, and one example with the full reasoning written out usually beats three that show only the final answer.

There’s also a calibration effect working against you: with few examples, the model leans toward whichever label appeared last or appeared most². With a single example that bias is at its maximum, because there’s nothing to balance it against.

How to pick the example

What works in practice:

1. Take a median case. Not the simplest, which teaches little, and not the weirdest, which teaches the model to treat everything as an exception.
2. Write the output exactly as you want to receive it. If you don’t want a code fence around the JSON, the example can’t have one.
3. If an empty case exists, show the empty case. One example where the field comes back null is worth more than a sentence saying “use null if missing”.
4. Test with the example swapped. If quality shifts a lot when you replace the example with an equivalent one, your task is example-sensitive and you probably need few-shot.

Step 4 is the one almost nobody does and the most informative. Running the same 20 inputs against three different examples takes minutes and answers directly whether one-shot is enough.

The cost

One example is the cheapest option after zero-shot. Worth putting numbers on it, because this decision usually gets made blind.

The numbers come from a real extraction task and are only there for order of magnitude. What matters is the ratio: going from zero to one example usually costs little and fixes the most common problem, which is format. Going from one to five triples input cost and only pays off when there’s genuine ambiguity to resolve.

If volume is high and the prompt is stable, look at prompt caching before cutting examples to save money: the example lands in the stable prefix and gets billed at a fraction of the price.

Don’t confuse it with one-shot learning

The two terms come from different places and don’t mean the same thing.

One-shot learning predates LLMs and comes out of computer vision. The idea is training a model to recognise a new class from a single labelled example — and there, actual training happens, with weight updates.

One-shot prompting trains nothing. Weights stay frozen, the example lives in the context window, and it disappears when the request ends. The confusion is common enough to deserve its own article.

Footnotes

1. Min et al. (2022) showed that replacing correct labels with random ones degrades performance much less than expected, suggesting demonstrations mainly specify format and label space. ↩

2. Zhao et al. (2021) describe this bias and propose calibrating the output before using it. ↩