22 Model Selection & Optimization Practice Questions & Answers

1. 1. A retail analytics team needs to classify 400,000 archived support tickets. The output feeds a report that is read the next morning, so no result is needed in real time. Their only stated goal is to reduce spend. Which approach best fits the constraint?

   • A.Enable streaming on every request to lower the cost per token
   • B.Fire all 400,000 requests concurrently against the synchronous endpoint so the job finishes sooner
   • C.Raise max_tokens on each request so fewer total requests are needed
   • D.Submit the work through the asynchronous message batch endpoint, which processes latency-tolerant jobs at a reduced token rate✓ Answer

   The batch endpoint exists precisely for high-volume, latency-tolerant work: requests are processed asynchronously and billed at a discount off standard rates. Parallelizing synchronous calls changes only wall-clock time, not price, and neither max_tokens nor streaming affects the per-token rate.

   Source: Anthropic docs — batch processing (asynchronous, discounted token usage)Report a problem with this question

2. 2. A live customer-chat assistant is missing its time-to-first-token target. The prompt is already small and the answers are short. Which change is most likely to reduce perceived latency?

   • A.Increase max_tokens so the model has more room to answer quickly
   • B.Add a cache breakpoint at the end of each request's unique user question
   • C.Lower the reasoning effort setting and stream the response instead of waiting for the complete message✓ Answer
   • D.Move the traffic to the asynchronous batch endpoint

   Lower effort makes the model generate fewer reasoning and output tokens, and streaming delivers text as it is produced instead of after the whole message is finished — both directly attack latency. Batching is asynchronous and is the wrong tool for interactive traffic; raising max_tokens is only a ceiling and speeds up nothing; a breakpoint on per-request unique text can never be re-read.

   Source: Anthropic docs — effort and streaming (latency levers)Report a problem with this question

3. 3. An engineer added a cache breakpoint to a large shared system prompt, but the cache-read token field is zero on every request. The system prompt begins with a line that interpolates the current date and time. What is happening?

   • A.Cache reads are only reported after the entry has been read at least twice
   • B.System prompts are never cacheable; only conversation messages are
   • C.The interpolated timestamp changes the prefix bytes on every request, so no prior cache entry can ever match✓ Answer
   • D.The breakpoint must be placed on the tool definitions instead of the system prompt

   Prompt caching is an exact prefix match, so a single differing byte anywhere before the breakpoint invalidates the entry and everything after it. A timestamp at the very start of the system prompt guarantees a unique prefix per request — move volatile values after the last breakpoint, or drop them.

   Source: Anthropic docs — prompt caching (prefix match, silent invalidators)Report a problem with this question

4. 4. A service builds part of its system prompt by serializing a configuration object to JSON and iterating over an unordered set of feature flags. Cache hit rate is near zero even though the underlying configuration never changes. What is the most likely cause?

   • A.The cache only stores plain text, so JSON content is skipped
   • B.Serialization is non-deterministic, so the same configuration renders to different bytes and produces a different prefix each time✓ Answer
   • C.Feature flags force the request onto a different model, which invalidates the cache
   • D.Configuration objects cannot be included in a cacheable prefix

   The cache key is derived from the exact rendered bytes, so unsorted object keys or iteration over an unordered collection can emit logically identical content in a different order and break the match. Sort keys and iterate a deterministic sequence so the same configuration always renders identically.

   Source: Anthropic docs — prompt caching (deterministic serialization)Report a problem with this question

5. 5. A long-running agent enjoys high cache hit rates until the application starts adding and removing tool definitions between turns to reflect the user's current permissions. Cache reads collapse to zero for the rest of the session. Why?

   • A.Tool definitions are never part of the cached prefix, so caching stops once any tool is declared
   • B.Permission checks disable caching for the remainder of the session
   • C.Each tool definition consumes one of the available cache breakpoints
   • D.Tool definitions render at the very front of the prompt, so changing them changes the prefix ahead of the system prompt and all messages✓ Answer

   The prompt renders in a fixed order — tools, then system, then messages — so a change to the tool list sits ahead of everything else and invalidates the entire cached prefix. Keep the tool list stable for the lifetime of a conversation and express variable capability some other way.

   Source: Anthropic docs — prompt caching (render order and invalidation hierarchy)Report a problem with this question

