Mina kodagenter använde Claude Fable 5 och OpenAI:s GPT-5.4, GPT-5.5 och GPT-5.6-familjen på verkligt arbete under hela 2026: webbplatser, iOS-appar, e-handel, CRM, musikverktyg, SEO-system och mina egna agentarbetsflöden. När jag summerade de lokala sessionsloggarna som fortfarande fanns kvar på min Mac, landade siffran på 21,54 miljarder token.
Den siffran är absurd. Den behöver också kontext.
Det mesta av detta är inte 21,5 miljarder nya ord som skrivits för mig. Långa agentsessioner skickar stora kodbaser och instruktioner genom kontexten flera gånger. En stor del läses från cache. Tokenantalet visar främst hur mycket kontext mina kodagenter bearbetade.
Min slutsats efter denna period är fortfarande tydlig: vi har höjt nivån. Modellerna kan hålla ihop längre uppgifter, använda verktyg och reparera misstag på en nivå som kändes långt borta för ett år sedan. Men modellen i sig är fortfarande den minst intressanta delen av ett pålitligt system.
Vad 21,5 miljarder token säger om kodagenter
Jag räknade OpenAI-användningen från varje `last_token_usage`-värde i bevarade Codex-loggar. Jag räknade Fable från unika assistentmeddelanden i Claude-loggar, med normal inmatning, cache-skapande, cache-läsning och utdata. Resultatet är ett mått på lokal aktivitet — inte en faktura från OpenAI eller Anthropic.
| Modell | Loggade aktivitetstoken | Unika användningshändelser / modelsvar |
|---|---|---|
| --- | ---: | ---: |
| GPT-5.5 | 12,96 miljarder | 95 930 |
| GPT-5.6 Sol, Terra och Luna | 1,88 miljarder | 12 370 |
| GPT-5.4 inklusive Mini | 3,43 miljarder | 26 624 |
| Claude Fable 5 | 3,27 miljarder | 16 878 |
| Totalt | 21,54 miljarder | 151 802 |
Med hjälp av högvattenmetoden stod GPT-5.4 för cirka 3,21 miljarder cachade inmatningstoken, GPT-5.5 för 12,30 miljarder och GPT-5.6-familjen för cirka 1,82 miljarder. Fable-loggarna innehöll cirka 3,05 miljarder cache-läsningar och 181 miljoner token för cache-skapande.
Det är därför det är vilseledande att jämföra totalen med den mängd text en människa skulle kunna läsa. Agentarbete återanvänder stora kontexter. Den relevanta frågan är om systemet gjorde rätt sak med dem.
Kodbasen bakom användningen: 59 GitHub-projekt
Vid mättillfället hade mitt GitHub-konto 59 repository: 50 privata och 9 offentliga. De fördelar sig ungefär så här:
På de 26 GitHub-repo som hade en lokal utcheckning med exakt samma namn hittade jag 6,90 miljoner spårade källkods-rader efter att ha filtrerat bort leverantörsfiler, byggfiler, cache och minifierade filer. Det talet domineras av tre stora äldre PHP-plattformar. Om jag tar bort dem återstår cirka 357 000 rader i den mer moderna, mer egenbyggda ytan som inkluderar TypeScript, Python, Swift, Shell och Astro.
Detta är inte ett försök att vinna en tävling i antal kodrader. En miljon dåliga rader är fortfarande skuld. Statistiken visar bredden på den miljö där modellerna testades: mobil, backend, frontend, automatisering, innehåll, drift och affärslogik.
Fable 5 och GPT-5.6 är bättre — på olika sätt
Anthropic beskriver Fable 5 som sin modell för stora kodprojekt, migreringar och långa autonoma sessioner. OpenAI beskriver GPT-5.4 som en sammanslagning av banbrytande kodning, kunskapsarbete och datoranvändning. GPT-5.6-familjen har flyttat fokus ännu mer mot långvarigt agentarbete.
Det stämmer ganska väl överens med min erfarenhet. Fable är ofta bättre på att förstå formen av ett svårt problem innan den börjar ändra kod. GPT-5.6 Sol är mer benägen att gripa tag i problemet, använda verktygen och driva arbetet framåt.
X-debatten visar samma uppdelning:
Den kritiken är rättvis. En bättre modell kan fortfarande skapa en sämre arbetsdag om routning, prissättning, kontextgränser eller säkerhetspolicy är svåra att förstå.
Modellen är motorn, inte bilen
En språkmodell kan resonera om kod. En kodagent måste också operera inom ett verkligt system.
Min praktiska stack ser ut så här:
Varje del löser ett annat problem. En färdighet utan verktyg är dokumentation. Ett verktyg utan policy är en risk. Minne utan versionshantering blir gammal folktro. Ett bygge utan live-kontroller kan fortfarande lämna produktionen trasig.
MCP Developer Workflows: The Real Control Layer→ är särskilt viktigt eftersom det flyttar integrationen från anpassade prompter till ett kontrakt som flera klienter kan förstå. Min MCP för personlig sida kan till exempel forska, skapa ett utkast, generera bilder, analysera SEO och publicera. Samma agent måste fortfarande veta när den ska stanna vid ett opublicerat utkast.
Det stora steget är längre arbetskedjor
I mitt tidigare test av GPT-5.5 i Codex→ såg jag samma förskjutning. För ett år sedan var en bra kodningssession ofta: fråga, få ett kodblock, kopiera, testa det själv. Nu kan en agent läsa projektregler, hitta rätt repo, inspektera en rutt, ändra koden, bygga, lösa en konflikt, pusha och verifiera produktionen.
Det är en kvalitativ förskjutning.
Samtidigt har jag sett modeller:
Det sista steget är fortfarande det dyraste: att bevisa att resultatet finns på rätt plats och fungerar för en riktig användare.
Vad vi fortfarande saknar
Bättre automatisk modellroutning
Jag vill inte välja modellnamn och resonemangsnivåer för varje deluppgift. Systemet bör skicka arkitekturgranskning till den modell som är bäst på helhetsbilden, mekaniska ändringar till en snabbare modell och slutlig verifiering till en separat kontrollant.
Bärbart arbetsminne
Kontexten är fortfarande fastlåst inom en specifik klient, modell eller sessionsfil. Färdigheter och MCP minskar smärtan, men en agent borde kunna byta modeller utan att förlora projektets beprövade arbetssätt.
Verifiering som en förstklassig funktion
De flesta demo-agenter belönar kodproduktion. Jag vill mäta andelen uppgifter som slutar i verifierat korrekt externt tillstånd: live-rutt, databasrad, installerad app, skickat meddelande eller godkänd bygg.
Tydligare kostnad
Cachade token är billigare och rapporteras ibland olika, men användaren ser ofta bara en stapel som försvinner snabbt. Agenten borde kunna säga: denna uppgift använde X nya inmatningstoken, Y cache-läsningar, Z utdatatoken och skapade följande verifierade resultat.
Min rekommendation: bygg systemet före super-prompten
Börja med en smal uppgift som kan verifieras. Ge agenten en liten uppsättning verktyg, skriv en färdighet för arbetsflödet och definiera vad som räknas som klart. Lägg sedan till minne och fler verktyg när du ser ett återkommande behov.
En användbar kodagent behöver inte fri tillgång till allt. Den behöver rätt åtkomst, rätt ordning och en stoppregel.
Jag använder nu Fable och OpenAI-modeller mindre som orakel och mer som komponenter. Fable kan granska en svår design. GPT-5.6 Sol, Terra och Luna→ kan delas upp efter arbetsprofil, och GPT-5.6 kan driva ett långt verktygsflöde. En mindre modell kan översätta eller klassificera. MCP kopplar dem till verkliga system. Färdigheter ger Codex ett återanvändbart arbetssätt→. Git och tester avgör om resultatet kan gå vidare.
21,54 miljarder token senare är den största förbättringen inte att modellerna skriver snyggare kod. De kan stanna kvar i arbetet längre. Vårt jobb är att bygga räcken, minne och verifiering som gör den tiden värd något.