Few-Shot Prompting With Examples: The Complete Guide (2026)

On this page

1. What is few-shot prompting?
2. Why few-shot still matters in 2026
3. How few-shot works (in-context learning)
4. When to use few-shot (and when not to)
5. Step-by-step method
6. How many examples? 2 vs 5 vs 8
7. Picking the right examples
8. The order-sensitivity trap
9. Few-shot prompt formula
10. Five worked few-shot examples
11. Common mistakes
12. Best practices
13. Few-shot vs zero-shot vs chain-of-thought
14. First-hand test: 3 patterns on the same task
15. FAQ

What is few-shot prompting?

Few-shot prompting is a technique where you give a language model 2 to 8 worked examples of the task you want it to perform, immediately before the real input, inside a single prompt — no fine-tuning, no training, no gradient updates. The model learns the pattern from the examples at inference time. This is also called in-context learning, and it is the single most-cited capability of large language models.

The terminology comes from the 2020 GPT-3 paper by Brown et al., which named four prompting modes by example count: fine-tuning (thousands of examples, with weight updates), few-shot (10–100 examples in context, no weight updates), one-shot (K=1), and zero-shot (K=0). The paper's central finding was that scaling the model dramatically increased how much the model could learn from a handful of examples in the prompt — the few-shot curve shoots up with model size while zero-shot moves more slowly.

A canonical few-shot prompt looks like this:

Classify the sentiment of each review as POSITIVE, NEGATIVE, or NEUTRAL.

Review: "Loved it, best phone I've owned." Sentiment: POSITIVE

Review: "Battery died in six months. Returning." Sentiment: NEGATIVE

Review: "Screen is okay. Camera is average. Delivery was slow." Sentiment: NEUTRAL

Review: "Fast charging works great but the UI is confusing." Sentiment:

Three worked examples set the exact label vocabulary (POSITIVE / NEGATIVE / NEUTRAL — not "good", not "mixed", not "4 stars"), the exact separator (a blank line + "Sentiment:" prefix), and the exact output length (one word). The fourth entry is the real input, and the model completes it. No instruction tuning the label set, no verbose system prompt, no chain-of-thought. The examples are the specification.

Why few-shot still matters in 2026

Direct answer: few-shot is now the specialist tool rather than the default, but on the tasks where it wins, it wins by a lot. Frontier models in 2026 — GPT-5, Claude 4.7 Opus, Gemini 2.5 Pro — handle most common tasks well in zero-shot, so for summarization, translation, and simple extraction the examples are overhead you don't need. On classification with a non-obvious label vocabulary, structured output with a bespoke schema, domain-specific tone, and rare formats like regulatory boilerplate, zero-shot silently drifts and few-shot pins it down.

Published benchmarks tell the same story. The 2024 systematic survey of prompt engineering by Sahoo et al. lists few-shot in-context learning as a standard baseline across modern benchmark suites. Independent 2026 testing by ClaudHQ's prompt benchmark reports that three-example few-shot adds roughly +12 points on GSM8K and +10 points on MMLU versus zero-shot, at about 1.8× the token cost — a textbook accuracy-for-cost trade. A 2026 grant-review study published in Frontiers in Education found few-shot was the strategy whose scores aligned closest to human expert reviewers, beating both zero-shot and strict-instruction prompts across three commercial LLMs.

And the dev community has confirmed what felt true in production: in a 2026 twelve-model benchmark on real business tasks, few-shot moved sentiment classification from 20% to 73–80% accuracy on multiple frontier models — and silently dropped another model from 93% to 30% on route optimisation. Few-shot in 2026 is still worth reaching for, but it has become a technique you reach for intentionally, measure, and roll back if it hurts.

How few-shot works (in-context learning)

The theoretical name for few-shot prompting is in-context learning: the model infers the task from the structure of the demonstrations and then applies it to the new input, all in a single forward pass. There are no weight updates. Nothing is "learned" in the traditional sense. The attention mechanism treats the examples as patterns to continue, the same way it would treat any other sequence.

The research on how in-context learning works is counterintuitive and worth internalising before writing few-shot prompts. In a widely-cited 2022 paper, Min et al. showed that the input-label mapping in the demonstrations matters surprisingly little — swapping correct labels for random labels only slightly hurt classification accuracy. What did matter was:

• The label space. The set of possible answers has to appear in the examples. If you only show POSITIVE and NEGATIVE, the model will not output NEUTRAL even for a clearly-neutral review.
• The distribution of inputs. If every example is a product review, the model treats the task as "classify a product review", not "classify a sentence".
• The format. The exact spacing, label capitalisation, prefix structure, and separator — the model is doing pattern completion more than it is reasoning.

