Multi-model routing voor coding agents: wanneer doen?

Wat multi-model routing doet met een coding agent

Multi-model routing stuurt elk verzoek naar het goedkoopste model dat het kan verwerken. Bij chatverkeer werkt dit goed. Bij een coding agent kost het meestal meer dan het oplevert, omdat de rekening van een agent wordt gedomineerd door een prompt-prefix die per model wordt gecachet. Wisselen van model zorgt ervoor dat deze cache verloren gaat.

De regel waar dit artikel voor pleit: routeer over providers voor beschikbaarheid, routeer over tiers voor kosten alleen bij taakgrenzen, en pin één model per sessie voor alles wat agent-gebaseerd is. Alles hieronder is de onderbouwing.

Vier termen, eenmalig gedefinieerd. Een router kiest een model per verzoek. Een gateway is de proxy waar het verzoek doorheen gaat, die al dan niet ook kan routeren. Een prompt cache is de provider die de verwerkte prefix van uw prompt opslaat, zodat een later verzoek dat deze prefix herhaalt tegen een fractie van de invoerprijs wordt gefactureerd. Een KV cache (key value cache) is hetzelfde concept binnen een server die u zelf beheert.

Waarom chatverkeer goed routeert en agentverkeer niet

Een chatverzoek bestaat uit één beurt. Het komt binnen, wordt geclassificeerd, gaat naar een model en keert terug. Er wordt niets meegenomen naar de volgende beurt. Een router kan deze vraag naar een klein model sturen en de volgende naar een groot model, zonder dat een van beide verzoeken weet dat de ander heeft plaatsgevonden. Dit is de werklast die bijna elke routeringsbenchmark meet, en goede routers zijn hier oprecht goed in.

Een agentbeurt is niet één verzoek. Eén instructie zoals "fix the failing test" wordt twintig tot zestig API-aanroepen. Elke aanroep verstuurt het volledige gesprek opnieuw: de system prompt, elke tooldefinitie, elk bestand dat de agent heeft gelezen en elke commando-output die hij heeft gezien. De context groeit alleen maar. Bij de dertigste aanroep kan het herhaalde voorvoegsel tienduizenden tokens bevatten, terwijl de werkelijk nieuwe inhoud in elke aanroep slechts enkele honderden tokens beslaat.

Die vorm verandert wat het woord "duur" betekent. Bij chat zijn de kosten grofweg de prijs van het model vermenigvuldigd met het verzoek. In een agent-loop zijn de kosten het voorvoegsel, dat bij elke afzonderlijke aanroep opnieuw in rekening wordt gebracht. De rest van dit bericht vloeit voort uit dat ene feit.

De prompt-cache is per model en de agent bevindt zich daarbinnen

Anthropic berekent voor een cache-read 0,1 keer de basisprijs voor input, en voor een cache-write van vijf minuten 1,25 keer. Dit zijn de gepubliceerde catalogusprijzen, zoals die gelden per augustus 2026.

[
  {
    "label": "Opus 5",
    "uncached_input_usd": "5.00",
    "cache_read_usd": "0.50"
  },
  {
    "label": "Sonnet 5",
    "uncached_input_usd": "2.00",
    "cache_read_usd": "0.20"
  },
  {
    "label": "Haiku 4.5",
    "uncached_input_usd": "1.00",
    "cache_read_usd": "0.10"
  }
]

Vergelijk de tweede reeks met de eerste, horizontaal in plaats van verticaal. Een cache-read op Opus 5 kost 0.50 dollar per miljoen tokens. Ongecachte input op Haiku 4.5, het goedkoopste model in de lijst, kost 1.00 dollar. Het opnieuw inlezen van een warm prefix op het duurste model kost dus minder per input-token dan het koud inlezen van datzelfde prefix op het goedkoopste model.

Die enkele vergelijking haalt de meeste routeringsplannen onderuit. Een router die werk naar een lagere klasse verplaatst, vergelijkt catalogusprijzen. Maar een agent die zich midden in een sessie bevindt, betaalt niet de catalogusprijs voor het model dat hij al gebruikt. Hij betaalt de prijs voor een cache-read, die al lager ligt dan het ongecachte tarief van het goedkope model.

