Een run in CodeLynq kan worden uitgevoerd door een van drie coding agents: Claude Code, de Codex CLI van OpenAI of een Grok CLI. Ze krijgen allemaal dezelfde goedgekeurde specificatie en doorlopen dezelfde verificatie, review, securityscan en architectuurcontrole voordat dezelfde pull request opengaat. De agent is een instelling per organisatie, geen ander product.
Met drie agents ligt de vraag voor de hand: moet een run daartussen kiezen? In september schreven we over routering tussen de niveaus van Claude en zeiden we, toen terecht, dat Grok en Codex daar buiten vielen. Dat is veranderd voor één smal geval, en juist dat smalle is waar deze post over gaat.
Twee instellingen, niet één
Automatische routering kiest per taak een Claude-model. Routering over providers is een tweede schakelaar, standaard uit, die de router ook de agent van een andere leverancier laat overwegen. Die twee hebben we bewust gescheiden. Welk model het werk doet, is een kostenbeslissing; welk bedrijf je code ziet, is een contractuele. Genoeg teams willen het eerste en mogen het tweede niet, en één schakelaar zou ze dwingen beide op te geven.
Een model dat in de organisatie-instellingen is vastgezet, gaat boven allebei. Als iemand bewust een model heeft gekozen, gaat de router daar niet tegenin.
Alleen waar een fout één nieuwe poging kost
De router overweegt Claude alleen te verlaten als hij al op het goedkoopste Claude-niveau is uitgekomen. In de praktijk is dat mechanisch werk: kleine chores zoals een dependency-update of een hernoeming, en kleine bugfixes die met een stacktrace binnenkwamen, waarbij het vinden van de bug al is gedaan. Als een goedkopere agent het daar fout doet, kost dat één nieuwe poging, en die is goedkoop.
Features, refactors en al het andere dat de regels op een sterker niveau zetten, wisselen nooit van provider. Een slechte refactor is duur door de review die nodig is om erachter te komen dat hij slecht is, niet door de tokens. Een paar cent besparen op de run is dan de verkeerde ruil.
Gemeten mislukkingen wegen zwaarder dan de prijs. De router telt al per project en per soort taak hoe vaak elk model het in één keer goed had. Heeft de goedkopere agent tien runs in een categorie en minder dan de helft daarvan in één keer goed, dan gaat dat project voor dat soort werk terug naar Claude, en de reden bij de run zegt dat.
Op dit moment is het codeermodel van Grok de kandidaat voor routering over providers. Codex draait als een organisatie het als agent kiest; de router kiest het niet uit zichzelf.
Drie leveranciers in één eenheid vergelijken
Je kunt niet op kosten routeren zonder kosten te vergelijken, en de CLI's helpen daar niet bij. Claude Code meldt wat een run kostte. Grok en Codex melden geen kosten en ook niet betrouwbaar het aantal tokens. Daarom houden we per model een tarieftabel bij, en vergelijkt de router een gemengd tarief dat is afgestemd op de vorm van een coderun: veel repository erin, een kleine diff eruit.
De schatting op basis van die tabel wordt apart opgeslagen van de kosten die een CLI meldt, zodat een gok nooit als meting wordt gelezen, en elke run houdt de schatting van het moment waarop hij draaide. Een model zonder tarief krijgt geen schatting in plaats van nul, want met nul lijkt het gratis en wint het elke vergelijking. Om dezelfde reden weigert het scherm waarin wij de tarieven bijhouden een nul en laat het vóór het opslaan zien welke soorten taken onder de nieuwe bedragen van agent zouden wisselen. Een tikfout in een tarief zou anders werk omleiden zonder één foutmelding.
Wat er onderweg misging
De eerste versie had een gat: de router kon een Grok-model kiezen terwijl de run nog op Claude Code stond. Onze eigen veiligheidscheck laat een model vallen dat niet bij de agent hoort, dus de run zou ongemerkt zijn doorgegaan op het standaardmodel van Claude, tegen de prijs die de router juist wilde vermijden. De agent volgt nu het gerouteerde model, en het runlog meldt wanneer hij wisselde.
De CLI's leerden ons nog iets. Onze eerste Grok-opdrachtregel nam de flags van Claude Code over, en die accepteert Grok niet. Codex start in een alleen-lezen sandbox tenzij je anders aangeeft, dus het kan niets wijzigen en toch afsluiten alsof het gelukt is. De opdrachtregels zijn nu getest tegen de echte programma's, die op exacte versies vastliggen in onze image, omdat deze tools naast de toegangsgegevens van je repository draaien.
Een router moet zichzelf uitleggen
Een tijdlang legden we bij elke run vast welk model de router koos, de reden, de agent en of de run een opschaling was. Niets daarvan kreeg de klant te zien. Een routeringsbeslissing die je niet kunt zien, kun je niet vertrouwen met een budget, en precies dat hadden we gebouwd.
Elke gerouteerde run toont nu op de runpagina zijn model, de agent die hem uitvoerde en de reden in gewone tekst: het taaktype en de omvang, een tweede repository, een stacktrace, of het gemeten succespercentage dat hem omhoog of omlaag zette. Wisselde hij naar een goedkopere agent, dan staat in de reden hoeveel goedkoper dat was volgens de geldende tarieven.
Nieuwe pogingen hadden hetzelfde probleem. Met routering aan wordt een mislukte run die je opnieuw probeert opgeschaald, want dezelfde poging op hetzelfde model herhaalt meestal dezelfde fout. Maar de knop daarvoor verscheen alleen bij runs in de wachtrij, dus het ene geval dat opschaling meebracht, was vanaf de runpagina onbereikbaar. Hij staat nu ook bij mislukte runs, als Run opnieuw proberen, en de run laat zien vanaf welk model hij is opgeschaald. Een mislukte run op een goedkopere agent gaat niet terug naar die agent; de nieuwe poging gaat naar Claude, op een sterker niveau.
Wat dit niet doet
- Het stuurt werk dat oordeelsvermogen vraagt niet naar een goedkopere leverancier, met opzet.
- Het kiest Codex niet voor je.
- Het kent de prijzen van de leveranciers niet; het kent onze tarieftabel. De router heeft nodig dat de volgorde van die bedragen klopt, wat een lagere lat is dan exact, maar een verouderd tarief trekt hem nog steeds scheef.
- Met routering over providers aan gaat de code van die runs naar die provider. Laat hem uit als je contracten één leverancier voorschrijven.
Vergelijk je agents, dan is de praktische test dezelfde die we op de router toepassen: kun je bij elke run zien welk model hem schreef en waarom? De agents zelf beschrijven we bij coding agents, en de kostenkant bij kostenbeheersing.