ModelRig

The optimal model is a moving target.

We built ModelRig because we needed to lower token costs while holding quality — or raising it. Not once, as a migration, but continuously, as the ground shifts.

The hard part isn't that providers fail. The deeper problem is that the optimal model for a task is an empirical, perishable fact. Capabilities drift; prices move. Last quarter's right answer becomes this quarter's quiet overspend, and re-checking by hand never gets staffed. On the current leaderboard, models that pass the same schema fixtures differ in effective cost by two orders of magnitude.

So we measure instead of assume. Schema conformance, grounding, caching — probed against real fixtures, dated, with confidence intervals, raw samples published so anyone can rerun them. A reproduction passes when your rerun lands inside the published interval, and a disagreement is a contribution. When declared and probed behavior differ, we publish the discrepancy; when a model passes, we say so just as plainly. Validity isn't accuracy: perfect JSON, wrong numbers. We gate on both.

It is work to stay current on where to find the best model for each workload — and that work never stays done. But finding the model is only half: you then run on the proof — see every run in an inspectable artifact store (your agents' work products, not just their calls), grade what's working, and improve cost and quality by baking off a cheaper-or-better model on replayed traffic. See, grade, improve: the job we built ModelRig to do.

Honesty about limits is part of the method, not fine print. Our corpus is small and finance-weighted; we state its exact mix on every leaderboard render. Data that outlives its freshness SLO gets a banner, not a quiet pass. The probe suite, the registry data, and the leaderboard are open — code under Apache-2.0, data under CC BY 4.0 — because evidence you can't inspect is just a claim with formatting. Your routes stay YAML in your git; leaving is a git rm. Turn Optimization on for a route and we keep its telemetry rows and the review samples your bake-offs need — in your organization, row-scoped by the database, visible and deletable in the console — and you get community priors on your first bake-off and evidence on your own routes, at the same flat 2%; on Pure router nothing is retained, also at 2%.

Coverage is the community's first job: contribute a fixture or a probe.