Caches worden geïndexeerd op basis van een hash van het prompt-prefix en zijn specifiek per model. Een verzoek aan een ander model wordt gehasht tegen een opslag die het nog nooit heeft gezien, waardoor er niets wordt gevonden en de volledige prijs wordt betaald. De cache is bovendien hiërarchisch: eerst tools, dan het systeem, dan de berichten. Een wijziging op welk niveau dan ook maakt dat niveau en alles wat daarna komt ongeldig; dit betekent dat het bewerken van één tool-definitie de cache van de systeem-prompt die erachter staat, verwijdert. Agents die tijdens runtime tools registreren, lopen hiertegenaan zonder dat er überhaupt een router aan te pas komt.

De werkelijke kosten van één switch tijdens een sessie

Neem een sessie met een stabiel voorvoegsel van 40.000 tokens; een gebruikelijke omvang zodra een agent een handvol bestanden heeft gelezen. Hieronder staan de kosten voor het voorvoegsel van één beurt, berekend op basis van de bovenstaande catalogusprijzen.

[
  {
    "label": "Opus 5, cache warm",
    "prefix_cost_usd": "0.020"
  },
  {
    "label": "Sonnet 5, turn after switch",
    "prefix_cost_usd": "0.100"
  },
  {
    "label": "Opus 5, cache re-warmed",
    "prefix_cost_usd": "0.250"
  }
]

Opus 5 blijven gebruiken met een warm cachegeheugen kost 0.020 dollar voor het voorvoegsel van die beurt. De eerste beurt na het routeren naar Sonnet 5 kost 0.100 dollar, omdat Sonnet geen vermelding voor dit voorvoegsel heeft en er een moet schrijven. Terugkeren naar Opus 5 kost 0.250 dollar, omdat de oorspronkelijke vermelding is verlopen terwijl de sessie elders was.

De retourrit betaalt dus twee cache-schrijfacties om twee cache-leesacties te vermijden. Daar staat tegenover dat de switch één beurt aan output opleverde tegen de outputprijs van Sonnet in plaats van die van Opus. Het details-blok werkt de gehele rit uit: de besparing komt uit op fracties van een cent, terwijl de cache-boete in de tientallen centen loopt. De boete is meer dan een orde van grootte groter en groeit mee met de lengte van het voorvoegsel, terwijl de besparing dat niet doet.

Opus 5, warm read     40,000 x $0.50 / 1e6  = $0.020
Sonnet 5, cache write 40,000 x $2.50 / 1e6  = $0.100   (1.25 x $2 base)
Opus 5, cache write   40,000 x $6.25 / 1e6  = $0.250   (1.25 x $5 base)

800 x ($25 - $10) / 1e6 = $0.012

Tool-call-formaten verschillen per provider

Een agent is een lus voor het aanroepen van tools, waardoor het formaat van de tool-call op een manier van belang is die bij chat nooit het geval is. De Messages API van Anthropic retourneert een tool_use-inhoudsblok en verwacht een tool_result-blok terug. OpenAI-compatibele API's retourneren een tool_calls-array waarin function.arguments een JSON-gecodeerde string is in plaats van een genest object. Een gateway vertaalt tussen deze twee, en voor standaardaanroepen is de vertaling foutloos.

De problemen ontstaan aan de randen. Parallelle tool-calls, waarbij een model meerdere aanroepen in één antwoord genereert, worden verschillend weergegeven en worden niet overal identiek ondersteund. Strikte schema-handhaving is een functie die per provider verschilt; een model dat op het ene eindpunt schema-valide argumenten garandeert, neigt op een ander eindpunt slechts naar valide argumenten. De agent ziet het verschil als een tool-resultaat dat een parse-fout bevat, die hij vervolgens probeert te herstellen door een extra beurt te verbruiken. Die herstelbeurten worden tegen de volledige prefix-prijs gefactureerd, waardoor een formaat-mismatch zowel in het transcript als op de factuur zichtbaar wordt.

