- In short
- An undeclared model-tier default is the silent choice a system makes when no deliberate tiering decision is taken at design time: it defaults to the most expensive available model. Its symptoms are cost far above projection, latency above the agreed target, and satisfaction scores that never moved despite the added spend. Extended reasoning features left enabled on simple steps compound the cost and latency. Diagnosing it means tracing those symptoms back to the missing decision rather than to the model getting more expensive.
The most expensive decision is the one nobody made
Every step that calls a model runs on some tier. If the architecture never states which, the system still picks one, and it picks the most expensive available model. This is the trap the Claude Certified Architect - Professional (CCAR-P) exam builds this analyse-level knowledge point around: the belief that not choosing a tier is a neutral omission. It is not. Not choosing is choosing the top of the capability-cost-latency spectrum, and doing so silently, without anyone deciding it should be that way.
The diagnostic skill is working backward from a set of production symptoms to this missing decision, and resisting the more comfortable explanations that put the blame anywhere else.
- Undeclared model-tier default
- The condition where no deliberate model-tier decision was made at design time, so the system defaults to the most expensive available model. It surfaces as cost far above projection, latency above the agreed target, and unchanged satisfaction scores despite the added spend, and is often compounded by extended reasoning features left on for steps that never needed them.
The symptom signature
An undeclared default has a recognisable signature. Cost runs far above the original modelling figure, often by a multiple rather than a margin. Latency on the user-facing path sits above the target the team agreed to, because the most expensive tier is also among the slowest. And, tellingly, satisfaction scores have not moved relative to the pre-launch baseline. That last symptom is the diagnostic key: the system is spending far more and delivering the same perceived quality. If the extra spend bought nothing measurable, the spend was not buying capability the work required.
Put together, the signature reads: paying top-tier prices, absorbing top-tier latency, and getting no quality dividend. That combination points at capability being paid for and not used, which is exactly what an undeclared default produces.
Extended thinking makes it worse
The cost problem is frequently compounded by an extended reasoning feature left enabled on steps that do not need it, such as a routing classifier. Extended thinking adds a separate billed reasoning pass and measurable latency to every call it touches. On a synthesis step that needs multi-step reasoning, that can be worth it; on a classifier that maps an input to one of a few categories, it is pure overhead added to every request. So an undeclared default often arrives with a second undeclared default riding on top of it: reasoning effort applied where no reasoning was required. The interaction with tiering is covered in extended thinking as a cost-latency tradeoff.
What the exam trips candidates on
The two traps are the two wrong explanations. The first is attributing a cost overrun to "the model getting more expensive" rather than to a missing tiering decision made at design time. A scenario will offer pricing changes or increased volume as a tempting cause; the credited reading traces the overrun to the absent decision. The second is assuming that because output quality is high, the model-tier choice must already be efficient. A scenario will point to strong output as evidence the tier is fine; the credited reading notes that a cheaper tier might produce the same quality, so quality alone proves nothing about efficiency.
Worked example
Ninety days after launch, a partner's system is costing seven times the modelled figure, median latency is 2.3 seconds against an 800ms target, and satisfaction scores are flat versus the pre-launch baseline. The team suspects Anthropic raised prices. What is the more likely root cause, and how should the architect confirm and fix it?
The price-increase theory does not fit the signature. A pricing change would not, on its own, produce a seven-fold overrun, and it would not explain the latency sitting far above target or the flat satisfaction scores. Those three symptoms together point somewhere else: every call is running on the most expensive tier because the architecture never made a per-step tier decision. The implicit default carried the top model through to production, and, on inspection, extended thinking was left enabled on a routing classifier that needed no reasoning at all, adding cost and latency to every request through that path.
To confirm, the architect examines the architecture document for a model-tier decision at each step. Finding none is the confirmation: the default was undeclared. The flat satisfaction score corroborates it, because the top-tier spend bought no measurable quality over the baseline.
The fix reconstructs the decision that was never made. Build an eval set covering what each step actually does. Route the classifier to the cheapest tier that passes its per-step eval and disable extended thinking there, since it needs none. Route mid-pipeline steps to Sonnet where the eval confirms no regression. Reserve the top tier for the one step whose eval shows it earns the cost. The overrun resolves because it was never a pricing problem or a quality problem; it was a missing decision, and making it deliberately is the cure.
Common misreadings to avoid
Misconception
A large cost overrun means the model got more expensive or traffic grew.
What's actually true
Misconception
If output quality is high, the model-tier choice must already be efficient.
What's actually true
How this shows up on the exam
Analyse-level questions present a production system with a cost and latency overrun and flat quality, then ask for the root cause. The reliable diagnosis is an undeclared model-tier default that shipped the most expensive model on every call, often compounded by extended reasoning left on simple steps. The fix is to build an eval and tier per step, not to blame pricing or accept high quality as proof of efficiency.
This knowledge point is the failure mode of per-step model tiering and interacts with extended thinking as a cost-latency tradeoff. Remediating it well often surfaces a stratified eval and partial migration decision when some steps regress on a cheaper tier and others do not.
A system is running at 7x its projected cost with latency well above target and satisfaction scores unchanged since launch. The architecture document lists no model-tier decision for any step. What is the most likely root cause?
People also ask
What happens if you never choose a model tier?
Why did our Claude costs come in far above projection?
Can high output quality hide an inefficient model choice?
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.