How Few Shot Prompting Works and How Many Examples to Use

Few-shot prompting means putting a handful of worked examples in your prompt, each showing an input and the output you want, before the real input. The model picks up the pattern from those examples and applies it to the new case. Zero-shot is the same prompt with no examples, just instructions.

For most tasks, start with two to five examples. Google's Gemini docs say models "can often pick up on patterns using a few examples" and warn that too many causes the model to overfit to them, so the count is something you tune rather than maximize. Format every example identically, wrap them so the model can tell examples from instructions, and make them varied enough that the model doesn't learn an accidental rule. The rest of this page covers how to do each of those things, when to skip examples entirely, and how few-shot differs from chain of thought.

What few-shot prompting means#

A "shot" is one example. Zero-shot prompts give instructions only. One-shot prompts give one example. Few-shot prompts give several. Anthropic's docs also call the technique multishot prompting; it's the same thing.

The reason it works is mostly about what a language model is. The Gemini prompting guide describes these models as working "like an advanced auto completion tool": given partial content, the model produces the most plausible continuation. If the content so far is three pairs of input and output in a fixed shape, the most plausible continuation of a fourth input is an output in that same shape. You aren't teaching the model new facts. You're constraining what a good continuation looks like.

That framing tells you what few-shot is good at, and both vendors agree on the list. Anthropic calls examples "one of the most reliable ways to steer Claude's output format, tone, and structure." Google says few-shot prompts "are often used to regulate the formatting, phrasing, scoping, or general patterning of model responses." Format, tone, scope, labeling conventions, length. If your problem is "the answer is right but it looks wrong," examples are the fix.

How many examples to give#

Neither vendor publishes a magic number, and I'd be suspicious of anyone who does. The guidance in both doc sets comes down to three points:

• A few is usually enough. Patterns in format and labeling are easy for current models to pick up.
• Too many hurts. Google's docs say the model "may start to overfit the response to the examples." In practice that looks like the model copying phrasing from an example instead of responding to the new input, or refusing to produce an output that none of the examples showed.
• Experiment. Google explicitly says "you may need to experiment with the number of examples."

My working rule: start with three. Add one for each distinct case the model keeps getting wrong, and stop when adding another doesn't change the output. For classification tasks I'd include at least one example per label, otherwise the model may treat a label it never saw as out of bounds. Format-only tasks (make the output JSON with these keys) often work with one or two.

Diversity matters more than count. Anthropic's advice is to make examples "diverse: cover edge cases and vary enough that Claude doesn't pick up unintended patterns." Three examples that all have positive sentiment, all run under ten words, and all discuss restaurants teach three rules you didn't intend. Three examples that differ in length, topic, and label teach only the rule you want.

How to format few-shot examples#

Two rules carry most of the weight: keep every example in exactly the same shape, and separate examples from instructions so the model can't confuse the two.

Google's guidance on consistency is specific: "It is essential to ensure a consistent format across all examples, especially paying attention to XML tags, white spaces, newlines, and example splitters." If one example ends with a blank line and the next doesn't, that's a pattern the model may try to reproduce. Same for Label: versus label: and Output: versus Answer:.

For separation, Anthropic recommends wrapping each example in <example> tags and the whole set in <examples> tags. Google recommends XML-style tags or Markdown headings as delimiters and says to pick one convention and stick with it within a prompt. Here's a template that follows both:

[ONE OR TWO SENTENCES DESCRIBING THE TASK AND THE OUTPUT FORMAT]

<examples>
<example>
Input: [EXAMPLE INPUT 1]
Output: [EXAMPLE OUTPUT 1]
</example>
<example>
Input: [EXAMPLE INPUT 2]
Output: [EXAMPLE OUTPUT 2]
</example>
<example>
Input: [EXAMPLE INPUT 3]
Output: [EXAMPLE OUTPUT 3]
</example>
</examples>

Input: [REAL INPUT]
Output:

Why it's worded this way: the instruction comes first so the model knows what the examples are examples of. The tags make the boundary between demonstration and task unambiguous. The trailing Output: with nothing after it is a completion cue. Google's docs show this exact move with a JSON-extraction prompt that ends in Output: so the model fills in the object rather than writing a sentence about it. And the real input uses the same labels as the examples, which is the consistency rule again.

If you want structured output, the same template works with a JSON body:

Valid fields are [FIELD_A], [FIELD_B], and [FIELD_C]. Omit fields with no value.

<examples>
<example>
Order: [EXAMPLE ORDER TEXT]
Output:
{"[FIELD_A]": [VALUE], "[FIELD_C]": [VALUE]}
</example>
</examples>

Order: [REAL ORDER TEXT]
Output:

The one example deliberately leaves out a field. That's how you show "omit empty fields" instead of describing it. Google's docs make the same point with a cheeseburger order: once the example drops the keys that weren't ordered, the model drops them in the next response too. For anything with a nontrivial schema, Google's guide steers you toward the Gemini API's structured output feature instead of relying on prompt examples alone, and the same logic applies to any provider that offers schema enforcement.

One more formatting rule from Anthropic: the style of your prompt influences the style of the output. If you don't want Markdown in the response, don't put Markdown in your examples.

Build the prompt in code#

Hand-editing five examples inside a string is where inconsistency creeps in. Keep the examples as data and render them with one function so every example gets identical labels, spacing, and tags.

EXAMPLES = [
    {'input': 'The checkout button does nothing on Safari 17.', 'output': 'bug'},
    {'input': 'Please add dark mode to the settings page.', 'output': 'feature'},
    {'input': 'How do I export my data as CSV?', 'output': 'question'},
]

def render_example(ex):
    return f"<example>\nInput: {ex['input']}\nOutput: {ex['output']}\n</example>"

def build_prompt(instruction, examples, real_input):
    body = '\n'.join(render_example(e) for e in examples)
    return (
        f"{instruction}\n\n<examples>\n{body}\n</examples>\n\n"
        f"Input: {real_input}\nOutput:"
    )

prompt = build_prompt(
    'Classify each support message as exactly one of: bug, feature, question.',
    EXAMPLES,
    'The app crashes when I rotate my phone.',
)
print(prompt)

That string is what you send as the user message to Claude, ChatGPT, or Gemini. Frameworks like LangChain ship their own few-shot prompt templates, but they do the same job: a list of example records, a per-example format string, a prefix, and a suffix. If you understand the plain version, the framework version is a thin wrapper over it.

A consistency check is cheap and catches the whitespace drift Google warns about:

const examples = [
  { input: 'Refund never arrived', output: 'billing' },
  { input: 'Login code expired too fast ', output: 'auth' },
  { Input: 'Where is the API docs link?', output: 'docs' },
];

const expectedKeys = JSON.stringify(Object.keys(examples[0]).sort());
const problems = [];

examples.forEach((ex, i) => {
  const keys = JSON.stringify(Object.keys(ex).sort());
  if (keys !== expectedKeys) {
    problems.push(`example ${i}: keys ${keys} differ from ${expectedKeys}`);
  }
  for (const [k, v] of Object.entries(ex)) {
    if (v !== v.trim()) {
      problems.push(`example ${i}: "${k}" has leading or trailing whitespace`);
    }
  }
});

console.log(problems.length ? problems.join('\n') : 'all examples consistent');

Run that before you ship a prompt and the Input versus input typo and the trailing space get flagged instead of silently becoming part of the pattern.

When zero-shot is enough#

Google's position is blunt: "We recommend to always include few-shot examples in your prompts. Prompts without few-shot examples are likely to be less effective." Anthropic's is softer, calling examples one of the most reliable steering tools without saying they're mandatory. My take sits in between.

Zero-shot is usually fine when:

• The output is free-form prose and any reasonable format is acceptable.
• You're exploring a task interactively and iterating on the instructions anyway.
• The format is already enforced by a structured output or schema feature, so examples would only restate the schema.
• The task is one the model already does well and your instructions are clear and specific.

