Few-Shot Prompting Examples: How Many to Use and Where

Ask a model to classify support tickets and describe the output in a paragraph, and it mostly complies. Show it three tickets already classified in the exact shape you want, and it locks on. That's few-shot prompting examples doing the work instructions can't: teaching the pattern by demonstration instead of description. The catch is that most people either use the wrong number of examples or vary their format, and both quietly wreck the result.

The pages that rank explain the concept well and then stop short. The few-shot page on promptingguide.ai shows solid examples in about 1,200 words but doesn't prescribe how many to use for which job, and closes on a course pitch. The longer guide on prompthub.us does nail the count and the ordering across roughly 4,500 words, then never compares how the three major models actually behave, and gates the depth behind its own platform. So here's the tight version: how many, where they go, and where each model differs.

What few-shot prompting is

Few-shot prompting is showing the model several worked examples, each an input paired with its correct output, before the real input. The model learns the task from the demonstrations. No retraining, no fine-tuning, just pattern-matching from what's in the context window, which is why it's also called in-context learning.

Here's what teams reach for it to do:

• Lock an output format that a written description keeps failing to enforce
• Classify text into a fixed label set with consistent phrasing
• Teach a niche or made-up convention the model has never seen
• Show the exact tone or structure for rewrites and summaries
• Demonstrate how to handle an edge case (an empty field, an ambiguous input)
• Reduce the instruction paragraph to a couple of lines plus examples

The common thread: the examples carry information that's painful to write as rules. "Match this shape" is three examples. Writing the shape out as prose takes a paragraph the model half-follows.

How many examples, really

Three to five, for most work. That's the honest answer the thin guides dodge and the long ones bury.

The curve is steep then flat. Two examples usually establish the pattern. A third or fourth sharpens it. Past five, accuracy barely moves while token cost keeps climbing on every single call. And beyond about eight, the model can start overfitting, copying incidental details of your examples instead of the underlying rule.

Rough guide by job

  Simple classification (fixed labels)   -> 2 to 3 examples
  Formatting / structure enforcement     -> 3 to 5 examples
  Nuanced tone or reasoning              -> 4 to 5 examples
  Edge-case handling                     -> add 1 example per edge case

The exception worth flagging: reasoning-heavy tasks sometimes do better with fewer, well-chosen examples plus a chain-of-thought instruction than with more examples alone. More isn't the lever people think it is.

Where the examples go, and in what shape

Two placement rules do most of the work, and both come down to how models weight tokens.

First, examples go after the instruction and before the real input. The model reads the rule, sees it demonstrated, then applies it to fresh input right where its attention is strongest. Second, put your most representative example last. Models weight recent context heavily, so the final example carries extra influence. If one example best captures the pattern, that's the one to end on.

Then the rule that matters more than count: keep every example in the identical shape. Same field order, same delimiters, same handling of blanks. Examples that vary in format teach the model to vary its output. That's not a small effect. It's the single most common reason few-shot "doesn't work" when the count looked fine.

How the three models handle few-shot

The technique carries across Claude, ChatGPT, and Gemini. The weighting doesn't. A prompt tuned on one can surprise you on another.

The habit that helps all three: delimit the examples clearly and label the slot for the real input. A block like EXAMPLES: followed by NOW CLASSIFY: stops the model from reading your last demonstration as part of the input to process. Gemini needs this most, but none of the three are hurt by it.

Prompt-craft patterns for few-shot

Include one hard example, not five easy ones

Five examples of the obvious case teach the obvious case. One example of the input that usually breaks, the empty field, the ambiguous label, the mixed format, teaches the model the boundary. A short set that covers the edges beats a long set of duplicates.

Show the failure output too

If a valid response is sometimes "none" or "cannot determine," show an example that returns exactly that. Otherwise the model learns every input deserves a confident answer, and it manufactures one for the cases that should come back empty. Demonstrate the honest non-answer.

Match the example format to your parser

When the output feeds a program, the examples have to be in the precise shape the parser expects, down to whether a list is empty as [] or "none". The model copies what it sees. An example showing [] teaches an empty array; one showing "none" teaches a string. Pick the one your code reads, and show only that.

Variables you'll set

The {{examples}} slot is where reliability is won or lost. Fill it with three consistent pairs and the format locks. Fill it with five inconsistent ones and you've taught the model to improvise.

Getting started

1. Write the instruction first, in one or two lines, so the examples support a rule.
2. Pick three to five real input-output pairs, including at least one hard case.
3. Rewrite every example into one identical shape, matching what your parser reads.
4. Order them so the most representative pair comes last.
5. Delimit the example block and label the slot for the real input.
6. Test on inputs the examples didn't cover, not just ones that echo them.
7. If accuracy stalls, fix the examples' consistency before adding more of them.

For a version where the examples live in a stable block that gets reused across runs, the Context Engineering Harness pack is built around exactly that layout.

Examples are half of a reliable prompt; the frame around them is the other half. For assembling that frame so the examples don't get buried, context engineering for LLMs covers the ordering. And when the few-shot output has to be machine-readable, a structured output prompt for reliable JSON shows how the examples and the contract lock the shape together. Pair either with the Context Engineering Harness when the same examples serve every run.