Model Selection and Optimization

What this domain tests

16.8% — about 9 of the 53 scored items, the second-heaviest domain on CCDV-F.

This is the domain first-hand reports single out. Candidates who passed describe CCDV-F as leaning hard on model configuration specifics — the tier trade-offs, fast mode, effort levels, adaptive thinking — and characterize those items as pure recall: you either know the parameter and where it lives, or you do not reason your way to it.

The four published skills and their weights:

Note the shape: Technical Fundamentals is the largest sub-skill here, and it is not about models at all — the blueprint scopes it to SDKs that wrap REST APIs, and websockets. The domain's title oversells the model-picking content; "Model Selection and Tradeoffs" is the smallest skill in it, at 2.7%.

One structural note before the detail. This is the fastest-moving material on the exam. Model names, prices, and context windows change on Anthropic's release cadence, and the exam guide itself carries a "subject to change without notice" line. Learn the mechanisms and the relative ordering — which parameter, where it lives, which tier trades what — and verify any absolute number against current documentation on the day you sit. Everything stated below reflects published documentation as of August 2026.

Theory outline

1. LLM Fundamentals (5.2%)

The blueprint scopes this to three clusters: basic model behavior (tokens, context windows, sampling, non-determinism, next-token generation), model options (fast mode, extended thinking, adaptive thinking, effort levels), and fundamental prompting techniques (zero-shot, single-shot, multi-shot).

The middle cluster is where the recall density is.

Tokens, windows, and non-determinism

A token is a sub-word unit; models generate one token at a time, each conditioned on everything before it. Two consequences the exam builds on:

• Output is inherently non-deterministic. Even with sampling turned all the way down, identical inputs never guaranteed identical outputs. Any answer option promising reproducible byte-identical generation is wrong.
• Token counts are model-specific. Tokenizers differ across model generations, so the same text can cost meaningfully different token counts on two models. Re-measure rather than assume.

The context window is the input ceiling; max_tokens is the separate output ceiling. Exhausting them produces different stop_reason values — model_context_window_exceeded for the window, max_tokens for the output cap.

Current tiers publish a 1M-token context window with a 128K output ceiling, except the Haiku tier, which is 200K in and 64K out (as of August 2026).

Thinking: adaptive is the modern shape

The single most important configuration fact in this domain.

Extended thinking with a fixed token budget is the legacy shape. You set thinking to enabled and supplied a budget_tokens value that had to be strictly less than max_tokens. That parameter is removed on current models and returns a 400; on the immediately preceding generation it is deprecated.

Adaptive thinking is the current shape. You set thinking to type adaptive, and the model decides when to think and how much per request. There is no token budget to tune. Adaptive thinking also enables interleaved thinking — reasoning between tool calls — automatically, with no beta header.

Two behavioral defaults that get tested:

• Whether omitting the thinking parameter means "no thinking" varies by model. On some current models an unset thinking parameter runs adaptive; on others it runs without thinking. Set it explicitly rather than relying on the default — and note the cost consequence: max_tokens caps thinking plus response text together, so a route that silently gains thinking can start truncating.
• Thinking display defaults to omitted on current models. Thinking blocks still appear in the response, but their text is empty. Set display to summarized to surface a readable summary. Display controls visibility only — thinking happens and is billed identically under every setting. To a streaming UI, the default looks like a long pause before any output appears.

The raw chain of thought is never exposed on any model. Summaries are what you get.

Effort

Effort sits inside output_config — not at the top level of the request. That placement is a recall item and a favorite distractor.

Levels, in order: low, medium, high, xhigh, max. The default is high, which is equivalent to omitting the parameter. Not every model supports every level; the top of the ladder arrived later than the rest.

Effort controls thinking depth and overall token spend together. Lower effort produces fewer and more consolidated tool calls, less preamble, and terser confirmations. The published guidance, in shape rather than absolutes:

Two judgment rules worth carrying:

