Model Selection and Optimization

Model Selection and Optimization is 16.8% of the CCDV-F blueprint — roughly 9 of the 53 scored questions, and the second-largest domain after Applications and Integration. Its name is slightly misleading. The blueprint splits it into four sub-skills, and the two that sound like the domain title are the smaller half: Model Selection and Tradeoffs is 2.7% and Cost and Token Management is 2.8%. The larger half is LLM Fundamentals (5.2%) and Technical Fundamentals (6.1%) — 11.3% between them. Spend your prep memorising a price table and you will have optimised for a fifth of the domain.

What the bigger half tests is mechanism. How tokenization works and why a token count is model-specific. What a context window holds, and how max_tokens interacts with it. What adaptive thinking is, what the effort parameter does, and why fixed thinking budgets were replaced. Why prompt caching is a prefix match rather than a lookup, and what that implies for prompt ordering. This is where a candidate who has only ever reached the API through a framework wrapper gets caught, because frameworks hide exactly these parameters.

The selection half is small but very answerable: know the tiers, know that per-token price is not task cost, and know that the right question is 'what does this workload need' rather than 'which model is best'. Treat the domain as two-thirds mechanism, one-third judgement.

What the exam actually tests

• —Tokenization: tokens are not words, counts are model-specific, and third-party tokenizers do not apply to Claude
• —Context window vs. max_tokens — what each bounds, and that max_tokens caps thinking plus visible output together
• —Adaptive thinking (`thinking: {type: "adaptive"}`) and the effort levels that replaced fixed token budgets
• —The current model tiers and what separates them: capability, context window, and price per million tokens
• —Cost levers ranked: prompt caching, the Batch API, model tier, effort — and what each is actually worth
• —Why per-token price is not task cost, and when a cheaper model ends up more expensive

Tokens, context windows, and max_tokens

A token is a sub-word unit produced by the model's tokenizer, so token counts do not track words or characters, and they are model-specific — the same string tokenizes differently across model generations. The only reliable way to measure is the token-counting endpoint (`POST /v1/messages/count_tokens`) called with the same model ID you will use for inference. Third-party tokenizers built for other vendors do not apply and will misreport Claude counts. The context window bounds the whole request-plus-response; `max_tokens` separately caps what the model may generate in this response, and on thinking-enabled models that cap covers thinking tokens and visible text together. A `max_tokens` sized tightly around the expected answer is the usual cause of a response that truncates mid-sentence with `stop_reason: "max_tokens"`.

The model tiers and what separates them

Three properties distinguish Claude models on the exam: capability tier, context window, and price. At time of writing the developer-facing line is Claude Opus 5 (1M context, $5 per million input / $25 per million output), Claude Sonnet 5 (1M context, $3 / $15) and Claude Haiku 4.5 (200K context, $1 / $5); Claude Opus 4.8 remains available at Opus pricing. Do not memorise the numbers as gospel — published rates move — but do internalise the ordering and the ratios: output tokens cost roughly five times input tokens, and the Haiku tier is roughly a fifth of Opus on input. The exam is far more likely to ask which tier fits a workload than to ask you to recite a price. Model IDs are exact strings and must be used verbatim; inventing a date suffix on an alias produces a 404.

Adaptive thinking and the effort parameter

Current Claude models use adaptive thinking: you set `thinking: {type: "adaptive"}` and the model decides per request how much to reason, rather than being handed a fixed token allowance. The older `thinking: {type: "enabled", budget_tokens: N}` form has been removed from the current models and returns a 400 — it is a favourite distractor precisely because it was correct advice a generation ago. Depth and overall token spend are steered instead by `output_config: {effort: ...}`, which accepts `low`, `medium`, `high`, `xhigh` and `max`, defaulting to `high`. Higher effort means more reasoning and more, less-consolidated tool calls; lower effort means terser, cheaper, faster. Effort is the tuning dial an exam scenario expects you to reach for when a workload is too slow or too expensive but still needs to be correct.

Prompt caching is a prefix match, not a cache lookup

Prompt caching is the highest-leverage cost lever in most production applications, and it is misunderstood more often than any other API feature. The cache key is the exact bytes of the rendered prompt up to a `cache_control` breakpoint, and the render order is tools, then system, then messages. Any byte change anywhere in that prefix invalidates everything after it — a timestamp interpolated into the system prompt, a per-request UUID, a tool list that varies by user, a JSON blob serialised with non-deterministic key order. Cache reads bill at roughly a tenth of base input price; cache writes bill at a premium, so caching only pays once a prefix is reused. Verify with `usage.cache_read_input_tokens`: if it stays at zero across identical-looking requests, something in the prefix is changing.

Ranking the cost levers

Optimisation questions usually present four plausible actions and ask which comes first. The defensible ordering: cache the stable prefix (largest win when a big system prompt or document set is reused), move non-latency-sensitive work to the Batch API (a flat 50% discount on both input and output), choose the smallest tier that meets the quality bar, then tune effort down. Two things are not cost levers despite appearing as options: sending more context 'so the model needs fewer turns', and lowering `max_tokens` to force shorter answers — the first inflates every request, the second truncates output and buys a retry. Streaming does not reduce cost at all.

Where candidates go wrong

How to study this domain

Split your time the way the blueprint does, not the way the title suggests: roughly two-thirds on LLM and technical fundamentals, one-third on selection and cost. Start with one exercise that teaches most of the mechanism at once — take a real prompt, call the token-counting endpoint against two different model IDs, and watch the counts differ. That kills the rule-of-thumb habit permanently.

Next, build the smallest caching demo: a large stable system prompt with a `cache_control` breakpoint, two identical requests, and a print of `usage.cache_read_input_tokens`. Then break it by interpolating a timestamp into the system prompt and watch reads drop to zero. After that, prefix-invalidation questions are free marks.

For the selection half, skip the price flashcards. Build a two-column list instead: workload on the left (bulk classification, interactive chat, long-horizon agentic coding, latency-critical routing), the tier and effort you would defend on the right. Practise justifying each in one sentence. Finally, learn the short list of parameters that now return errors — fixed thinking budgets and sampling parameters — because those are the cheapest points here.

Common questions