AI-coderingskosten op schaal beheren

AI-coderingsinstrumenten leveren enorme waarde op: bij Databricks heeft agentisch coderen elke meetbare velocity-metriek verbeterd en heeft het in sommige teams geleid tot een factor tien meer output. Maar bijna elk bedrijf dat AI-tools op schaal implementeert, is tegen dezelfde muur aangelopen: exponentieel stijgende kosten. Die curve is onhoudbaar; als deze niet wordt beheerst, zal hij uiteindelijk de omzet overstijgen.

Deze explosie van uitgaven heeft ondernemingen in een paradoxale situatie gebracht: enerzijds is er het verlangen om de AI-transformatie maximaal door te zetten en krachtige tools in handen van werknemers te leggen, anderzijds moet men rekening houden met een aggregate kostenprofiel dat de efficiëntiewinst die AI biedt, dreigt ondermijnen of zelfs tenietdoen.

Gelukkig zijn enkele van de vroegste grootschalige gebruikers tot een reeks benaderingen gekomen die dit raadsel oplossen. Hiermee wordt aan een "dubbel mandaat" voldaan: (a) het bieden van brede toegang tot AI-tooling met minimale wrijving, en (b) het houden van de totale kosten binnen een ongeveer vast budget per gebruiker. Dit artikel beschrijft bewezen technieken voor kostenbeheer, gebaseerd op onze ervaring bij Databricks en gesprekken met andere digital-native bedrijven, waaronder Stripe, Coinbase, Uber en Ramp.

De "Efficiëntiegrens" voor coderingsmodellen

De krachtigste kostenhefboom is het overstappen naar efficiëntere modellen zodra deze worden uitgebracht. Dit punt verdient nadere toelichting, omdat de simpele uitleg van "goedkopere modellen" in feite een genuanceerde relatie tussen modelkosten en kwaliteit maskeert.

In algemene termen betekent frontier model het model met de hoogste intelligentie; frontier-labs richten zich grotendeels op het verleggen van de absolute grenzen van intelligentie. Deze modellen kunnen nu complexe problemen in wiskunde of cybersecurity oplossen. Maar wanneer AI op schaal wordt ingezet, is een ander type grens belangrijker: de efficiëntiegrens (efficiency frontier).

De efficiëntiegrens wordt gedefinieerd door de set modellen die het beste prijspunt hebben voor een bepaald niveau van intelligentie. De meeste dagelijkse coderingswerkzaamheden vereisen geen wiskundige bewijzen of baanbrekende beveiligingsinzichten. Wat in totaal telt, is de kostprijs van modellen die voldoen aan de kwaliteitslat voor typisch software-engineeringwerk. Deze "efficiëntiegrens" verschuift veel sneller dan de intelligentiegrens; er worden bijna wekelijks nieuwe modellen uitgebracht die een betere intelligentie-per-prijsunit bieden dan vorige modellen.

Kostenhefboom #1: Overstappen naar open source en goedkopere modellen

Het snel adopteren van nieuwere, efficiëntere modellen levert de grootste kostenbesparingen op van alle technieken. Om deze winst te behalen, moet een bedrijf echter eerst weten welke modellen hun huidige modellen daadwerkelijk verslaan. Dit kan moeilijk zijn omdat publieke benchmarks vaak onvoldoende inzicht geven in de prestaties bij echte coderingstaken.

Veel bedrijven hebben daarom geautomatiseerde evaluaties gebouwd die representatiever zijn voor hun interne ontwikkelmix. Databricks heeft onlangs een voorbeeld van zo'n benchmark gepubliceerd, waarbij we zeer concurrerende prijs-prestatieverhoudingen zagen voor GLM-modellen. Deze benchmark leidde ertoe dat we GLM intern uitrolden naar ontwikkelaars.

Vaak verschuiven nieuwe modellen de efficiëntiegrens echter niet, en leveren evaluaties regelmatig negatieve resultaten op:

• Stripe ontdekte dat Opus 4.7 de kwaliteit niet significant verbeterde ten opzichte van Opus 4.6, terwijl de kosten wel stegen. Ze hebben daarom besloten Opus 4.7 intern niet beschikbaar te stellen.
• Databricks zag vergelijkbare kostenregressies bij het vergelijken van Opus 5.0 met versie 4.8.

Harness- en modelflexibiliteit

Omdat de grootste winst voortkomt uit het overschakelen naar nieuwe modellen, is het gebruik van tooling die modelflexibiliteit toestaat een cruciaal onderdeel van kostenbeheersing. De tool die gewoonlijk in combinatie met een specifiek model wordt gebruikt, wordt een harness genoemd. Propriëtaire frontier-modellen worden steeds vaker zo ontworpen dat ze goed werken met specifieke harnesses; bepaalde harnesses "werken beter" met bepaalde modellen.

