“Why not just…” — fair question, straight answers
Four versions of the same reasonable objection, answered without attacking anyone. Where Haybox fits, and where it doesn’t.
…use my editor’s built-in model picker?
Your editor is good at editing; keep it. Haybox is editor-neutral and sits underneath, which buys you three things the picker can’t: routing that’s accountable to measured outcomes rather than a menu, one ledger across every tool you use, and acceptance floors with de-routing when quality slips. Also worth saying plainly: tools that sell tokens or seats aren’t structured to minimize your spend. We are, and the receipt shows it.
…use OpenRouter or another gateway?
Gateways are useful, and the category’s success is part of why we exist. The difference is what each system can see. A request gateway sees requests. Haybox sees work: the repository, the diff, the tests, your accept or reject, the revert a week later. Routing on request metadata and routing on verified outcomes are different products, and only one of them can put a floor under quality, or tell you the savings number with a straight face.
…use an observability tool?
Spend dashboards report the bill. Haybox is upstream of the bill: it routes the work that generates it, then reports with task-level receipts. If you already run an observability stack, the Ledger’s exports will get along with it fine.
…script this myself?
You could, and the daemon source is readable if you want a head start. What the weekend version won’t have: acceptance floors, sampled baseline comparisons, revert tracking, deterministic rules injection, a maintained model catalog, and routing that improves from measured outcomes. If you build it anyway, publish your numbers; we mean that.
If after all this the answer is “still not for me,” fair. Take the free Shadow Mode report on your way out; it’s your data.