- In short
- Per-step model tiering assigns different model tiers to different steps of a multi-step pipeline based on what each step actually requires. A simple classification or routing step rarely needs the same tier as a final synthesis or reasoning step. Deciding correctly requires a per-step eval rather than a single end-to-end score, because an aggregate number hides which step actually needs the higher tier.
Stop tiering the pipeline; tier the steps
A multi-step pipeline is not one workload; it is several, chained together. A step that classifies an incoming request, a step that retrieves relevant context, and a step that synthesises a final answer stress the model in completely different ways. Treating the pipeline as a single thing and assigning it one model tier ignores that. The Claude Certified Architect - Professional (CCAR-P) exam treats per-step tiering as an apply-level skill: take the capability-cost-latency spectrum and apply it independently to each step, rather than once to the whole.
The payoff is concentrated. In most pipelines the majority of calls are simple steps that a cheaper tier handles indistinguishably, while a minority are hard steps that justify a higher tier. Tiering per step captures that structure; blanket tiering throws it away.
- Per-step model tiering
- Assigning each step of a multi-step pipeline the model tier its work actually requires, rather than applying one tier uniformly. Simple, well-specified steps such as routing or classification typically run on a cheaper tier, while synthesis or judgment steps may justify a higher one. The decision is validated by a per-step eval, not by a single end-to-end score.
Simple steps and hard steps are different work
The core observation is that a simple classification or routing step rarely needs the same tier as a final synthesis or reasoning step. Routing a request to one of a few branches, or classifying a ticket into a fixed set of categories, is well-specified, low-ambiguity work. The cheaper tier handles it reliably and runs faster, which matters because these steps often execute on every request. A final synthesis step, where the output's quality depends on weighing evidence and producing coherent judgment, is where a higher tier can move the result.
Assigning the same tier to both means one of two waste patterns. Either you tier up to cover the hard step and overpay on every simple step, or you tier down to save on the simple steps and starve the hard one of the capability it needed. Neither is efficient, and both are avoidable by tiering per step.
Why you need a per-step eval
Deciding per-step tiers requires a per-step eval, not a single end-to-end score. This is the subtle part. An aggregate end-to-end score tells you the pipeline's overall quality, but it blends every step together and hides which step actually needs the higher tier. A pipeline can look healthy at the top level while a single step is quietly carrying, or quietly failing, and the aggregate score cannot show you which. To tier correctly you evaluate each step against its own graded set, so you can see exactly where capability is load-bearing and where it is surplus.
This inherits the gating discipline from eval-gated model swaps: each per-step tier decision is itself a small, evidence-gated choice with its own test set and threshold.
What the exam trips candidates on
The two traps are the two ways teams avoid the work. The first is applying one blanket model tier to an entire pipeline because it is simpler to configure. Simplicity of configuration is a real convenience and a poor reason; the credited answer tiers per step. The second is judging model fit using only an aggregate end-to-end score that hides which step actually needs the higher tier. A scenario will show a healthy-looking overall number and invite you to conclude the tiering is fine; the credited answer insists on per-step evaluation to locate where the capability is actually needed.
Worked example
A summarisation pipeline has three steps: a router that decides the document type, a section-level extractor, and a final synthesiser that writes the summary. It runs entirely on Opus and passes an end-to-end eval at 0.93. The team concludes the tiering is optimal. Why is that conclusion unsupported, and how should they proceed?
The 0.93 end-to-end score establishes that the pipeline produces good summaries. It says nothing about whether each step needs Opus, because it blends all three steps into one number. The router and the extractor could be running on a tier far above what their work requires, and the aggregate score would look identical either way. The conclusion that tiering is optimal is drawn from a metric that structurally cannot reveal tiering waste.
The correct move is a per-step eval. Build a graded set for the router alone, judging only whether it assigns the right document type; a graded set for the extractor alone; and a graded set for the synthesiser alone. Run candidate tiers against each. The router is well-specified low-ambiguity work and will very likely hold quality on Haiku. The extractor may hold on Sonnet. The synthesiser is where the end-to-end quality is actually being produced, and its per-step eval is where a higher tier can justify its cost.
The result is a mixed-tier pipeline: a cheap router, a mid-tier extractor, and the higher tier reserved for the one step whose per-step eval shows it earns the spend. The end-to-end quality is preserved, the cost drops, and the decision is now grounded in evidence about each step rather than an aggregate that hid the answer.
Common misreadings to avoid
Misconception
Using one model tier for the whole pipeline is fine because it's simpler to configure.
What's actually true
Misconception
A strong end-to-end eval score proves the tiering is optimal.
What's actually true
How this shows up on the exam
Apply-level questions present a multi-step pipeline running on a single tier, often with a reassuring end-to-end score, and ask how an architect should tier it. The reliable answer tiers per step according to what each step requires and validates each decision with a per-step eval rather than an aggregate one.
This knowledge point applies the Sonnet-first default heuristic step by step and borrows the gating rigour of eval-gated model swaps. Failing to make a per-step decision is exactly the silent default described in diagnosing an undeclared model-tier default.
A three-step pipeline (route, extract, synthesise) runs entirely on Opus and scores 0.92 on an end-to-end eval. The team says this proves every step needs Opus. What should the architect point out?
People also ask
Should every step of a pipeline use the same model?
Which pipeline steps can run on a cheaper model?
Why is an end-to-end score misleading for tiering?
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.