6. 6. A team is restructuring a prompt so that caching works. The prompt contains a fixed 30-page policy manual, a per-session user profile, and the user's current question. In what order should these be placed for the best cache reuse?

   • A.The order does not matter as long as a cache breakpoint is present somewhere
   • B.Current question first, then the policy manual, then the session profile
   • C.Session profile first, then the current question, then the policy manual
   • D.Policy manual first, then the session profile, then the current question last✓ Answer

   Because matching is a prefix operation, content must be arranged from most stable to most volatile: anything that changes must sit after everything you want reused. Putting the per-request question anywhere before the manual would give every request a unique prefix and make the large stable block uncacheable.

   Source: Anthropic docs — prompt caching (stable content first, volatile content last)Report a problem with this question

7. 7. A developer says caching is "definitely working" because the request includes a cache breakpoint and latency feels better. What is the correct way to confirm that the cache is actually being read?

   • A.Measure end-to-end response time and compare it against an earlier run
   • B.Read the cache-read token field in the response's usage object and confirm it is non-zero across repeated requests✓ Answer
   • C.Confirm the request body contains a cache breakpoint marker
   • D.Check that the response contains fewer output tokens than before

   A breakpoint is only a request that the prefix be cached; the response's usage object is the authoritative record of what actually happened, and the cache-read field reports how many tokens were served from cache. Latency is confounded by load and output length, so it cannot prove a hit.

   Source: Anthropic docs — prompt caching (verifying cache hits via usage)Report a problem with this question

8. 8. After a multi-hour agent run, an operator sees a very small uncached-input token number in the usage data and concludes that telemetry is broken because the conversation was clearly enormous. What is the correct interpretation?

   • A.Long conversations stop reporting token usage once they exceed a certain length
   • B.Total prompt size is the uncached field plus the cache-write and cache-read fields; a small uncached number means most of the prompt was served from cache✓ Answer
   • C.The uncached field always reports the full prompt, so the number proves the history was silently discarded
   • D.Cached tokens are removed from the context window, which is why the count is small

   The uncached-input field counts only the remainder that was processed at full price after the last matched breakpoint, so it must be added to the cache-write and cache-read fields to recover the true prompt size. A tiny uncached number alongside a large cache-read number is evidence that caching is working well, not that data is missing.

   Source: Anthropic docs — prompt caching (token accounting in usage)Report a problem with this question

9. 9. A batch job sends one request per document, and every document is different from its first token. A developer proposes adding cache breakpoints to "save money on all of them." What is the expected outcome?

   • A.Costs drop only after the first request, once the cache has warmed up
   • B.Costs rise slightly, because each request pays the cache-write premium and no request can ever read a shared prefix✓ Answer
   • C.Costs stay identical, because breakpoints on unique content are silently ignored and never billed
   • D.Costs drop, because each document is cached for later reuse by the same request

   Caching pays off only when many requests share the same leading bytes: a cache write costs more than an ordinary input token, while a cache read costs far less. With no shared prefix there are no reads to amortize the writes, so the net effect is a small increase in cost.

   Source: Anthropic docs — prompt caching (write premium vs. read discount, break-even)Report a problem with this question

10. 10. Two request shapes are proposed for a document Q&A feature. Shape A puts the retrieved document first and the user's question last. Shape B puts the user's question first and the retrieved document last. Documents repeat often across users; questions never repeat. Which shape is cacheable and why?

    • A.Shape B, because the shortest element should always come first
    • B.Shape A, because the repeated document forms a shared leading prefix that later requests can match✓ Answer
    • C.Both, because the same total content is present in each request
    • D.Neither, because content retrieved at runtime can never be cached

    Matching starts at the very first token, so a reusable prefix only exists if the repeated content comes first. In shape B the unique question sits at position zero, which makes every request diverge immediately and leaves nothing for a later request to match.

    Source: Anthropic docs — prompt caching (shared prefix, varying suffix)Report a problem with this question

11. 11. A short system prompt is marked with a cache breakpoint. Requests succeed with no error, but the cache-creation token count stays at zero and nothing is ever cached. What is the most likely explanation?

    • A.A malformed breakpoint always fails silently instead of returning an error
    • B.Short prompts are cached but the usage fields are only populated for large prompts
    • C.The prefix is shorter than the minimum cacheable length for that model, so caching is skipped silently✓ Answer
    • D.The cache entry expired before the response was returned

    There is a minimum cacheable prefix length, and it differs from model to model; a prefix below that threshold is simply not cached and the request succeeds with no warning. Because the failure is silent, the only way to detect it is to check the cache token fields in usage rather than assume the breakpoint took effect.

    Source: Anthropic docs — prompt caching (model-dependent minimum cacheable prefix)Report a problem with this question

