Why routing decisions need to be deterministic
If you can’t reproduce a routing decision, you can’t audit it. That is the whole argument for why Soriku’s router is deterministic, not probabilistic, and it took longer to build than a router that just picks whatever feels fastest at the time.
A routing decision that isn’t reproducible is a decision nobody can stand behind later. If a customer asks why their security review went to one model instead of another, or a regulator asks the same question in a more formal tone, "it seemed like a good idea at the time" is not an answer. Neither is "we’re not sure, it might do something different if you ran it again."
Same input, same output, every time
The rule is simple to state: the same prompt, checked against the same capability map, under the same constraints, goes to the same model every single time. The only thing that changes a routing decision is the capability map itself changing, and a new measurement always carries a timestamp. Nothing about time of day, server load, or which model happens to be warm in memory gets a vote.
A re-benchmark is a deliberate, logged event, not something that happens quietly in the background and reshuffles your routing table without telling you. If a model’s score moves, you can see when it moved and why the routing decision that used to land on model A now lands on model B.
Ties don’t get resolved by a coin flip
Two models occasionally land close enough on a category that the difference sits inside the measurement’s own spread. That’s not a gap for randomness to fill. A fixed priority order settles it, the same way every time, so a near-tie today resolves the same way it resolved yesterday. We keep the tie-break rule dull on purpose. Interesting tie-breaks are the first thing that breaks reproducibility.
Compare that to routing built around load balancing or vibes: the same request sent on a Tuesday and a Wednesday can land on a different model for reasons that have nothing to do with the prompt, which server happened to be free, which model was already loaded. That’s a reasonable design for spreading load evenly. It’s a bad fit for a decision you might have to explain six months later.
Every answer carries its own paper trail
Every response Soriku returns comes with the model that produced it, the score that got it picked, and the category it was scored against. That’s not a debugging feature bolted on for developers, it’s the same information a human reviewer would need to check the decision after the fact, without re-running anything.
Determinism doesn’t make the router smarter. It makes it something you can stand behind, which turns out to matter more than being clever on any single request.