What you’ll be able to do
- Explain tokens, context window, and what shares that budget
- State precisely what temperature 0 does and does not guarantee
- Choose between zero-shot, single-shot, and few-shot prompting
- Pick the right thinking mode and effort level for a task
What you need to know
Tokens and the shared budget
Tokens are subword units — roughly 3-4 characters of English — and they're what you're billed by, in both directions. The context window is the ceiling on how many fit in a single request.
The detail people miss: that budget is shared by everything in the call. System prompt, full conversation history, tool definitions, tool results, retrieved documents, and the response being generated, all inside the same limit. max_tokens caps only the output portion; it is not the context window and does not extend it.
This is why a long conversation with heavy tool output eventually fails even though each individual message is small — the accumulated total, not any one part, hits the ceiling.
Sampling, and the temperature misconception
The model produces a probability distribution over possible next tokens and samples from it. That sampling step is why two identical requests can return different text.
Temperature 0 reduces variation. It does not guarantee byte-identical output. This is the single most tested misconception in the domain, and it appears as a confident-sounding teammate assertion in the question stem.
The follow-on matters as much as the fact: if a design genuinely depends on identical responses, the fix is validation and normalisation on the receiving end, not a sampling parameter. Building a pipeline that assumes determinism and then setting temperature to 0 to make it true is the wrong shape.
The prompting ladder
- Zero-shot — instruction only. Correct default. Cheapest, and adequate for most well-specified tasks.
- Single-shot — one example. Useful when the format is unusual but the task is simple.
- Few-shot / multi-shot — several examples establishing a pattern. The standard upgrade when instructions alone don't generalise to edge cases.
Climb the ladder only when the rung below fails. Examples cost tokens on every single request, so few-shot as a reflex is a permanent tax to solve something a clearer instruction might have handled once.
Thinking modes and effort
Four options the blueprint names explicitly:
- Fast mode — minimal deliberation, lowest latency
- Extended thinking — the model reasons before answering; buys accuracy on genuinely hard problems, costs tokens and latency
- Adaptive thinking — deliberation scaled to apparent difficulty
- Effort levels — a dial on how much reasoning to spend
The tested judgment is proportionality. Extended thinking on a classification task that has one obvious right answer buys nothing and bills for the privilege. Fast mode on an ambiguous clinical case saves a little and gets it wrong.
Key concept
The context window is shared by everything in the request including the response. Temperature 0 reduces variation but never guarantees identical output. Climb the prompting ladder only when the cheaper rung fails.
Practice scenario
Work it through, then open this
Temperature 0 reduces variation; it does not guarantee byte-identical output. A pipeline that requires identical responses needs validation and normalisation on the receiving end. Building on the assumption and then reaching for a sampling parameter to make it true is the wrong shape.
Build exercise — Right-size one real pipeline
20 min
-
List every task in one pipeline and tag each as high-volume/bounded, balanced, or high-stakes/complex.
- Why: This tagging is the actual tier-selection judgment the exam tests, not a lookup table.
- You should see: Most tasks cluster at one end — pipelines are rarely evenly spread across all three.
-
For anything tagged high-volume, check whether it’s genuinely latency-tolerant.
- Why: This one fact decides Haiku+Batch versus Haiku real-time.
- You should see: A clear yes/no per task, not an assumption carried over from how it’s built today.
-
Re-price the pipeline in this order: cache the stable prefix, trim bloated context, right-size the tier, batch what tolerates delay.
- Why: Order matters — cheaper, quality-neutral levers come before touching model tier.
- You should see: A cost estimate that drops before you’ve changed a single model tier.
Exam traps
Believing temperature 0 produces byte-identical output
It reduces variation only. Designs that need identical responses need validation on the receiving end, not a sampling setting.
Confusing max_tokens with the context window
max_tokens caps the output. The window covers system prompt, history, tools, results, and the response together.
Reaching for few-shot examples as a first response
They bill on every request forever. Try a clearer, more specific instruction before paying that tax permanently.
Enabling extended thinking on simple bounded tasks
Deliberation on a task with one obvious answer adds cost and latency and buys no accuracy.