16 Model Selection & Optimization Practice Questions & Answers

1. 1. A developer asks how Claude actually produces its response text. Which description of the generation process is correct?

   • A.It retrieves the closest pre-written answer from a database of stored responses
   • B.It composes the entire response in a single step and then streams it for display purposes only
   • C.It selects one of several complete draft responses written in advance during training
   • D.It generates output one token at a time, with each new token predicted based on all the tokens that came before it✓ Answer

   Large language models are autoregressive: they repeatedly predict the next token conditioned on the full sequence so far, appending each prediction and repeating until a stop condition is reached. This is why output is metered and billed in tokens and why generation can be streamed token by token.

   Source: docs.claude.com — About Claude: Glossary (LLMs, tokens, pretraining/next-token prediction)Report a problem with this question

2. 2. What does a Claude model's "context window" refer to?

   • A.The total amount of tokens the model can work with in one request, covering both the input prompt (including conversation history) and the generated output✓ Answer
   • B.The maximum number of output tokens the model can produce, excluding the input
   • C.The number of API requests allowed per minute for the organization
   • D.The amount of text the model saw during training

   The context window is the model's working capacity for a single request: prompt tokens (system prompt, tools, conversation history, documents) plus the tokens it generates must all fit inside it. Because it is shared between input and output, long conversations must be budgeted, compacted, or trimmed so the total stays within the limit.

   Source: docs.claude.com — Build with Claude: Context windowsReport a problem with this question

3. 3. A developer sends the exact same prompt twice and gets two differently worded (but equally correct) answers. What is the best explanation?

   • A.The model was retrained between the two requests, changing its knowledge
   • B.The context window resets to a random size on every request
   • C.The API served a cached answer the first time and a fresh one the second time
   • D.LLM generation is non-deterministic: each token is sampled from a probability distribution, and even the most deterministic settings have never guaranteed byte-identical outputs✓ Answer

   Output tokens are chosen by sampling from the model's predicted probability distribution, so run-to-run variation is expected behavior, not a bug. Anthropic's documentation notes that even setting temperature to 0 on models that supported it never guaranteed identical outputs — applications needing exact repeatability must design for it (e.g., structured outputs, validation), not rely on determinism.

   Source: docs.claude.com — Glossary (temperature) and Model migration guide: sampling parameters and determinismReport a problem with this question

4. 4. On models that expose a temperature sampling parameter, what does raising the temperature do?

   • A.It expands the model's context window
   • B.It makes responses longer by raising the output token limit
   • C.It reduces latency by generating tokens faster
   • D.It makes token selection more random and diverse, because lower-probability tokens become more likely to be sampled✓ Answer

   Temperature rescales the probability distribution the next token is sampled from: higher values flatten the distribution so unlikely tokens are picked more often (more creative/varied output), while lower values sharpen it toward the most likely tokens (more focused output). It has no effect on speed, context size, or output limits.

   Source: docs.claude.com — About Claude: Glossary (temperature)Report a problem with this question

5. 5. A company processes millions of short customer-support tickets per day, tagging each with a simple category. Latency and cost per request are the dominant concerns, and the task is easy. Which model tier best fits this workload?

   • A.Opus with extended thinking enabled for extra accuracy
   • B.Haiku, the fastest and most cost-effective tier, since the task is simple and volume is high✓ Answer
   • C.Any tier works identically, since all Claude models cost the same per token
   • D.Opus, because the highest-capability model should always be used

   Model selection should match capability to task difficulty: Haiku is positioned as the fastest, most cost-effective tier for simple, high-volume tasks like classification, where the intelligence of Opus adds cost and latency without improving outcomes. The tiers have meaningfully different per-token prices and speeds, so routing easy work to the smallest sufficient model is the standard cost optimization.

   Source: docs.claude.com/en/docs/about-claude/models — model tier positioning (Haiku: fastest, most cost-effective)Report a problem with this question

6. 6. A team is building an autonomous agent for multi-hour code migrations and deep research runs that must sustain long chains of reasoning and tool use with minimal human correction. Which model tier is the recommended fit?

   • A.Haiku, because agents need the fastest possible responses
   • B.Opus, the most capable tier, designed for the hardest long-horizon agentic and reasoning work✓ Answer
   • C.A fine-tuned embedding model, since agents do not use chat models
   • D.Whichever model is cheapest, since agent harnesses equalize model quality

   Opus is Anthropic's most capable tier and is explicitly recommended for the hardest, longest-horizon problems: large code migrations, extended autonomous work, and deep research. Long agentic runs compound errors, so per-step capability matters most there — cheaper tiers win on fast turnaround and cost for easier tasks, not on sustained autonomous execution.

   Source: docs.claude.com/en/docs/about-claude/models — model tier positioning (Opus for hardest long-horizon agentic work)Report a problem with this question

