Which model

---
name: which-model
description: Pick the AI model for a task before starting it, run a fair side-by-side test when the pick is a coin flip, and keep a scorecard so the picks improve. Use when I say which model, should this be the small or the big model, is this worth the top tier, run a bake-off, or when I paste outputs from two or more models and ask which one won.
---
Pick the model for the task, not the task for the model. I should leave each session knowing which tier does this job and why, with the result written down.

The failure this prevents: running everything through the biggest model out of habit, or the cheapest out of thrift, and never noticing that a different model got better at this kind of work.

Think in tiers, not names. Small (fast, cheap, for simple high-volume work), middle (the default for daily drafting, summarizing, code edits, research), top (multi-file builds, architecture, anything where a wrong answer costs more than the tokens). Names expire. Tiers do not.

## Step 1. Grade the task

Ask four questions and answer each in one line. If I gave enough to answer them, answer them yourself and show me. If not, ask all four at once, never one at a time.

  Stakes: how wrong can it be, and what does wrong cost?
  Steps: how many distinct things have to happen in order?
  Reading: how much does the model have to hold at once?
  Volume: how many times will this run?

## Step 2. Route it

Name the tier, then the current model in that tier from the vendor I am using, and give one sentence on why. If I am in Claude Code, give the exact switch command (/model plus the alias). If I am in a chat app, tell me which picker entry.

Before routing, read model-scorecard.md if it exists in the working folder. A scorecard entry for this kind of task outranks the defaults above. Entries older than 60 days are stale: say so, and offer a re-test instead of trusting them.

Do not default to the top tier. If the middle tier can do it, say the middle tier. If turning up effort or thinking on the current model would solve it without switching, say that first.

## Step 3. Bake-off, when the grade is a coin flip or I ask for one

Write one prompt for the task. It goes into every model word for word.
Write the scoring criteria before any output exists: three to five, specific to this task, each scored one to five. Show me the criteria and wait for a yes.
I run the prompt in each model and paste the outputs back labeled A, B, C. I do not tell you which model is which, and you do not ask until scoring is done.
Score every criterion for every output, show the table, name the winner and the margin. If the winner is within one point of second place, call it a tie and recommend the cheaper model.
Then I reveal the names, and you write the result to the scorecard.

## Step 4. Scorecard

Append one line to model-scorecard.md, creating the file if needed:

  YYYY-MM-DD | task type | models tested | winner | margin | one note

When I say "what changed," list every scorecard entry older than 60 days and every entry that names a model with a newer release you know about. If you can search, check the vendor model pages first. If you cannot, say the date of your knowledge and do not guess at releases.

## Rules

Never score outputs whose model names you can see. Tell me to hide them.
Never invent a benchmark number or a release date. Point me at the vendor page instead.
Never assume the newest model is the best for this task. Newer is a reason to re-test, not a verdict.
You are allowed to say "not me." If the scorecard shows another vendor's model winning at this kind of task, say so plainly. A model picker that can only pick its own vendor is a brochure.

The register, in one example: "Stakes: low, it is a first draft you will edit. Steps: two. Reading: one page. Volume: daily. Middle tier. In Claude Code that is /model sonnet. Your scorecard has no entry for first drafts, so if you want to be sure, say bake-off and I will write the prompt and the criteria first."