Das Token-Limit ist ein Budget, keine bloße Einschränkung.

Seit einigen Wochen beobachte ich, dass Paperclip mein wöchentliches Token-Kontingent innerhalb eines einzigen Tages aufbrauchen kann. Das Problem ist nicht der hohe Verbrauch an sich. Würde er zu proportionalen, sichtbaren Änderungen in den Anwendungen führen, könnte man ihn als Arbeitskosten betrachten. Gleichzeitig drehte sich ein Großteil der Aktivitäten um Systementwicklung und Dokumentation, während sich die Projekte, die diese Arbeit unterstützen sollte, deutlich langsamer weiterentwickelten.

Deshalb habe ich Paperclip so eingestellt, dass der Verbrauch bei 75 % des Limits gestoppt wird. Das verbleibende Limit dient dem Schutz anderer Einsatzbereiche von Codex, da Paperclip nicht mein einziger Arbeitsbereich ist. Dies ist eine einfache Sicherheitsmaßnahme, die jedoch ein wichtigeres Problem offenbart: Token sind keine abstrakte Zahl, die irgendwo in einem Dashboard angezeigt wird. Sie stellen ein gemeinsames Betriebsbudget dar, um das Aufgaben, Projekte und Agenten konkurrieren.

Ich spreche lieber von Computational Intelligence als von Künstlicher Intelligenz. Dies ist keine bloße Stilfrage. Eine gute Definition sollte die Realität so genau wie möglich beschreiben. Das Wort „künstlich“ kann etwas Unwirkliches, Illusorisches oder der menschlichen Intelligenz Unterlegenes suggerieren. „Berechnungsbasiert“ hingegen bezeichnet einen Mechanismus: Algorithmen, Mathematik und die Ausführung von Berechnungen. Dies setzt nicht voraus, dass menschliche Intelligenz die einzig wahre oder höchste Form der Problemlösung darstellt.

Ein gutes Beispiel für die Grenzen dieser anthropozentrischen Sichtweise ist Physarum polycephalum. In dem Experiment wurden Futterstellen an Positionen verteilt, die 20 großen US-amerikanischen Ballungsräumen entsprachen. Der einzellige Schleimpilz verband diese mit einem Netzwerk, das in einem vereinfachten Graphen 36 der 41 Verbindungen des US-amerikanischen Interstate-Highway-Systems nachbildete (Adamatzky und Ilachinski, 2012). Dies bedeutet jedoch nicht, dass der Schleimpilz eine menschliche Persönlichkeit besitzt oder perfekte Autobahnen entworfen hat. Dies zeigt jedoch, dass sinnvolle Berechnungen und Netzwerkoptimierung nicht ausschließlich dem menschlichen Verstand vorbehalten sind.

Aus dieser Perspektive ist ein Token-Limit vergleichbar mit einer Begrenzung der menschlichen Zeit, der Team-Bandbreite oder der verfügbaren Rechenleistung. Es bestimmt noch nicht, wie viel Wert geschaffen wird. Vielmehr legt es fest, wie viel Arbeit das System versuchen kann zu erledigen, bevor es die Fähigkeit verliert, nachfolgende Aufgaben auszuführen.

Ressourcenverbrauch ist kein Beweis für Ergebnisse

Es gibt keine allgemeingültige optimale Anzahl an Tokens für jede Aufgabe. Das Schreiben eines kurzen Gedichts und das Erstellen einer Tabelle mit Kosten und Einnahmen erfordern unterschiedlich viel Aufwand. Daher ist es unmöglich, ein System allein anhand des Verhältnisses von Tokens zur Anzahl der generierten Dateien, Antworten oder Aufgaben fair zu bewerten.

Ausgangspunkt muss ein Problem sein. Dem Agenten sollten ein Ziel, ein Kontext und eine Beschreibung des Ergebnisses bereitgestellt werden, die nach ihrer Ausführung für den Menschen oder den nächsten Agenten nützlich sind. Erst dann kann man hinterfragen, ob die Kosten gerechtfertigt waren. Ein Artefakt wird nicht allein dadurch wertvoll, dass es umfangreiche Überlegungen erforderte. Dokumentation ist notwendig, wenn sie Arbeit ermöglicht. Wenn die Änderung, die sie eigentlich ermöglichen sollte, ersetzt wird, verbraucht sie das Budget, ohne die Aufgabe abzuschließen.

Paperclip bietet heute zwei mögliche Diagnosen. Möglicherweise ist das verfügbare Budget für den Umfang der zugewiesenen Projekte zu gering. Möglicherweise liegt das Problem in der Arbeitsorganisation: zu breit gefasste Aufgaben, unzureichend definierter Kontext, sich wiederholende Aktivitäten oder Akzeptanzkriterien, die eine leicht zugängliche Dokumentation begünstigen. Es ist auch möglich, dass beide Einschränkungen gleichzeitig wirken. Die Tatsache, dass das Limit erreicht wurde, erlaubt keine Trennung der beiden Faktoren.

Ein größeres Budgetpaket löst kein schlecht definiertes Problem. Es ermöglicht lediglich, dass die Arbeit länger auf dieselbe Weise fortgesetzt wird. Andererseits kann ein zu geringes Budget eine ordnungsgemäß geplante Abfolge unterbrechen, bevor ihre Komponenten zu einem Ergebnis zusammengeführt werden. Daher sollte das Limit in Verbindung mit der Aufgabenstruktur analysiert werden, nicht als separates technisches Hindernis.

Unzureichender Kontext

Die zweite begrenzte Ressource ist der Kontext. Der Bearbeiter benötigt Informationen, um das Problem, die Abhängigkeiten und die Akzeptanzbedingungen zu verstehen. Erhält es zu wenige Daten, muss es raten oder eine lokale Lösung finden, die das restliche System nicht berücksichtigt. Erhält es hingegen alle jemals über das Projekt aufgezeichneten Daten, können die für einen bestimmten Schritt benötigten Informationen im Datenrauschen untergehen.

Mein Arbeitsprinzip ist paradox: Dem Agenten sollte die maximal benötigte Datenmenge zur Verfügung gestellt werden, die gleichzeitig die minimal notwendige Menge darstellt. Es geht nicht darum, jedes Token zu speichern, sondern um Angemessenheit. Der Kontext sollte alles Notwendige für die korrekte Ausführung eines bestimmten Schritts enthalten und keine Inhalte beinhalten, die für die aktuelle Entscheidung oder Aktion nicht hilfreich sind.

Die Studie „Lost in the Middle“ zeigte, dass die Modellleistung bei Aufgaben mit langem Kontext von der Position der relevanten Informationen abhing und häufig abnahm, wenn diese sich in der Mitte der Eingabe befanden (Liu et al., 2024). Dies beweist nicht, dass jede lange Eingabeaufforderung schlecht ist. Es zeigt jedoch, dass die Akzeptanz von Informationen durch das Modell nicht gleichbedeutend mit deren gleichwertiger effektiver Nutzung ist.

Der RULER-Benchmark zeigte einen ähnlichen Unterschied. Die Autoren testeten 17 Modelle, die laut Werbung mindestens 32.000 Token unterstützen. Fast alle dieser Ansätze verloren mit zunehmender Länge und Komplexität an Effektivität, und nur die Hälfte erreichte das angenommene Leistungsniveau bei 32.000 Token (Hsieh et al., 2024). Das angegebene Fenster stellt daher eine technische Obergrenze für die Eingabe dar und ist keine Garantie für sinnvolles Schließen über seine gesamte Länge.

Dies korrigiert die Annahme, dass das verfügbare Fenster standardmäßig gefüllt werden sollte. Es ist nur dann sinnvoll, es mit Daten zu füllen, wenn diese für die Aufgabe benötigt werden und so angeordnet sind, dass der Agent Abhängigkeiten erkennen kann. Leerer Raum im Kontext ist keine verschwendete Energie. Manchmal schützt er vor Informationen, die mit dem eigentlichen Problem um Aufmerksamkeit konkurrieren.

Die Aufgabe muss in die Kapazität des Ausführenden passen

Wenn die korrekte Ausführung der Aufgabe mehr Kontext erfordert, hat das System zwei sinnvolle Optionen: Es kann spezifische fehlende Informationen hinzufügen oder das Problem in kleinere, abhängige Schritte unterteilen. Die Unterteilung beinhaltet nicht die Erzeugung beliebig kleiner Aufgaben. Jeder Schritt erfordert eine Eingabe, ein erwartetes Ergebnis und ein Akzeptanzkriterium, und sein Ergebnis muss im nächsten Schritt verwendbar sein.

