Fable 5: kwaliteit heeft een prijs

De afgelopen maanden voltrekt zich een subtiele maar belangrijke verschuiving in de wereld van AI-tools: pure prestaties zijn niet langer genoeg. Nu moeten we ook kijken naar wat het kost.

Claude Fable 5 illustreert die spanning perfect. Het model wordt aangeprezen als een van de meest geavanceerde voor langlopende taken, complex redeneren, code en agents. Het kan ambitieuze workflows aan, instructies volgen over lange sessies en werken met heel veel context.

Maar die kracht heeft een prijs: Fable 5 kan veel meer tokens verbruiken dan lichtere modellen op de markt. En in een wereld waar AI steeds vaker per gebruik wordt gefactureerd, wordt dat detail een strategische kwestie.

De beste modellen denken langer na

Om de kosten van Fable 5 te begrijpen, moeten we terug naar een eenvoudig idee: niet alle tokens komen alleen van wat de gebruiker schrijft of wat het model antwoordt.

Wanneer een geavanceerd model een complexe taak aanpakt, verbruikt het ook tokens om te analyseren, te plannen, tools te gebruiken, context te lezen, tussenstappen uit te voeren en zijn eigen fouten te corrigeren.

Dat geldt in het bijzonder voor modellen die op agents gericht zijn. Een klassieke chatbot beantwoordt een vraag. Een agent daarentegen verkent een repository, leest meerdere bestanden, probeert een correctie, draait tests, interpreteert fouten, herziet zijn plan en begint dan opnieuw. Elke stap verbruikt tokens.

Fable 5 is specifiek ontworpen voor dit soort tijdrovende taken. Het kan uitblinken in moeilijke problemen, maar het kan ook veel langer blijven "nadenken" dan een eenvoudiger model. Daardoor kan een taak die voor de gebruiker kort lijkt, op de achtergrond duur uitvallen.

Hier wordt het interessant. Een slimmer model kan soms goedkoper zijn als het snel het juiste antwoord vindt. Maar het kan ook veel meer kosten als het te veel verkent, te veel context leest of een eenvoudige taak overanalyseert.

Fable 5 en de "effort"-parameter

Met Fable 5 introduceert Anthropic een belangrijk concept: effortsturing. Met de "effort"-parameter stel je de diepgang van het redeneren van het model bij. Hoe hoger de effortinstelling, hoe meer tijd het model kan besteden aan analyseren en werken. Dat is nuttig voor een complexe migratie, een technisch onderzoek of een lange agentische taak; het is onnodig duur voor een kleine correctie, een herformulering of een eenvoudige zoekopdracht.

Met andere woorden: Fable 5 is niet zomaar een model. Het is een motor met meerdere versnellingen.

Het addertje, zoals zo vaak, is dat gebruikers de beste kwaliteit willen zonder te betalen voor de complexiteit die die mogelijk maakt. Een heerlijk menselijke houding: een Formule 1-wagen eisen om brood te gaan halen, en dan verrast zijn door de benzinerekening.

In een ontwikkelteam roept dat een nieuwe vraag op: hebben we echt het krachtigste model nodig voor elke taak? Het antwoord is nee. Om een tekst na te lezen, een verzoek te categoriseren, een eenvoudige foutmelding uit te leggen of basisdocumentatie te genereren, volstaat vaak een lichter model. Om een architectuur te analyseren, een lastige bug te fixen of een agent door een complexe repository te loodsen, is Fable 5 de juiste keuze.

De beste aanpak is niet "het beste model voor alles gebruiken." Het is het intelligentieniveau kiezen dat bij de taak past.

Waarom verbruikt het zoveel?

Daar zijn drie hoofdredenen voor.

De eerste is context. Geavanceerde modellen worden vaak ingezet voor complexe taken: veel bestanden, geschiedenis, afhankelijkheden en instructies. Al die context moet gelezen, omgezet in tokens en verwerkt worden.

De tweede is redeneren. Hoe dieper een model analyseert, hoe meer middelen het verbruikt. Ook al is het niet zichtbaar in het uiteindelijke antwoord, dat redeneren weegt op de totale kosten.

De derde is de werking als agent. Een agent antwoordt niet in één keer: hij werkt in een lus: lezen, begrijpen, handelen, controleren, corrigeren. Die lus is krachtig, maar vermenigvuldigt het aantal aanroepen, tools, leesacties en tussenresultaten.

Daarom kan Fable 5 duur worden in codeworkflows. Het levert niet zomaar een functie op: het inspecteert een project, bewerkt bestanden, volgt een spoor, laat het los, begint opnieuw en levert een robuustere oplossing. Dat gedrag is nuttig. Het is ook duur.

Onnodig tokenverbruik vermijden

Bij krachtige modellen zit het risico niet alleen in de prijs per token. Het zit in "token burn": het onnodig verbruiken van tokens.

