Domain 2 — Model Selection and Optimisation (16.8%)

16.8% of the exam, roughly 9 questions. Half LLM fundamentals, half the economics of running one in production.

2.1 Fundamentals worth being precise about

• Tokens are sub-word fragments, not words or characters. Rough English guidance is three to four characters per token, but it varies by language and by content — code, JSON and non-Latin scripts tokenise less efficiently. Tokenisers also differ between model generations, so a prompt counted against one model is only an estimate for another.
• The context window is the total budget for input plus output on a single request: system prompt, tool definitions, full message history, attachments, thinking blocks and the response. Exceed it and you get model_context_window_exceeded.
• The API is stateless. There is no server-side conversation. Every turn resends the entire history, which is why long conversations get progressively more expensive and eventually hit the window.
• Sampling: temperature controls randomness; top_p is nucleus sampling. Adjust one, not both. Low temperature for extraction, classification and anything you will parse; higher for drafting and ideation.

2.2 Counting tokens before you send

The token counting endpoint accepts the same inputs as a Messages call — system, messages, tools, images, PDFs — and returns input_tokens. It is free, separately rate-limited, and the right tool for three jobs: staying inside the context window, estimating cost before committing, and routing a request to a cheaper model when it turns out to be small. The count is an estimate; the authoritative figure is usage on the actual response.

2.3 Choosing a model

Two defensible starting strategies. Efficiency-first: start on the cheapest tier that plausibly works, evaluate against real cases, move up only where you find a capability gap. Best for prototyping, latency-sensitive paths and high volume. Capability-first: start at the top, get it working, then move down or reduce effort until quality degrades. Best for genuinely hard problems where you do not yet know what is required.

Either way the examinable step is the same: evaluate on your own task. "Pick the most capable model" and "always pick the cheapest" are both wrong answers when the stem gives you a way to measure.

The multi-model pattern — pair a cheap model with a capable one: the cheap tier handles routing, screening, extraction and the bulk of tokens, and escalates only the hard cases. This is frequently the correct answer to a question about cutting cost without losing quality.

2.4 Thinking and effort

Reasoning can be requested in two shapes, and you should recognise both:

• A manual budget — thinking: {"type": "enabled", "budget_tokens": N}. The minimum is 1,024 tokens and the budget must leave room under max_tokens, because thinking tokens are billed and counted as output. The budget is a target, not a cap; max_tokens remains the hard ceiling.
• Adaptive effort — the model decides whether and how much to think, steered by an effort level rather than a fixed budget. This is the direction newer models take.

Either way, reasoning costs output tokens and latency. Use it where the task is genuinely analytical; it buys nothing on extraction, formatting or classification.

2.5 Cost and token management

Caching mechanics worth memorising: at most four cache_control breakpoints; the hierarchy is tools → system → messages; mark the last block that stays identical across requests. Changing tool definitions invalidates everything below; changing tool_choice or adding an image invalidates messages only. Verify with cache_read_input_tokens and cache_creation_input_tokens — and note that input_tokens counts only what follows your last breakpoint.

2.6 Rate limits

Three separate limits apply per model: RPM (requests per minute), ITPM (input tokens per minute) and OTPM (output tokens per minute). Capacity refills continuously under a token-bucket algorithm rather than resetting on a clock, so a burst can trip a limit even when your average is comfortably inside it.

The detail worth knowing: cache reads do not count toward ITPM. Cached input is effectively free throughput, which makes prompt caching a way to raise capacity as well as to cut cost.

Every response carries anthropic-ratelimit-requests-remaining, anthropic-ratelimit-input-tokens-remaining, anthropic-ratelimit-output-tokens-remaining and matching limit and reset headers. Watching them lets you throttle before you are throttled, which is strictly better than reacting to 429s.

← Previous: Domain 1 — Applications and Integration  |  Next: Domain 3 — Agents and Workflows →