Als een bedrijf modelonafhankelijkheid wil behouden, zijn er grofweg twee benaderingen:

1. Gebruikers vragen van harness te wisselen: Ontwikkelaars krijgen een set harnesses (zoals Claude Code, Codex of Cursor) en wordt gevraagd over te stappen wanneer het bedrijf de uitgaven naar goedkopere modellen wil verplaatsen. Het nadeel is dat de overstapkosten voor een individuele ontwikkelaar hoog kunnen zijn. Als deze kosten te hoog worden, werkt de harness als een de facto lock-in voor een modelfamilie.
2. Gebruik van een meta-harness: Een nieuwere en populairdere aanpak is het gebruik van een meta-harness. Deze biedt een uniforme gebruikerservaring aan ontwikkelaars, terwijl verzoeken worden doorgestuurd naar onderliggende harnesses (zowel propriëtair als open source). Dit waarborgt model- en harness-onafhankelijkheid en vermindert de overstapkosten voor de ontwikkelaar. Bij Databricks is dit de standaardmodus voor ontwikkelaars die Omnigent gebruiken.

Kostenhefboom #2: Dynamische routering van verzoeken en taken

In plaats van gebruikers zelf een model te laten kiezen dat geschikt is voor de taak, suggereert onderzoek dat automatische selectie van modellen en tools de efficiëntie in agentische coderingsworkflows verder kan verhogen. Routeringsbenaderingen vallen uiteen in drie categorieën:

• Routering op verzoekniveau (Request Level Routing): Een stateful proxy bevindt zich tussen een client (zoals een coding harness) en de onderliggende foundation-modellen. De proxy probeert verzoeken te routeren naar het goedkoopste model dat in staat is om dat specifieke verzoek te beantwoorden. Voor agentische use-cases moet deze routering ook rekening houden met server-side caching, omdat een 'cold cache hit' zeer kostbaar is bij workloads met een grote context. Voorbeelden hiervan zijn Cursor Router, OpenRouter’s AutoRouter, de Router-functie van Ramp en de Smart Routing-functie in de Unity AI Gateway van Databricks.
• Routering op taakniveau (Task Level Routing / Meta Harness): Een client-side proces verdeelt taken over verschillende harnesses op basis van de complexiteit. Een eenvoudige taak ("hernoem dit component van X naar Y") wordt anders behandeld dan een complexe, open vraag ("onderzoek designoverwegingen om latency te verminderen"). De dispatcher (meta-harness) bepaalt welk niveau model nodig is en delegeert de gehele end-to-end taak. Omnigent is een voorbeeld van een meta-harness die dit patroon ondersteunt.
• Escalatie- en delegatiepatronen: Eén harness koppelt twee modellen: een duur model met hoge intelligentie en een goedkoop 'worker'-model.
• In sommige benaderingen, zoals de Advisor Tool van Claude, beheert het goedkopere model het proces en escaleert het naar het dure model wanneer dat nodig is.
• Het omgekeerde patroon bestaat ook: in Devin Fusion van Cognition is het duurdere model de hoofdloop, die selectief werk uitbesteedt aan een goedkoper model.

Interne resultaten bij Databricks tonen aan dat de AI Gateway Smart Router de gemiddelde taakkosten consistent met meer dan 30% kan verlagen, terwijl de kwaliteit nagenoeg gelijk blijft aan die van het duurste model in de set.

Kostenhefboom #3: Zichtbaarheid, 'tripwires' en budgetten bieden aan ontwikkelaars

Harde budgetten (waarbij toegang volledig wordt afgesloten bij een bepaalde drempel) worden door bijna elk bedrijf alleen als laatste redmiddel gebruikt. Dit heeft twee redenen:

1. Als een ontwikkelaar het plafond bereikt, is het blokkeren van AI-tools belemmerend voor de productiviteit.
2. Sommige "high spending" gebruikers zijn juist degenen die enorme efficiëntiewinsten behalen en een enorme output produceren. Deze gebruikers ontmoedigen is contraproductief.

In plaats van een harde limiet hanteren de meeste bedrijven een genuanceerde aanpak gericht op zichtbaarheid en toenemende wrijving naarmate de uitgaven stijgen:

• Zichtbaarheid: Bijna alle bezochte bedrijven hebben een mechanisme om gebruikers direct feedback te geven over hun lopende uitgaven, vaak inclusief tips over hoe ze kosten kunnen verlagen door goedkopere modellen te gebruiken. Het is essentieel dat gebruikers hun uitgaven over alle tools heen kunnen zien.
• Spend Gates: Ontwikkelaars moeten actie ondernemen of goedkeuring vragen bij bepaalde uitgavenniveaus. De eenvoudigste vorm is een waarschuwing die zelf kan worden weggeklikt, bedoeld om onbedoelde kosten te voorkomen. Verder kunnen gates worden ingevoerd die expliciete budgetgoedkeuring vereisen via het management.
• Downshifting: Wanneer een ontwikkelaar een spend gate bereikt, kan deze worden teruggezet naar een goedkoper model in plaats van volledig te worden geblokkeerd. Omdat de goedkoopste modellen drastisch minder duur zijn, kan het werk doorgaan zonder enorme extra kosten.
• Opschorting (Suspension): In extreme gevallen behouden systemen de mogelijkheid om gebruikers volledig uit te sluiten van token-toegang. Dit is meestal een tijdelijke maatregel en het startpunt voor een gesprek over efficiënt AI-gebruik.

Kostenhefboom #4: Verminderen van token overhead

Wanneer een gebruiker een eenvoudige vraag stelt (zoals "onderzoek en fix deze bug"), verzamelt de agent enorme hoeveelheden relevante context, roept talloze tools aan, doorzoekt de codebase en integreert systeeminformatie. Tegen de tijd dat de LLM-inferentie plaatsvindt, is de initiële input van de gebruiker slechts een fractie van de data; de kosten worden gedomineerd door context die de gebruiker niet expliciet heeft toegevoegd.

Technieken om deze context bloat te verminderen zijn nieuw, maar veelbelovend:

• Het afdwingen van frequentere compactie (compressie) van de actieve context.
• Gebruikmaken van harnesses die "minder praatgraag" (token-efficiënter) zijn, of bestaande harnesses tunen om minder overhead te genereren.
• Populaire tools auditeren en hun redundantie verminderen.
• Ontwikkelaars aanmoedigen taken op te splitsen in kleinere eenheden, waardoor de contextscope afneemt.

Bij grote contexten speelt prompt caching een belangrijke rol. Zowel propriëtaire als open source LLM's hebben instellingen voor prompt caching. Hoewel het schrijven naar de cache geld kost, kunnen cached reads de kosten per inferentie drastisch verlagen. Het handmatig tunen van deze cache-instellingen om de hitrate te verhogen kan grote verbeteringen opleveren.

Bij Databricks leidde eenvoudige tuning van de harness en caching-instellingen tot een vermindering van bijna 50% in het aantal gegenereerde tokens en de bijbehorende kosten, zonder kwaliteitsverlies voor de ontwikkelaars.

Het AI Gateway design pattern

De bovenstaande technieken stellen specifieke technische eisen:

• Om snel gebruik te maken van nieuwe modellen is een centrale plek nodig waar het "modelmenu" wordt beheerd.
• Voor budgetzichtbaarheid over meerdere tools is een uniforme observability-capaciteit nodig.
• Voor het beheren van context bloat moet men toolcall-outputs kunnen observeren en compressie kunnen afdwingen.

Deze behoeften worden collectief opgelost door een nieuwe klasse infrastructurele software: de AI Gateway. Een AI gateway fungeert als centraal punt voor:

1. Capaciteitsbeheer en proxying van toegang tot onderliggende modellen (propriëtair en OSS).
2. Budgettracking en -handhaving, inclusief complexe policies zoals progressieve wrijving en model-downshifting.
3. Configuratiebeheer voor end-user tools (bijv. model allow-lists en compactie-instellingen).
4. Logging van coderingssessies voor efficiëntieanalyse en benchmarking.

Databricks vertrouwt hiervoor zwaar op de Unity AI Gateway.

Conclusie

De exponentiële groei van AI-coderingskosten is geen onvermijdelijkheid, maar een oplosbaar engineering- en governanceprobleem. Bedrijven die dit onder controle hebben, volgen een gemeenschappelijk playbook:

• Jaag meedogenloos de efficiëntiegrens na in plaats van de intelligentiegrens.
• Adopteer tooling die modelflexibiliteit behoudt.
• Routeer werk intelligent naar het goedkoopste geschikte model.
• Vervang harde budgetten door zichtbaarheid en progressieve wrijving.
• Reduceer de token overhead die de werkelijke uitgaven domineert.

Geen van deze technieken vereist dat men de productiviteitswinsten opoffert. Samen stellen ze organisaties in staat om te voldoen aan het dubbele mandaat: brede, wrijvingsloze toegang binnen een voorspelbaar kostenkader.

Databricks heeft de belangrijkste componenten van deze cost management stack beschikbaar gesteld als open source of gratis software: de Unity AI Gateway voor centraal beheer en Omnigent voor developer tooling.