12. 12. A service fans out 50 identical-prefix requests at the same instant to speed up a batch of variations. None of them register a cache read. What should the service do instead?

    • A.Add a second cache breakpoint to each of the concurrent requests
    • B.Send all 50 requests twice, discarding the first round
    • C.Reduce the size of the shared prefix so it can be written faster
    • D.Send one request first and wait until its response begins before firing the remaining requests✓ Answer

    A cache entry is not readable while it is still being written, so simultaneous identical requests all miss and all pay the full uncached price. Firing one request first and waiting for its response to begin lets that request write the entry, after which the remaining requests can read it.

    Source: Anthropic docs — prompt caching (concurrent request timing)Report a problem with this question

13. 13. Mid-conversation, an application switches to a different model to save money on the remaining turns, keeping the exact same system prompt, tools, and message history. What happens to the prompt cache?

    • A.The existing cache cannot be reused, because cache entries are scoped to the model that created them✓ Answer
    • B.The cache transfers automatically because the rendered bytes are unchanged
    • C.The cache is reused but billed at the write rate for the first request
    • D.Only the tool portion of the cache is lost; system and messages still hit

    Caches are model-scoped, so switching models invalidates the whole prefix and the next request pays a full cold write on the new model. If part of a workload genuinely belongs on a cheaper model, isolate it in its own conversation rather than switching models inside one cached thread.

    Source: Anthropic docs — prompt caching (model-scoped cache entries)Report a problem with this question

14. 14. A multi-tenant assistant interpolates the signed-in user's name and account ID into the top of its shared system prompt. Cache reads occur only when the same user sends several messages in a row. What single change most improves cache reuse across the whole user base?

    • A.Shorten the system prompt so per-user variation matters less
    • B.Move the per-user details into the tool definitions instead
    • C.Keep the system prompt identical for every user and inject the per-user details later, after the cached prefix✓ Answer
    • D.Give each user their own cache breakpoint inside the system prompt

    Any per-user value placed near the front of the prompt creates a separate prefix per user, so nothing can be shared across tenants no matter how many breakpoints are added. Freezing the shared prefix and moving identity details into later message content restores a single cache entry that every user's request can read.

    Source: Anthropic docs — prompt caching (per-user prefixes as a silent invalidator)Report a problem with this question

15. 15. A team's older integration allocates a fixed number of reasoning tokens per request and tunes that number by hand for each route. They want to modernize the configuration. What is the current recommended approach?

    • A.Set the reasoning budget equal to the output ceiling so it is never a constraint
    • B.Disable reasoning entirely and compensate with a longer system prompt
    • C.Keep the fixed token budget but recalculate it after every model release
    • D.Use adaptive reasoning and control depth with the effort setting, letting the model decide how much to reason per request✓ Answer

    Adaptive reasoning replaces the hand-tuned fixed budget: the model scales reasoning to the difficulty of each request, and the effort setting expresses the depth-versus-cost preference declaratively. A hard-coded token budget has to be re-tuned for every prompt and every model change, which is exactly the maintenance burden the adaptive mode removes.

    Source: Anthropic docs — adaptive thinking and effortReport a problem with this question

16. 16. An engineering workflow is accurate but slower and more expensive than the budget allows. Evaluations show the current model handles the task well. What should be tried first?

    • A.Remove reasoning output from the response so fewer tokens are billed
    • B.Immediately switch to the fastest, lowest-cost tier available
    • C.Reduce max_tokens so the model is forced to answer sooner
    • D.Step the effort setting down on the same model and re-run the evaluation to see whether quality holds✓ Answer

    Effort is a within-model lever on how many reasoning and output tokens are spent, so lowering it trades depth for latency and cost without giving up the capability you already validated. Jumping straight to a different tier changes far more variables at once and invalidates the evaluation evidence you have; a lower output ceiling truncates answers rather than making them cheaper to produce, and hiding reasoning does not reduce what is billed.

    Source: CCDV-F exam guide, Domain: Model Selection & Optimization (effort as a tuning lever)Report a problem with this question

17. 17. After enabling reasoning on an extraction endpoint, responses that used to complete now stop partway through the answer. The output limit was never changed. What is the most likely cause?

    • A.Reasoning replaces the visible answer, so the response is complete as returned
    • B.Reasoning is billed as input, so the input limit is now the binding constraint
    • C.Reasoning tokens are billed as output and count against the same output ceiling, leaving less room for the visible answer✓ Answer
    • D.Enabling reasoning halves the effective output limit by design

    Reasoning is generated output: it is billed at output rates and consumes the same output allowance as the text the user sees. A limit that was comfortable without reasoning can now be exhausted before the answer finishes, so the output ceiling must be raised when reasoning is turned on.

    Source: Anthropic docs — adaptive thinking (reasoning tokens billed as output, counted toward max output)Report a problem with this question