Self-hosted eindpunten vereisen dat dit expliciet wordt geconfigureerd. De OpenAI-compatibele server van vLLM vereist --enable-auto-tool-choice in combinatie met een --tool-call-parser die is afgestemd op de modelfamilie (hermes, mistral, llama3_json en andere), plus een chat-template die berichten met een tool-rol verwerkt. De documentatie van vLLM is direct over de beperkingen van dit pad: met tool_choice="auto" en zonder strikte schema-beperking extraheert vLLM tool-calls uit platte tekst, waardoor argumenten soms onjuist kunnen zijn of het parameterschema van de functie kunnen schenden. Het kiezen van de verkeerde parser voor uw model is een configuratiefout die zich manifesteert als een agent die geen tools kan aanroepen; dit is nuttig om te weten voordat u verkeer hiernaartoe routeert. Het verschil tussen Ollama en vLLM voor het zelf hosten van modellen is hier van belang, omdat beide tools op verschillende voorwaarden aanbieden.

Een fallback halverwege een taak wijzigt het gedrag zonder foutmelding

Fallback-routing is de functie die het vaakst per ongeluk wordt ingeschakeld. Een gateway is geconfigureerd om het opnieuw te proberen met een ander model wanneer het eerste model een rate limit of een 5xx-fout retourneert, waarna het gefaalde model voor enkele seconden in een cooldown wordt geplaatst. Bij chatverkeer is dit precies wat gewenst is. Bij een langdurige agent-taak betekent dit echter dat de tweede helft van uw taak is uitgevoerd door een model dat u niet heeft gekozen.

Niets rapporteert dit. De taak faalt niet, de agent geeft geen waarschuwing en de exit-status is succesvol. Wat u krijgt, is een taak waarbij het plan door het ene model is geschreven en de bewerkingen door een ander zijn uitgevoerd, met een toon en gewoonten die halverwege veranderen. Het enige betrouwbare signaal is het model-veld in het request-logboek van de gateway of de metadata van de response. Als u dus fallbacks gebruikt, log dit veld dan per request en lees het uit wanneer een resultaat u verrast. Het debuggen van gedrag zonder te weten welk model het heeft geproduceerd, kost meer tijd dan de fallback heeft bespaard.

Dezelfde valkuil geldt voor context-compressie. Veel agents vatten een lange geschiedenis samen door een klein model aan te roepen. Als die aanroep een ander model of een andere system prompt gebruikt, schrijft het zijn eigen cache-entry en ververst het de cache van de hoofdsessie niet, waardoor de volgende volledige beurt een cold prefix veroorzaakt. De compressie bespaarde tokens, maar verloor de cache.

Routing-overhead is reëel, maar latentie is niet het grootste probleem

Routers voegen per verzoek werk toe, en het is zinvol om nauwkeurig te zijn over de omvang daarvan. DigitalOcean rapporteert dat hun Arch-Router-model de routeringsintentie in ongeveer 51 milliseconden oplost, met een routeringsnauwkeurigheid van 93.17% in hun eigen evaluatie. Dit zijn hun cijfers, gebaseerd op hun eigen metingen en benchmarks; het zijn niet de onze en het is geen universeel resultaat. Als we deze cijfers als uitgangspunt nemen, is de conclusie geruststellend: 51 milliseconden over veertig agent-aanroepen is ongeveer twee seconden extra voor een taak die enkele minuten duurt.

Twee seconden is niet wat routering hier duur maakt. De overhead die wel pijn doet, is een router die classificeert met een volledige model-aanroep, omdat dit een tweede inferentie per verzoek is, die net als elke andere wordt gefactureerd en in de wachtrij wordt geplaatst. Onder beide ligt de hierboven genoemde cache-rekenkunde, wat helemaal geen overhead is. Het is de kostprijs van hetgeen routering juist moest optimaliseren.

