Meine Code-Agenten nutzten Claude Fable 5 und die OpenAI-Familien GPT-5.4, GPT-5.5 und GPT-5.6 für echte Arbeit im Jahr 2026: Websites, iOS-Apps, E-Commerce, CRM, Musik-Tools, SEO-Systeme und meine eigenen Agenten-Workflows. Als ich die noch auf meinem Mac verbliebenen lokalen Sitzungs-Logs zusammenzählte, landete die Zahl bei 21,54 Milliarden Tokens.
Diese Zahl ist absurd. Sie bedarf jedoch auch des Kontexts.
Der Großteil davon sind nicht 21,5 Milliarden neue Wörter, die für mich geschrieben wurden. Lange Agenten-Sitzungen senden große Codebasen und Anweisungen mehrfach durch den Kontext. Ein großer Teil wird aus dem Cache gelesen. Die Token-Anzahl zeigt hauptsächlich, wie viel Kontext meine Code-Agenten durchgearbeitet haben.
Mein Fazit nach diesem Zeitraum ist weiterhin klar: Wir haben ein Level erreicht. Die Modelle können längere Aufgaben zusammenhängend bewältigen, Tools nutzen und Fehler auf einem Niveau reparieren, das sich noch vor einem Jahr weit entfernt anfühlte. Dennoch ist das Modell selbst immer noch der am wenigsten interessante Teil eines zuverlässigen Systems.
Was 21,5 Milliarden Tokens über Code-Agenten aussagen
Ich habe die OpenAI-Nutzung anhand jedes `last_token_usage`-Werts in den gespeicherten Codex-Logs gezählt. Fable habe ich anhand eindeutiger Assistenten-Nachrichten in den Claude-Logs gezählt, unter Verwendung von normalem Input, Cache-Erstellung, Cache-Lesezugriff und Output. Das Ergebnis ist eine lokale Aktivitätsmessung – keine Abrechnung von OpenAI oder Anthropic.
| Modell | Protokollerte Aktivitäts-Tokens | Eindeutige Nutzungsereignisse / Modell-Antworten |
|---|---|---|
| --- | ---: | ---: |
| GPT-5.5 | 12,96 Milliarden | 95.930 |
| GPT-5.6 Sol, Terra und Luna | 1,88 Milliarden | 12.370 |
| GPT-5.4 einschließlich Mini | 3,43 Milliarden | 26.624 |
| Claude Fable 5 | 3,27 Milliarden | 16.878 |
| Gesamt | 21,54 Milliarden | 151.802 |
Bei Anwendung der High-Water-Methode entfielen auf GPT-5.4 etwa 3,21 Milliarden gecachte Input-Tokens, auf GPT-5.5 12,30 Milliarden und auf die GPT-5.6-Familie etwa 1,82 Milliarden. Die Fable-Logs enthielten etwa 3,05 Milliarden Cache-Lesezugriffe und 181 Millionen Tokens für die Cache-Erstellung.
Deshalb ist es irreführend, die Gesamtsumme mit der Textmenge zu vergleichen, die ein Mensch lesen könnte. Agenten-Arbeit verwendet große Kontexte mehrfach. Die relevante Frage ist, ob das System das Richtige mit ihnen getan hat.
Die Codebasis hinter der Nutzung: 59 GitHub-Projekte
Zum Zeitpunkt der Messung hatte mein GitHub-Konto 59 Repositories: 50 private und 9 öffentliche. Sie verteilen sich ungefähr wie folgt:
Bei den 26 GitHub-Repos, die ein lokales Checkout mit exakt demselben Namen hatten, fand ich nach dem Herausfiltern von Vendor-, Build-, Cache- und minimierten Dateien 6,90 Millionen getrackte Quellcodezeilen. Diese Zahl wird von drei großen Legacy-PHP-Plattformen dominiert. Wenn ich diese entferne, verbleiben etwa 357.000 Zeilen in der moderneren, stärker selbstgebauten Oberfläche, die TypeScript, Python, Swift, Shell und Astro umfasst.
Dies ist kein Versuch, einen Codezeilen-Wettbewerb zu gewinnen. Eine Million schlechte Zeilen sind immer noch technische Schulden. Die Statistiken zeigen die Breite der Umgebung, in der die Modelle getestet wurden: Mobile, Backend, Frontend, Automatisierung, Content, Operations und Geschäftslogik.
Fable 5 und GPT-5.6 sind besser – auf unterschiedliche Weise
Anthropic beschreibt Fable 5 als sein Modell für große Codeprojekte, Migrationen und lange autonome Sitzungen. OpenAI beschreibt GPT-5.4 als eine Verschmelzung von frontier Coding, Wissensarbeit und Computernutzung. Die GPT-5.6-Familie hat den Fokus noch stärker auf langlaufende Agenten-Arbeit verschoben.
Das deckt sich ziemlich gut mit meiner Erfahrung. Fable ist oft besser darin, die Form eines schwierigen Problems zu verstehen, bevor es beginnt, Code zu ändern. GPT-5.6 Sol greift das Problem eher an, nutzt die Tools und treibt die Arbeit voran.
Die X-Debatte zeigt dieselbe Aufspaltung:
Diese Kritik ist berechtigt. Ein besseres Modell kann dennoch einen schlechteren Arbeitstag erzeugen, wenn Routing, Preisgestaltung, Kontextlimits oder Sicherheitsrichtlinien schwer zu verstehen sind.
Das Modell ist der Motor, nicht das Auto
Ein Sprachmodell kann über Code raisonnieren. Ein Code-Agent muss auch innerhalb eines realen Systems operieren.
Mein praktischer Stack sieht so aus:
Jeder Teil löst ein anderes Problem. Ein Skill ohne Tools ist Dokumentation. Ein Tool ohne Richtlinie ist ein Risiko. Memory ohne Versionskontrolle wird zu alter Folklore. Ein Build ohne Live-Checks kann die Produktion dennoch kaputt lassen.
MCP Developer Workflows: The Real Control Layer→ ist besonders wichtig, weil es die Integration von benutzerdefinierten Prompts weg und in einen Vertrag verlagert, den mehrere Clients verstehen können. Mein Personal-Page-MCP kann beispielsweise recherchieren, einen Entwurf erstellen, Bilder generieren, SEO analysieren und veröffentlichen. Derselbe Agent muss dennoch wissen, wann er bei einem unveröffentlichten Entwurf stoppen muss.
Der große Sprung sind längere Arbeitsketten
In meinem früheren Test von GPT-5.5 in Codex→ sah ich dieselbe Verschiebung. Vor einem Jahr war eine gute Coding-Sitzung oft: fragen, einen Code-Block erhalten, kopieren, selbst testen. Jetzt kann ein Agent Projektregeln lesen, das richtige Repo finden, eine Route inspizieren, den Code ändern, bauen, einen Konflikt lösen, pushen und die Produktion verifizieren.
Das ist eine qualitative Verschiebung.
Gleichzeitig habe ich Modelle gesehen, die:
Der letzte Schritt ist immer noch der teuerste: zu beweisen, dass das Ergebnis am richtigen Ort existiert und für einen echten Benutzer funktioniert.
Was uns noch fehlt
Besseres automatisches Modell-Routing
Ich möchte nicht für jede Teilaufgabe Modellnamen und Reasoning-Level auswählen. Das System sollte Architektur-Reviews an das Modell senden, das am besten für das Gesamtbild geeignet ist, mechanische Änderungen an ein schnelleres Modell und die finale Verifizierung an einen separaten Checker.
Tragbarer Arbeitsspeicher
Der Kontext steckt immer noch in einem spezifischen Client, Modell oder einer Sitzungsdatei fest. Skills und MCP reduzieren den Schmerz, aber ein Agent sollte in der Lage sein, Modelle zu wechseln, ohne die bewährte Arbeitsweise des Projekts zu verlieren.
Verifizierung als First-Class-Feature
Die meisten Demo-Agenten belohnen die Code-Produktion. Ich möchte den Anteil der Aufgaben messen, die in einem verifiziert korrekten externen Zustand enden: Live-Route, Datenbankzeile, installierte App, gesendete Nachricht oder genehmigter Build.
Klarere Kosten
Gecachte Tokens sind günstiger und werden manchmal anders berichtet, aber der Nutzer sieht oft nur einen Balken, der schnell verschwindet. Der Agent sollte sagen können: Diese Aufgabe hat X neue Input-Tokens, Y Cache-Lesezugriffe, Z Output-Tokens verwendet und das folgende verifizierte Ergebnis erstellt.
Meine Empfehlung: Baut das System vor dem Super-Prompt
Beginnt mit einer engen Aufgabe, die verifiziert werden kann. Gebt dem Agenten einen kleinen Satz an Tools, schreibt einen Skill für den Workflow und definiert, was als erledigt gilt. Fügt dann Memory und weitere Tools hinzu, wenn ihr einen wiederkehrenden Bedarf seht.
Ein nützlicher Code-Agent braucht keinen freien Zugriff auf alles. Er braucht den richtigen Zugriff, die richtige Reihenfolge und eine Stopp-Regel.
Ich nutze Fable- und OpenAI-Modelle jetzt weniger wie Orakel und mehr wie Komponenten. Fable kann ein schwieriges Design reviewen. GPT-5.6 Sol, Terra und Luna→ können nach Arbeitsprofil aufgeteilt werden, und GPT-5.6 kann einen langen Tool-Flow steuern. Ein kleineres Modell kann übersetzen oder klassifizieren. MCP verbindet sie mit realen Systemen. Skills geben Codex eine wiederverwendbare Arbeitsweise→. Git und Tests entscheiden, ob das Ergebnis voranschreiten kann.
21,54 Milliarden Tokens später ist die größte Verbesserung nicht, dass die Modelle hübscheren Code schreiben. Sie können länger in der Arbeit bleiben. Unsere Aufgabe ist es, Leitplanken, Memory und Verifizierung zu bauen, die diese Zeit wertvoll machen.