TL;DR
Few-shot prompting means showing the AI two or more worked examples — Input A → Output B — instead of describing what you want, so it imitates the exact pattern, tone, and format you demonstrated. It is the strongest lock on custom output that exists — and the most expensive prompt you can send, because every example rides along in every message.
The Analogy
Try teaching someone a pirouette over the phone.
"Rotate your body 360 degrees on one leg, on the ball of your foot, arms rounded, head spotting." Technically complete. And utterly unteachable that way — the words describe the skill, but the skill isn't made of words. Now put the same student in front of a dance instructor, who says nothing and simply does three pirouettes, slowly, and says: "like that."
The student's body already knows more from three demonstrations than from any paragraph of description. Humans learn many things by imitation far faster than by instruction — and language models, it turns out, are built the same way. Show a model three examples of a pattern and it will often reproduce the pattern flawlessly, including details you never thought to mention and would not have known how to describe.
That's the whole distinction of this lesson. A one-shot prompt tells — verb, context, format — and for standard work (summarize, list, translate, rewrite), telling is enough, because the model already knows those dances. Few-shot prompting shows — you paste the dance itself, two or three performances of Input → Output, and the model mimics. Describing your company's peculiar support-ticket format in prose is the phone call. Pasting three real tickets is the demonstration.
One more thing about dance instructors: demonstrations aren't free. The instructor's time, the studio, the three slow performances — showing costs more than telling, every single session. Keep that thought; it becomes the economics of this whole technique.
How It Works & The Cost
A few-shot prompt is a stack of worked examples followed by a new input, structured so the pattern is unmistakable:
| Element | Role |
|---|---|
| Example 1: Input → Output | Defines the transformation |
| Example 2: Input → Output | Confirms it wasn't a coincidence |
| Example 3: Input → Output | Locks edge-case behavior (the tricky input shows how you want hard cases handled) |
| New input | The model's turn to continue the pattern |
The examples do something instructions cannot: they demonstrate everything at once — format, tone, length, capitalization, what to include, what to skip — including a hundred micro-decisions you never noticed you were making. "Apple → Pomme. Car → Voiture. Now translate: House." — three lines, and the model knows the language, the direction, the casing, and the register. No instruction paragraph could specify all of that in fewer tokens. This is why few-shot outperforms even excellent descriptions whenever the target pattern is custom: the model stops guessing your dialect and starts speaking it.
Now the bill. Every example you paste is text on the context window — the desk the model re-reads before every single reply. Examples don't evaporate after the first answer; they sit on the desk for the whole conversation, adding tokens to every subsequent message processed. Three meaty examples can easily outweigh the rest of the conversation combined. And in Uzu, where messages are priced in G-Credits, that physics becomes visible in your balance: a few-shot prompt simply costs more per message than a lean one-shot, and it keeps costing more for as long as the chat lives.
Hence the rule this curriculum runs on:
One-shot by default; few-shot by necessity. Show examples when the format or logic is truly custom — a house style, a parsing rule, a classification scheme with your own edge cases. If a clear instruction can capture it, tell it. Telling is cheaper — and often, it's enough.
The purest economy play: examples earn their price only when a wrong format would cost you more than the tokens did — a re-run, a manual cleanup, a downstream system that breaks on malformed output. That's the few-shot test: not "would examples help?" (they almost always help) but "does this pattern require demonstration?"
Before & After (The Prompts)
Example 1 — the house-style headline
Rewrite this feature announcement as a punchy headline in our brand voice.
"Brand voice" is a phone-call description of a pirouette. The model guesses — punchy to it, brand to it — and hands back something energetic and completely off-voice.
Rewrite this feature announcement as a headline matching our style. Our style:
Old dashboard, new dashboard → Your metrics called. They want a bigger screen. Offline mode shipped → Wi-Fi gone. Work ain't. Dark theme released → Night owls, this one's for you.
Feature announcement: Bulk export is live →
Three demonstrations and the model isn't guessing anymore — the length, the arrow format, the bolding, the wordplay register are all shown, including the micro-style you could never have specified. The fourth line completes a pattern, not an instruction.
Example 2 — the extraction format
Extract the date, city, and total from each receipt line below.
Simple enough — until your system consuming the output expects YYYY-MM-DD | CITY_UPPERCASE | cents-no-symbol, a format that exists nowhere in nature. The instruction version produces readable dates, proper city names, and a currency symbol — correct, and incompatible.
Extract each line into: date, city, total. Follow the pattern exactly:
"Paid $42.50 in Lisbon on 3 May" → 2026-05-03 | LISBON | 4250 "São Paulo, 12/Jan, R$199.90" → 2026-01-12 | SÃO PAULO | 19990
"Checkout Tokyo 7 Nov ¥3,000" →
Two examples, and the undocumented rules are taught: ambiguous day-month order resolved, accents kept in uppercase, symbols stripped, decimals converted to units. Machine-ready output from a model that was never "configured" for anything — it was shown.
Example 3 — the tone that must not drift
Make my customer replies warm but not gushing, professional but not stiff.
Every word in that sentence is a matter of taste, and the model's taste differs from yours. The reply comes back festooned with exclamation points — warm, per its reading.
Rewrite my draft replies to match this voice:
Draft: "Your refund was processed." → Reply: "Your refund is on its way — you'll see it within 3 business days. Thanks for your patience while we sorted this out." Draft: "The item is out of stock." → Reply: "That one sold out faster than we expected! We're restocking this week and I'll email you the moment it's back."
Draft: "Your account was suspended." →
Tone cannot be described; it can only be demonstrated. With two examples, the third reply lands in-voice automatically — no exclamation-point lecture required.
Common Pitfalls
- Conflicting examples. Example one outputs lowercase, example three capitalizes; one is formal, one cracks jokes. The model resolves the contradiction by averaging it — producing output unlike any of your examples. Audit your examples like audit findings: every detail must agree, because every detail teaches.
- Too many examples, blown desk. Ten examples "for safety" occupy the context window for the entire conversation — crowding out later context and inflating the token cost of every reply in Uzu. Two to four sharp examples almost always lock the pattern; add a fifth only when a specific edge case demands its own demonstration.
- Lazy examples. An example with a typo, a lazy output, or a format drift doesn't just fail to teach — it actively teaches your defect. The model will reproduce your errors with perfect fidelity. Polish examples like published copy.
- Using few-shot for standard tasks. Pasting three examples of "summarize in a paragraph" demonstrates nothing the model doesn't already do from one clear instruction — you're paying demonstration prices for a dance everyone knows. Save the technique for patterns that genuinely live only in your examples.
- Forgetting the examples persist. The stack you pasted at message one is still on the desk at message thirty — still costing tokens, still influencing tone. If a later task in the same chat needs different behavior, either start a fresh chat or explicitly retire the pattern ("new format from here: ...").
FAQ
What is the difference between zero-shot, one-shot, and few-shot prompting?
Zero-shot means asking with no examples — pure instruction, like "translate this to French." One-shot means including a single example to anchor the pattern; few-shot means two or more worked examples, which is where pattern-lock gets strong enough for custom formats. (This curriculum's "one-shot prompt" anatomy is about a complete single instruction — and when that instruction includes examples, it graduates into few-shot.) The more unusual your target pattern, the more examples it takes to teach it.
When should I use few-shot instead of just describing the format?
Use few-shot when the pattern is custom, precise, and costly to get wrong: house styles, parsing rules, classification schemes, output feeding another system — anything where prose description leaves the model guessing. If the format is standard (a table, five bullets, a paragraph) or a description can fully capture it, one-shot is faster, cheaper, and sufficient. The test: could a competent stranger reproduce your format from your description alone? If not, demonstrate.
Do examples make AI prompts more expensive?
Yes. Every example is tokens on the context window, and the window is re-processed for every reply in the conversation — so examples add cost not once but continuously. In Uzu, where messages are priced in G-Credits, a heavy few-shot stack is visibly the priciest prompt you can send. That's why the discipline is: demonstrate only what description can't capture, and keep examples to the minimum that locks the pattern.
Next Lesson
Few-shot asks you to already have perfect examples — but what about the pattern you can't show because you've never written it? There's a move for that: stop drafting the answer and start drafting the question. Hand the prompt-writing itself to the machine.
Continue to the next lesson: Meta-Prompting
Practice drill before you go: find one output format you've corrected the AI on more than twice. Build a three-example stack from your corrections — your drafts as inputs, your fixed versions as outputs — and run the next task through it. Notice what the model reproduces that you never wrote down.