When routing is dynamic, "which model ran?" is an audit question

The first half of 2026 had a word for AI budgets: tokenmaxxing, use as much as possible and sort the bill out later. The correction now has a word too. Business Insider recently described “modelmaxxing”: engineering leaders assigning different models to different work, frontier models where the task earns it, cheaper ones everywhere else, one CTO telling his engineering teams, twice a week, which models to use and when.^[1] It works, and it beats blunt token caps.

Routing wants to be a policy, not a standup item

A human prescribing models per team twice a week is a person doing, by hand, what a request path can do per call: classify the work, route it to the cheapest model that clears the quality bar, keep the frontier models for the requests that need them. That migration is already underway across the tooling ecosystem, and it is the right direction. Spend follows task value instead of habit.

But notice what quietly changed. Before routing, “which model do we use?” was a decision with a paper trail: a config value, a procurement note, a line in the architecture doc. After routing, it is a runtime outcome that can differ on every request. The efficiency is real, and so is the new question it leaves behind.

The question arrives later, and it arrives per request

For plenty of teams the question never bites. For anyone operating under review, it does, and always retrospectively. A customer escalates one specific answer. A validator asks which model version produced the outputs in the quarter under review. An incident needs the exact configuration behind one bad response. A vendor register says one model name and the router, doing its job, served three. None of these are objections to routing. They are the same question at different altitudes: for this request, which model actually ran, and can you show me rather than tell me?

An answer that has to be reconstructed from the router's own logs is a claim by the operator. It may well be true. It is not evidence, and the difference starts to matter exactly when the question is asked by someone whose job is not to take your word for it.

Route aggressively, prove precisely

The fix costs one property: the routing decision should produce a signed record at the moment it is made. Seal's request path works that way. You point your SDK at the gateway with a base URL change, ask for routing by cost, latency, quality, or estimated energy, and each call it allows through comes back with a receipt that names the model, the rule that chose it, a hash of the request, and the time of the decision.^[2] The receipt verifies offline against a published key with open-source verifiers, so the person asking “which model ran?” checks the answer themselves rather than trusting whoever operates the router.

The energy option deserves a word, because it falls out of the same mechanism. Routing that minimises estimated energy use returns the estimate on the decision, which gives sustainability reporting a per-decision line item. The figures are modelled estimates, not metered measurements, and we label them that way.

The honest boundary

A signed receipt proves what the gateway said ran, made tamper-evident at decision time; it does not, by itself, prove what the provider's compute did behind its API. We document that boundary, and the rest of the trust assumptions, in the threat model of our own system.^[3] For the routing question, the receipt is the difference that matters: the model name stops being a recollection and becomes a dated, checkable record.

Modelmaxxing is the right instinct: pay for exactly the capability each request needs. The teams that will be glad they did it properly are the ones whose routing layer can also answer, months later and under someone else's scrutiny, the only question that survives the savings: which model actually ran?