CCDV-F - Model Selection and Optimization (16.8% of the exam) - Section 5.4
Budget tokens and manage cost for a Claude application.
Published skill weight 2.8 percent. Covers token budgeting, token usage tracking, cost modelling, and caching techniques including prompt caching and cache check-pointing applied specifically to reduce cost rather than only to reduce latency.
lock_openFree sampleModel Selection and Optimizationmedium
A legal drafting service sends a large unchanging clause library at the head of every request, followed by the lawyer's short question. The team enables prompt caching to meet a stated per-request cost ceiling, but the request builder writes a generated line carrying the current timestamp and the requesting user's name immediately above the clause library. Spend per request does not fall, and an engineer concludes that caching only ever helps latency. How should the situation be read?
AThe engineer is right that caching is a latency feature, so the ceiling should instead be met by cutting the output limit on every request until spend per request falls inside it.
BCaching applies to generated replies rather than to sent input, so it can only help when two lawyers ask a question worded identically, which this traffic does not contain.
CCaching cannot apply while the clause library is this large, so the remedy is to move the service to a smaller model and accept whatever drop in drafting quality that brings.
DCaching is primarily a cost control, and it is being defeated because the timestamp and user name change the beginning of every request; move that volatile text below the clause library so the prefix is identical on each call.check_circle Correct
Prompt caching is mainly a cost control and it only pays when the cached prefix is identical on every request. A cached prefix is matched from the start of the request forward, so any per-request value interpolated ahead of the reusable material makes each request unique and forces the whole library to be processed as fresh input. Moving the timestamp and user name below the library restores an identical prefix, which is what turns the repeated clause text into cached input and brings spend down.
Why A is wrong: Tempting because caching does improve time to first token and the output limit is easy to change. It is wrong on both counts: caching is primarily a cost control on repeated input, and a lower output limit truncates drafted clauses rather than reducing the repeated input that dominates the bill.
Why B is wrong: Tempting because a response cache keyed on identical questions is a familiar pattern from ordinary web services. It is wrong because prompt caching operates on the repeated portion of the request sent to the model, not on the replies that come back.
Why C is wrong: Tempting because a smaller model is the standard lever when a per-request ceiling is missed. It is wrong because size is not what defeated the cache, and downsizing without measuring the drafting quality bar trades a solvable configuration fault for a quality regression.
Why D is correct: Correct because a cache serves the longest identical leading portion of a request, and volatile text placed above the library makes every request differ from the first token onwards.
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.
It will overstate cost, because whitespace and indentation in source code are discarded before tokenisation; the team should subtract a fixed allowance for formatting from each word count.
errorWhy it is wrong: Tempting because indentation looks like content that carries no meaning, but whitespace is part of the text that is tokenised, and no fixed allowance would make a word count into a token count.
Select the fastest and cheapest tier and recover the shortfall by asking it to reason step by step in the prompt, which raises accuracy on reasoning tasks at no extra tier cost.
errorWhy it is wrong: Tempting because prompting for reasoning does help on some tasks, but a 29 point measured gap is a capability gap, and treating an unmeasured prompt change as a fix ships a build below the stated floor.
Leave the generated time line at the head and move the cache breakpoint above the style guide, since a cached read depends only on where the breakpoint sits in the request.
errorWhy it is wrong: Tempting because the breakpoint is the visible caching control, but a cached read requires the content before the breakpoint to be byte-identical to a previous request, and moving the breakpoint higher leaves an even smaller prefix that still starts with a changing line.