• When output is shallow on a complex task, raise effort rather than prompting around it. Adding "think carefully" prose to a low-effort request is the weaker lever.
• At xhigh or max, set a large max_tokens. The model needs room to think and answer inside one budget; a tight ceiling produces a response that is mostly thinking followed by a truncation.

Fast mode

Fast mode runs the same model at a substantially higher output-tokens-per-second rate, at premium pricing. It is a research preview, restricted to the Opus tier, and first-party API only — not available on Bedrock, Vertex, or Foundry.

Three things are required on every request, together:

1. Call the beta messages endpoint.
2. Pass the fast-mode beta flag.
3. Set speed to fast as a top-level request parameter — not a header, not nested inside another object.

The response reports which speed actually served the request on the usage object. Fast mode draws on its own rate limit, separate from standard capacity for the same model, so a 429 there does not mean your standard quota is exhausted. On a rate-limit response you either wait out the retry-after or drop the speed parameter and fall back to standard — noting that switching speed invalidates the prompt cache, because speed is part of the cached prefix's identity.

Fast mode is not available with the Batch API. Requesting it on a model that no longer supports it returns an error rather than silently degrading.

Sampling parameters

temperature, top_p, and top_k are removed on the newest models and return a 400. On older models, the rule was that you use at most one of temperature or top_p, never both.

The exam-relevant consequence is what replaces them:

• If you used temperature at zero for determinism, the replacement is low effort plus a tighter prompt — and it is worth internalizing that temperature zero never guaranteed identical outputs anyway.
• If you used a high temperature for creative variance, the replacement is prompting — asking explicitly for varied phrasing, or having the model propose several distinct directions and choosing one.

Any answer option that reaches for temperature to solve a behavior problem on a current model is wrong twice over: it would 400, and it was never the right tool for instruction-following anyway.

Prompting techniques

The blueprint names zero-shot, single-shot, and multi-shot, and the distinction is just the number of worked examples supplied in the prompt:

Examples beat instructions for pinning down structure. Instructions beat examples for stating rules. (Prompt engineering proper is a separate domain on this exam at 11%.)

2. Technical Fundamentals (6.1%)

The largest skill in this domain, and the one whose title gives away least. The blueprint scopes it to foundational technical concepts supporting AI application development, specifically naming integrating with SDKs that wrap REST APIs and websockets.

The SDK sits on top of REST — and you should use it

The Claude API is a REST API; the official SDKs are typed clients over it. The exam's framing is that reaching past the SDK to hand-rolled HTTP is a choice with costs, and the costs are the tested part.

What the SDK gives you that raw HTTP does not:

Two consequences worth memorizing:

• Timeouts are themselves retried. Worst-case wall-clock is roughly the timeout multiplied by retries plus one — so a 10-minute timeout with the default two retries can block for about 30 minutes. A stem describing exactly that is describing configured behavior, not a hang.
• Catch a chain, most-specific first. A single broad catch discards the retryable-versus-terminal distinction the SDK went to the trouble of encoding. Rate limiting and a malformed request need different responses.

Credential resolution is not just one environment variable. An unset API key does not mean there are no credentials — the SDKs resolve through an ordered chain that also includes an auth token and a stored login profile, and a bare zero-argument client picks those up. The inverse is the classic trap: a stale exported API key silently outranks a profile, so requests quietly hit whichever organization that key belongs to. An empty-string key still occupies its precedence slot and authenticates as empty rather than falling through.

Websockets and the streaming reality

The blueprint names websockets, and the honest technical answer is the tested one: the Claude API streams over Server-Sent Events, not websockets. SSE is a one-directional server-to-client stream over ordinary HTTP, which is exactly the shape of token-by-token generation.

Where websockets legitimately appear is between your application and your own frontend. The common architecture is: browser holds a websocket to your server, your server holds an SSE stream to the Claude API, and your server relays tokens onward. That split matters because it is where an exam scenario about "real-time chat" resolves — the bidirectional transport is yours to own, the model transport is SSE.