Practically, this means a few-shot prompt is not "teaching the model with correct examples"; it is "setting the pattern the model will continue". That reframing changes how you pick examples (see Picking the right examples below).

When to use few-shot (and when not to)

A short decision rule based on three years of production results:

• Use zero-shot for summarization, translation, classification into obvious labels (good/bad), rewriting, tone change, and most Q&A over clean context. See the zero-shot article for the full list.
• Use few-shot when (a) the output format is unusual or domain-specific, (b) the label vocabulary is bespoke (e.g. "P1-critical / P2-major / P3-minor / P4-informational"), (c) the task requires consistency across hundreds of calls, (d) zero-shot got 60–80% accuracy and you need 90%+, or (e) tone matters and prose descriptions aren't enough to pin it.
• Skip few-shot and go straight to chain-of-thought when the task is arithmetic, multi-step reasoning, planning, or anything where the model needs to think out loud. Chain-of-thought beats few-shot on reasoning benchmarks consistently.
• Skip few-shot and go to fine-tuning or RAG when you need thousands of examples' worth of knowledge, or when the knowledge keeps changing. Few-shot's example count caps at the context window.

Step-by-step method

1. Try zero-shot first. Write the instruction cleanly and run it on five real inputs. If it works, stop — few-shot is overhead you don't need.
2. Identify the specific failure mode. Is the model using the wrong label vocabulary? Dropping fields? Getting the tone wrong? Being inconsistent across runs? Each failure maps to a different kind of example you need to supply.
3. Pick 3 diverse examples. Not 1 (unreliable), not 10 (expensive and sensitive to order). Three is the right default for most classification and extraction tasks. Each example should cover a different edge case.
4. Standardise the format. Every example uses the exact same structure, labels, separators, and output shape. Even one inconsistent example will train the model to drift.
5. Order examples hardest-first or easiest-first. Both patterns work; mixing them random is worse (see Order-sensitivity trap).
6. Run three times with three orderings. If results are stable, ship. If results vary by more than 10%, you have an order-sensitivity problem — fix it before shipping.
7. A/B against zero-shot. Measure accuracy, latency, and token cost on the same test set. If few-shot is <5% better, use zero-shot.
8. Verify on a held-out set. Classic trap: examples perform well on inputs that look like the examples. Validate on 20 inputs that don't look like your examples.

How many examples? 2 vs 5 vs 8

Benchmark data from ClaudHQ 2026 and the 12-model dev.to test both show diminishing returns past 5 examples. The guidance below reflects what we've seen in production and matches the published results:

• 2 examples. Minimum viable few-shot. Works for simple format specification, works less well for complex label spaces. Risk: the model may interpret two examples as a strict rule rather than a pattern.
• 3 examples. The right default for most classification and extraction tasks. Big accuracy jump over 2, smaller cost than 5. Cover: common case, edge case, boundary case.
• 5 examples. Right for complex structured output (JSON schema, multi-field extraction) where you want to pin exact field order and nested structure. Diminishing returns begin above this.
• 8 examples. Reserved for highly structured outputs with 5+ fields or for classification into 6+ labels where each label needs at least one example. Beyond 8, you're usually better off with fine-tuning.
• 10+ examples. Rarely worth it. Token cost explodes. Example-order sensitivity grows. If you need 10 examples to get the behaviour right, the task probably needs fine-tuning or a different technique (chain-of-thought, structured output constraints, or RAG).

Picking the right examples

Example selection is the single biggest determinant of few-shot quality. The rules we've converged on:

• Diversity over similarity. If all your examples look like the easiest case, the model generalises poorly to harder inputs. Mix easy, medium, and edge cases.
• Cover every label. For classification, include at least one example per label. Labels with zero examples will almost never be predicted.
• Keep each example short. Long demonstration examples burn tokens and dilute the pattern signal. If your task's typical input is 200 words, use 200-word examples — not 2000-word ones.
• Match input distribution. If production inputs are customer support emails, your examples should be support emails — not blog posts or wiki articles.
• Watch for leakage. Do not pick examples that are near-duplicates of inputs you'll see at inference time. The model will memorise the exact answer and look better than it is.
• Make the output shape identical. Same field order, same punctuation, same casing. The model copies format far more faithfully than it copies reasoning.

The order-sensitivity trap

