ModelSpec is an analysis of alternatives for AI models: it decides which models fit a job from your requirements, sourced benchmarks and real cost, and shows its work.

How to choose an AI model for a job

State Must and Prefer, read the evidence, and inspect a dated worked example.

Worked example as of 2026-09-23, from the public data image.

What is an analysis of alternatives for AI models?

An analysis of alternatives for AI models decides which models fit a job and shows its work, using the job's requirements, sourced benchmarks and real cost. ModelSpec performs this analysis per job or role. Read about ModelSpec for its entity facts.

How do you state the job's requirements?

Put non-negotiable requirements in Must and tradeable priorities in Prefer. A Must screens candidates for a condition such as a licence, context capacity or self-hosting support. A Prefer tells the engine how to weigh the candidates that remain. Start with an existing use-case template, then change it to match the job.

What evidence decides which models fit?

Requirements, sourced benchmark measurements and real task cost decide the result. Check whether a benchmark measures the capability your job needs and whether the facts cover the offering you can actually use. Missing facts stay unknown; they are not proof of compliance. Use dated model comparisons to inspect the evidence.

Why is the top often a tie?

The top is a tie when the evidence cannot separate the leading alternatives under the engine's probability rule. Task cost, throughput, open weights and independent measurements can help choose within that tie. A tie-breaker does not turn uncertainty into an evidence-supported winner. The worked example below prints the engine's rule and available tie-breakers.

Why compare cost per task?

Cost per task prices the input and output your job actually uses. A token price alone leaves out task size and the offering's price schedule. Set a realistic workload before comparing costs. Check retries and correction work separately when estimating total operating cost.

What does the screened-out list tell you?

The screened-out list explains which candidates failed a requirement and why. Read it before relaxing a Must. Keep failed requirements separate from unknown facts and missing objective evidence. A model that may qualify still needs evidence before it becomes a recommendation.

Read the full decision method for Must, Prefer, uncertainty and reproducibility.

What does a dated budget-coding decision show?

This delayed example applies the Coding agent on a budget template. Alternative labels replace product names throughout this guide. The linked dated use-case page names the models.

Use Must for non-negotiable context and budget limits, then Prefer to trade coding strength against cost.

• Must: model.class = text-generator. Coding work needs a model that generates text and code.
• Must: model.lifecycle = active. An active model is still supported by its lab or provider.
• Must: model.context_window >= 200000. A large repository needs room for code, tests, and instructions.
• Must: offering.cost_per_task <= 0.05. The offering must stay within the per-task budget.
• Prefer: software_engineering, weight 0.6. Prefer stronger evidence on real software-engineering tasks.
• Prefer: -offering.cost_per_task, weight 0.4. Among qualifying offerings, prefer the cheaper task.

Decision status: partial. Decision dec_e714b968d27e687c50bbf4db on public snapshot snap_05a963d2477ac2fb.

Tied on the evidence: Alternative D, Alternative E.

probability bands: a model joins the leader when P(its score >= the leader's) >= 0.25 under the score posteriors; a weighted capability with an 80% interval wider than 2.8 is not enough evidence

Tie-breakers describe members of the tie. They do not establish a winner. Unavailable means the engine did not return a value or a unique tie-breaker.

• Lowest task cost: Unavailable.
• Highest throughput: Unavailable.
• Sole open-weights member: Unavailable.
• Most independently measured member: Alternative E.

Cost per task is in USD for the engine-selected offering at 40000 input tokens and 4000 output tokens. The engine applies the offering's input and output prices to that task size. This template uses the engine's default task size. It does not measure retries or the cost of correcting an answer. Unavailable cost is not free.

Scores and score intervals use dimensionless normalised objective units. P(best) is the engine probability. Thin evidence is undetermined and is not a recommendation.

Which alternatives were screened out?

These counts group exclusion rows by failed condition. A model can appear under more than one condition or offering, so the counts are not distinct model totals. An offering can fail while another offering of the same model qualifies.

Showing 10 of 1381 exclusion rows. Offering labels identify routes within this example.

Read the full screened-out list on the dated use-case page.

Some candidates may qualify but lack a required fact or objective value: model.context_window, offering.cost_per_task.

The live board uses current data. Its answer can change as evidence changes.

Apply this template on Decide

Human lookup is free on Decide. CLI, API, and MCP access requires a key. Access and pricing.

Guides · Use-case examples · Model comparisons · How we decide