Slimme routing: de goedkoopste provider die snel genoeg is voor jouw prompt
Verschillende providers verkopen hetzelfde model, en de goedkoopste is vaak de traagste bij lange prompts. Dus voor elk verzoek controleert UberLLM hoe snel elke provider begint te antwoorden bij die promptgrootte en wat dit verzoek bij elk van hen zou kosten, behoudt de providers die snel genoeg zijn (binnen 2x van de snelste, of onder 1 seconde), en stuurt het verzoek naar de goedkoopste daarvan. Er is niets in te stellen: het draait op elk chatverzoek, tenzij je je eigen routingopties doorgeeft.
Waarom de goedkoopste provider niet goed genoeg was
Een model zoals DeepSeek V4.1 Flash wordt door verschillende providers tegen verschillende prijzen verkocht. Elke aanvraag naar de goedkoopste sturen werkt voor korte prompts. Het gaat mis bij lange prompts, want voordat een model zijn eerste woord schrijft, moet het de hele prompt lezen, en sommige providers lezen lange prompts veel langzamer dan andere.
We hebben dit gemeten op live verkeer op 28 oktober 2026. Bij DeepSeek V4.1 Flash deed de goedkoopste provider er 15 seconden over om het eerste woord te versturen voor prompts van 32k–128k tokens, en 34 seconden boven 128k. Een andere provider deed er 1.5–2 seconden over voor dezelfde prompts.
Dat is het belangrijkst voor coding agents. Claude Code, Cline en vergelijkbare tools sturen de hele werkcontext bij elke beurt, vaak 60k–130k tokens, en het grootste deel daarvan is een cache read.
Alleen de prijs leidde ook tot slechte keuzes bij die prompts. Rangschikken op basis van de normale inputprijs negeerde de prijs van cache reads, dus een lange gecachte prompt kon naar een reseller gaan die $0.07 per miljoen gecachte tokens rekende, terwijl een andere provider $0.0013 rekende. Die aanroep was langzamer en ongeveer 50x duurder.
Wat gebeurt er bij elk verzoek
- Snelheid meten per promptgrootte. UberLLM registreert de tijd tot de eerste token van elke provider voor elk model, in vier groepsgroottes: onder 8k tokens, 8k–32k, 32k–128k en boven 128k. Dezelfde provider beantwoordde een 31-token prompt in 1.7 seconden en een 105k-token prompt in 15.5 seconden, dus één nummer per provider zou onjuist zijn. De gegevens komen van echte oproepen. Aparte snelheidscontroles elke 5 minuten bij ongeveer 20k, 60k en 150k tokens vangen een vertraging op bij één grootte, zelfs wanneer korte oproepen snel zijn.
- Deze exacte aanvraag prijzen bij elke provider. Input, gecachte input en output worden afzonderlijk geprijsd, op basis van de tokenmix van deze aanvraag. Voor lange agent prompts is de prijs voor het lezen uit de cache meestal het grootste deel van de rekening.
- De providers behouden die snel genoeg zijn. Een provider kwalificeert wanneer de typische tijd tot de eerste token binnen 2x van de snelst gemeten provider ligt, of onder 1 seconde. Snelheid wordt beoordeeld op de mediaan. Langzame uitschieters tellen voor een kwart gewicht mee zodra een provider ten minste 10 samples heeft, zodat één slechte oproep een goede provider er niet uit duwt.
- De aanvraag naar de goedkoopste daarvan sturen. De snelste provider wint alleen wanneer de goedkopere te traag zijn.
- De gegevens actueel houden. 5% van de aanvragen gaan naar een provider waar we te weinig gegevens over hebben, zodat een provider die sneller is geworden, wordt opgemerkt. Een provider die een oproep weigert, wordt als onbruikbaar behandeld en binnen 15 minuten opnieuw geprobeerd.
Zonder snelheidsgegevens voor een model gaat de aanvraag naar de goedkoopste beschikbare provider. Een provider die boven de gebruikelijke prijs van het model geprijsd is, wordt alleen gekozen voor snelheid wanneer deze nog steeds minstens 50% onder de officiële catalogusprijs van het model ligt.
Lange prompts: een tweede provider wanneer de eerste traag is
Zelfs een snelle provider start soms traag. Bij één gecachte 120k-token prompt startte dezelfde provider in 0.45, 3.7 en 8.5 seconden bij drie opeenvolgende aanroepen. De juiste provider kiezen kan dat niet oplossen, dus lange gestreamde verzoeken krijgen een back-up:
- Prompts van 32k–128k tokens: als er na 1 seconde nog geen eerste woord is aangekomen, gaat hetzelfde verzoek ook naar een andere snelle provider.
- Prompts van meer dan 128k tokens: beide verzoeken starten tegelijk.
- De eerste provider die antwoordt, streamt het antwoord. Het andere verzoek wordt geannuleerd zodra het eerste woord arriveert.
Je krijgt één antwoord en betaalt voor één antwoord. Wij betalen voor het geannuleerde verzoek, uit een vast dagbudget. Wanneer dat budget op is, gaan lange verzoeken naar één provider tot de volgende dag (UTC).
Herpogingen gaan naar een andere provider
Als een aanroep mislukt voordat u enig antwoord ontvangt, probeert UberLLM het opnieuw via een andere route, tot 4 pogingen. Vóór slimme routering kon een herpoging opnieuw bij dezelfde trage provider terechtkomen. Een aanroep die bij elke poging mislukt, kost $0. De details vindt u in modellen en routering.
Resultaten op live verkeer
DeepSeek V4.1 Flash, tijd tot eerste woord:
| Promptgrootte | Voor | Na |
|---|---|---|
| 32k–128k tokens | 18 s | 3.3 s |
| Meer dan 128k tokens | 40 s | 3.4 s |
Bij gestreamde calls van meer dan 32k tokens (28 oktober 2026), ging de traagste 10% van de calls van 57 seconden naar 8.7 seconden. De kosten van 1,000 van die calls gingen van $2.49 naar $1.04, omdat cache-read prijzen nu meetellen in de keuze. Op 29 oktober begon een prompt van 203k tokens te antwoorden in ongeveer 4 seconden.
Eén beperking: geen enkele provider start een prompt van 100k tokens direct. Het duurt bij allemaal een paar seconden. Slimme routering verwijdert de extra wachttijd van de trage providers. Het kan de tijd die een snelle provider nodig heeft om de prompt te lezen niet wegnemen.
Wat je betaalt
Elke aanvraag wordt gefactureerd voor wat de provider die deze heeft afgehandeld in rekening bracht, zonder extra UberLLM-kosten. Elke oproep en de bijbehorende kosten staan vermeld in Dashboard → Activity. Om de prijs te maximeren, stuur provider.max_price mee met zowel prompt als completion. Slimme routering kiest dan alleen providers onder jouw limiet, en een aanvraag wordt nooit daarboven gefactureerd.
Je eigen routing gebruiken in plaats daarvan
Je hoeft niets te veranderen om smart routing te krijgen. Als je providers benoemt in provider.only, provider.ignore of provider.order, provider.sort instelt, of een :floor of :nitro suffix toevoegt aan de model id, wordt jouw keuze gebruikt en wordt smart routing niet uitgevoerd voor dat verzoek:
{
"model": "deepseek/deepseek-v4.1-flash",
"provider": { "sort": "price" },
"messages": [{ "role": "user", "content": "Hello" }]
}
provider.max_price is de uitzondering: het werkt samen met smart routing. Alle opties staan vermeld in modellen en routing.