CCDV-F · module 2 of 8 · 16.8% of the exam

Model selection and optimization

Weight: 16.8 percent of the exam. Tests whether you can pick the right Claude model for a stated workload and then make that workload fast and affordable without degrading it.

What the exam expects

This domain is not a pricing quiz. Almost every question hands you a workload with at least one explicit constraint (a latency budget, a cost mandate, a document size, a deadline) and asks which choice respects it. The examiners are looking for three habits.

First, right-sizing. Model choice is a per-route decision, not a company policy. "Always use the most capable model" and "always use the cheapest" are both wrong answers, and the exam reliably offers you at least one of each as a distractor.

Second, knowing which lever solves which problem. Cost, latency, input size, and output size are four different constraints with four different remedies. A large fraction of the wrong answers on this domain are correct techniques applied to the wrong problem: raising max_tokens to fix an input-context problem, caching a prefix that differs on every request, or lowering the model tier when the actual issue was that the response was not streamed.

Third, recognising silent failures. Prompt caching in particular fails quietly. It does not error when it does not work; it just bills you full price. Several questions are built around a symptom (zero cache reads, an unexpectedly small input_tokens) and ask for the root cause.

The model lineup and how to right-size

As of 2026 the Claude 5 family is the current generation. Use the exact alias strings; they are complete as written, and appending a date suffix to one produces a 404 rather than a pinned snapshot.

Two things in that table decide questions on their own.

The context window is a hard constraint independent of difficulty. Haiku 4.5 tops out at 200K tokens while the Claude 5 family offers 1M. A 400,000 token document cannot be sent to Haiku no matter how simple the question about it is, and no request parameter changes that. When a scenario names a large single input, check the window before you reason about task difficulty at all.

Maximum output is a separate number. Current models generate up to 128K output tokens, but the SDKs require streaming for large ceilings because a long non-streaming generation exceeds HTTP timeouts. If a scenario describes a request that runs for minutes and then dies with a connection error, the answer is to stream, not to change models.

The decision heuristic the exam rewards: high volume, structurally simple, tight latency goes to Haiku; most balanced production work goes to Sonnet; complex, multi-step, expensive-to-unwind work goes to Opus; and the premium tier is reserved for tasks whose difficulty genuinely demands it.

Reasoning depth: adaptive thinking and effort

Two parameters control how hard the model works, and they are complementary rather than interchangeable.

thinking: {type: "adaptive"} lets Claude decide when and how much to reason. On the Claude 5 family the older fixed-budget form, {type: "enabled", budget_tokens: N}, is removed and returns a 400. If you see budget_tokens in a migration scenario, the fix is adaptive thinking plus an effort level, not a smaller budget.

output_config: {effort: ...} accepts low, medium, high, xhigh, and max, and defaults to high. Lower effort produces fewer and more consolidated tool calls, less preamble, and terser output. It is the right lever when an agent is chatty and over-stepping but the model choice is settled.

Two model-specific behaviours are worth memorising because they generate 400s:

• On Claude Opus 5, thinking is on by default when you omit the parameter, and thinking: {type: "disabled"} is accepted only at effort high or below. Pairing disabled thinking with xhigh or max is rejected.
• On Claude Fable 5, thinking is always on. An explicit {type: "disabled"} returns a 400; omit the parameter instead.

Also know that thinking.display defaults to "omitted" on current models. Thinking still happens and is still billed, but the blocks stream with empty text. A product that renders reasoning as a progress indicator must opt into display: "summarized" or its users will see a blank panel and a long pause.

The distinction the exam probes hardest: effort tunes how thoroughly a model works within its own capability ceiling; it does not raise that ceiling. A small model at max effort still cannot do what a larger model does.

Prompt caching: the prefix rule and what breaks it

Everything about caching follows from one invariant: it is a strict prefix match, and any byte that changes invalidates everything after it. The render order is fixed as tools, then system, then messages.

Practical consequences the exam tests directly:

• Stable content first, volatile content last. A timestamp, session ID, or UUID interpolated into the system prompt sits at the front of the prefix and invalidates the whole thing on every request. This is the single most common cache bug in the question banks.
• A breakpoint marks where a cached prefix ends. Placing cache_control after the user's specific question means every request writes a unique entry and reads nothing. For a shared preamble with a varying question, the breakpoint goes at the end of the shared part.
• Not all changes cost the same. Changing the tool list or switching models invalidates everything, because tools render at position zero and caches are scoped per model. Changing tool_choice, toggling thinking, or appending a message invalidates less. This invalidation hierarchy is worth knowing precisely.
• Determinism matters. Serialising a dictionary without sorting keys produces different bytes for identical logical content, which shows up as intermittent, pattern-free cache misses.
• Short prefixes silently do not cache. Each model has a minimum cacheable size. Below it, you get no error, just zeroed usage fields.

The economics: cache reads cost roughly 0.1 times base input price; writes cost about 1.25 times with the default five minute TTL, or about 2 times with a one hour TTL. So the five minute TTL breaks even at two requests and the one hour TTL needs about three. Bursty traffic with long idle gaps is the case for the longer TTL.

Verify with usage.cache_read_input_tokens. Zero reads across repeated identical-prefix requests means something is invalidating silently. And remember that input_tokens reports only the uncached remainder: total prompt size is input_tokens plus cache_creation_input_tokens plus cache_read_input_tokens. A cost dashboard that sums only input_tokens will wildly under-report a well-cached agent.

