Prompting techniques are remedies for specific failure modes, not a ladder to climb. Anthropic’s prompt-engineering guide starts with three prerequisites: defined success criteria, a way to test against them empirically, and a first-draft prompt. It also notes that not every failing eval is best solved by prompting; sometimes selecting a different model improves cost and latency more easily, and tuning effort is a related lever (see 6.1). So the professional sequence is diagnose the failure, apply the smallest technique that addresses it, and measure (see 3.4 for diagnosis).
Zero-shot: the default, and where it stops being enough
Zero-shot means clear, direct instructions with the context and motivation behind them and no examples. Anthropic frames Claude as a capable new employee who lacks your norms: the more precisely you explain the task, format and reasons, the better the result. If a zero-shot prompt is correct and consistent on your eval set, stop; every added example or reasoning step costs tokens on every call.
Zero-shot stops being enough in recognisable ways: format drifts between runs, judgement on ambiguous cases is inconsistent, or extraction returns empty fields for information that is present but arranged differently from what the instructions imagined. More instructions rarely fix these; a demonstration usually does.
Few-shot (multishot): teach the pattern
Anthropic describes examples as one of the most reliable ways to steer output format, tone and structure. Its guidance for building them: make them relevant (mirroring the real use case), diverse (covering edge cases and varied enough that the model does not latch onto unintended patterns) and structured (wrapped in <example> tags, several inside <examples>, so they are not confused with instructions). The docs suggest 3 to 5 examples; do not memorise a number, because coverage of your failing scenarios matters more and your eval decides when more examples stop helping.
Two practices raise the value of each example. Include the reasoning for the choice (why this label or field value rather than a plausible alternative) so the model learns the principle instead of the surface pattern. And include negative and null cases, such as an input where a field is genuinely absent and the correct output is null, which also reduces fabricated values.
<examples>
<example>
<input>Please refund order 8891, it arrived broken.</input>
<reasoning>A specific order number plus a defect means an order-level
action, so the order tool is right, not the account tool.</reasoning>
<output>lookup_order</output>
</example>
</examples>Examples carry risks: they can over-anchor the model on their length, wording or label mix, they cost input tokens on every call (a stable block is a good caching candidate, see 6.5), and they go stale when policy changes. Evaluate on held-out cases, never on the examples in the prompt.
A practical mapping from symptom to first remedy:
| Symptom | First remedy |
|---|---|
| Inconsistent format or tone | Few-shot examples, or a schema if the format is machine-read |
| Invalid or non-conforming JSON | Structured outputs (output_config.format, strict tool use) |
| Fabricated values for absent fields | Nullable or optional fields plus an example that returns null |
| Inconsistent judgement on ambiguous cases | Explicit criteria plus examples with reasoning |
| Multi-step reasoning errors | Thinking and effort, or reasoning-style examples |
| Wrong tool chosen | Better tool descriptions first (see 1.1), then examples |
| Fields that should sum or reconcile do not | Validation and retry in code |
Key concept: match the technique to the failure mode
Instructions define intent, examples teach a pattern, schemas constrain format, thinking improves multi-step reasoning, and code validates invariants. Reaching for the wrong one is the classic mistake: “think step by step” does not fix an inconsistent output format, and few-shot examples do not guarantee valid JSON.
Chain-of-thought is now thinking plus effort
Classic chain-of-thought asked the model to reason in its visible answer. On current models the primary mechanism is thinking: when active, Claude reasons in thinking blocks before answering, which helps on maths, coding, analysis and long agentic work. Thinking tokens are billed as output tokens and count toward max_tokens, so it is a cost and latency decision. On Claude 4.6 and later models thinking is adaptive: the model decides when and how much to think, steered by the effort parameter and query difficulty. Defaults differ by model (see 6.1): on Opus 5 and Sonnet 5 it is on when you omit the parameter, on Fable 5.1 it is always on, and Haiku 4.5 uses the older manual mode. On Claude 4.7 and later models, setting budget_tokens returns a 400 error, so control depth with effort, and use max_tokens as the hard ceiling.
Anthropic’s prompting guidance for reasoning is short:
- Prefer general instructions (“think thoroughly”) over a hand-written step-by-step plan; the model’s reasoning often exceeds what you would prescribe.
- Few-shot examples work with thinking: put
<thinking>tags inside examples to show the reasoning pattern. - When thinking is off, manual chain-of-thought with
<thinking>and<answer>tags is a fallback. On Opus 5 the docs prefer keeping thinking on at a lower effort, because with thinking disabled the model can occasionally write tool calls as text or leak internal XML tags into its output. - A “verify before you finish” instruction catches errors on many models, but Opus 5 verifies on its own, and carried-over verification instructions there can cause over-verification.
Reasoning is not free and often unnecessary. For simple classification, extraction or formatting, extra thinking adds latency and cost with no gain; lower effort, or tell the model to respond directly when a question needs no reasoning. On Opus 5, Sonnet 5 and Fable models thinking text is omitted from responses by default, so if a product needs a visible rationale, request it in the output contract.
Structured output and measurement
Make the output contract explicit. Structured outputs guarantee schema-compliant JSON via constrained decoding (with documented limits: no recursive schemas, no numeric or string-length constraints, and refusals or truncation can still occur); they do not guarantee correct values. Because prefill on the last assistant turn is unsupported on Claude 4.6 and later models, use instructions or structured outputs to force a format.
Then run an ablation on a held-out eval set: zero-shot baseline, then add criteria, then examples, then thinking or higher effort, changing one thing at a time. Track pass rate by category, input and output tokens and latency. Examples add input tokens per call; thinking adds output tokens; so compare techniques by cost per passing case, not by accuracy alone (see 3.2 for eval design and 3.5 for cost optimisation). Anthropic’s eval guidance favours automated grading and, for LLM grading, a different model as grader than the one that generated the output.
Common exam distractor
When output format or judgement is inconsistent, “add more detailed instructions” and “turn on maximum reasoning” are the tempting wrong answers; diverse examples with reasoning (or a schema for machine-read format) is the fix. The mirror-image distractor is the belief that examples or structured outputs make the content correct: they fix pattern and format, not facts.