Op een server die u zelf beheert, geldt dezelfde regel met minder bewegingsvrijheid. Het lokale equivalent van de prompt-cache is prefix-caching in de KV-cache, die zich in het GPU-geheugen bevindt. Het hosten van twee modellen op één GPU verdeelt dat geheugen tussen beide, waardoor elk model een kleinere KV-cache behoudt en prefixes sneller verwijdert. Routeren tussen twee lokale modellen kan daarom de cache-hitrate voor beide tegelijk verlagen. Als u hiervoor hardware dimensioneert, is het geheugen en de CPU die een coding agent daadwerkelijk nodig heeft op een VPS een nuttiger startpunt dan een router.

De beslisregel

• Routeer over providers voor beschikbaarheid. Wanneer het alternatief een mislukt verzoek is, is elke prijs de juiste prijs. Koppel de fallback aan een model met hetzelfde formaat voor tool-aanroepen, zodat de lus van de agent blijft werken, en log welk model elk verzoek heeft afgehandeld.
• Routeer alleen bij taakgrenzen over verschillende niveaus voor kostenbeheersing. Kiezen voor Haiku voor een hernoeming en Opus voor een refactor is een goede beslissing als deze eenmalig wordt genomen, voordat de sessie begint. Het is een slechte beslissing in de dertigste beurt van die sessie.
• Koppel één model per sessie voor alles wat agent-gebaseerd is. De waarde van een sessie zit in de warme cache. Behandel het wisselen van modellen zoals u het wissen van die cache zou behandelen, want dat is precies wat er gebeurt.
• Routeer subagents vrijelijk. Een subagent die met een verse, kleine context begint, heeft geen warme cache om te verliezen, dus deze kan draaien op elk model dat bij de taak past. Dit is de enige plek binnen een agent waar routering vrijwel kosteloos is.

Voor de opbouw hiervan doet de gateway het werk: model-aliassen en expliciete fallback-lijsten. Een minimale LiteLLM proxy-configuratie ziet er als volgt uit.

model_list:
  - model_name: agent-primary
    litellm_params:
      model: anthropic/claude-opus-5
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: agent-standby
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY

router_settings:
  fallbacks: [{"agent-primary": ["agent-standby"]}]
  num_retries: 2
  cooldown_time: 30

Wijs de agent naar agent-primary en deze blijft op één model totdat dat model onbereikbaar is. Beide vermeldingen bevinden zich bij dezelfde provider, waardoor het formaat voor tool-aanroepen niet verandert wanneer de fallback wordt geactiveerd. U accepteert op dat moment nog steeds een wijziging van niveau, wat een afweging is die alleen de moeite waard is omdat het alternatief een mislukt verzoek is. Dat is beschikbaarheidsroutering zonder bijbehorende kostenroutering; dit is de combinatie die de meeste programmeer-agents wensen. De volledige opbouw, inclusief sleutels en budgetten, wordt behandeld in het draaien van een zelfgehoste LiteLLM gateway op uw eigen VPS, en dit bericht herhaalt dat bewust niet.

Wanneer één goed gekozen model beter is dan elke router

Routing is een oplossing voor variatie in de moeilijkheidsgraad van verzoeken. Een programmeer-agent heeft minder van die variatie dan het lijkt, omdat het dure gedeelte van elke aanroep hetzelfde voorvoegsel is, ongeacht waar de aanroep om vraagt. Zodra het voorvoegsel domineert, krimpt het verschil tussen uw goedkope en dure tier naar het verschil in hun outputprijzen, en output vormt slechts een klein deel van de tokens van een agent.

De eerlijke standaardinstelling is daarom één model, eenmalig gekozen, met caching ingeschakeld en een voldoende lange TTL (time to live) om de pauzes te overbruggen wanneer u stopt om een diff te lezen. Anthropic biedt een cache-schrijfactie van één uur tegen 2 keer de basis-inputprijs, wat zichzelf na twee keer lezen terugbetaalt, en dat is vaak een effectiever middel dan welke router dan ook. Kies de tier bewust met behulp van een directe vergelijking van Opus, Sonnet en Haiku, en als de rekening nog steeds het probleem is, verlaag deze dan met budgetten en kleinere contexten zoals beschreven in het beheersen van AI-agentkosten op een VPS in plaats van met het wisselen tijdens een sessie.

