Die Aufstellung, die wir inzwischen am häufigsten herumzeigen, ist eine Kostenabrechnung. Ein Monat Agentenläufe, aufgeschlüsselt nach Token-Art. Die erste Zeile ist die, auf die jeder zuerst schaut: generierte Tokens. Der Code, die Pull-Request-Beschreibungen, die Testausgaben-Zusammenfassungen — alles, was der Agent geschrieben hat. Ein überschaubarer Betrag.
Die Zeile darunter ist etwa fünfundsiebzigmal so groß.
Sie heißt “Cache Reads” und beschreibt etwas, das niemand als Arbeit wahrnimmt: das wiederholte Einlesen desselben Kontexts. Wer über die Kosten von Agenten spricht und dabei an den erzeugten Text denkt, redet über die kleinere der beiden Zahlen.
Ein Lauf ist nicht eine Anfrage
Wenn du dir vorstellst, was ein Agent tut, denkst du vermutlich an eine Frage und eine Antwort. Tatsächlich ist ein Lauf eine Kette. Der Agent liest das Ticket. Er sucht die relevante Datei. Er liest sie. Er ändert etwas. Er startet die Tests. Er liest die Ausgabe. Er korrigiert. Vierzig Schritte sind für eine mittelgroße Aufgabe nichts Ungewöhnliches.
Und bei jedem einzelnen dieser Schritte bekommt das Modell den gesamten bisherigen Verlauf noch einmal zu sehen. Zwischen den Schritten gibt es kein Gedächtnis; der Verlauf ist das Gedächtnis. Was in Schritt drei gelesen wurde, wird in Schritt vier wieder mitgeschickt, und in Schritt fünf, und in Schritt vierzig.
Dagegen gibt es einen Mechanismus, und ohne ihn wäre die ganze Bauform unbezahlbar: Der Anbieter merkt sich den unveränderten Anfang einer Anfrage und berechnet ihn beim nächsten Mal nur noch mit einem Bruchteil — grob ein Zehntel dessen, was frisch eingelesene Tokens kosten. Das ist der Grund, warum Agenten überhaupt wirtschaftlich laufen.
Ein Zehntel von etwas, das vierzigmal passiert und dabei mit jedem Schritt größer wird, ist trotzdem viel. Am Ende steht ein Verhältnis in der Größenordnung von 75 zu 1 zwischen dem, was gelesen wurde, und dem, was herauskam. Die genaue Zahl schwankt mit der Aufgabe. Die Größenordnung tut es nicht.
Die Stellschraube, an der alle zuerst drehen
Daraus folgt etwas Unbequemes: Fast alles, was intuitiv nach Sparen aussieht, spart nichts Messbares.
Der Agent soll knapper antworten — das verändert die kleinere Zahl. Kürzere Commit-Nachrichten, weniger ausführliche PR-Beschreibungen, keine Erklärtexte: alles die kleinere Zahl. Man kann den Output halbieren und findet die Ersparnis in der Summe kaum wieder.
Es ist verständlich, dass die Diskussion dort landet. Der Output ist das Einzige, was man sieht. Die Cache Reads stehen in keinem Ticket und in keinem Review — sie stehen nur in der Abrechnung.
Hebel eins: das Modell pro Rolle
Ein Agentensystem ist selten ein Modell. Es sind mehrere Rollen: eine plant, eine schreibt den Code, eine prüft das Ergebnis, eine fasst zusammen. Die naheliegende Einstellung ist, überall das stärkste Modell zu nehmen, weil man an keiner Stelle Qualität verlieren will.
Das ist an genau einer Stelle richtig und an den übrigen teuer. Ein Prüfer, der beantwortet, ob eine URL mit 200 antwortet und ob der Link tatsächlich im gerenderten HTML steht, braucht nicht das Modell, das die Änderung geschrieben hat. Die Frage ist eng, die Antwort ist überprüfbar, und ein kleineres Modell beantwortet sie zuverlässig zu einem Bruchteil des Preises. Dasselbe gilt für Zusammenfassungen, für Klassifikationen, für das Sortieren von Suchergebnissen.
Die Ausnahme ist die schreibende Rolle. Dort zu sparen rechnet sich meistens nicht, weil ein fehlgeschlagener Lauf fast dasselbe kostet wie ein erfolgreicher — und danach noch einmal bezahlt werden muss. Rollentrennung heißt nicht “überall billiger”. Sie heißt: teuer nur dort, wo Irrtum wirklich weh tut.
Hebel zwei: wie viel Kontext ein Lauf anfassen muss
Der zweite Hebel folgt direkt aus der Mechanik oben. Jede Datei, die ein Agent öffnet, bleibt im Kontext und wird von da an bei jedem weiteren Schritt mitgelesen. Wer sich am Anfang eines Laufs “zur Orientierung” durch dreißig Dateien arbeitet, bezahlt diese dreißig Dateien nicht einmal, sondern so oft, wie der Lauf noch Schritte hat.
Das macht Lesedisziplin zum wirksamsten Einzelhebel, den wir gefunden haben. Gezielt nach einem Symbol suchen statt ein Verzeichnis durchzugehen. Die Datei öffnen, die im Ticket steht, und erst dann weitersuchen, wenn sich zeigt, dass sie nicht reicht. Bei uns ist das inzwischen eine ausformulierte Regel im Auftrag an den Agenten, und sie hat mehr bewegt als jede Prompt-Optimierung davor.
Der zweite Teil desselben Hebels ist die Länge des Laufs. Kosten wachsen nicht linear mit der Anzahl der Schritte, sondern schneller, weil jeder zusätzliche Schritt einen größeren Kontext liest. Ein Lauf, der sechzig statt zwanzig Schritte braucht, kostet deutlich mehr als das Dreifache.
Was kostet also eine Aufgabe?
Nicht: wie viel Code dabei herauskommt. Sondern drei andere Dinge.
Wie viel Kontext nötig ist, um sie überhaupt zu verstehen. Eine Änderung an einer klar benannten Datei ist billig; dieselbe Änderung in einem System, dessen Zusammenhänge sich der Agent erst erschließen muss, ist ein Vielfaches davon.
Wie viele Schritte sie braucht. Das hängt weniger am Modell als daran, ob die Aufgabe eindeutig beschrieben ist.
Und ob sie beim ersten Mal gelingt. Ein abgebrochener Lauf kostet fast so viel wie ein erfolgreicher, nur ohne Ergebnis. Die Zahl der Wiederholungen ist damit ein Kostenposten — und die Qualität der Aufgabenbeschreibung eine Kostenmaßnahme, nicht bloß eine Höflichkeit gegenüber der Maschine.
Drei Fragen für das nächste Gespräch
Wenn dir jemand die Kosten eines Agentensystems vorrechnet, sind drei Fragen aufschlussreicher als jede Prognose.
Wie teilt sich die Rechnung nach Token-Art auf? Welches Modell läuft in welcher Rolle? Und was kostet eine typische Aufgabe im Median — und wie weit streut das nach oben?
Wenn die erste Frage nicht beantwortet werden kann, ist alles Weitere geschätzt. Das ist kein Vorwurf, sondern der übliche Zustand: Die Zahl steht in der Abrechnung des Anbieters, nicht im eigenen Dashboard, und niemand hat bisher hingesehen.
Die Rechnung für einen Agenten ist keine Rechnung für erzeugten Text. Sie ist eine Rechnung fürs Nachschlagen. Wer das einmal verinnerlicht hat, optimiert an anderen Stellen — und meistens an den richtigen.
