- In short
- Model options such as extended or adaptive thinking and effort levels trade more computation for better reasoning on harder tasks, while shot-based prompting controls how many worked examples you provide: zero-shot gives instructions only, single-shot adds one example, and multi-shot adds several. More examples generally improve consistency on ambiguous or format-sensitive tasks, but extended thinking on simple tasks only adds latency and cost.
Two dials you can turn before touching the prompt wording
Beyond the words of a prompt, you have two structural levers for shaping how a Claude model responds. The first is a set of model options, extended thinking, adaptive thinking, and effort levels, that decide how much computation the model spends reasoning before it answers. The second is shot-based prompting, which decides how many worked examples you include. This knowledge point in the LLM Fundamentals task statement for the Claude Certified Developer - Foundations (CCDV-F) exam is about recognising both dials and knowing when turning them up actually helps.
Both dials cost tokens, which is why they sit on top of the tokens and context window fundamentals: extra thinking produces more output tokens, and every example you add is more input tokens filling the same bounded window. Turning a dial is never free, so the skill is matching the dial to the difficulty of the task.
- Shot-based prompting
- Providing worked examples in the prompt to shape the model's output. Zero-shot supplies instructions only, single-shot supplies one example, and multi-shot (few-shot) supplies several. Examples demonstrate the desired format and reasoning rather than describing them.
Model options: buying more reasoning
Extended thinking, adaptive thinking, and effort levels are all ways of giving the model more room to reason. Extended thinking lets the model work through a problem more deliberately before committing to an answer, which helps on genuinely hard, multi-step reasoning. Adaptive thinking adjusts how much of that deliberation the task actually warrants. Effort levels expose the same trade directly: more effort means more computation spent, aimed at harder problems.
The unifying idea is a trade: you spend more computation to get better reasoning on difficult tasks. That trade is worth it when the task is hard enough to need it. It is not worth it on simple tasks, and this is exactly where the CCDV-F exam sets a trap. Turning extended thinking on for a trivial classification or a short lookup does not make the answer meaningfully better; it mainly adds latency and cost. The correct instinct is to reserve heavier reasoning options for problems that genuinely reward them, not to leave them on everywhere as a supposed quality default.
Shot-based prompting: teaching by example
Shot-based prompting is the other dial, and it works by demonstration rather than instruction. In zero-shot prompting you give the model instructions and nothing else, trusting it to infer the desired shape of the answer. In single-shot prompting you include one worked example, showing an input and the exact output you want for it. In multi-shot (also called few-shot) prompting you include several such examples.
Examples are powerful because they pin down things that instructions describe only loosely: the precise output format, the tone, the level of detail, the way edge cases should be handled. The general rule the exam expects you to know is that more examples generally improve consistency on ambiguous or format-sensitive tasks. When the output must match a rigid structure, or when the instruction alone leaves room for interpretation, adding examples narrows the model onto the pattern you actually want.
This is also where shot-based prompting connects to sampling and non-determinism. Multi-shot examples reduce variation by demonstrating the target pattern so clearly that the most probable continuation is the one you want, which pairs naturally with a lower randomness setting when consistency is the goal. Examples and the randomness dial pull in the same direction: toward repeatable, on-format output.
Matching the dial to the task
The two traps this knowledge point flags are really the same mistake in two forms: reaching for a heavier option when a lighter one would do.
The first trap is enabling extended thinking for simple tasks. The reasoning budget goes unused, the response takes longer, and the cost rises, all for an answer that a standard response would have produced just as well. Extended thinking earns its place on hard problems, not as a blanket setting.
The second trap is expecting zero-shot to match multi-shot consistency on format-sensitive output. If you need output in a strict shape every time and you provide no examples, do not be surprised when the model interprets your instruction loosely and drifts across runs. On those tasks, the fix is not a longer instruction; it is one or more worked examples that show the exact shape. Recognising which dial a situation calls for, more reasoning, more examples, or neither, is the judgment this knowledge point tests.
Why this knowledge point matters
This concept sits at Bloom level understand and difficulty 2: you are expected to explain what each option does and reason about when to use it, not merely list them. It builds on the token fundamentals and feeds directly into model-selection judgment, where these same trade-offs recur. The decision of whether to spend more computation is the same shape as the quality, latency, and cost trade-offs you weigh when choosing among models, and knowing when a task needs heavier reasoning is part of matching work to the right model in Opus, Sonnet, and Haiku use cases.
Internalise the pairing and you will make two good calls reflexively: add examples when consistency matters, and save extended thinking for problems hard enough to reward it.
Worked example
A developer gets inconsistent output from a formatting task and reacts by enabling extended thinking, which does not help.
The task is to convert freeform product descriptions into a fixed JSON record with the same keys every time. Using a plain zero-shot instruction, the developer sees the model sometimes omit a key, sometimes reorder fields, and sometimes wrap the JSON in prose. Reaching for a quality lever, they enable extended thinking. Latency climbs, cost rises, and the format still drifts.
Both traps are on display. Extended thinking was the wrong dial: this is not a hard reasoning problem, it is a format-consistency problem, so the extra computation bought latency and cost without fixing the inconsistency. And zero-shot was never going to deliver the reliability the developer wanted on format-sensitive output.
The right move is the other dial. Add two or three multi-shot examples showing a description and its exact JSON record, and the model locks onto the pattern, emitting the same keys in the same shape far more consistently. Pairing those examples with a lower randomness setting tightens it further. The lesson is precise: match the dial to the task. Consistency on a format-sensitive job comes from examples, not from more thinking.
Common misreadings to avoid
Misconception
Turning on extended thinking always improves the answer, so I should leave it enabled everywhere.
What's actually true
Misconception
A well-written zero-shot instruction is as reliable as multi-shot for producing output in a strict format.
What's actually true
How it shows up on the exam
CCDV-F questions here describe a developer choosing between more reasoning and more examples, or one who reached for the wrong dial. A scenario about inconsistent, format-sensitive output points to adding examples; a scenario about a simple task made slow and expensive points to extended thinking being switched on needlessly. The correct answers track the two grounded rules: more examples generally improve consistency on ambiguous or format-sensitive tasks, and extended thinking on simple tasks only adds latency and cost. Match the dial to the difficulty and the questions resolve cleanly.
A team needs a classification prompt to return one of five exact labels every time, but zero-shot output occasionally returns a synonym or an explanation instead of a bare label. What is the most effective fix?
People also ask
What is the difference between zero-shot and multi-shot prompting?
When should you enable extended thinking?
Do more examples always improve output?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.