Een agent kan veel tokens verbruiken door een gebrek aan richting. Hij leest te veel bestanden, vraagt te veel context op, maakt verkeerde aannames, schrijft code voordat hij het probleem echt begrijpt, corrigeert zonder plan en begint dan telkens opnieuw.

Dat is niet per se de schuld van het model. Vaak ligt het aan de workflow. Een vaag verzoek als "verbeter deze functie" dwingt de agent om te gokken. Een duidelijk verzoek als "fix deze bug in deze module, zonder de publieke API te wijzigen, en voeg een non-regressietest toe" verkleint de zoekruimte enorm. Hoe minder de agent hoeft te gokken, hoe minder hij verspilt.

Brainstormen

Op het eerste gezicht lijkt een brainstormstap toevoegen contra-intuïtief. Waarom de agent meer laten nadenken als het doel is om tokens te besparen? Omdat goed brainstormen geen doelloos ronddwalen is. Het is een korte afbakeningsfase.

In een codeworkflow dient het om snel meerdere benaderingen te verkennen voordat er code wordt geschreven. De agent kan mogelijke opties, risico's, bestanden die waarschijnlijk geraakt worden, te controleren aannames en succescriteria in kaart brengen.

Die stap helpt een veelvoorkomende valkuil te vermijden: zich op een oplossing storten, te vroeg code aanpassen, dan ontdekken dat de aanpak verkeerd was en helemaal opnieuw moeten beginnen. Net als bij menselijke ontwikkeling, behalve dat mensen het "ervaring" noemen nadat ze drie omgevingen hebben gesloopt.

Een plugin als Superpowers, die een brainstormfase integreert in een meer gestructureerde workflow, is specifiek ontworpen om die onnodige lussen te vermijden. Hij moedigt de ontwikkelaar aan om te verduidelijken, te ontwerpen, te plannen, te coderen en dan te controleren. Het idee is niet om de AI meer te laten praten, maar om hem in de juiste volgorde te laten handelen.

Het belang van een gestructureerde workflow

Een agent verbruikt veel middelen wanneer hij op zijn stappen moet terugkeren. De kosten komen zelden van één enkel antwoord: ze komen van onnodige iteraties. Een gestructureerde workflow beperkt dat op meerdere manieren:

• Hij dwingt tot verduidelijking. De agent controleert de vereiste voordat hij code genereert, wat correcties naast de kwestie voorkomt.
• Hij beperkt het verkennen. Door eerst de relevante bestanden te bepalen in plaats van de hele repository te lezen, verlaagt hij het aantal inputtokens.
• Hij maakt een plan. Een nauwkeurig plan maakt een directere uitvoering mogelijk, met minder mislukte pogingen.
• Hij controleert het resultaat. Tests en acceptatiecriteria geven aan of de taak af is, in plaats van eindeloos aan de code te blijven sleutelen.

Brainstormen is dus geen goocheltruc. Het comprimeert geen tokens: het vermindert vooral de rommel. En bij code-agents is rommel duur.

Wat onthouden we?

Fable 5 werpt een vraag op die verder gaat dan alleen de prijs: hoe gebruiken we krachtige modellen zonder ze alles te laten opslokken?

• Gebruik het meest geavanceerde model niet voor eenvoudige taken. Lichtere modellen volstaan vaak voor samenvattingen, herformuleringen, classificaties, kleine correcties of eenvoudige scripts.
• Baken taken af. Hoe preciezer een verzoek, hoe minder de agent hoeft te verkennen.
• Beperk de context. De hele repository aan een model voeren "voor het geval dat" is zelden een goede strategie. Geef de juiste bestanden, de juiste logs en de juiste beperkingen.
• Meet. Volg de kosten per geslaagde taak, niet alleen per verzoek. Een duur antwoord kan rendabel zijn als het twee dagen werk bespaart; een goedkoop antwoord kan nutteloos zijn als het een verkeerde fix oplevert.
• Gebruik workflows. Brainstormen, plannen, test-driven development, menselijke validatie en geautomatiseerde verificatie zijn geen details. Het zijn economische vangrails.

En in de nabije toekomst?

Modellen als Fable 5 tonen aan dat AI een volwassener fase ingaat. De vraag is niet langer alleen "welk model is het krachtigst?", maar "welk model, met hoeveel effort, voor welke taak en tegen welke kosten?"

De bedrijven die het meest uit AI halen, zijn niet per se die met toegang tot het duurste model, maar die meerdere intelligentieniveaus weten te orkestreren: een licht model voor eenvoudige taken, een middenklassemodel voor routinewerk en een zeer krachtig model voor echt complexe problemen.

Fable 5 is dus niet alleen een technische vooruitgang. Het is ook een economische herinnering: wanneer AI lange tijd kan werken, kan het ook lange tijd geld uitgeven.

Echte expertise zal er niet alleen in bestaan AI meer te laten doen. Het zal erom gaan haar te leren niet zomaar iets te doen voordat ze begint.