One timing detail that catches teams out: a cache entry becomes readable only once the first response begins streaming. Fan out 200 identical-prefix requests simultaneously and you get 200 writes and zero reads. Send one, wait for it to start, then send the rest.

Batch processing and the other cost levers

The Message Batches API bills token usage at 50 percent of standard prices. It is the correct answer whenever a scenario describes large, uniform work with no latency requirement: overnight enrichment, back-catalogue summarisation, bulk classification. Three facts decide questions:

• Results come back in arbitrary order and must be matched by custom_id. Keying by position is a bug.
• Most batches finish quickly, but the contract allows up to 24 hours. "Guaranteed within five minutes" is always a wrong option.
• Batching composes with caching. A shared document across every request in a batch gets both the discount and the cache reads.

Beyond batching and caching, the other genuine levers are model tier, effort, and structural changes such as routing cheap traffic to a smaller model behind a classifier. Note what is not a lever: truncating user input to save tokens changes the deliverable and is treated as an anti-pattern, not an optimization. If input does not fit, the correct response is to raise chunking or summarization rather than silently cut it.

For token estimates, always use the count_tokens endpoint with the same model ID the real request will use. Third-party tokenizers are calibrated for other model families and misestimate badly, especially on code and non-English text.

Latency optimization

Latency questions usually have one of four answers:

1. Stream. Long generations must stream, both to survive HTTP timeouts and to make time-to-first-token acceptable.
2. Lower effort, which reduces deliberation and tool-call chatter without changing models.
3. Right-size the model, moving simple high-volume calls to Haiku.
4. Warm the cache, so the first user of a deployment does not absorb a cold write.

Fast mode exists as well: it runs Opus-tier models at higher output tokens per second at premium pricing, on the first-party Claude API only. It is a real option, but the exam expects you to notice its platform and pricing constraints rather than reach for it reflexively.

How to think through the question

Domain 2 scenarios are dense with numbers, and most of those numbers are there to identify the binding constraint. Work through them in this order.

Step 1: name the binding constraint. Read the scenario for the thing that actually limits the design: a latency budget in milliseconds, a token count that exceeds a window, a cost mandate, a deadline, or the absence of one. There is usually exactly one, and it is stated explicitly.

Step 2: classify the constraint as input, output, cost, or latency. This single classification eliminates most distractors. Input-side problems (context pressure, oversized documents) are never solved by max_tokens. Output-side problems (truncation, timeouts) are never solved by caching. Cost problems have four candidate levers: tier, caching, batching, effort.

Step 3: ask what the question actually wants. "What should they do first?" wants the cheapest diagnostic or the blocking prerequisite. "What is the root cause?" wants a mechanism, not a remedy. "Which change most improves it?" wants the highest-leverage single move, which means you must compare the viable options rather than stopping at the first one that would help.

Step 4: eliminate options that ignore the stated constraint. An option recommending Opus for a 200 millisecond budget is out regardless of how it justifies itself. An option recommending synchronous processing for work due next week is out.

Step 5: eliminate over-provisioning and blanket policies. Anything phrased as "always use X" or "X should be the default for anything Y" is almost always wrong in this domain.

Worked example

A compliance team must answer 300 standardized questions against the same 60,000 token filing. Answers are needed by end of week. An engineer plans 300 synchronous requests, each carrying the full filing.

Step 1: the constraints are a large shared input (60,000 tokens repeated 300 times) and an explicitly loose deadline ("end of week").

Step 2: this is a cost problem, not a latency or window problem. The filing fits comfortably in a 1M context window, and nothing needs an immediate answer.

Step 3: the question asks which change most reduces cost, so we need the highest-leverage move, not merely a helpful one.

Step 4: any option that keeps the work synchronous is ignoring the loose deadline, which is the clearest signal in the scenario. That eliminates the "synchronous with caching" style options.

Step 5: now compare the survivors. Batching alone halves the rate. Caching alone makes the repeated filing roughly ten times cheaper to read. They compose, so the answer that applies both dominates either one. An option claiming they are mutually exclusive is asserting a rule that does not exist, which is a common distractor shape.

The answer is to submit all 300 as one batch with the filing in a cached shared prefix.

Exam traps

• "Raise max_tokens" for a context-window problem. Tempting because both are token limits; wrong because one caps output and the other constrains input. Compaction or context editing is the input-side answer.
• "Always use the most capable model to be safe." Tempting because it sounds risk-averse, and scenarios often add emotive framing (finance, healthcare, customer-facing) to reinforce it. The exam is testing whether you weigh cost and latency explicitly.
• Putting the specific question first "so the model sees it immediately." Intuitive, and exactly backwards for cache hit rate. Volatile content goes last.
• Reaching for budget_tokens as the modern way to bound reasoning. It reads as precise control; on current models it is a 400. Adaptive thinking plus effort is the replacement.
• Treating effort as a substitute for model tier. Both affect quality and cost, so they feel interchangeable. Effort works within a capability ceiling that only the model sets.
• Assuming batch results come back in order. Positional matching works in testing with tiny batches and corrupts data at scale.
• Concluding caching "does not work" because reads are zero. Zero reads is a symptom with a findable cause, usually a volatile prefix, a non-deterministic serialization, a varying tool list, or a prefix below the minimum size.
• Truncating input to control cost. Never the right answer, because it silently changes what the model is answering about.

Quick reference