Midden in een sessie van model wisselen kost niets
· 3 min lezen
En dat is een ontwerpbeslissing, geen feature. De meeste agent-tooling wordt voor één aanbieder geschreven en daarna aan andere aangepast. Die volgorde klinkt als een implementatiedetail. Het is de hele kwestie.
Achteraf aanpassen betekent dat de aannames van de eerste aanbieder al dragend zijn tegen de tijd dat de tweede erbij komt. Ze zitten in de opslag van gesprekken, in hoe een tool-aanroep wordt weergegeven, in hoe een gestreamd antwoord wordt geparsed — en op geen van die plekken denkt iemand een jaar later nog te kijken. Wat je merkt is alleen het symptoom: van aanbieder wisselen betekent een migratie, en een migratie midden in een sessie betekent dat je niet van aanbieder wisselt.
Waar de aanname zich verstopt
De voor de hand liggende plek om te kijken is de HTTP-aanroep, en die plek is fout. De endpoints van twee willekeurige aanbieders liggen een weekend werk uit elkaar. Het dure deel is wat je met het antwoord hebt gedaan.
Neem één detail. De meeste aanbieders koppelen een tool-resultaat aan het id van de aanroep die het opleverde. Gemini koppelt het aan de naam van de functie. Als je gespreksopslag tool-resultaten bewaart zoals aanbieder A ze beschreef, dan is ondersteuning voor Gemini geen nieuwe HTTP-client — het is een wijziging in de vorm waarin elke transcriptie die je ooit hebt geschreven al staat.
Dat is het hele probleem in het klein. Er bestaat geen adapter die het oplost, want de informatie is bij het schrijven weggegooid.
Neutrale geschiedenis
Het alternatief is om, voordat de eerste aanbieder wordt geschreven, te besluiten dat de geschiedenis van geen van hen is.
OHarness slaat sessietranscripties op in een vorm die de engine definieert (packages/engine/src/core/types.ts), niet in het formaat van een aanbieder. Een tool-resultaat bevat toolName en ook toolCallId — niet omdat de engine beide nodig heeft, maar omdat Gemini de naam nodig heeft en alle anderen het id, en de neutrale vorm naar allebei moet kunnen worden omgezet.
Het wire-formaat van een aanbieder wordt aangemaakt op het moment dat een verzoek de deur uitgaat en weggegooid wanneer het antwoord weer is verwerkt. Niets wordt erin bewaard.
Midden in een sessie van aanbieder wisselen zet dus niets om. Niet omdat de omzetting snel is, maar omdat er geen oude vorm is om van om te zetten.
Wat dit concreet oplevert
Een model is iets met een prijs, capaciteit, een rate limit en een slechte week. Als dat de beslissingen van iemand anders zijn en je hebt één model, worden het jouw beslissingen. Het punt van een vervangbare backend is niet nieuwigheid — het is dat de dag waarop een aanbieder zijn voorwaarden wijzigt een dag is waarover je een mening kunt hebben.
Het laat ook het saaie geval werken. Maak een opzet met iets goedkoops, wissel naar iets duurs voor het moeilijke deel, en schakel terug naar een model op je eigen computer als het netwerk slecht is of de code het gebouw niet mag verlaten. Dat is allemaal dezelfde sessie.
Het deel dat niet gratis is
Eerlijk over de afweging: het neutrale formaat is een verplichting. Elke mogelijkheid die per aanbieder verschilt — redeneerinspanning, prompt caching, parallelle tool-aanroepen, beeldondersteuning — moet als vlag op het model worden vastgelegd in plaats van uit de aanbieder te worden afgeleid, omdat de verkeerde vorm sturen een 400 oplevert en geen minder goed antwoord. Dat is een echte kostenpost, eenmaal betaald, op een plek waar hij zichtbaar is.
Het alternatief is hem herhaaldelijk te betalen, in het donker, zolang het project bestaat.
OHarness is een open source agent-harness met een MIT-licentie. Het praat rechtstreeks met Anthropic, OpenAI en Google Gemini, met elk OpenAI-compatibel endpoint en met lokale runtimes zoals Ollama, LM Studio en vLLM. De architectuurreferentie beschrijft hoe de gelaagdheid wordt afgedwongen in plaats van alleen bedoeld, en wat een agent-harness is behandelt het idee eromheen.