Original practice question. The scoring rubric is our teaching guide. How we research and score answers
TL;DR: Position the tier by the jobs it does best (high-volume, latency-sensitive tasks), price it to open new use cases while managing cannibalisation of the mid tier, publish evaluation results and clear guidance on when to use it versus larger models, secure capacity for demand spikes, stage access to catch issues, and give developers routing examples and migration help. Measure adoption by new workloads separately from shifted ones.
How to approach it
Work through positioning, evaluation, pricing, capacity, rollout, developer enablement and measurement. Address cannibalisation explicitly, since a cheaper tier will attract some traffic from more expensive ones.
A strong answer
1. Positioning. What is the tier for? Classification, extraction, routing, autocomplete, high-volume summarisation, real-time chat where speed matters more than depth. Define it by jobs, with clear statements of what it is not good at (complex reasoning, long multi-step tasks).
2. Evaluation and documentation.
- Results on standard and task-specific benchmarks, compared with existing tiers, including where it is weaker.
- Latency and throughput figures by region.
- Safety evaluations and usage policy applicability.
- A model card or documentation covering capabilities, limitations and intended uses.
3. Pricing. The tier's price sets which workloads move to it. Considerations:
| Consideration | Implication |
|---|---|
| New use cases unlocked | Price low enough that previously uneconomic workloads (bulk processing, per-keystroke features) become viable |
| Cannibalisation | Some mid-tier traffic will move; acceptable if total usage and margin grow |
| Margin | Serving cost per token must support the price at expected utilisation |
| Spread | Keep clear separation from the mid tier so routing decisions are obvious |
For reference, Anthropic's lineup spans 100 times in input price as of 6 November 2026, from Claude Haiku 5.5 at $0.10 per million input tokens to Claude Fable 5.1 at $10, which shows how wide tier spreads can be.
4. Capacity. Cheap, fast tiers can see sudden demand spikes as developers move batch jobs. Forecast with early-access data, reserve headroom, and set initial rate limits that protect reliability, raising them as capacity grows.
Rate-limit pools are a launch decision in their own right. Anthropic's published limits (checked 6 November 2026) give each new model its own pool, separate from the combined pool older versions share: at the Start tier, Claude Sonnet 5.5 allows 4,000 requests a minute while the shared Sonnet 4.x pool allows 1,000. The scarce frontier tier runs tighter, with Fable at 500,000 input tokens a minute against 2,000,000 for Haiku 5.5. A separate, larger pool lets developers try the new tier without starving production traffic on the old one, and it is a visible signal of where the platform wants traffic to go.
5. Staged rollout.
6. Developer enablement. Routing examples ("send classification to the new tier, complex requests to the larger model"), cost calculators, migration notes for prompts, and updated SDKs on day one.
7. Measurement. Share of new tier usage from new workloads versus shifted from other tiers, total platform usage and revenue, gross margin by tier, latency and error rates, developer feedback on quality.
What interviewers probe next
"Finance worries the new tier will cut revenue from the mid tier." Model scenarios: shifted traffic at lower price versus new volume and new customers. Cheaper tiers usually expand the market; monitor and adjust pricing if shift dominates.
"Early testers report the new tier fails at a common task." Update documentation and guidance before general availability; consider delaying if the task is central to the positioning.
How it's scored
| Signal | Weak | Hire | Strong Hire |
|---|---|---|---|
| Positioning | "Cheaper and faster" | Target use cases | Jobs it does best and explicit non-goals, with routing guidance |
| Pricing and economics | A price | Considers margin | New-use-case unlock vs cannibalisation vs margin, with clear tier separation |
| Execution | Announce it | Staged rollout | Evaluation and documentation, capacity planning, staged access, developer enablement, new-versus-shifted measurement |
Common mistakes
Positioning a cheap tier as "almost as good" without saying where it falls short.
Launching without capacity headroom for a demand spike.
Measuring success by total usage of the new tier without separating shifted from new workloads.
See launching a model and developer platform PM.