- In short
- When both a cost ceiling and a latency target must be met at once, the task is to identify which single lever moved the configuration into range and articulate why. A stable, repeated system prompt makes caching the strongest candidate, so caching typically dominates cost reduction over a model-tier change in that scenario. A sound justification ties the chosen lever to the specific workload property that makes it effective, rather than naming a general best practice.
Meeting two constraints at once
This is the evaluate-level capstone of the cost-latency task statement. Earlier knowledge points gave you the individual levers, tier, tokens, and volume, caching, p95 latency, batch. Here you have to meet a cost ceiling and a latency target simultaneously and then justify the configuration, which means naming the single lever that did the most work to bring it into range and explaining why that lever fits this workload. It is not enough to land a working configuration; you have to be able to say what moved it and why.
The reason justification matters is that the exam tests reasoning, not lucky guesses. Two candidates can pick the same configuration for opposite reasons, one because it matches the workload, one because it 'sounded safe,' and only the first has actually done the analysis. The skill is producing the specific, workload-grounded reason.
- Configuration justification under dual constraints
- An evaluate-level analysis that, when a cost ceiling and a latency target must both be met, identifies the single lever that moved the configuration into range and ties it to the specific workload property that makes it effective, rather than naming a generic best practice or defaulting to the most capable model.
Match the lever to the workload property
A justification is only as good as the workload property it names. Each lever is effective because of a specific property: caching pays off when the prompt is long, stable, and reused; batch pays off when the SLA tolerates delay; a cheaper tier pays off when the task tolerates it; cutting output length pays off when responses are longer than the task needs. So justifying a choice means pointing at the property in the scenario that makes the chosen lever work. 'We enabled caching because caching reduces cost' is a general best practice; 'we enabled caching because the 5,000-token system prompt is identical across all 50,000 monthly requests, so the cached prefix is read tens of thousands of times' is a justification tied to the property.
The canonical case the exam highlights: a stable, repeated system prompt makes caching the strongest lever, and in that scenario caching typically dominates cost reduction over a model-tier change, because the stable prefix is the dominant input-cost driver and caching attacks it directly. When the scenario hands you a long stable prompt, caching is usually the lever that moved the configuration, and the property that justifies it is the prompt's stability and reuse.
The traps: safe-sounding levers that miss the constraint
The two ways this goes wrong are both about picking a lever that sounds right in general but does not address the stated constraint. The first is defaulting to the most capable model as the 'safe' answer. A top tier feels like the cautious choice, but if the constraint is a cost ceiling or a latency target, the most capable model usually makes cost worse and does nothing to address the actual limit; it answers a quality question nobody asked. The second is picking a lever that is generically sensible but mismatched to the workload property, such as raising the token cap when the constraint is cost rather than quality, which inflates cost in the name of a quality gain the scenario never required.
Avoiding both means reading what the constraint actually is and choosing the lever whose workload property matches it. The credited answer names the lever and the property together and rejects the safe-sounding-but-mismatched options.
What the exam trips candidates on
Two traps. The first is defaulting to the most capable model as the safe answer when it does not address the stated cost or latency constraint. The second is picking a lever that sounds correct in general but does not match the workload property described, such as raising the token cap when the actual constraint is cost, not quality. The credited answer identifies the single decisive lever and justifies it by the specific workload property, not by a generic best practice.
Worked example
A customer-service agent handles 50,000 requests per month. The system prompt is 5,000 tokens and identical on every request; user input averages 300 tokens and output 400. The configuration must come in under an $800/month cost ceiling and a 3-second p95 latency target. Three options are offered: (A) switch to the most capable model 'to be safe,' (B) enable prompt caching, (C) raise the max_tokens cap 'for headroom.' Which lever moved the configuration into range, and why?
Start by reading what the constraints actually are: a cost ceiling and a p95 latency target, not a quality problem. Now look for the workload property that a lever can exploit. The stand-out feature is the 5,000-token system prompt that is identical across all 50,000 monthly requests. That stable, repeated prefix is the dominant input-cost driver, and it is the textbook strongest caching candidate: written once, read tens of thousands of times at a fraction of the input rate, which cuts both cost and per-request latency. So option B is the lever that moves the configuration into range, and the justification is specifically the prompt's stability and reuse, not a generic 'caching is good.'
The other two options are the traps. Option A, the most capable model 'to be safe,' does not address either stated constraint and typically makes cost worse, so it is the default-to-top-tier trap; safety-by-capability is not an answer to a cost or latency limit. Option C, raising max_tokens 'for headroom,' targets quality headroom the scenario never asked for and only raises worst-case cost and latency, which is the second trap, a generically plausible lever mismatched to the actual cost constraint. The credited answer is B, and the reason it is credited is that it names the single decisive lever and ties it to the concrete workload property, the long stable reused prompt, that makes caching dominate here over a tier change.
Common misreadings to avoid
Misconception
When you have to meet cost and latency constraints, choosing the most capable model is the safe default.
What's actually true
Misconception
Any recognised cost-latency best practice is a valid justification for a configuration.
What's actually true
How this shows up on the exam
Expect a scenario with an explicit cost ceiling and latency target, a workload property that favours one lever, and distractors like 'use the most capable model' or 'raise the token cap.' The reliable reading is to name the single decisive lever, usually caching when the prompt is long and stable, and justify it by the concrete workload property. This capstone draws on prompt caching, p95 latency, the three cost-latency levers, and batch processing.
An agent runs 50,000 requests/month with an identical 5,000-token system prompt, under an $800 cost ceiling and a 3-second p95 target. Which choice, and justification, is credited?
People also ask
How do you justify a Claude configuration choice?
Why is caching often the dominant lever for a stable prompt?
Is the most capable model the safe default answer?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
Official prep for this domain
Anthropic's own free prep module for this part of the syllabus, on the official prep course. Free with an Anthropic Academy sign-in.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.