You loaded your prompt with 8 examples to “cover every case”. Now the output copies whichever example most resembles your input, even when the task needs fresh reasoning. Or worse: the output is a mosaic of all 8, blending phrases that should never coexist. More examples feel like they should produce more accurate outputs. Past a certain point they do the opposite. Examples crowd out the instruction, drift apart in style, smuggle in edge cases that mislead the common case, and burn tokens better spent on the task.
Fastest fix: count your examples; if you have 5 or more, cut to the 1-3 most typical ones, make them agree on style, and put the task instruction (Now do this for the input below:) immediately after them. If you are on a reasoning model (GPT-5.5 Thinking/Pro, Claude with extended thinking, Gemini 3.1 Pro), try deleting the examples entirely first — see the reasoning-model note below.
This page walks through why “more examples” is not “better output”, how to choose 1-3 examples that actually pin the result, and the one case where 2026 reasoning models flip the rule on its head.
The reasoning-model exception (read this first)
This changed since few-shot prompting became standard advice. On modern reasoning models that think before answering, few-shot examples often hurt rather than help.
- DeepSeek’s own R1 release paper reports that few-shot prompting “consistently degrades” R1’s performance and recommends describing the problem and output format directly in a zero-shot setting (DeepSeek-R1 paper).
- Studies on OpenAI’s o1-preview found the same: piling few-shot context onto a reasoning model degraded results, a sharp reversal from non-reasoning models (Microsoft, “From Medprompt to o1”).
The mechanism: a reasoning model that sees examples tends to imitate the surface pattern of those examples instead of using its own chain of thought to solve your case from scratch. The examples short-circuit the reasoning you are paying for.
Practical rule as of June 2026:
| Model type | Examples? | Examples used in 2026 |
|---|---|---|
| Reasoning / “thinking” mode | Try zero-shot first; add 1 example only for output format | GPT-5.5 Thinking & Pro, Claude Opus 4.7 / Sonnet 4.6 with extended thinking, Gemini 3.1 Pro thinking, DeepSeek R1 |
| Fast / non-reasoning mode | 1-3 examples usually help | GPT-5.5 Instant, Claude without extended thinking, classic chat completions |
If you are on a reasoning model, the rest of this page still applies for the format-anchoring example you may keep — but start by deleting the examples and stating the task plainly. Often that alone fixes the drift.
Common causes (non-reasoning models)
1. Stacking to “cover every case”
You added an example for edge case A, then one for edge case B, then “just in case” examples C through H. The collection now spans a wider style range than your real inputs.
How to spot it: 5 or more examples, each handling a different edge.
2. Examples drift in style or structure
Example 1 is concise. Example 4 is verbose. Example 7 uses bullets. The model averages them, and the output is inconsistent. Research on many-shot prompting finds that long, mixed example blocks raise the rate of output-format errors, because the extra length distracts the model from the required answer shape (Many-Shot In-Context Learning, Agarwal et al.).
How to spot it: your examples differ in length, register, or structure.
3. Examples include edge cases that mislead
You added an edge-case example. The model now treats that edge as the typical case and applies its handling to everyday input.
How to spot it: outputs handle edge cases well but mishandle the common case.
4. Examples occupy more tokens than the task
In a 2000-token prompt with 1600 tokens of examples, the task is 20% of the prompt. The model anchors on the dominant content — examples — and treats the task as a footnote.
How to spot it: token count of examples is greater than task + constraints + output spec combined.
5. No clear instruction after the examples
You ended on the last example with no “now do X for the input below”. The model assumes you want example 9 in the same vein and produces another example, not the answer.
How to spot it: the prompt ends on an example, not on a task verb.
Which bucket are you in
| Symptom | Most likely cause | Jump to |
|---|---|---|
| Output copies one example almost verbatim | Too many / too-similar examples, or reasoning model imitating | Step 1 / reasoning note |
| Output blends phrases from several examples | Examples drift in style (cause 2) | Step 1 + Step 2 |
| Common input handled like a rare edge case | Misleading edge example (cause 3) | Step 5 |
| Model returns another example, not the answer | No task instruction after examples (cause 5) | Step 3 + Step 4 |
| Output format keeps breaking on long prompts | Example block too large (cause 4) | Step 6 |
Before you change anything
- Count your examples. If over 4, you are likely past the sweet spot.
- Identify the typical case vs the edge cases among your examples.
- Decide which 1-3 examples are truly representative.
- Confirm your examples agree on style and structure.
- Plan to put the task instruction immediately after the examples.
- Check whether you are on a reasoning model — if so, plan to test zero-shot too.
Information to collect
- Current prompt with all examples.
- Output that drifted toward an example or blended several.
- Your typical input vs your edge cases.
- Token count of examples vs task (most playgrounds show a live token count).
- Model name and mode (Instant vs Thinking, extended thinking on/off) and any system prompt.
Shortest path to fix
Step 1: Cut to 1-3 representative examples
Pick examples that:
- Cover the typical case (not edge cases)
- Agree on style and structure
- Demonstrate the output shape clearly
For each remaining example, justify its inclusion in one sentence. If you cannot, cut it.
Step 2: Order examples by representativeness
Put the most typical example first. The first example anchors hardest; the last is recency-anchored.
Example 1 (most typical): ...
Example 2 (variant within typical range): ...
Example 3 (boundary of typical): ...Step 3: Label examples explicitly
EXAMPLE 1:
Input: <input 1>
Output: <output 1>
EXAMPLE 2:
Input: <input 2>
Output: <output 2>
NOW DO THIS FOR THE INPUT BELOW:
Input: <real input>
Output:The explicit NOW DO THIS label stops the model from continuing the example sequence.
Step 4: Put the task instruction immediately after examples
The task verb should be the last thing the model reads before generating. Recency works in your favor.
Step 5: Handle edge cases separately
If you genuinely need edge-case coverage, do not stuff it into the main few-shot. Route instead:
Main prompt: handle typical case (with 1-3 typical examples).
If input matches <edge condition>, route to a separate sub-prompt
with edge-case examples and edge-case rules.Edge handling stays off the common path.
Step 6: Audit example budget
If your examples exceed roughly 1000 tokens, prune them. Each example should be the minimum needed to demonstrate the pattern, not a full real-world specimen. Trimming here also reduces the format-error rate that long example blocks cause.
How to confirm the fix
- Number of examples is between 1 and 3 (or zero on a reasoning model that improved without them).
- All examples agree on style, structure, and tone.
- The most typical example is first.
- A
NOW DO THISor equivalent label appears immediately before the real input. - Output handles the typical case well, and you route edge cases separately.
- Running the same prompt 3 times produces consistent outputs (re-roll at the same temperature; if you are validating format, set temperature to 0 to isolate the example effect from sampling noise).
If it still fails
- Your typical case may not be well-defined. Write 1 ideal example and use only that.
- Examples may still drift. Audit them line by line for consistency in length, register, and structure.
- The task may not benefit from examples at all. Try removing them entirely — especially on a reasoning model.
- For very diverse inputs, switch to retrieval (RAG) that pulls the few most relevant examples per input instead of a fixed many-shot block.
FAQ
How many examples is “too many”? For non-reasoning models, 1-3 is the working sweet spot and gains usually flatten by 2-3. Going to 5+ tends to plateau and then decline as noise and format errors accumulate. Some classification tasks benefit from true many-shot (dozens of examples), but open-ended generation rarely does.
Should I use examples at all on GPT-5.5 Thinking or Claude with extended thinking? Start without them. Reasoning models often do better zero-shot; vendor research on R1 and o1 shows few-shot can degrade them. Keep at most one example, and only to pin the output format, not to teach the reasoning.
My output keeps copying one example word for word. Why? Either the examples are too similar to each other (so the model overfits to that one pattern), or a reasoning model is imitating the example instead of reasoning. Diversify or trim the examples, and on a reasoning model try deleting them.
Is more examples ever better? Yes, for narrow, well-defined classification on non-reasoning models, accuracy can keep rising into the dozens before saturating. But for writing, extraction, and Q&A, context dilution usually wins past a handful, so default to 1-3.
The model returns another example instead of answering. What did I do wrong?
The prompt ended on an example with no task instruction. Add an explicit NOW DO THIS FOR THE INPUT BELOW: line right before the real input (Step 3).
Prevention
- Default to 1-3 examples for most tasks on non-reasoning models; default to zero-shot on reasoning models.
- Audit example libraries quarterly and cut examples that drift from the standard.
- Keep the example budget under about 30% of total prompt tokens.
- Place the task instruction immediately after examples, never before.
- For diverse inputs, prefer dynamic example selection (retrieval) over static many-shot.
- When unsure about count, A/B test 1, 3, and 5 examples and pick the lowest count that hits quality.
Related reading
- Missing examples output drift
- Long prompt degrades output
- Prompt lacks source hierarchy
- Prompt lacks context hierarchy
- Role instruction alone not enough
Tags: #Troubleshooting #Prompt #Prompt quality #Prompt engineering