Model selection and optimization

Start with the mechanics, because two exam questions live inside them. An LLM generates one token at a time, each chosen from what tends to follow the text so far — sophisticated autocomplete, not retrieval. That single property produces both the fluency and the fabrications: the model is never "looking things up" — it is continuing a pattern.

Hallucination therefore concentrates in the checkable specifics: names, dates, figures, quotations, URLs. And the exam’s rule of thumb follows: the more precise the statement, the more it needs verification.

The second mechanic: the next token is sampled, not deterministically retrieved, so the same prompt in fresh conversations can produce different answers. Test prompts across several runs; a citation that appears in one run and not another deserves suspicion. This is also why evals, not single trials, decide anything.

01The SDK layer

This domain also re-examines the API from the side you actually build on. The official SDKs — Python, TypeScript, C#, Go, Java, PHP, Ruby — are thin wrappers over the same REST endpoints you met in the Applications domain. A client method maps to an endpoint one-to-one, the statelessness is unchanged, and every fact about headers and error types still applies underneath. What the wrapper adds is the operational layer: authentication and version headers sent for you, typed request and response objects, automatic retries and backoff, streaming helpers that collect server-sent events into a finished message, and timeout and connection management.

Three SDK facts with exam mileage:

• —Python needs 3.10 or newer and ships sync and async clients that read ANTHROPIC_API_KEY from the environment — construct the client bare and the key never touches your code.
• —Streaming is the same POST /v1/messages with stream set — server-sent events over the ordinary request, not websockets.
• —The TypeScript SDK refuses to run in a browser bundle unless you explicitly override the guard, deliberately, because a bundled key is a published key.

02Choosing a model

The whole tier list in one table. Prices are US dollars per million tokens, input/output — the numbers the exam quotes:

Two window footnotes the exam leans on. Output ceilings scale with the window: the 1M-token models accept up to 128K output tokens per request against Haiku 4.5’s 64K. And the 200K tier is not Haiku-only — retired models such as Sonnet 4.5 sit on it too, so read the model ID in any window question before answering.

Cost-first is one honest strategy: start on Haiku 4.5 for prototypes, tight latency and high-volume simple work, and upgrade only where evals show a specific gap.

Capability-first runs the other way, and both are two-way streets: start on Opus 5.5, escalate to Fable 5.1 when even high effort fails your evals, then walk it back down as the workflow matures — effort lower, or a smaller model, once the evals hold steady.

The exam phrases the choice as scenarios: a latency-sensitive, budget-constrained ticket classifier is a Haiku answer, even though Opus is the general default.

03Effort and thinking — the dials people blur

Several models accept an effort setting that trades thoroughness against latency and cost without changing models — and the docs are blunt that tuning effort is usually a better lever than switching models. The ladder runs low, medium, high, xhigh, max. Most models default to high; Opus 5.5 to medium.

Effort governs every output token — text, tool calls and thinking alike — so it works with or without thinking enabled: it sets thoroughness per token rather than switching reasoning on. The pattern to recognise in questions: "same model, cheaper and faster" means turn effort down before you reach for a smaller model. And for long-running agentic work, the answer points the other way, to xhigh.

Two billing facts the exam extracts: thinking tokens are billed as output tokens and count inside max_tokens. And hiding the thinking text from the response (the "omitted" display default on several models) reduces latency, not cost.

One more speed option: fast mode, a research preview on the Opus line — requested with speed: "fast" plus the fast-mode-2026-02-01 beta header — delivering up to 2.5× the output token rate at premium prices. The gain is in generation speed, not in time to first token. Three more facts to pin:

• —Fast mode is an inference configuration, not a different model.
• —Switching it on invalidates the prompt cache.
• —It is unavailable through the Batches API.

04Counting, pricing and cost modelling

Claude bills per million tokens, by class: input and output at the list rates above, plus separate rates for writing a prompt cache (five-minute and one-hour flavours) and for hitting one. The accounting arrives itemised in every response’s usage field, and once caching is in play input splits three ways — input_tokens, cache_read_input_tokens and cache_creation_input_tokens — the same three classes the pricing distinguishes.

The token-counting endpoint measures a request before you send it — same inputs as messages (system prompt, tools, images, PDFs), no model run. Its uses: checking a request against rate limits before submission, routing decisions, and squeezing a prompt toward a target length. The blind spots are sharper:

• —It errors on server tools, the MCP connector and URL- or file-sourced content — send base64 instead.
• —It ignores caching entirely: passing cache_control does not simulate cache savings, because caching only happens on real requests.
• —It uses the tokenizer of the model you name — and the newest models’ tokenizer counts roughly 30% higher than the previous generation. Recount on the target model before migrating, or your old dashboards will under-project spend.

Fixed overhead is the sleeper cost: a short weather question with one tool definition is already hundreds of tokens before the user has said anything, and a base64-encoded PDF with a one-line instruction is thousands. Count, don’t estimate from message length.

The cost ladder from Anthropic’s own guidance is worth memorising in order. The free wins come first, with no quality given up:

• —Prompt caching.
• —Token hygiene — trimming the fixed overhead above.
• —Prompt audits against the actual model.
• —Batching at 50% off, when latency allows.
• —Spend limits as a backstop.

Only then the trade-offs that can cost quality: model choice, effort, output caps.

05The traps in this domain

• —"Effort and thinking are one setting" — no. Effort sets thoroughness per output token; adaptive and extended thinking are the reasoning controls.
• —"Every current model takes an effort level and adaptive thinking" — Haiku 4.5 takes neither: manual extended thinking, no effort dial.
• —"Hidden thinking is free" — reasoning tokens bill as output whether or not you see the text.
• —"Fast mode is a faster model" — same model, faster inference, premium price, cache-busting.
• —"The counting endpoint previews my caching bill" — it ignores caching altogether.
• —"Newer models cost more" — the reverse: Opus 5.5 lists at $4/$20 against the older 4.1’s $15/$75. The model ID is itself a cost decision.
• —"Lowest per-token price is cheapest" — compare cost per completed task.