"Zero-shot" means prompting Claude with instructions alone — no worked examples. "Few-shot" means including a handful of input–output demonstrations. Modern Claude models are strong zero-shot performers, which is exactly why the decision deserves thought: examples are no longer something you add by default, but a tool you reach for when the task has properties that instructions handle poorly.
Start zero-shot, and start clear
Anthropic's own prompting guidance leads with clarity, not examples. The golden rule from the official docs: treat Claude like a brilliant but brand-new employee — if a colleague with minimal context would be confused by your prompt, Claude will be too. A large fraction of "the model needs examples" cases are really "the instructions are ambiguous" cases. Before adding demonstrations, tighten the zero-shot prompt: state the audience, explain why constraints matter (Claude generalizes from reasons), spell out edge-case handling, and structure the prompt with XML tags. A clear zero-shot prompt is cheaper to run, easier to maintain, and easier to reason about when output goes wrong.
The two properties that justify few-shot
Task novelty. How far is your task from things that are common and well-specified? "Summarize this email" is well-trodden; Claude's defaults will be reasonable. "Classify support tickets into our nine internal categories, where 'Tier-2 Hardware' excludes peripherals but includes docking stations" is your organization's invention — no instruction short of a specification will pin down every boundary, and three or four boundary-illustrating examples will. The more house-specific the task, the more examples earn their tokens.
Output sensitivity. How much does the exact shape of the output matter downstream? If a human reads the result, small variations are harmless. If a parser, spreadsheet import, or another prompt consumes it, variations are defects. Examples are excellent at freezing format, tone, and level of detail — the things that are tedious to specify and easy to demonstrate. (For strictly machine-read JSON, skip ahead: structured outputs guarantee schema validity in a way no number of examples can.)
| Situation | Reasonable default |
|---|---|
| Common task, human reader | Zero-shot |
| Common task, machine-parsed output | Zero-shot + structured outputs |
| House-specific task, human reader | Few-shot (3–5 examples) |
| House-specific task, strict format or brand voice | Few-shot + structured outputs or tagged output |
Count the real cost
When you do add examples, follow the documented recipe — 3–5 relevant, diverse pairs wrapped in <example>/<examples> tags (see few-shot examples) — and then account for them honestly:
- Token cost is measurable, and often small after caching. The free token-counting endpoint tells you exactly what your example block adds; note that counts are model-specific, so recount against the model you'll actually run. A static example block placed before per-request content is cacheable, and cache reads bill at one-tenth the base input price on every platform (Amazon Bedrock requires explicit cache breakpoints).
- Maintenance cost is the sneaky one. Examples encode policy. When your categories or tone rules change, the examples must change too, or they'll quietly out-vote your updated instructions. Treat the example set as versioned config — see prompt versioning.
A hybrid worth knowing
Zero-shot and few-shot aren't exclusive. A common production pattern is a fully specified zero-shot instruction block plus one example whose job is purely to show the output shape — not to teach the task. That single demonstration removes most format drift at minimal token cost, and it's often all a well-instructed prompt needs.
Where to go next
Build the measurement habit with a prompt evaluation framework and A/B testing; the feature matrix shows which output-control features each platform supports.