Gebruik routing wanneer verzoeken onafhankelijk en kort zijn, of wanneer sub-agents met een nieuwe context beginnen. Pin het model vast wanneer u één lange sessie heeft die één taak uitvoert. Het meeste werk van een programmeer-agent is van het tweede type, en dat is waarom de router die geld bespaart op uw chatproduct, u hier stilletjes geld zal kosten. Als u nog niet heeft besloten welk model u voor de agent zelf gebruikt, behandelt de vergelijking van Claude Code tegenover Cursor, Codex en Copilot hoe elk daarvan omgaat met modelselectie, en sommige nemen deze beslissing zelfs voor u.

FAQ

Gaat de prompt-cache echt verloren als ik halverwege een sessie van model wissel?

Ja. Prompt-caches zijn gekoppeld aan een hash van het prompt-voorvoegsel en worden per model opgeslagen. Een verzoek dat naar een ander model wordt gestuurd, zoekt in een opslag die dat voorvoegsel nog nooit heeft gezien. Het vindt niets en u betaalt de volledige prijs voor ongecachte invoer, plus de kosten voor het schrijven naar de cache als caching is ingeschakeld. Terugschakelen herstelt het oorspronkelijke item evenmin, omdat de standaard levensduur van vijf minuten tegen die tijd meestal is verstreken. Controleer de velden cache_read_input_tokens en cache_creation_input_tokens in het usage-object van het antwoord: een beurt waarbij nul gecachte tokens worden gelezen tijdens een lange sessie is het symptoom.

Is routeren naar een goedkoper model ooit goedkoper voor een agent?

Alleen als er geen warme cache is die verloren kan gaan. Een cache-read bij Anthropic kost 0,1 keer de basisinvoer, waardoor een warme read op Opus 5 goedkoper is dan de ongecachte invoerprijs op Haiku 4,5. Zodra een sessie een groot gecacht voorvoegsel heeft, is het huidige model al de goedkope optie voor invoer. Routeren loont wanneer de context vers en klein is: aan het begin van een taak, of in een subagent die alleen de benodigde context meedraagt.

Waarom gedroeg mijn agent zich halverwege een taak anders?

Controleer of er een gateway-fallback is geactiveerd. Een rate limit of een 5xx-fout bij het primaire model zorgt ervoor dat de gateway het verzoek opnieuw probeert bij het stand-by model en het primaire model enkele seconden in een afkoelperiode plaatst, waardoor de rest van de taak elders wordt uitgevoerd. Dit levert geen foutmelding of waarschuwing op en de taak rapporteert nog steeds succes. Het veld model in het gateway-verzoeklogboek of de antwoordmetadata is het enige betrouwbare verslag; log dit dus per verzoek als u fallbacks gebruikt.

Werken tool-calls hetzelfde bij elke provider?

Niet precies. De Messages API van Anthropic gebruikt tool_use en tool_result inhoudsblokken, terwijl OpenAI-compatibele API's een tool_calls-array gebruiken waarvan de function.arguments een JSON-gecodeerde string is. Een gateway vertaalt de gangbare gevallen goed, maar parallelle tool-calls en strikte schema-handhaving verschillen per provider. Bij zelfgehoste vLLM moet u --enable-auto-tool-choice en een --tool-call-parser instellen die overeenkomt met uw modelfamilie. De documentatie van vLLM vermeldt dat de server zonder strikte schema-beperking tool-calls uit platte tekst extraheert, waardoor argumenten soms onjuist geformatteerd kunnen zijn.

Hoe lang moet ik de cache-TTL instellen voor een programmeersessie?

Gebruik de standaard levensduur van vijf minuten voor continu werk, en de optie van één uur wanneer een mens diffs tussen beurten doorleest. Anthropic prijst de schrijfactie van vijf minuten op 1,25 keer de basisinvoer en de schrijfactie van één uur op 2 keer, tegenover een read-actie van 0,1 keer. De schrijfactie van vijf minuten wordt terugverdiend met één read-actie, en die van één uur met twee. Bij elke sessie waarbij u verwacht terug te keren en door te gaan, zijn de kosten voor de langere levensduur meestal lager dan de kosten voor een koud voorvoegsel.