Direct answer: rearranging the order of few-shot examples can shift classification accuracy by 10 percentage points or more on the same task, with the same model, with the same inputs. This is one of the most surprising results in in-context learning and the one most often ignored in production.

The effect was formalised by Lu et al. in the paper Fantastically Ordered Prompts and Where to Find Them, which showed that permuting four examples could produce accuracy variance of 25+ points on GPT-2 and GPT-3 era models. The gap has shrunk on modern frontier models but has not disappeared. If you ship a few-shot prompt without testing at least three orderings, you are gambling 5–15% of your accuracy.

Practical rules:

• Always test ≥3 orderings on your held-out set before shipping. Keep the best.
• Easiest-first and hardest-first both work. Mixing random usually underperforms.
• Group by label. For classification, examples of the same label clustered together often outperform random interleaving.
• Recency bias is real. The last example in the prompt has disproportionate influence on the model's output. Put your most-representative example last.
• Document the order you chose. If someone later refactors the prompt and shuffles the examples, accuracy will drop and nobody will know why.

Few-shot prompt formula

The formula every solid few-shot prompt follows:

[1. Task instruction — one sentence, specifies the exact action]

[2. Format specification — optional, called out if the format is unusual]

[3. Example 1 — easiest/clearest case] Input: {input text} Output: {output in exact target format}

[4. Example 2 — covers an edge case or an underrepresented label] Input: {...} Output: {...}

[5. Example 3 — the most representative case; sets recency] Input: {...} Output: {...}

[6. Real input] Input: {real text} Output:

Three variables matter: the task instruction (keep it to one sentence — do not describe the format in prose, let the examples do it), the examples (3 diverse, ordered deliberately), and the input prefix (identical to every example). The model stops generating when it hits a pattern break, which is why the "Output:" at the end with no newline matters.

Five worked few-shot examples

Example 1 — Classification with a bespoke label vocabulary

Classify each incoming support ticket into exactly one of:
P1-critical / P2-major / P3-minor / P4-informational

Ticket: "Checkout returns 500 for all US customers for the last 20 minutes." Priority: P1-critical

Ticket: "The export CSV has an extra trailing comma on the last row." Priority: P3-minor

Ticket: "Would be great to have dark mode in the admin." Priority: P4-informational

Ticket: "Password reset email is going to spam for about 10% of users." Priority:

Why this works: the label vocabulary is bespoke (P1/P2/P3/P4), zero-shot would guess "high/medium/low". Three examples pin the vocabulary and cover three of the four labels. Common mistake: forgetting to include a P2 example will cause the model to never predict P2.

Example 2 — Structured extraction into a strict JSON shape

Extract contact details from each signature block as JSON.
Schema: {"name": str, "title": str|null, "email": str, "phone": str|null}

Signature: "Priya Sharma Head of Product [email protected] · +91-98765-43210" JSON: {"name": "Priya Sharma", "title": "Head of Product", "email": "[email protected]", "phone": "+91-98765-43210"}

Signature: "Marcus — [email protected]" JSON: {"name": "Marcus Lee", "title": null, "email": "[email protected]", "phone": null}

Signature: "Yuki Tanaka [email protected]" JSON:

Why this works: the schema is specified once (not described in words), nullable fields are shown explicitly, name-only vs full-signature cases are both covered. If you asked zero-shot for the same task you'd often get "Yuki Tanaka" with no title field, or "title: 'unknown'" instead of null.

Example 3 — Rewriting into a strict tone

Rewrite each engineering note in the voice of a senior customer-success manager — plain, honest, no hedging, no "we apologise", no corporate boilerplate.

Original: "There was a brief outage affecting a small subset of users." Rewritten: "Checkout was down for about 20 minutes. US customers only. We know what caused it; it will not recur."

Original: "We are investigating reports of email deliverability issues." Rewritten: "Password reset emails have been hitting spam for about 10% of accounts since Tuesday. Fix is landing today."

Original: "A scheduled maintenance window may cause intermittent slowness." Rewritten:

Why this works: "no hedging, no apologise, no boilerplate" is almost impossible to pin in zero-shot — the model has been trained to apologise. Two examples make the pattern concrete.

Example 4 — Date normalisation

Normalise each date to ISO 8601 (YYYY-MM-DD). If the date is relative or ambiguous, return null.

Input: "Last Tuesday" ISO: null

Input: "5 Oct 2026" ISO: 2026-10-05

Input: "10/4/26" ISO: null

Input: "October 5, 2026" ISO:

Why this works: "10/4/26" is intentionally ambiguous (US vs European format) and the example teaches the model to refuse. Without the ambiguous example, the model will guess and be wrong half the time.

Example 5 — Structured output for an agent action

Given a user request, output exactly one JSON action object. Valid actions: "search", "create_task", "reply", "escalate".

Request: "Find all open bugs assigned to me." Action: {"action": "search", "query": "assignee:me status:open type:bug"}

Request: "Please file a ticket to add 2FA to the admin panel." Action: {"action": "create_task", "title": "Add 2FA to admin panel", "priority": "P2-major"}

Request: "The CEO is asking about the Q3 incident." Action: {"action": "escalate", "to": "director_oncall", "context": "CEO query re: Q3 incident"}

Request: "Can you remind me what SLA we have with Acme Corp?" Action:

Why this works: an agent that produces inconsistent JSON breaks the agent harness. Three examples cover three different actions, pin the key names, and show that fields vary by action. Try these in the Prompt Lab against GPT-5, Claude 4.7 Opus, and Gemini 2.5 Pro to see output stability differences.

Common mistakes

• Using too many examples. 10+ examples trigger order sensitivity and burn tokens without proportional accuracy gain.
• Examples that are not actually similar. If one example is 50 words and another is 500, the model doesn't know which length to copy.
• Missing a label. For classification, labels you don't demonstrate are labels you won't predict.
• Format drift between examples. One example uses "Priority:" and another uses "priority:" — the model will output both at random.
• Not testing order variants. You ship with the first ordering that worked and leave 5–15% of accuracy on the table.
• Picking examples that leak the answer. Near-duplicates of test inputs make the model look better than it is.
• Verbose task instruction. If you have 100 words of instruction plus 5 examples, the instruction is doing more work than the examples. Delete the prose; the examples are the specification.
• Few-shot where chain-of-thought is needed. For arithmetic and multi-step reasoning, zero-shot CoT (Kojima et al. 2022) usually beats few-shot without CoT.

Best practices

• Start at 3 examples. Scale up only when you can measure the improvement.
• Keep examples short — ideally the same length as your production inputs.
• Include at least one edge case; otherwise the model fails silently on the hard half of your traffic.
• Standardise format first (spacing, labels, separators), then worry about example content.
• Pin the most representative example last — recency bias is real.
• Measure 3 orderings on 20+ held-out inputs before shipping.
• Document which ordering you chose and why.
• Re-evaluate quarterly: when models update, the right example count can shift.
• If few-shot cost becomes significant at scale, cache the example block as a system message or use the provider's prompt-caching feature.

Few-shot vs zero-shot vs chain-of-thought

First-hand test: 3 patterns on the same task

Methodology (directional, not statistical). We built a 20-input classification set for a bespoke 4-label support ticket vocabulary (P1 / P2 / P3 / P4) with inputs mixed across all four labels. We tested the same task three ways against GPT-5 — zero-shot ("classify this ticket as P1/P2/P3/P4"), 3-example few-shot (easy / edge / representative, ordered easiest-first), and 5-example few-shot (one example per label plus one boundary case). Each configuration was run three times across three example orderings where applicable. n=20 is small; treat the numbers as directional rather than benchmark-grade.

What we learned. (1) Zero-shot failures were exactly what you'd expect — the model picked "high/medium/low" style labels and had to be mapped to P1–P4 by regex. The 35% error rate was 100% format drift, not misclassification. (2) 3-example few-shot fixed the format drift completely and moved from 65% → 85%. (3) Going from 3 to 5 examples added 5 points of accuracy but doubled the token cost — in a high-volume setting, 3 is the better default. (4) Order sensitivity showed up starkly at 5 examples: the same five examples in a different order dropped accuracy from 90% to 80%. We shipped the 3-example configuration with the easy→hard ordering documented in the prompt comments.

This is small-n and not a controlled experiment — the point is the shape of the result, which matches what the published benchmarks have found: few-shot gives you a sharp accuracy lift on structured tasks, with real cost and real sensitivity to how you order the examples.

FAQ

How many few-shot examples should I use by default?

Three. Start with 3 diverse examples for classification and extraction. Scale to 5–8 only for complex structured outputs where you can measure the gain. Above 8 examples, consider fine-tuning or RAG instead — token cost and order sensitivity both grow faster than accuracy.

Does the order of few-shot examples matter?

Yes, surprisingly a lot. Rearranging examples can shift accuracy by 10 points on the same prompt (Lu et al. 2022). Always test ≥3 orderings on a held-out set before shipping. Easiest-first and hardest-first both work; put your most representative example last to exploit recency bias.

