pick-model

Pick Model

Classify the task, apply the escalators, then recommend the cheapest Claude tier that meets the quality requirement.

Mindset

• Right-size and do not default up. Keep to the cheapest tier that meets the quality bar. Escalating after a failed attempt costs one retry; an Opus habit costs every call.
• Judge reasoning demand, not volume. Pass a long document to a summariser at the same tier as a short one.
• Name tiers (fast, balanced, reasoning) before model names. Model names are retired and renamed; tier meaning lasts.
• Escalate with a stated reason. Always name the signal that moved the tier.

When to Use

• Use it when a user asks which model fits a task, before the work starts.
• Use it when an agent must assign a model to a sub-task without a human in the loop.
• Use it when a pipeline or batch job overspends on a frontier model for simple work.
• Use it when the cost against capability trade-off must be explicit, for example in production routing.

When Not to Use

• Do not use it when infrastructure or an explicit user instruction already fixes the model.
• Do not use it once the task is finished, because the choice is moot.
• Do not use it for cross-vendor comparisons or live pricing, which this skill does not hold.
• Do not use it when a fine-tuned or domain-specific model decides the outcome, not the tier.

Procedure

1. Read the task from $ARGUMENTS. Ask for it when the argument is empty.
2. Match the task type to a base tier in the matrix below. Match what the task demands, not how long it is.
3. Run every escalator check below. Move up exactly one tier when any escalator fires, capped at Opus.
4. Apply the tie-breaks below to a borderline call.
5. Adjust for cost and latency only after the tier is settled.
6. Make the recommendation in the output template below. Always name the escalator or matrix row that decided it.

Base tier by task type