Related asynchronous mechanics from this skill: consuming a stream without blocking, executing parallel tool calls concurrently, and polling batch status rather than holding a connection open.

3. Model Selection and Tradeoffs (2.7%)

The smallest skill in the domain despite naming it. The blueprint scopes it to Opus versus Sonnet versus Haiku use cases, adaptive thinking support, trade-offs across quality, latency, and cost, and breaking behavior changes across model releases.

The tier ladder

Learn the ordering, not the price list — prices change and the exam guide disclaims its own currency.

The selection heuristic the exam rewards: start at the simplest tier that meets the quality bar and move up on evidence, not on instinct. And note the interaction with effort — a mid-tier model at high effort can outperform a higher tier at low effort, so tier and effort are two dials on the same trade-off, not independent choices.

Three tier facts that are stable enough to memorize:

• Haiku is the only current tier with a materially smaller context window and output ceiling. If a stem needs a very large context, that alone eliminates it.
• Feature support is not uniform across tiers. Fast mode is Opus-tier only. Effort-level support has varied by generation. Never assume a parameter that works on one tier works on all.
• Each model family draws on its own rate-limit pool. Shifting traffic from one model to another neither frees headroom on the old pool nor inherits it.

Breaking behavior changes across releases

The blueprint names this explicitly, which makes it fair game, and it is the part candidates least expect.

Model upgrades are not pure string swaps. The categories of change:

The last row is the subtle one and it produces a specific exam scenario. A prompt tuned to overcome an older model's reluctance becomes over-aggressive on a newer, more literal one. Instructions written as "CRITICAL: you MUST always use this tool" cause overtriggering once the model follows instructions faithfully; the fix is to soften the language, not to add more guardrails on top.

The disciplined upgrade path is therefore: change the model ID, remove parameters that now error, re-baseline token counts and cost with the counting endpoint, re-tune effort, then re-run the eval set before promoting. And expect a cold prompt cache on the first request against the new model, because caches are model-scoped.

4. Cost and Token Management (2.8%)

The blueprint scopes this to token budgeting, cost management, usage tracking, cost modeling, and caching techniques — prompt caching and cache checkpointing.

Measuring before optimizing

The token counting endpoint is the ground truth, and counts are model-specific, so pass the model you will actually call. Never estimate Claude tokens with another vendor's tokenizer — it undercounts on ordinary prose and badly on code and non-English text.

The endpoint is stateless, which is exactly what makes a before-and-after diff easy: count each version separately and subtract.

Reading usage

Every response carries a usage object. The four fields that matter and the one misreading that gets tested:

Total prompt size is the sum of the three input fields, not input_tokens alone. A long-running agent showing a small input_tokens has not shrunk its context — it has cached most of it.

Cost modeling

Four levers, in rough order of impact for a typical application:

1. Prompt caching, when a large prefix repeats. Reads at about a tenth of full input price.
2. Message Batches, a flat 50% discount whenever nothing is waiting on the result.
3. Tier and effort, chosen per route rather than globally — cheap routes should not run at the same settings as hard ones.
4. Output length, since output tokens cost several times input tokens. Constraining verbosity through prompting is a direct cost lever.

Two structural notes: input and output are priced differently, with output the more expensive side, so an output-heavy workload has a different optimization profile from a context-heavy one. And a workload dominated by a repeated large prefix is a caching problem, not a model-choice problem — downgrading the tier there solves the smaller half.

Cache checkpointing

The blueprint's own term for deliberate breakpoint placement. The design rule follows from the prefix-match invariant:

Classify every input by how often it changes, order the prompt so stable content physically precedes volatile content, and place breakpoints at the stability boundaries.

Mechanics that bound the design:

• Maximum 4 breakpoints per request.
• 20-block lookback. Each breakpoint searches backward at most 20 content blocks for a prior entry. An agentic turn that appends many tool_use and tool_result pairs can blow past that in one turn and silently miss on the next request. The fix is an intermediate breakpoint inside long turns.
• Concurrency. A cache entry becomes readable only once the first response begins streaming. Firing N identical requests in parallel means all N pay full price. Send one, wait for the first token, then fan out.
• Pre-warming. A request with max_tokens set to zero runs prefill and writes the cache without generating output — useful at startup when first-request latency is user-visible. It is not worth doing when traffic is continuous enough to keep the cache warm on its own.

Invalidation is tiered. Changing tool definitions or the model invalidates everything. Changing the system prompt keeps the tools cache. Changing message content keeps tools and system. Toggling tool_choice or thinking keeps tools and system. So per-request tool_choice changes are nearly free; adding one tool mid-conversation is not.

Task budgets versus max_tokens

A distinction the exam can test directly, because the two look similar and behave oppositely.

Task budgets are a beta feature on recent models, set inside output_config. The reason to reach for one: on a long agentic run, max_tokens alone gives you a cliff — the model has no idea it is about to be cut off. A task budget lets it prioritize and finish cleanly.

Worked problems

Problem 1. A developer upgrading a summarization service to a current model changes the model ID and redeploys. Every request now returns a 400. The request sets temperature to 0.2 and configures thinking as enabled with a budget_tokens of 8000. What must change?

A. Lower budget_tokens below max_tokens B. Remove temperature and replace the thinking configuration with adaptive thinking, controlling depth through effort C. Move temperature inside output_config D. Add the extended-thinking beta header

Approach: Two independent removals collide in one request. Sampling parameters return a 400 on the newest models, and the fixed thinking budget was removed in favor of adaptive thinking. Both must go, and the replacement for depth control is the effort parameter — not a smaller budget.

Why the others fail: A applies the old constraint (budget under max_tokens) to a parameter that no longer exists on this model, and leaves temperature failing anyway. C invents a relocation; temperature has no home in output_config — it is gone. D reaches for a beta header, but adaptive thinking enables interleaved reasoning with no header at all.

Answer: B

Problem 2. A product streams reasoning to users so they can watch the model work. After moving to a current model, the UI shows a long blank pause and then the full answer at once. Thinking blocks are arriving, but their text is empty. What is the cause?

A. Adaptive thinking does not produce thinking blocks B. Thinking display defaults to omitted; set it to summarized to receive readable reasoning C. The raw chain of thought must be requested with a beta header D. Streaming must be disabled to receive thinking content

Approach: The symptom names itself — blocks present, text empty — which is exactly the documented behavior of the omitted display default on current models. The fix is a request-side parameter, not response handling. Note that display affects visibility only; thinking happens and is billed the same either way.

Why the others fail: A contradicts the stem, which says blocks are arriving. C describes something that does not exist — the raw chain of thought is never returned on any model, only a summary. D inverts the mechanism; streaming is what makes progressive reasoning visible in the first place.

Answer: B

Problem 3. A latency-sensitive Opus-tier route needs faster token output and the team is willing to pay a premium. A developer adds a speed parameter set to fast and redeploys against the standard messages endpoint. Nothing changes. What is missing?

A. Fast mode requires the beta messages endpoint and the fast-mode beta flag alongside the speed parameter B. speed belongs inside output_config next to effort C. Fast mode is enabled through a header only, not a request parameter D. Fast mode requires raising max_tokens

Approach: Fast mode is the exam's canonical three-part configuration: the beta endpoint, the beta flag, and speed as a top-level request parameter. Supplying one of the three does nothing. The other conditions worth remembering are that it is Opus-tier and first-party only.

Why the others fail: B confuses it with effort — effort is the parameter that lives inside output_config; speed is top-level. C states the opposite of the documented shape: the beta flag is a header-level concern, but speed itself is a body parameter. D is unrelated; max_tokens governs length, not throughput.

Answer: A

Problem 4. A research assistant sends its 30,000-token knowledge base as a cached prefix. To reduce latency, an engineer fires eight identical-prefix requests in parallel at startup. The bill shows eight cache writes and zero reads. Why?