Few-shot earns its tokens when:

• The output has a format the model keeps getting slightly wrong.
• There's a house style, label set, or scoping rule that's hard to describe but easy to show.
• You want shorter or longer answers than the default. Google's snow example is a clean demonstration: with no examples the model picked the long explanation, and with two examples that preferred the short one, it switched.
• You need consistent behavior across many calls in production.

A practical workflow: write the zero-shot version first. Run it against a dozen real inputs. Every failure that's about shape rather than substance becomes a candidate example. Google's docs also note that once examples are clear enough you can remove some of the instructions, which is a decent test of whether your examples are pulling their weight.

Few-shot prompting vs chain of thought#

These two get compared because both are "add stuff to the prompt" techniques, but they target different problems. Few-shot shows what the output should look like. Chain of thought asks the model to work through intermediate steps before answering, which helps on tasks where the answer depends on reasoning rather than format.

They combine. A few-shot example can include the reasoning, not just the answer. Anthropic's current guidance for models with extended thinking is to present each worked example as "a problem, the method to apply, and the expected answer," and notes that these examples shape how the model approaches similar problems in its own thinking blocks. Here's a template in that shape:

Solve problems of this kind using the method shown.

<examples>
<example>
Problem: [EXAMPLE PROBLEM]
Method: [THE STEPS OR RULE THAT LEADS TO THE ANSWER]
Answer: [EXAMPLE ANSWER]
</example>
<example>
Problem: [SECOND EXAMPLE PROBLEM]
Method: [STEPS]
Answer: [ANSWER]
</example>
</examples>

Problem: [REAL PROBLEM]

The Method line is the point. It demonstrates the approach rather than just the destination, which is what you want when the failure mode is "wrong reasoning" rather than "wrong format." The real problem has no Answer: cue after it on purpose; on models that reason before answering, you want them to do that work rather than jump straight to the label.

One caveat specific to Claude, straight from Anthropic's docs: on recent models with thinking, a prompt that asks the model to write out its reasoning in <thinking> tags may be declined. Rely on the thinking feature instead, and only fall back to manual "think it through, then put the final answer in <answer> tags" prompting when thinking is off.

Common mistakes with few-shot examples#

• Examples that all share an accidental trait. Same length, same label, same topic. The model learns the trait. Vary them on purpose.
• Inconsistent labels or whitespace. Output: in one example and Answer: in another, or a stray trailing space. Render examples from data instead of typing them.
• Examples that don't match the real inputs. Anthropic's first rule is "relevant: mirror your actual use case closely." Toy examples about fruit won't help a prompt that processes support tickets.
• Too many examples. Past a point you get overfitting and wasted tokens. If the output is right, stop adding.
• Burying examples under a long document. For inputs of 20k+ tokens, Anthropic says to put the long data at the top, above your query, instructions, and examples. Google's long-context advice is the same: context first, instructions at the end.
• Using examples to teach a schema. If the structure is complex, use a structured output feature and keep examples for tone and edge cases.
• Never testing the order. Google lists reordering prompt sections (examples, context, input) as an iteration strategy because order can change the result. Try at least two arrangements.
• Treating the count as fixed. The right number for one model and task isn't the right number for another. Re-tune when you switch models.

Quick reference#

• Start with three examples. Add one per failure mode you see. Stop when the output stops changing.
• One example per label for classification tasks.
• Identical shape for every example: same labels, same casing, same whitespace, same separators.
• Wrap examples in <examples> and <example> tags. It's Anthropic's recommended form and works fine on other models.
• Instruction first, examples second, real input last, ending on a completion cue like Output:.
• Long documents go above the instructions and examples.
• Vary length, topic, and label across examples so the only shared pattern is the one you want.
• Keep examples as data and render them with code.
• Use structured output features for complex JSON; use examples for style and edge cases.
• For reasoning tasks, show problem, method, answer. Don't ask Claude's thinking models to write reasoning in tags.
• Primary references: Anthropic's multishot prompting guidance and Google's prompt design strategies.

Quick answers