När jag jämförde Claude och Codex på samma Drupal-uppgradering förra veckan dök det upp ett resultat jag inte förväntat mig: modellen som gjorde mest jobb använde klart färre tokens. Claude körde deprecation-scannar, installerade analysverktyg, sökte upp releasestatus för varje blockerad modul och tittade i databasen. Codex höll sig till read-only och prissatte det som var osäkert. Ändå använde Claude klart färre tokens.
Det fick mig att fundera. Tokens brukar kännas som ett mått på hur mycket en modell har gjort. Men i praktiken mäter de ofta något annat.
Själva experimentet finns i artikeln där jag jämförde Claude och Codex på samma Drupal-estimat.
Tokens mäter inte arbete, de mäter osäkerhet
En agent som vet vad den får göra och har ett tydligt nästa steg gör ofta bara det steget. En agent som inte vet var gränserna går behöver resonera mer. Den väger alternativ, skriver ut antaganden och prissätter risker som den kanske hade kunnat kontrollera om instruktionen varit tydligare. Allt det kostar tokens utan att producera ett bättre svar.
Skillnaden i det här experimentet var inte att Codex lade mer tid på uppgiften. Den lade mer tid på att hantera det som instruktionerna inte sa. Varje antagande den behövde göra för att rörelseutrymmet var oklart genererade text, och den texten kostar.
Det syntes tydligast i tre mönster.
Tre instruktionsmönster som driver upp kostnaden
Inget mandat. Om instruktionen inte säger vad agenten får och inte får göra, behöver modellen fylla i det själv, och den väljer ofta det försiktiga alternativet. "Feel free to check themes and db if needed" lästes av en modell som tillstånd och av en annan som läs-bara-mandat. Samma ord, två tolkningar, stor skillnad i output. Det som saknades var ett mandat: du får installera analysverktyg lokalt om du städar upp efteråt. Du får läsa databasen. Du får inte röra staging eller produktion.
Ingen verifieringstrappa. Om instruktionen inte säger hur agenten ska hantera osäkerhet, väljer den ofta att prissätta den. Det är ett rimligt val när alternativet är oklart. En verifieringstrappa gör alternativet konkret: för varje blockerat beroende, kolla om en kompatibel release finns, kolla om beroendet ens används, kör en scan om du äger koden. Osäkerhet som kan omvandlas till fakta kostar färre tokens än osäkerhet som ska beskrivas och prissättas.
Ingen frågetröskel. "Ask questions if needed" är en instruktion som låter öppen men i praktiken producerar frågesektioner längst ner i ett färdigt dokument, inte frågor ställda mitt i arbetet. Modellen avslutar uppgiften och listar sedan det den borde ha frågat om från början. En frågetröskel definierar när agenten ska stanna: om ett obesvarat antagande kan påverka totalen tydligt, stanna och fråga innan du fortsätter.
Vad tätare instruktioner ser ut
Det är lättare att förstå i konkreta termer. Här är ungefär vad jag lade till i version 2 av min estimate-skill efter det här experimentet:
Ett mandatstycke som säger explicit vad agenten får installera lokalt, att den ska avinstallera det efteråt och dokumentera vad som kördes, och att staging och produktion aldrig ska röras. Inte för att modellen inte vet det, utan för att det tar bort tolkningsutrymmet.
En verifieringstrappa för uppgraderingsläget: kolla kompatibel release för varje blockerad modul, kolla faktisk användning i databasen, kör deprecation-scan på den kod vi äger. Varje steg är antingen genomfört med belägg eller noterat som ej genomfört och varför.
En frågetröskel: om ett öppet antagande kan flytta totalen med mer än en femtedel, stanna och fråga. Inte skriv en frågesektion. Stanna.
Och ett antaganderegister i outputen: varje antagande är antingen verifierat med belägg eller prissatt som risk. Det ska synas i estimatet, inte gömmas i spannet.
Det är en avvägning, inte en regel
Tätare instruktioner minskar tokenanvändningen av rätt anledningar: agenten vet vad den får göra och behöver inte resonera sig fram till det. Men det finns en gräns. Det som gjorde Claude-estimatet bra var initiativ som modellen tog utan att instruktionen bad om det. En hårt styrd skill kan trycka undan just den sortens omdöme.
Det rätta är inte alltid maximalt tydliga instruktioner. Det är instruktioner som tar bort onödigt tolkningsutrymme utan att stänga av det nyttiga. Mandat och verifieringstrappor tar bort tveksamhet om vad agenten får göra. De behöver inte begränsa hur den tänker när den väl gör det.
Tokenräkningen är i det här sammanhanget ett symptom snarare än ett mål. Om en körning kostar mer tokens än du förväntar dig och outputen inte är bättre, är det troligen inte modellen som är problemet. Det är vad instruktionen lämnade öppet.