18. 18. To cut costs, a team sets the reasoning visibility option so that reasoning content is not returned in the response. They expect the bill to drop. What actually happens?

    • A.Cost rises, because hiding reasoning requires an extra summarization pass that is billed separately
    • B.Cost is unchanged, because the visibility setting controls only what is returned, not whether reasoning is performed and billed✓ Answer
    • C.Cost drops only for streaming requests
    • D.Cost drops proportionally, because unreturned tokens are not billed

    Visibility settings are a presentation control: the model still reasons and you are still billed for every reasoning token generated, even when the response carries no reasoning text. To actually reduce reasoning spend you must lower the effort setting or turn reasoning off where the model permits it.

    Source: Anthropic docs — adaptive thinking (display controls visibility only)Report a problem with this question

19. 19. A product needs to route incoming emails into one of eight categories. Volume is millions per day, the classification rule set is simple, and the routing must complete in well under a second. Which model tier fits best?

    • A.The fast, low-cost tier, because the task is simple and high-volume with a tight latency budget✓ Answer
    • B.The balanced mid tier with the highest effort setting, to be safe
    • C.The most capable long-horizon reasoning tier, so classification accuracy is maximized
    • D.Whichever tier scored highest on a published reasoning benchmark

    Tier selection weighs capability against speed and cost, and a simple, well-specified classification at massive volume is exactly the profile the fast low-cost tier is built for. Paying for a deep-reasoning tier here buys capability the task does not use while breaking both the latency and the cost constraint.

    Source: CCDV-F exam guide, Domain: Model Selection & Optimization (capability, speed, cost trade-off)Report a problem with this question

20. 20. A deployment script hardcodes each model's context window and maximum output length in a constants file, copied from a blog post at the time of integration. Requests begin failing after the team pins a newer model. What is the correct fix?

    • A.Pin the previous model permanently so the constants stay valid
    • B.Increase every hardcoded constant by a fixed safety margin
    • C.Catch the failures and retry with progressively smaller inputs
    • D.Query the models endpoint (or read the current documentation) for that model's limits instead of relying on copied constants✓ Answer

    Context windows, output ceilings, and feature support are per-model properties that change as new models ship, so they must be discovered at runtime from the models endpoint or read from current documentation rather than frozen in code. Copied constants and safety margins are guesses that silently drift out of date, and freezing on an old model just defers the problem.

    Source: Anthropic docs — models overview and models endpoint (runtime capability discovery)Report a problem with this question

21. 21. A manager wants to switch the company's summarization pipeline to a different model tier because a vendor blog reports it scoring higher on a public benchmark and costing less per token. What should the team do before committing?

    • A.Rely on the published benchmark but keep a rollback plan in case users complain
    • B.Adopt the change immediately, since the benchmark and the price are both objective measurements
    • C.Run a single side-by-side sample prompt and compare the two answers by eye
    • D.Build an evaluation set from the company's own prompts and data and measure both candidates on it✓ Answer

    A published benchmark measures a task distribution that is almost certainly not yours, and a lower per-token price says nothing about how many tokens your workload will actually consume. The documented first step in any model change is an evaluation set built from your own prompts and data, since that is the only evidence that predicts your production result.

    Source: CCDV-F exam guide, Domain: Model Selection & Optimization (evaluate on your own task before migrating)Report a problem with this question

22. 22. A cost-forecasting job estimates prompt sizes with a tokenizer library built for another vendor's models, then applies a fixed multiplier whenever the team pins a newer model. Budget projections keep missing badly. What is the correct practice?

    • A.Call the token-counting endpoint with the same model that will run inference, and re-measure after any model change✓ Answer
    • B.Estimate tokens by dividing the character count by a fixed constant
    • C.Read the token counts from the response of a previous run on the old model
    • D.Keep the third-party tokenizer but recalibrate the multiplier once per quarter

    Tokenization is model-specific, so a tokenizer built for a different vendor — or counts measured on a different model — will not match what the target model actually charges. The token-counting endpoint returns an estimate produced by the tokenizer of the model you pass it, which is why the model argument must match the one used for inference and why counts must be re-baselined rather than scaled by a blanket multiplier after a model change.

    Source: Anthropic docs — token counting (model-specific tokenization, do not use third-party tokenizers)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 →