7. 7. A startup wants near-frontier quality on everyday coding and agentic tasks, but at a noticeably lower per-token price and faster turnaround than the top tier. Which choice matches Anthropic's model-family guidance?

   • A.Sonnet, the middle tier that balances intelligence, speed, and cost for most production workloads✓ Answer
   • B.Running two Haiku calls and averaging their answers
   • C.Haiku, since it is the most intelligent model in the lineup
   • D.Opus in fast mode, which lowers the per-token price below Sonnet

   Sonnet is positioned as the balanced tier: it delivers strong (near-Opus on many coding/agentic benchmarks) intelligence at a lower per-token price and better speed than Opus, which is why it is the default recommendation for most production workloads. Fast mode does not reduce price — it increases output speed at premium pricing — and Haiku trades intelligence for speed and cost, not the reverse.

   Source: docs.claude.com/en/docs/about-claude/models — tier positioning (Sonnet: balance of intelligence, speed, and cost)Report a problem with this question

8. 8. What distinguishes adaptive thinking from the older manual extended-thinking configuration that used a fixed budget_tokens value?

   • A.Adaptive thinking disables reasoning entirely to save tokens
   • B.Adaptive thinking only works when streaming is disabled
   • C.Adaptive thinking moves reasoning to a separate, second model
   • D.With adaptive thinking, the model itself decides when to think and how much, including between tool calls, so there is no fixed thinking-token budget for the developer to tune✓ Answer

   Manual extended thinking required the developer to pick a fixed budget_tokens ceiling for reasoning; adaptive thinking replaces that with model-controlled reasoning depth — Claude decides per request whether and how much to think, and automatically interleaves thinking between tool calls. Developers steer overall depth with the effort setting instead of a token budget.

   Source: docs.claude.com — Build with Claude: Adaptive thinking (replaces manual budget_tokens extended thinking)Report a problem with this question

9. 9. What should a developer expect when lowering the effort level (e.g., from high to low) on a model that supports the effort parameter?

   • A.Fewer and more consolidated tool calls, terser output, and lower token spend — trading thoroughness for cost and latency✓ Answer
   • B.The model switches to a smaller model tier automatically
   • C.The context window shrinks proportionally
   • D.Responses become more accurate but slower

   The effort parameter controls how much work the model puts into thinking and acting: lower effort produces fewer, more consolidated tool calls, less preamble, and terser confirmations, cutting token spend and latency at some cost to thoroughness. It is the primary cost-quality dial on supported models — the model tier and context window are unchanged.

   Source: docs.claude.com — Build with Claude: Effort parameter (cost-quality tradeoffs)Report a problem with this question

10. 10. Which statement correctly describes fast mode?

    • A.It is free to use but reduces answer quality
    • B.It doubles the context window so prompts process faster
    • C.It silently substitutes a smaller, cheaper model to answer faster
    • D.It runs the same model with substantially higher output tokens per second, at premium per-token pricing and its own rate limit✓ Answer

    Fast mode is a speed option, not a model swap: the request runs on the same model but is served at a much higher output-token rate, and that throughput is billed at premium per-token pricing with a rate limit separate from standard traffic. Because quality is unchanged, the decision is purely a latency-versus-cost tradeoff.

    Source: docs.claude.com — Fast mode (same model, higher output speed, premium pricing, separate rate limit)Report a problem with this question

11. 11. A team migrates its code to a newer Claude model by changing only the model ID string. Their requests still include thinking: {type: "enabled", budget_tokens: 8000}, a parameter the newer model no longer supports. What happens, and what is the correct fix?

    • A.The request succeeds but is billed at double the normal rate
    • B.The API automatically converts it to the closest supported setting
    • C.The request is rejected with a 400 error; the fix is to remove the fixed budget and switch to adaptive thinking, tuning depth with the effort setting✓ Answer
    • D.The parameter is silently ignored, so no change is needed

    Removed request parameters are hard breaking changes: on models where the fixed thinking budget has been removed, sending budget_tokens returns a 400 invalid_request_error rather than being ignored or converted. Migration therefore requires a code edit — replace the manual budget with adaptive thinking and use effort to control reasoning depth — which is why migration guides tell you to audit parameters, not just swap the model string.

    Source: docs.claude.com — Model migration guide: breaking changes (budget_tokens removed → 400; use adaptive thinking)Report a problem with this question

