CCDV-F - Applications and Integration (33.1% of the exam) - Section 2.3
Apply Claude API behaviour and mechanics correctly in application code.
Published skill weight 6.8 percent. Covers messages, tools, streaming, vision, thinking and caching; invoking Claude through third-party vendors; Messages API data access patterns; batch API use; and the tradeoff between selecting the realtime API and the batch API for a given workload.
Messages APIstreamingvision and thinkingprompt cachingbatch API versus realtime APIthird-party vendor invocation
Practice question for this objective
lock_openFree sampleApplications and Integrationmedium
A compliance team must classify 60,000 archived emails against a fixed rubric. The job runs once a week, nothing blocks a user while it runs, and the team is told to hold the lowest cost per email that still meets the rubric's accuracy bar. An engineer proposes firing 60,000 concurrent realtime Messages API requests so the job finishes sooner. Which approach best fits the stated constraint?
AKeep the concurrent realtime requests, because completing the run sooner is what the weekly schedule requires and concurrency is the only way to reach that throughput.
BSubmit the classifications through the Message Batches API, since the work is latency tolerant and batch processing is the cheaper path for a large offline volume.check_circle Correct
CKeep the realtime requests but reduce max_tokens on each one, so that every classification is billed against a much smaller output allowance.
DKeep the realtime requests and enable prompt caching on the rubric, because caching a stable prefix removes the need to choose a different request path.
Choose the Message Batches API for large latency-tolerant volumes, and the realtime Messages API only when something is blocked waiting. The deciding factor is whether anything blocks on the response. A weekly archival classification has no waiting user, so the work can be submitted asynchronously in bulk, which is the cheaper path per request; realtime calls buy interactivity nobody in this scenario is paying attention to.
Why A is wrong: Tempting because concurrency really does shorten wall-clock time, but the stated constraint is cost per email and not completion time, and a fan-out of realtime requests is the most expensive way to buy throughput.
Why B is correct: Correct: no user is waiting, the volume is large and uniform, and the Message Batches API exists precisely for asynchronous bulk work at a lower cost per request than realtime calls.
Why C is wrong: Tempting because max_tokens looks like a spend dial, but it is a truncation limit rather than a cost lever: it caps how long a response may run and risks cutting a classification short without changing the request path.
Why D is wrong: Tempting because caching the shared rubric prefix is a genuine cost control and worth doing, but it is complementary to the request path rather than a substitute for it, and it leaves the expensive realtime fan-out in place.
Answers that look right on this material and are not. Each one is a distractor from a different question in the CCDV-F bank for this domain.
Add a sentence to the system prompt stating firmly that the extraction tool must be called for every receipt and that prose replies are not acceptable.
errorWhy it is wrong: Wording the instruction more strongly does reduce the rate, which is why teams try it first, but an instruction remains advice the model may not follow and cannot turn a measured one in six into a guarantee.
Fold the pending timeout and retry adjustments into the same commits, because the module is already open and touching those call sites twice costs more reviewer time.
errorWhy it is wrong: Tempting because batching saves a pass over the code, but mixing a behaviour change into the restructuring destroys the attribution the team asked for.
The handbook prefix must be moved onto the asynchronous bulk submission path, so that the repeated input tokens are billed at the lower bulk rate on every interaction the assistant serves.
errorWhy it is wrong: Tempting because the bulk path genuinely does cost less per token, but it is asynchronous and this assistant answers a waiting user, so adopting it would trade the stated cost ceiling against a response time the product cannot give up.