Tie-Breaking Between Equal API Providers: Publish the Rule

Tie-breaking between equal API providers sounds like an edge case, but it decides a real share of agent traffic. When two candidates land on the same score, the measurements have stopped choosing, and whatever rule breaks the tie is now picking the provider. If that rule is undocumented, the most consequential part of the decision is the part nobody can inspect.

Ties are more common than exact equality suggests

Two providers rarely produce identical raw numbers. They often produce scores that the data underneath cannot honestly separate, and that is the case that matters.

Three properties of a comparison make near-ties routine:

• Scores are rounded for display and for storage, so small differences collapse into the same value.
• Latency and success rate are measured on a finite number of calls. A gap smaller than the variation between samples is not evidence that one provider is better.
• The score is relative to the candidates in that one comparison. Add or remove a third candidate and two scores that were apart can meet, or two that were level can separate.

A sensible decision layer therefore treats candidates within a small margin as tied, rather than letting a fraction of a point choose the winner. Once you accept that, the tie-break rule stops being a footnote and becomes a routing policy.

Not every tie is the same tie

A tie on the final number can hide very different situations, and the rule should know which one it is facing.

Two candidates can be level because they are genuinely close on every measured dimension. They can also be level because one is cheaper and slower while the other is dearer and faster, and the weights happen to balance. Those are different ties. In the first, either provider is a defensible choice. In the second, the buyer's actual preference would settle it immediately, and the tie only exists because no preference was stated.

There is a third case that is easy to miss. When a dimension has not been measured for one candidate, an honest comparison drops that dimension from its weighting rather than scoring it as zero. A fully measured candidate can then tie with one scored on fewer dimensions. The scores match, but the evidence behind them does not, and a tie-break that ignores this treats a known quantity and a partial one as interchangeable.

The three families of tie-break rules

Most routers break ties in one of three ways, and each one has a cost.

• A fixed ordered list of criteria, ending in a stable unique key. For example: lower price first, then lower measured latency, then higher success rate, then the candidate identifier. The result is fully reproducible. The cost is that the last key always favours the same provider when everything else is level, which is a quiet bias against everyone whose identifier sorts later.
• Random selection among tied candidates. Volume spreads evenly and no provider is systematically favoured. The cost is that the decision cannot be replayed, so neither the buyer nor the losing provider can check why one call went where it did.
• Rotation or a seeded split. Volume spreads like random selection, but the choice for any given call can be recomputed from the seed or position. This keeps both fairness and reproducibility, at the price of a little more state.

None of these is wrong. What is wrong is not knowing which one is running. A buyer that cannot name its tie-break rule cannot explain a meaningful fraction of its own routing, which undermines the whole argument for explainable decisions over model judgement.

Why the rule has to be published in advance

A tie-break chosen after the fact is indistinguishable from a thumb on the scale. Publishing the rule before any decision is made is what turns it from discretion into policy.

It matters to three parties. The buyer needs to reproduce its own decisions when an outcome is questioned later. The losing provider needs to know whether it lost on measurements or on an ordering rule it could never have influenced. And anyone auditing the route needs to see that the same inputs always produce the same choice.

It also matters for what happens next. In a tie, the runner-up is not a weaker candidate. It is an equal one that lost on the rule. That makes it the most natural second-choice provider when the winner fails, and the decision record should make that explicit rather than burying it in a list of rejections.

Record the tie itself. A stored decision should show that the top candidates were level and which rule separated them. Recording agent provider decisions is only useful if the record distinguishes a choice the data made from a choice the tie-break made.

Resolve most ties before the fallback rule runs

The cleanest tie-break is the one the buyer supplies by stating what it cares about. Candidates that are level on a balanced score are rarely level on a single dimension, so naming a preference dissolves most ties before any fallback is needed.

That is the same discipline described in how AI agents choose an API provider: state requirements once and apply them everywhere. If a workload is price-sensitive, say so. If it waits on a user, say latency matters most. The ordering rule should then only handle the ties that survive a stated preference, which is a much smaller set.

For providers, the practical lesson runs the other way. If you keep landing in ties, look at which dimension is level. A tie on price can be broken by a small change on your side. A tie created by a dimension you have not been measured on may disappear once enough of your calls have been observed.

Where Apiosk fits

Apiosk's `/v1/decide` returns one provider, the rule that picked it, every rejected candidate with the exact constraint that removed it, and the runners-up in order. Reading that response next to `/v1/compare` for the same candidates shows whether the winner and the first runner-up carried the same score, which tells you the choice came from the rule rather than the measurements.

Buyers can resolve many ties up front with `optimize_for=price|latency|reliability|balanced`, alongside hard limits such as `max_price` and `max_latency_ms`. Every 0–100 score in the comparison is relative to that candidate set and arrives with its weights and per-dimension contributions, and unmeasured dimensions are dropped and named rather than scored as zero. `POST /v1/decisions` records which provider was chosen and which alternatives were rejected, so a tied choice stays traceable afterwards.

If you are a provider who keeps tying with a competitor, list your endpoint as a reviewed candidate so that every dimension you can be measured on actually is, and the next tie is decided by evidence rather than by an ordering rule.