Adaptief denken en kostenvoorspelling
Bijgewerkt September 1, 2026 · eerst gepubliceerd September 1, 2026
Het redeneerbudget was vroeger een getal dat je zelf instelde. Je stuurde thinking: {type: "enabled", budget_tokens: N}, en N was tegelijk een rem en een voorspelling: in het slechtste geval kostte elk verzoek N redeneertokens, en finance kon vermenigvuldigen.
Die parameter is verouderd op Opus 4.6 en Sonnet 4.6, en op de nieuwste modellen — Fable 5 en 5.1, Sonnet 5, Opus 5, 4.8 en 4.7 — geeft meesturen een 400. De vervanging is thinking: {type: "adaptive"}, waarbij het model zelf bepaalt hoeveel het nadenkt op basis van de moeilijkheid van het verzoek.
Gemiddeld is dat meer output per euro. Maar het haalt ook een plafond weg, en als je voorspelling op dat plafond was gebouwd, klopt hij nu niet meer. Dat merk je pas als de maand dicht is.
Wat er in de cijfers verandert
De gemiddelde kost per verzoek daalt meestal, omdat makkelijke verzoeken niet langer betalen voor redeneren dat ze niet nodig hadden. De variantie stijgt, omdat zware verzoeken niet langer worden afgekapt op je plafond. Die twee bewegen tegenovergesteld, en een budget dat als maximum per verzoek is uitgedrukt heeft dan niets meer om zich aan vast te houden.
Het praktische probleem zit niet in het gemiddelde maar in de staart: een promptwijziging, een nieuw documenttype of gebruikers die moeilijkere vragen stellen, schuiven een deel van je verkeer naar dieper redeneren, en niets in je configuratie houdt dat tegen.
Voorspel de verdeling, niet het plafond
Drie wijzigingen, in volgorde van wat ze opleveren.
Volg redeneertokens als aparte reeks. Ze staan al in het usage-object van elke respons. Scheid ze van input- en outputtokens in je telemetrie, dan zie je de verschuiving op de dag dat hij gebeurt, niet pas aan het einde van de maand.
Budgetteer op percentielen. Vervang "N tokens per verzoek" door een p50 en een p99 per route. De p50 vertelt wat de workload kost; het verschil tussen p50 en p99 vertelt hoe blootgesteld je bent aan een slechte week.
Alarmeer op de verhouding, niet op het totaal. Redeneertokens als aandeel van het totaal per route is het ene getal dat het eerst beweegt wanneer een promptwijziging het model harder laat werken. Een alarm op het totale uitgavenbedrag gaat dagen later af, als het volume zich al heeft opgestapeld.
Waar een plafond nog wel hoort
Het per-verzoek-instelpunt weghalen betekent niet dat alle limieten verdwijnen. Uitgavenlimieten per route en per tenant werken nog steeds, vangen nog steeds runaway-loops op, en daar hoort de rem nu te zitten — op de grens die van jou is, niet in een requestparameter die niet meer bestaat. Voor latency-gevoelige paden waar diep redeneren nooit de moeite waard is, is de hefboom de modelkeuze, niet een tokenbudget.
Gerelateerd
Gerelateerd
Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit →