23 Model Selection & Optimization Practice Questions & Answers

1. 1. A high-volume summarization route needs to spend fewer tokens per call, so a developer decides to lower the reasoning effort. Where does the effort setting belong in a Messages API request?

   • A.In an HTTP header on the request, rather than in the JSON body sent.
   • B.Inside the thinking object, as a field placed beside its type field.
   • C.At the top level of the request body, as a sibling of max_tokens.
   • D.Inside the output_config object, as the effort field on that object.✓ Answer

   The effort level is a field of output_config, not a top-level request parameter and not part of the thinking object; it tunes reasoning depth and token spend within a single model, so it is the first quality-trading lever once the free wins are taken.

   Source: Anthropic Messages API reference - output_config.effortReport a problem with this question

2. 2. A service running on an older model sets a fixed thinking budget with budget_tokens. After the model string is swapped for a newer one, every request fails with HTTP 400. What does this tell the team about the migration?

   • A.The parameter is merely deprecated, so the server ignores it and the body can stay.
   • B.A parameter dropped in a newer model is rejected outright, so the body must change too.✓ Answer
   • C.A transient rollout issue is at work, so the same body will pass on a later retry.
   • D.The budget now travels in a header, so the same value has to move out of the body.

   A request parameter that a newer model no longer accepts is rejected with a validation error rather than being silently ignored, and adaptive thinking replaces the fixed budget, so moving to a newer model is a code change and not only a model-string swap.

   Source: Anthropic model migration guide - removed request parametersReport a problem with this question

3. 3. A developer wants a current model to reason more on hard tickets and less on easy ones, without hand-tuning a number in every request. Which description matches how extended thinking is configured on current models?

   • A.Depth is fixed by the model tier alone, so a request cannot influence how much it thinks.
   • B.A fixed token budget is declared per request, and the model must consume all of it.
   • C.Thinking depth follows the temperature setting, so raising it lengthens the reasoning.
   • D.Adaptive thinking lets the model set depth per turn, and effort tunes the overall spend.✓ Answer

   Current models use adaptive thinking, where the model varies how much it reasons turn by turn, and the effort level is the knob for overall spend; a fixed per-request thinking budget belongs to an earlier generation of the API.

   Source: Anthropic extended thinking documentation - adaptive thinkingReport a problem with this question

4. 4. A team streams responses and sees thinking blocks arrive with empty text, because display is left at its default. They conclude that no reasoning tokens are produced or billed. Why is that conclusion wrong?

   • A.An empty thinking block means the model took a non-thinking path for that call.
   • B.Thinking tokens are billed only when a readable summary of them is returned.
   • C.The blocks are empty because reasoning is deferred to the next turn of the chat.
   • D.Display controls visibility only, so the reasoning still runs and is still billed.✓ Answer

   The display setting decides only whether a readable summary of the reasoning comes back; the raw chain of thought is never returned under any setting, and the thinking tokens are generated and billed either way.

   Source: Anthropic extended thinking documentation - thinking display and billingReport a problem with this question

5. 5. To hold down cost, a developer caps max_tokens far below what that route's answers usually need. Users start reporting answers that stop mid-sentence. What is happening on those requests?

   • A.The turn stops at the cap and returns stop_reason max_tokens, so it must be retried.✓ Answer
   • B.The model rewrites the answer to fit the cap, so quality drops but the reply is whole.
   • C.The remaining text is held server-side and delivered on the next request of the chat.
   • D.The request is refused before generation, so the truncated attempts are never billed.

   max_tokens is a hard per-response ceiling the model is not aware of: hitting it truncates the output mid-thought with stop_reason max_tokens, and the tokens already generated are billed, so the retry makes a low cap a false economy on anything but a deliberately short output.

   Source: Anthropic Messages API reference - stop_reason max_tokensReport a problem with this question

6. 6. A report generator asks a current model for a very long document and sets a correspondingly large max_tokens without streaming. The call fails with an HTTP timeout before any content returns. What is the right fix?

   • A.Split the request into parallel calls so that each one returns before the timeout.
   • B.Cut max_tokens down until the reply fits inside the client default timeout window.
   • C.Raise the client retry count so the request is reissued until an attempt lands.
   • D.Send the request as a stream and assemble the reply with the final-message helper.✓ Answer

   A non-streaming request holds the connection open until the entire response has been generated, so a large output cap runs past the HTTP timeout; streaming keeps data flowing, and the SDK final-message helper reassembles the complete reply when individual events are not needed.

   Source: Anthropic SDK guidance - streaming required for large max_tokensReport a problem with this question

7. 7. A team enables streaming across a chat product and expects the monthly bill to fall. The usage figures stay flat. What does streaming actually change?

   • A.It compresses the response on the wire, so the same answer bills fewer output tokens.
   • B.It reuses the previous turn tokens, so repeated context is billed once per conversation.
   • C.It shows tokens as they are produced, cutting perceived latency and timeout risk.✓ Answer
   • D.It halts generation once the client has rendered enough text, trimming what is billed.

   Streaming changes how the same tokens are delivered, not how many are generated, so billing is identical; its wins are perceived latency for a waiting user and avoiding request timeouts on long outputs.

   Source: Anthropic streaming documentation - purpose of streamingReport a problem with this question

8. 8. Forty thousand support tickets have to be classified before a morning report, and nobody is waiting on any single result. Which approach fits that constraint best?

   • A.Submit the work to the Message Batches API and read the results when the batch ends.✓ Answer
   • B.Drop to the smallest available model for every ticket, since the volume is what costs.
   • C.Issue the calls in parallel from many workers, since concurrency lowers per-token cost.
   • D.Send the calls one at a time with streaming on, since streaming is the cheapest delivery.

   Batch processing trades latency for cost: the same requests submitted asynchronously are billed at a discount to realtime calls, and an overnight window is exactly the latency tolerance a batch needs. Parallel fan-out shortens wall clock but does not lower the per-token price.

   Source: Anthropic Message Batches API - asynchronous processing discountReport a problem with this question

9. 9. A batch of a few thousand requests finishes and a developer pairs the results with the input list by position. Some records end up scored with another ticket's output. Which rule is being broken?

   • A.Results are paginated, so only the first page lines up with the original input order.
   • B.Results omit the failed requests, so the list shifts and has to be padded back out.
   • C.Results come back in arbitrary order, so each one must be matched by its custom_id.✓ Answer
   • D.Results are ordered by completion time, so the list has to be sorted before pairing.

   The Batches API returns each result keyed by the custom_id the caller supplied and in any order, so a position in the result stream carries no relationship to a position in the submitted list; matching by index silently mixes records up.

   Source: Anthropic Message Batches API - results are returned by custom_id in any orderReport a problem with this question

10. 10. A developer takes a working realtime request that uses streaming and submits the same parameters inside a batch request. The batch is rejected as invalid. What explains the rejection?

    • A.It failed because a streaming request needs a matching header on the batch itself.
    • B.A batch takes streaming only when every request in it also streams its own response.
    • C.Streaming is not available inside a batch, whose results are read whole after it ends.✓ Answer
    • D.Streaming inside a batch is allowed, so the failure means the size cap was exceeded.

    Batch entries are processed asynchronously and their results are retrieved after the batch ends, so per-request streaming has no meaning there and the parameter is not accepted; streaming belongs to the realtime path where a caller is waiting on the response.

    Source: Anthropic Message Batches API - unsupported request parametersReport a problem with this question

11. 11. An agent caches a long system prompt and reuses it across turns. A release adds one tool to the tool list, and cache reads drop to zero on every request afterwards. Why did one small change cost so much?

    • A.The tool list sits outside the cached prefix, so the drop comes from the system text.
    • B.A tool change resets the cache lifetime, so the entry expires early and is rebuilt.
    • C.Tool definitions are cached apart, so adding one clears only that tool own entry.
    • D.Tools render before system and messages, so editing them invalidates all that follows.✓ Answer

    Prompt caching is a prefix match rendered in the order tools, then system, then messages, and a byte change anywhere in the prefix invalidates everything after it, so an edit to the tool list cascades down through the system prompt and the message history.

    Source: Anthropic prompt caching documentation - cache invalidation hierarchyReport a problem with this question

12. 12. A service caches a long system prompt, yet cache_read_input_tokens is zero on every repeat request. The system prompt is built by a helper that stamps the current time into its first line. What should the developer do?

    • A.Extend the cache lifetime so the entry survives between the repeated calls made.
    • B.Move the timestamp to the very top of the system prompt so the rest stays stable.
    • C.Add more cache breakpoints so that one of them lands ahead of the changing line.
    • D.Move the timestamp out of the prefix and place it after the last cache breakpoint.✓ Answer

    Any byte that differs between requests breaks the prefix match for everything after it, so a per-request timestamp or id anywhere in the system prompt silently prevents caching; volatile content belongs after the last breakpoint, where it cannot invalidate the stable part.

    Source: Anthropic prompt caching documentation - silent invalidatorsReport a problem with this question

