CCDV-F Domain 5: Model Selection and Optimization

Everything Claude reads and writes is measured in tokens, not characters or words. A token is roughly three to four characters of English text on average, though the ratio varies with language, code, and formatting — Claude never sees your prompt as a string, it sees a sequence of token IDs, and every billing figure, every context-window limit, and every output-length setting is denominated in that unit, not in bytes or words.

The context window is the combined budget for everything a single request touches: your system prompt, the full conversation history you resend, any tool definitions, and the space reserved for the response. It is not a per-turn allowance — in a multi-turn conversation, each new request typically resends the entire prior transcript, so the context window is a hard ceiling on how much history plus output a single call can carry, and it fills up in practice as a conversation grows even though the model's rated context-window number never changes.

Adaptive thinking is the mechanism that replaced the older fixed thinking-token-budget approach on the newest models. Instead of you specifying a hard token ceiling for the model's internal reasoning before it starts, the model decides for itself when a task warrants deeper reasoning and how much of it to do — you influence the depth through an effort setting rather than a token count. This has a direct latency and cost consequence: turning reasoning on, or raising effort, doesn't just change answer quality, it adds tokens you're billed for and time you wait for, on top of the visible response. A request that used to have a predictable token ceiling now has a more variable one, shaped by how hard the model judges the task to be.

• Higher effort settings generally mean more reasoning tokens, higher cost, and higher latency — not a free quality upgrade.
• Reasoning tokens are billed as part of output, even when the model's internal reasoning is never shown to the user.
• A task that doesn't need deep reasoning still pays some tax if effort is set too high for it — matching effort to task difficulty is itself a cost lever, not just a quality one.

It's easy to think of the SDK you import as its own thing with its own rules. Underneath, every SDK call is a thin wrapper around two transports: a standard request/response call for a complete answer, and a streaming transport that delivers the response incrementally as it's generated, for cases where you want to start displaying output before the model finishes. The SDK's job is ergonomics — typed request and response objects, automatic retries on transient failures, and helpers that assemble a streamed response into a single object for you — not new capability the underlying transport doesn't already expose.

This matters for the exam because it means nothing about pricing, context windows, rate limits, or model behavior lives "in the SDK." Those are properties of the account, the model, and the request itself. Swapping SDK language, or dropping to raw HTTP calls entirely, changes nothing about what you're billed or what the model can do — it only changes how much boilerplate you write to get there.

Two operational consequences follow directly from treating the SDK as a wrapper. First, error handling belongs at the transport layer: a rate-limit response, an authentication failure, or a malformed request comes back as a standard error your SDK surfaces in its own idiom, but the underlying cause and remedy are the same regardless of which SDK raised it. Second, because the SDK is not where model selection or cost logic lives, none of that logic should be hidden inside SDK configuration either — the model ID, the token budget, and the caching strategy are request-level decisions your application code should own and be able to reason about explicitly, not defaults buried in a client constructor.

The current lineup spans four tiers, and the exam expects you to reason about the tradeoff between capability, latency, and cost rather than defaulting to the most powerful option out of habit.

Notice that Sonnet 5's pricing is itself a real exam-relevant detail: at $2 input / $10 output per million tokens, it is cheaper than the prior generation Sonnet 4.6 was at $3/$15 — a reminder that a model tier's relative cost position isn't fixed across generations. A workload sized against last generation's pricing table needs to be re-sized, not assumed to still hold.

Fold adaptive thinking back into this decision: a harder task run on a cheaper model at high effort can end up costing more, in both tokens and latency, than the same task on a stronger model at lower effort — because effort spend and model capability are two separate levers on the same problem. Model selection and thinking configuration are not independent choices; they're two variables you tune together against the same latency and cost budget.

This is the domain's sharpest trap, and it's worth stating plainly: the request shape that configures extended reasoning is not the same across every current model, and code written against one model's shape can fail outright on another.

A related, narrower trap sits on the newest model tier specifically: temperature, top_p, and top_k are general Messages API parameters that exist and work on many models, but they are rejected outright — a 400 error — on the newest model tier. Developers who default to setting temperature on every request, out of habit from earlier model generations, will find that habit breaks the moment the same request is pointed at the newest tier. These are per-model restrictions to account for in a multi-model codebase, not universal parameters you can set once and forget.

• Never assume a request payload that works on one model tier is valid on another without checking that tier's supported parameters first.
• A codebase that routes across model tiers needs its request-building logic branched or abstracted by model capability, not written once against a single tier's shape.
• Treat "is this parameter still supported on the model I'm calling" as a standing question whenever you add a new model to an existing routing layer.

Anthropic exposes a dedicated endpoint for counting tokens before you spend money on a request: it accepts the same input shape as a normal Messages API call and returns just the input token count, and — unlike the inference call itself — it's free to use, though it's rate-limited separately from your inference traffic. Calling it before a request lets you estimate cost, check you're inside the context window, or decide whether to route to a cheaper model, all without paying for a completion.

Cost modeling for a real workload comes down to multiplying a per-request token estimate by request volume and by the model's per-token price — separately for input and output, since they're priced differently on every tier. The worked example below walks through exactly that arithmetic, once without any optimization and once with prompt caching applied to the stable portion of the prompt, so you can see where the savings actually come from and where they don't.

Worked example: suppose an application sends 10,000 requests per day, each with 2,000 input tokens — 1,500 of which are a stable system prompt plus shared context that doesn't change per request, and 500 of which are the unique per-request question — and 500 output tokens, running on Claude Sonnet 5 at $2 input / $10 output per million tokens.

Two things stand out. First, caching cut this workload's total daily cost by roughly 30% — but every dollar of that saving came from the input side; the $50-per-day output cost didn't move at all, because caching only discounts input tokens the model reads, never the tokens it generates. Second, the saving is conditional on the cache actually staying warm: if requests arrived more than five minutes apart on average, the default cache TTL would expire between requests, each one would repay the write premium, and much of this saving would evaporate. Caching is a lever you have to verify is working, not one you can assume is working from the mere presence of a cache marker — the next section covers exactly how to check.

Prompt caching lets you avoid re-billing full price for content that repeats identically across requests — a system prompt, a set of tool definitions, a large shared document — by writing it to a cache once and reading from that cache on subsequent requests at a steep discount.

• Cacheable: tools, system blocks, and message content — text, image, document, tool-use, and tool-result blocks.
• Not directly cacheable: thinking blocks (they're only cached as part of a prior assistant turn, not on their own), citations sub-content, and empty text blocks.

The order the request is rendered in matters: tools first, then system, then messages — and the cache breakpoint you mark applies to the last stable block before it, with a 20-block lookback for finding a matching prior cache entry. Content placed after your breakpoint is never cached, so volatile, per-request content belongs at the end of the request, after everything reusable.

Because a caching failure is silent rather than a hard error, the only reliable way to confirm caching is actually happening is to check the response's usage figures: cache_creation_input_tokens (tokens written to the cache this request) and cache_read_input_tokens (tokens served from the cache at the discounted rate). If both are zero across repeated, identical-prefix requests, the cache isn't engaging — check prefix length against the model's minimum, and check that nothing upstream of your breakpoint is varying between requests.