Choose the Right Model Tier per Task

Tier: Core · Hands-on time: ~40 minutes

Professionals who route every task to the flagship overpay and wait; those who route everything to the cheap tier quietly ship errors. This playbook gives you a decision recipe and makes you validate it with evidence.

When to use

• •
  Setting defaults for yourself or a team ("which model do we use for what?").
• •
  A recurring task's cost or latency has started to matter (pairs with pb-11).
• •
  Building anything on an API where model choice is a line item you'll pay for monthly.

Prerequisites

• •
  Access to at least two tiers (any provider's small + flagship, or hosted + your local Ollama model from pb-07).
• •
  One recurring task with an eval set from pb-09 — the recipe without the eval is just new vibes.

The workflow

1. 1.

   Score the task on four axes (1 = low, 3 = high). Write the scores down:

   Copy

   TASK: <name>
   STAKES     (1 disposable draft → 3 client-facing / irreversible): _
   COMPLEXITY (1 mechanical transform → 3 multi-step reasoning/design): _
   VOLUME     (1 few per week → 3 hundreds+ per day): _
   LATENCY    (1 can wait minutes → 3 interactive/blocking): _
   

2. 2.

   Apply the routing rules, in order:

   • •
     Confidential data? → local model tier, regardless of other scores (capability ceiling accepted as the price of privacy).
   • •
     STAKES = 3 or COMPLEXITY = 3 → start at frontier tier.
   • •
     VOLUME = 3 and STAKES ≤ 2 → start at small tier; the eval decides if it survives there.
   • •
     Everything else → start at mid-tier. This is the correct default for most professional work — treat deviations as things to justify.
   • •
     High LATENCY need pushes one tier down from wherever you landed (smaller = faster), unless STAKES = 3 vetoes it.
3. 3.

   Validate with your eval set. Run the pb-09 eval (same 10 cases, same grading) on the recommended tier AND one tier below it. You now have the only comparison that matters: your task, both tiers, scored.

   Copy

   Tier recommended : score /10 = _
   One tier cheaper : score /10 = _
   

4. 4.

   Apply the downgrade rule. If the cheaper tier scores within 1 point of the recommended tier and passes both trap cases, take the cheaper tier — you just bought the same outcome for roughly an order of magnitude less. If it drops more than 1 point, the recommendation stands; the delta is what quality costs.

5. 5.

   Record the routing decision. Add a line to the task's prompt file in your library (pb-05): Model tier: mid (evaled YYYY-MM-DD, small=7.5 mid=9). A routing choice without a date rots silently.

6. 6.

   Re-check on model refreshes. When a provider ships a new generation, yesterday's mid-tier often matches last year's flagship. Re-run step 3 on your highest-spend tasks — tier demotions after a model refresh are the easiest cost win in this entire track.

Tool variants

• Single-provider ladder (any major vendor): simplest ops — one API key, one console; tiers map cleanly onto small/mid/frontier.
• Cross-provider routing: pick the best model per rung across vendors; better fit per task at the cost of multiple accounts and eval runs per provider. Worth it at real volume.
• Local + hosted hybrid: Ollama (pb-07) as the confidential/volume rung, hosted mid or frontier for the reasoning rung — the standard pattern for services companies with client-data constraints.

Verification

• •
  Both eval runs are recorded — a routing decision with only one tier tested is unvalidated.
• •
  Trap cases (pb-09) passed on the tier you chose: cheap tiers fail traps more; a downgrade that sacrifices trap behavior is not a savings.
• •
  The four-axis scores are written down, so a colleague can audit why this task lives on this tier.
• •
  Latency actually measured for interactive tasks: time one real request per tier — perceived speed differences are often smaller (or larger) than assumed.

Pitfalls

• Prestige defaulting. Using the flagship for everything because it's "the best." For mechanical transforms (pb-03-style extraction), small tiers routinely tie — you're paying 10× for zero delta.
• Benchmark transfer. Public leaderboards measure their tasks, not yours. Your 10-row eval outranks any leaderboard for routing your task.
• Downgrading on cost alone. A cheaper tier that adds one silent error per week to client deliverables costs more than the API bill it saved. STAKES = 3 tasks earn their frontier bill.
• Set-and-forget routing. Undated decisions survive long past the model landscape that justified them. The date in your prompt file is the fix.
• Ignoring output-token pricing. Verbose tasks (long reports) are output-heavy, and output is priced several times higher — a "cheap" model prompted into verbosity can out-cost a terse frontier call (details in pb-11).

Restricted-environment variant

• •
  Confidential-data tasks skip the ladder entirely: local tier (pb-07), full stop. Run the eval anyway — knowing your local model scores 7/10 on the task tells you exactly how much human review the restriction is buying you.
• •
  Anonymized-then-hosted (pb-01 method) reopens hosted tiers for some client tasks: eval on anonymized inputs to confirm the anonymization didn't break task quality.
• •
  Enterprise tenants with data-residency/no-training guarantees may make mid-tier hosted models compliant where consumer tools aren't — the routing rule then becomes "approved tenant tiers only," and the recipe applies within that menu.

Success criteria

• •
  Three of your recurring tasks have written four-axis scores and an assigned tier.
• •
  At least one task was validated with a two-tier eval comparison, numbers recorded.
• •
  At least one task was deliberately downgraded (or a downgrade was rejected) based on eval evidence — either outcome proves the recipe is live.
• •
  Every routing decision in your prompt library carries a date and the eval scores behind it.