13. 13. A developer inspects usage on a cached request and sees a small input_tokens value next to a large cache_read_input_tokens value. What does that small input_tokens number represent?

    • A.The tokens the model truly attended to, once the cached prefix was discarded.
    • B.The tokens this request wrote into the cache, before any can be read back later.
    • C.The whole prompt size, with the cached tokens counted a second time inside it.
    • D.The tokens after the last breakpoint that were not served from cache this time.✓ Answer

    input_tokens counts only the uncached input for that request; cache_read_input_tokens and cache_creation_input_tokens are reported separately, and the total input for the call is the sum of the three figures.

    Source: Anthropic prompt caching documentation - usage fieldsReport a problem with this question

14. 14. A developer adds prompt caching to an endpoint whose traffic is almost entirely one-off requests with no prefix shared between users. The bill goes up slightly. Why?

    • A.Cache reads are billed at the same rate as input, so entries only add overhead.
    • B.Caching bills the prefix twice per request, as input and as a cache entry too.
    • C.Every request pays the write premium and none of them ever gets a read back.✓ Answer
    • D.Cache entries are billed for their whole lifetime, so idle ones keep accruing.

    Writing a prefix into the cache costs somewhat more than the same uncached input, while a cache read costs materially less, so caching only pays back when a prefix is genuinely reused; single-shot traffic pays the write premium and never collects the read discount.

    Source: Anthropic prompt caching documentation - cache write and read pricing multipliersReport a problem with this question

15. 15. A long-running agent turns on server-side compaction. The developer appends only the response text back onto the message list each turn, and context keeps growing as though compaction never ran. What went wrong?

    • A.The full response content must be appended, since the compaction blocks live in it.✓ Answer
    • B.Compaction needs the caller to delete the earlier turns before it takes any effect.
    • C.Compaction applies only to tool results, so a text-heavy conversation is untouched.
    • D.The summary arrives on the following response, so one more turn is needed for it.

    Compaction summarizes earlier context on the server and returns that state as blocks inside the response content, so appending only the extracted text silently drops it and the conversation reverts to full history; clearing strategies are a separate mechanism that removes old blocks instead of summarizing them.

    Source: Anthropic context management documentation - compaction versus context editingReport a problem with this question

16. 16. Before shipping a route that stuffs a large document into every prompt, a developer wants an accurate input size to budget against. What is the right way to get that number?

    • A.Send one request and read the output token count, which tracks the input closely.
    • B.Divide the character count by four, the accepted ratio quoted for English prose.
    • C.Call the token counting endpoint with the same model, system prompt and messages.✓ Answer
    • D.Run a third-party tokenizer library over the text and use the count that it reports.

    The count_tokens endpoint counts the request exactly as the API would, including the system prompt and tool definitions, so it is the only reliable pre-flight number; third-party tokenizers are built for other models vocabularies and character heuristics drift with language and content.

    Source: Anthropic token counting endpoint - /v1/messages/count_tokensReport a problem with this question

17. 17. A developer is choosing between two models for a route that must accept unusually large inputs, and needs each candidate context capacity and supported features. What is the sound way to settle it in code?

    • A.Send progressively larger prompts until one errors, then take that size as the limit.
    • B.Assume a family shares one set of limits, since capacity follows the family name.
    • C.Query the Models API for the current entry and read its capability and limit fields.✓ Answer
    • D.Hardcode the figures from that tier launch announcement into a constant in the code.

    Capability, price and context capacity differ from model to model and change with each release, so the current values are discovered by querying the Models API or reading the current documentation rather than being memorized, probed by trial and error, or inferred from a family name.

    Source: Anthropic Models API - GET /v1/models capability discoveryReport a problem with this question

18. 18. A route uses a frontier model at low effort. A cheaper model at high effort has a lower per-token price but needs more turns and more retries to finish the same task. How should the choice be made?

    • A.Compare first-response latency, since a faster model finishes the work for less money.
    • B.Compare cost per completed task, since extra turns and retries land on the same bill.✓ Answer
    • C.Compare the output token price alone, since output dominates what a request is charged.
    • D.Compare the per-token input price, since that is the figure the invoice is built from.

    Anthropic guidance is to judge cost per completed task rather than per-token price: a more capable model at a lower effort level often solves the task in fewer turns with fewer retries, so it can be cheaper overall even at a higher headline rate.

    Source: Anthropic cost optimization guidance - cost per completed taskReport a problem with this question

19. 19. To cut spend, a team proposes routing easy requests to a small model and hard ones to a large model, keeping the same long cached system prompt on both paths. What consequence should they weigh first?

    • A.Caches are scoped per model, so the shared prefix is cached and paid for on each path.✓ Answer
    • B.The router itself must be a model call, so that extra hop is what makes cascades costly.
    • C.Routing forces the prefix to be resent uncached, since only one model may hold an entry.
    • D.Caches are shared across models, so the second path reads the first path entry for free.

    Prompt caches are scoped to a single model, so a cascade cannot reuse one model cached prefix on another and duplicates the write cost on both paths; measure the simpler alternative first, which is one capable model at a lower effort level.

    Source: Anthropic prompt caching documentation - caches are model-scopedReport a problem with this question

20. 20. A TypeScript service sets the client timeout to 30, intending thirty seconds. Long requests start failing almost immediately. What is the cause?

    • A.The value is clamped to the smallest timeout the client allows, well under a second.
    • B.Timeouts must be set per request in that SDK, so the client-level value never applied.
    • C.The timeout is a per-token limit, so a long generation trips it however it is written.
    • D.That SDK expresses the timeout in milliseconds, so the value set a thirty-ms limit.✓ Answer

    Timeout units differ between the official SDKs - some take seconds, some milliseconds, some a duration type - so a number copied from one language to another silently changes meaning; check the unit for the SDK actually in use before setting it.

    Source: Anthropic SDK client configuration - timeout units by SDKReport a problem with this question

21. 21. A latency-sensitive endpoint sets a generous client timeout and leaves automatic retries at their default. A user reports a request that hung far longer than the timeout before failing. What explains it?

    • A.Timeouts are retried, so worst-case wall clock is the timeout times each attempt made.✓ Answer
    • B.The timeout covers the connection only, so generation time is not counted against it.
    • C.The timeout resets on each streamed event, so a slow stream can extend it without end.
    • D.Retries queue behind rate limits, so the delay comes from waiting rather than the calls.

    A timeout is one of the failures the SDK retries automatically, so total wall clock can reach the timeout multiplied by the number of attempts, which is the initial call plus the configured retries; the two settings have to be budgeted together.

    Source: Anthropic SDK client configuration - timeouts are retriedReport a problem with this question

22. 22. An integration wraps every API call in one broad catch that logs and retries. It now retries malformed requests forever and gives up on rate limits too early. How should the handling be restructured?

    • A.Retry every failure with backoff, since a permanent error will simply fail again cheaply.
    • B.Catch the typed exceptions from most specific to least, retrying only retryable ones.✓ Answer
    • C.Match on the message text of each error, so new failure kinds are handled as they appear.
    • D.Treat any error carrying a status code as retryable, skipping connection failures only.

    The SDKs expose typed exception classes, and a most-specific-first chain is what separates retryable failures such as rate limits, server errors and connection problems from permanent ones such as a malformed request or bad credentials; string matching breaks whenever a message is reworded.

    Source: Anthropic SDK error handling - typed exception classesReport a problem with this question

23. 23. A chat feature sends only the newest user message on each turn, and Claude keeps losing track of details from earlier in the conversation. What does the developer need to change?

    • A.Turn on streaming, which holds the connection open and preserves the turns in order.
    • B.Resend the whole conversation each turn, because the API keeps no state between calls.✓ Answer
    • C.Set a conversation id on every call so the server links the turns into one session.
    • D.Raise max_tokens so the model has room to recall what was said in earlier turns.

    The Messages API is stateless, so each request is answered from exactly what it contains and the history has to be resent every turn; that growing history is the dominant cost driver in long conversations, which is why most of it should arrive as cached reads.

    Source: Anthropic Messages API - stateless conversation historyReport 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. It is delivered via Pearson VUE; Anthropic publishes the current question count, time limit, passing score and fee in the official CCDV-F exam guide. Official certification page →