A. Parallel requests are excluded from prompt caching B. A cache entry becomes readable only after the first response begins streaming, so concurrent requests cannot read what each other is still writing C. The prefix exceeds the maximum cacheable length D. Eight requests exceed the four-breakpoint limit

Approach: Eight writes and zero reads is the documented signature of the concurrency timing rule. Nothing is wrong with the prefix — the requests simply raced. The fix is to send one, wait for its first streamed token, then fan out the remaining seven, which will all read.

Why the others fail: A invents an exclusion; parallel requests cache normally once an entry exists. C is contradicted by the evidence — writes are succeeding, so the prefix clears the minimum, and there is no maximum that would apply here. D confuses per-request breakpoints with concurrent requests; the limit of four is breakpoints within a single request.

Answer: B

Problem 5. A coding agent runs long autonomous sessions. It currently sets a large max_tokens as its only spend control, and traces show runs that are cut off mid-edit with substantial work unfinished. Which change best addresses the failure mode?

A. Lower max_tokens so failures happen sooner and cheaper B. Add a task budget so the model paces itself across the loop and wraps up gracefully, keeping max_tokens as the hard per-response cap C. Drop effort to low to consume fewer tokens per step D. Switch to a smaller model tier

Approach: The failure is truncation without warning, and its root cause is that max_tokens is not surfaced to the model — it cannot pace against a limit it cannot see. A task budget is the model-aware control: the model sees a countdown across the loop and prioritizes accordingly. The two coexist, with max_tokens remaining the enforced ceiling.

Why the others fail: A makes the symptom more frequent, not less. C reduces per-step spend but does nothing about the model's blindness to the ceiling — and lower effort on a hard agentic task risks under-thinking. D trades capability for cost and leaves the same cliff in place, just further out.

Answer: B

Exam traps

• Reaching for budget_tokens. The fixed thinking budget is removed on current models and returns a 400. Adaptive thinking plus effort is the replacement — and effort is not a token count.
• Putting effort at the top level. Effort lives inside output_config. Levels are low, medium, high, xhigh, max, defaulting to high.
• Assuming thinking is visible. Display defaults to omitted — blocks arrive with empty text. Set display to summarized. Billing is unchanged either way, and the raw chain of thought is never returned.
• Configuring fast mode partially. All three are required together: the beta messages endpoint, the fast-mode beta flag, and speed set to fast as a top-level parameter. Opus-tier only, first-party only, not with the Batch API, and switching speed invalidates the cache.
• Using temperature to steer behavior. Sampling parameters return a 400 on the newest models. Determinism becomes low effort plus a tighter prompt; variance becomes explicit prompting.
• Confusing task budget with max_tokens. max_tokens is a hard, model-unaware per-response cap. A task budget is model-aware pacing across a loop, minimum 20,000 tokens. Only one of them prevents a cliff.
• Treating a model swap as a string change. Expect removed parameters, changed defaults, a different tokenizer, a cold cache, and shifted behavior. Re-baseline counts and re-run evals.
• Carrying forward aggressive prompt language. Instructions written to overcome an older model's reluctance cause overtriggering on a newer, more literal one. Soften the language rather than adding guardrails.
• Assuming feature parity across tiers and platforms. Fast mode is Opus-tier and first-party only; effort-level support has varied by generation; rate-limit pools are per-model-family, so moving traffic neither frees nor inherits headroom.
• Reading input_tokens as total prompt size. It is the uncached remainder only. Total equals input_tokens plus cache_creation_input_tokens plus cache_read_input_tokens.
• Estimating tokens with a third-party tokenizer. Undercounts Claude, worst on code and non-English text. Use the counting endpoint, with the model you will actually call.
• Forgetting the 20-block cache lookback. Long agentic turns that append many tool_use and tool_result pairs can exceed it and silently miss. Add an intermediate breakpoint.
• Calling websockets the model transport. The Claude API streams over Server-Sent Events. Websockets belong between your server and your own frontend, not between your server and the API.