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.
Analysis of alternatives, model router or hard-coded model: which job each does
Choose a decision method for the job and the moment a model must be selected.
Which approach fits the decision you need to make?
Use an analysis of alternatives to choose models for a job, a model router to select a model for each request, and a hard-coded model to keep an already suitable integration stable. A router is the better tool for per-request routing on live traffic. A hard-coded model is the better tool when one model already fits and change is costly.
Updated .
| Question | Analysis of alternatives | Model router | Hard-coded model |
|---|---|---|---|
| When do you decide? | Before deployment or when a job's requirements change. | For each request on live traffic. | During implementation or a planned configuration change. |
| What does it optimise? | Fit to explicit job requirements and preferences. | The routing policy's quality, cost, latency or availability objective. | A stable integration with the chosen model. |
| What evidence does it use? | Sourced facts, admitted benchmarks and offering costs in a snapshot. | Request features and whatever evaluations, feedback or telemetry the router uses. | The tests and operational experience used to choose and retain that model. |
| Can you reproduce the decision? | The same spec and snapshot reproduce the answer. | Reproduction needs the policy version, request and relevant runtime state. | The configured choice is repeatable; model outputs and service versions can still change. |
| How are licence, self-hosting and VRAM constraints handled? | Express supported constraints as Must and inspect unknown facts and exclusions. | Restrict the candidate pool and enforce policy checks; routing alone does not prove compliance or hardware fit. | Validate the chosen licence, deployment route and memory fit before release and after changes. |
| What per-request latency and cost does it add? | The analysis runs per job and adds no routing hop to model requests. | Selection can add compute, latency or service cost; the amount depends on the implementation. | No model-selection step runs per request; the model's serving latency and cost remain. |
| How can it fail? | Incomplete evidence or an inaccurate job spec can leave the decision unresolved or unsuitable. | A miscalibrated policy or stale feedback can route requests to an unsuitable model. | A fixed choice can become unsuitable as the job, model or service changes. |
| When is it the right fit? | A defensible choice for a job with constraints and alternatives worth evaluating. | Per-request routing on live traffic with varying needs. | One model already fits and the cost of change outweighs the expected benefit. |
Can these approaches work together?
An analysis of alternatives can establish an eligible set for a router or justify a fixed model choice. The router still needs a policy for live requests, and a fixed choice still needs monitoring when requirements change. ModelSpec decides per job or role and does not proxy model requests.
Read the decision method, try a dated use-case example, or inspect model comparisons. About ModelSpec states its claims.
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