12. 12. During a model migration, a team keeps its system prompt and tools byte-identical but changes the model ID. What happens to their existing prompt cache on the first request to the new model?

    • A.Caching is permanently disabled after any model change
    • B.The cache does not apply — prompt caches are scoped per model, so the first request on the new model pays full input price and writes a fresh cache entry✓ Answer
    • C.The old model's cache is merged into the new model's cache at no cost
    • D.The cache carries over automatically because the prompt bytes did not change

    Prompt caches are model-scoped: the cache key covers the model as well as the rendered prompt prefix, so switching models means no prior entry can match, even with identical bytes. The first request on the new model processes the full prompt at normal price (plus the cache-write premium if a breakpoint is set) and re-warms the cache; subsequent requests then read from it normally. Budget for this one-time cost spike when planning a migration cutover.

    Source: docs.claude.com/en/docs/build-with-claude/prompt-caching — caches are model-specific; migration guide note on cache invalidationReport a problem with this question

13. 13. What is the fundamental rule governing whether a prompt-cache checkpoint gets a hit?

    • A.Caching matches on overall topic similarity, so paraphrased prompts still hit the cache
    • B.The cache matches on prompt length, so any prompt of the same token count hits
    • C.Caching is an exact prefix match: any change anywhere in the content before a cache breakpoint invalidates the cache from that point onward, so stable content must come first and volatile content last✓ Answer
    • D.Only the final user message is checked; earlier content never affects cache hits

    The cache key is derived from the exact bytes of the rendered prompt up to each cache_control breakpoint, in the fixed render order tools → system → messages. A single differing byte — a timestamp, a reordered JSON key, a changed tool — invalidates everything after it, which is why the core design rule is: frozen, shared content first; per-request volatile content after the last breakpoint.

    Source: docs.claude.com/en/docs/build-with-claude/prompt-caching — prefix matching and cache invalidation rulesReport a problem with this question

14. 14. How does prompt caching change what you pay for a large, frequently reused prompt prefix (using the default short cache TTL)?

    • A.Reads cost the same as normal input tokens, but responses return faster
    • B.Caching only reduces output-token charges, not input-token charges
    • C.Writing the cache costs a small premium over normal input (about 1.25x), and subsequent reads cost only about one-tenth of the base input price — so the savings compound with every reuse✓ Answer
    • D.Both writes and reads are free once caching is enabled

    Cache economics work because the write premium is paid once and reads are drastically discounted: a 5-minute-TTL cache write bills at roughly 1.25x the base input rate, while every subsequent cache read bills at roughly 0.1x. That means the investment breaks even by the second request and yields near-90% input savings on the cached span thereafter — which is why caching is the first lever for cutting cost on chat, RAG, and agent workloads with a big shared prefix. Cache reads also reduce latency.

    Source: docs.claude.com/en/docs/build-with-claude/prompt-caching — pricing (writes ~1.25x for 5-min TTL, reads ~0.1x of base input)Report a problem with this question

15. 15. A developer added cache_control breakpoints, but usage.cache_read_input_tokens stays at 0 across many repeated requests. What is the most likely cause?

    • A.The account must be upgraded before caching activates
    • B.Cache reads are only reported once per day in usage statistics
    • C.Something in the prompt prefix changes on every request — such as a current timestamp or randomly ordered JSON in the system prompt — silently invalidating the cache each time✓ Answer
    • D.cache_control must also be set on the response object, not just the request

    Because caching is an exact prefix match, any per-request variation in the prefix — datetime.now() interpolated into the system prompt, unsorted JSON serialization, a UUID, a tool set that varies per user — makes every request a unique prefix that can never match a prior entry. There is no error; the only symptom is zero cache reads, so the fix is to diff the rendered prompt bytes between two requests, find the varying piece, and move it after the last breakpoint or make it deterministic.

    Source: docs.claude.com/en/docs/build-with-claude/prompt-caching — troubleshooting cache misses; usage.cache_read_input_tokensReport a problem with this question

16. 16. A team runs a nightly job that summarizes tens of thousands of documents. Results are needed by the next morning, not in real time. Which approach cuts the model bill the most for this workload?

    • A.Enable fast mode, which discounts tokens for large jobs
    • B.Raise max_tokens on every request so fewer requests are needed
    • C.Send all requests in parallel at midnight to get off-peak pricing
    • D.Submit the requests through the Batches API, which processes them asynchronously at a 50% discount off standard token prices✓ Answer

    The Batches API is the designated tool for non-latency-sensitive bulk work: batches are processed asynchronously (typically within an hour, up to 24 hours) and all token usage is billed at 50% of standard prices, while still supporting normal features like caching and vision. Fast mode raises cost for speed (the opposite tradeoff), there is no off-peak pricing, and raising max_tokens does not reduce the number of tokens billed.

    Source: docs.claude.com — Build with Claude: Batch processing (asynchronous, 50% discount on token prices)Report a problem with this question

Practice questions based on the official Claude Certified Developer – Foundations (CCDV-F) exam guide and Anthropic's public documentation. This is an independent study tool, not affiliated with or endorsed by Anthropic, and does not grant certification. The real exam is 53 questions, 120 minutes, passing at a scaled 720/1000, delivered via Pearson VUE ($125). Official certification page →