Do I need correct labels in my few-shot examples?

Partially. The Min et al. 2022 paper famously showed that replacing correct labels with random labels only slightly hurt accuracy on many classification tasks. What matters most is that the label space, input distribution, and format of the examples match the task. Still — use correct labels. The surprising research finding is not a reason to be sloppy; it's a reason to understand what examples actually teach the model.

Is few-shot the same as in-context learning?

Yes. "Few-shot prompting" is the practitioner's name; "in-context learning" is the research name. Both describe the same thing: giving a model demonstrations in a prompt and asking it to generalise, without weight updates.

When should I use few-shot vs chain-of-thought?

Few-shot when you need format consistency, bespoke labels, or domain-specific tone. Chain-of-thought when the task requires reasoning — arithmetic, multi-step problems, planning. For the hardest reasoning tasks, combine them: 2–3 worked examples that each show reasoning out loud. See the pillar guide's chain-of-thought section.

Can I mix zero-shot and few-shot in the same prompt?

Not productively. If a prompt has examples, it is a few-shot prompt. The question is really whether to add examples at all — and if yes, 2–5 is the right range. Adding one example (one-shot) is usually worse than zero-shot or three-shot; the model treats one example as a strict rule rather than a pattern.

Do few-shot examples count against the context window?

Yes. Every token in every example is a token you're paying for and a token taken from the context budget. On modern frontier models with 200K+ context windows this rarely matters for small example counts, but at 10+ examples × 500 words each, you can push into the "lost in the middle" regime where the model under-weights content in the middle of a long prompt (Liu et al. 2023).

Should few-shot examples go in the system prompt or the user prompt?

Either, with trade-offs. System prompt: examples are cached across calls (cheaper), the pattern feels authoritative. User prompt: easier to swap at runtime, works with providers that don't support system-prompt caching. In practice, we put long static examples in the system message and dynamic context (the real input) in the user message. Both GPT-5 and Claude 4.7 Opus handle both patterns well.

Related prompts

• Browse the PromptSpace library — 4,000+ prompts organised by task and technique
• Prompt Lab — run few-shot patterns against GPT-5, Claude 4.7 Opus, and Gemini 2.5 Pro side-by-side
• PromptSpace Skills — curated skills for classification, extraction, and structured output

Related guides

• Prompt Engineering 2.0: The Complete Guide — the pillar hub this article supports
• Zero-Shot Prompting Explained: When It Works & When It Fails — the technique you try before reaching for few-shot
• How to Write AI Prompts That Actually Work — the fundamentals that make every technique more reliable

Sources

1. Brown, T. et al. (2020). Language Models are Few-Shot Learners. arXiv:2005.14165. The original GPT-3 paper that established the zero-shot / one-shot / few-shot terminology and reported the characteristic accuracy curve of in-context learning as a function of example count and model size.
2. Min, S. et al. (2022). Rethinking the Role of Demonstrations: What Makes In-Context Learning Work? arXiv:2202.12837. Shows that the input-label mapping in demonstrations matters surprisingly little; what matters most is the label space, input distribution, and format.
3. Lu, Y. et al. (2022). Fantastically Ordered Prompts and Where to Find Them. arXiv:2104.08786. Formal analysis of order sensitivity in few-shot prompting, showing permutation-induced accuracy variance of up to 25 points on GPT-era models.
4. Sahoo, P. et al. (2024). A Systematic Survey of Prompt Engineering in Large Language Models: Techniques and Applications. arXiv:2402.07927. Modern survey that treats few-shot in-context learning as a baseline across benchmark suites and maps it against the broader prompt-engineering stack.
5. Kojima, T. et al. (2022). Large Language Models are Zero-Shot Reasoners. arXiv:2205.11916. Introduces zero-shot chain-of-thought, which is often the right escalation from few-shot for reasoning tasks.
6. Liu, N. F. et al. (2023). Lost in the Middle: How Language Models Use Long Contexts. arXiv:2307.03172. Empirical evidence that the head and tail of long prompts receive more attention than the middle — relevant for ordering many-shot examples.

Try these few-shot patterns in Prompt Lab → PromptSpace Prompt Lab runs the five examples above against GPT-5, Claude 4.7 Opus, and Gemini 2.5 Pro side-by-side so you can see output stability and format drift directly. Browse 4,000+ curated prompts organised by technique, and continue the series with the next supporting article in the pillar cluster, Prompt Engineering 2.0: The Complete Guide.