Die LLM-Studie zur Agentenplanungsforschung nennt die Aufgabenzerlegung neben Planauswahl, Gedächtnis, Reflexion und externen Modulen als einen der wichtigsten Planungsmechanismen. Gleichzeitig hebt sie offene Probleme in Bezug auf Planung und Ausführung hervor (Huang et al., 2024). Die Aufteilung allein garantiert keinen Erfolg. Sie kann lokal korrekte Teile erzeugen, die, wenn sie kombiniert werden, das ursprüngliche Problem nicht lösen.

Bei der Planung meiner eigenen Arbeit verwende ich eine einfache Heuristik: Ich plane keine Aufgaben, die weniger als etwa fünf Minuten dauern; Aufgaben, die länger als etwa 25 Minuten dauern, versuche ich aufzuteilen, um den Fokus zu behalten. Dies ist keine Umrechnung von menschlicher Zeit in Agenten-Tokens. Die Analogie betrifft die Granularität. Eine Aufgabe muss groß genug sein, damit ihr Ergebnis sinnvoll ist, aber klein genug, damit der Ausführende die notwendigen Abhängigkeiten einbeziehen kann.

In einem Agentensystem sollte ein Schritt mit einem kontrollierten Zwischenergebnis enden. Hat der Agent die Anforderungen analysiert, darf das Ergebnis nicht einfach nur die Information über den Abschluss der Analyse enthalten. Es sollte strukturierte Anforderungen liefern, die für den Planer nützlich sind. Hat der Entwickler eine Funktion geändert, sollte das Ergebnis Code und den Nachweis enthalten, dass die korrekten Abläufe weiterhin funktionieren. Dadurch wird verhindert, dass der nächste Agent den gesamten vorherigen Kontext neu erstellen und dieselbe Arbeit erneut bezahlen muss.

Budget sollte die Wertschöpfung schützen

Die 75%-Schwelle ist derzeit eine manuelle Beschränkung, keine universelle Vorgabe. In anderen Systemen kann die angemessene Reserve höher oder niedriger sein. Die Funktion dieser Grenze ist wichtig: Kein autonomer Prozess sollte unkontrolliert die gesamte gemeinsam genutzte Ressource belegen und Aufgaben mit höherer Priorität blockieren.

Vor dem Start einer größeren Sequenz ist es daher wichtig, das verfügbare Budget, das Mindestergebnis und die Abbruchbedingung zu kennen. Nach jedem größeren Schritt sollte das System beantworten können, was sich tatsächlich geändert hat, welches Ergebnis weitergegeben wird und ob die Fortsetzung noch einen höheren Wert hat als die Schonung der Ressource für eine andere Aufgabe. Beim Erreichen der Grenze sollte zunächst der Zustand und der Nachweis gesichert werden, erst dann sollte der Umfang reduziert oder die Arbeit eingestellt werden.

Ziel ist nicht, den Tokenverbrauch jedes Agenten so gering wie möglich zu halten. Eine solche Optimierung könnte oberflächliche Antworten und das Ignorieren von Abhängigkeiten belohnen. Ziel ist vielmehr ein angemessener Verbrauch: so viel Schlussfolgerung und Kontext wie nötig, um das vereinbarte Ergebnis korrekt zu liefern, ohne endlose Aktivitäten zu finanzieren, die das System nicht weiterbringen.

Das Paketlimit könnte tatsächlich zu niedrig sein. Bevor ich es jedoch als alleinige Ursache betrachte, möchte ich sicherstellen, dass das System Budget einhält, Kontext einem Schritt zuordnet, Arbeit aufteilt, ohne das Gesamtergebnis zu verlieren, und das Ergebnis vom Aktivitätsverlauf unterscheidet. Nur dann führt ein größerer Token-Pool zu einem höheren Durchsatz. Ohne diese Mechanismen handelt es sich möglicherweise lediglich um einen größeren Speicher, den Paperclip auf dieselbe Weise leert.

Bibliographie

✦Systeme für mehr Autonomie bauen.