Tokens, Kontext, Caching und agentische Loops als Referenzwerk

„Was kostet es, wenn ich acht Stunden am Tag mit einem Coding Agent arbeite?“

Die Frage klingt nach einer einfachen Rechnung. Acht Stunden Nutzung, ein Preis pro Stunde, fertig.

Bei agentischer Softwareentwicklung funktioniert diese Rechnung nicht.

Ein Coding Agent wird normalerweise nicht nach Laufzeit abgerechnet. Entscheidend ist, wie oft ein Sprachmodell aufgerufen wird, wie viel Kontext dabei verarbeitet wird, wie viel davon bereits bekannt und gecacht ist und wie viel neue Ausgabe das Modell erzeugt.

Zwei Entwickler können acht Stunden mit demselben Modell arbeiten und dabei völlig unterschiedliche Kosten verursachen. Noch verwirrender wird es, wenn ein Anbieter meldet, dass während eines Arbeitstags beispielsweise 100 Millionen Tokens verarbeitet wurden. Diese Zahl allein sagt erstaunlich wenig über die tatsächlichen Kosten aus.

Um die Kosten moderner Coding Agents zu verstehen, muss man deshalb zunächst verstehen, was während einer agentischen Entwicklungssitzung technisch passiert.

---

Vom Chat zum Coding Agent

Bei einem klassischen Chat ist das Modell der zentrale Akteur:

Benutzer
   ↓
Prompt
   ↓
Sprachmodell
   ↓
Antwort

Ein Coding Agent arbeitet anders. Er verbindet das Sprachmodell mit Werkzeugen und führt eine Aufgabe iterativ aus:

Aufgabe verstehen
       ↓
Repository untersuchen
       ↓
Dateien lesen
       ↓
Änderung planen
       ↓
Code verändern
       ↓
Build ausführen
       ↓
Ergebnis analysieren
       ↓
Tests ausführen
       ↓
Testergebnisse analysieren
       ↓
Code erneut verändern
       ↓
Tests erneut ausführen
       ↓
Ergebnis überprüfen

Das Modell beantwortet also nicht einfach eine Frage. Es arbeitet innerhalb einer Schleife aus Denken, Handeln und Beobachten.

Diese Schleife wird häufig als Agentic Loop bezeichnet.

Vereinfacht:$$Reasoning \rightarrow Action \rightarrow Observation \rightarrow Reasoning$$

Jeder Durchlauf kann einen oder mehrere neue Modellaufrufe verursachen.

Genau hier beginnt die Kostenrechnung.

---

1. Token

Ein Token ist eine Verarbeitungseinheit eines Sprachmodells.

Tokens sind weder exakt Wörter noch Zeichen. Ein Wort kann aus einem Token bestehen, aber ebenso aus mehreren. Satzzeichen, Leerzeichen, Zahlen und Teile von Quellcode können ebenfalls eigene Tokens bilden.

Für die Kostenrechnung ist diese sprachliche Feinheit weniger wichtig als die grundsätzliche Unterscheidung zwischen Eingabe und Ausgabe.

Input Tokens

Input Tokens sind Informationen, die einem Modell zur Verarbeitung übergeben werden.

Bei einem Coding Agent können dazu gehören:

• die Benutzeranweisung,
• Systemanweisungen des Agenten,
• Projektregeln,
• bisherige Konversation,
• Quellcode,
• Dateiinhalte,
• Verzeichnisstrukturen,
• Git-Diffs,
• Suchergebnisse,
• Compilerfehler,
• Testresultate,
• Logdateien,
• Dokumentation,
• Ergebnisse anderer Werkzeuge.

Input ist damit wesentlich mehr als das, was der Entwickler selbst in das Eingabefeld schreibt.

Eine Anweisung wie:

Implementiere die Validierung und führe anschließend alle Tests aus.

besteht vielleicht nur aus wenigen Tokens.

Der tatsächliche Modellaufruf kann trotzdem zehntausende Tokens umfassen, weil der Agent zusätzlich Projektinformationen, relevante Dateien und den bisherigen Arbeitskontext mitsendet.

Output Tokens

Output Tokens sind Informationen, die das Modell neu erzeugt.

Dazu gehören je nach Agent unter anderem:

• Text,
• Analysen,
• Code,
• Änderungsvorschläge,
• strukturierte Daten,
• Tool-Aufrufe,
• Teile des Reasonings.

Output Tokens sind bei vielen kommerziellen Modellen deutlich teurer als Input Tokens.

Damit ergibt sich zunächst eine einfache Kostenformel:$$K = \frac{T_{input}}{1\,000\,000} P_{input} + \frac{T_{output}}{1\,000\,000} P_{output}$$

Dabei steht:

• $T$ für die Anzahl Tokens,
• $P$ für den Preis pro Million Tokens.

Für einen einfachen Chat reicht dieses Modell als erste Näherung.

Für einen modernen Coding Agent ist es unvollständig.

---

2. Inference

Eine Inference oder Inferenz ist vereinfacht gesagt eine Ausführung des Sprachmodells.

Das Modell erhält einen Kontext und erzeugt daraus eine Ausgabe.

Ein wichtiger Unterschied besteht deshalb zwischen:

eine Aufgabe

und:

ein Modellaufruf

Eine Aufgabe kann sehr viele Modellaufrufe verursachen.

Ein Coding Agent könnte beispielsweise:

1. die Aufgabe analysieren,
2. nach relevanten Dateien suchen,
3. Suchergebnisse auswerten,
4. zwei Dateien lesen,
5. eine Änderung durchführen,
6. einen Build starten,
7. einen Compilerfehler analysieren,
8. den Code korrigieren,
9. Tests starten,
10. einen fehlgeschlagenen Test analysieren,
11. erneut Code ändern,
12. Tests wiederholen,
13. das Endergebnis überprüfen.

Aus einer einzigen Benutzeranweisung entsteht damit eine ganze Kette von Inferenzschritten.

Die Gesamtkosten entsprechen deshalb eher:$$K_{gesamt} = \sum_{i=1}^{n} K(Inference_i)$$

als einem Preis für die ursprüngliche Benutzeranfrage.

---

3. Context Window

Das Context Window bezeichnet die maximale Menge an Informationen, die ein Modell innerhalb eines Modellaufrufs berücksichtigen kann.

Es wird üblicherweise in Tokens angegeben.

Ein Modell mit einem großen Context Window kann beispielsweise umfangreiche Quellcodedateien, Projektregeln, Dokumentation und einen längeren Gesprächsverlauf gleichzeitig berücksichtigen.

Drei Größen dürfen dabei nicht miteinander verwechselt werden:

Maximales Context Window

Die technische Obergrenze des Modells.

Aktuell verwendeter Kontext

Die Menge an Informationen, die der Agent momentan an das Modell übergibt.

Neu zu verarbeitender Kontext

Der Teil davon, der nicht bereits über einen Cache wiederverwendet werden kann.

Ein hypothetisches Beispiel:

Maximales Context Window:    200'000 Tokens
Aktueller Kontext:            72'000 Tokens
Neuer Input:                   3'000 Tokens
Cache Read:                   69'000 Tokens
Erzeugter Output:              4'000 Tokens

Die Aussage „das Modell hat 200’000 Tokens Kontext“ sagt damit weder aus, dass bei jedem Aufruf 200’000 Tokens verarbeitet werden, noch dass 200’000 Tokens zum normalen Inputpreis abgerechnet werden.

---

4. Warum Kontext bei Coding Agents ständig wieder auftaucht

Ein Modell besitzt zwischen unabhängigen Inferenzschritten nicht automatisch ein dauerhaftes Gedächtnis des gesamten Projekts.

Damit ein späterer Modellaufruf weiß, was vorher passiert ist, muss relevanter Kontext erneut verfügbar gemacht werden.

Ein stark vereinfachtes Beispiel:

Inference 1

System Prompt
Projektregeln
Aufgabe
Datei A
        ↓
      Modell

Später:

Inference 2

System Prompt
Projektregeln
Aufgabe
Datei A
Ergebnis von Inference 1
Datei B
Compileroutput
        ↓
      Modell

Noch später:

Inference 3

System Prompt
Projektregeln
Aufgabe
bisheriger Arbeitskontext
Datei A
Datei B
Testergebnis
        ↓
      Modell

Der Kontext kann dadurch während einer längeren Sitzung erheblich wachsen.

Würde bei jedem Schritt der komplette Kontext vollständig neu zum normalen Inputpreis verarbeitet, wären agentische Systeme deutlich teurer.

Hier kommt Prompt Caching ins Spiel.

---

5. Prompt Caching

Prompt Caching ermöglicht die Wiederverwendung bereits verarbeiteter Teile eines Prompts beziehungsweise Kontexts.

Bei Coding Agents ist das besonders wertvoll, weil große Teile des Kontextes zwischen zwei Modellaufrufen identisch bleiben können.

Dazu gehören beispielsweise:

• Systemanweisungen,
• Projektregeln,
• große Teile der Konversation,
• bereits gelesene Dateien,
• Repository-Kontext,
• länger gültige Dokumentation.

Statt denselben Kontext bei jedem Inferenzschritt vollständig neu zu verarbeiten, kann ein Anbieter bestimmte Teile wiederverwenden.

Für die Kostenanalyse entstehen damit mindestens drei unterschiedliche Arten von Input.

Fresh Input

Fresh Input bezeichnet neuen Kontext, der tatsächlich neu verarbeitet werden muss.

Beispiele:

• eine neue Benutzeranweisung,
• eine neu gelesene Datei,
• ein neuer Compilerfehler,
• das Ergebnis eines gerade ausgeführten Tests.

Cache Write

Beim Cache Write wird wiederverwendbarer Kontext in einen Prompt Cache aufgenommen.

Dieser Vorgang kann eine eigene Preisstruktur besitzen.

Cache Read

Beim Cache Read wird bereits gecachter Kontext erneut verwendet.

Cache Reads sind bei entsprechenden Preismodellen typischerweise deutlich günstiger als die vollständige erneute Verarbeitung desselben Inputs.

Damit wird aus der einfachen Kostenformel:$$K = K_{fresh} + K_{cache-write} + K_{cache-read} + K_{output}$$

Oder ausführlicher:$$K = \frac{ T_fP_f + T_wP_w + T_rP_r + T_oP_o }{1\,000\,000}$$

mit:

• $T_f$: Fresh Input Tokens,
• $T_w$: Cache Write Tokens,
• $T_r$: Cache Read Tokens,
• $T_o$: Output Tokens,
• $P$: jeweiliger Preis pro Million Tokens.

Diese Formel beschreibt die Kosten moderner agentischer Systeme wesentlich besser als die einfache Unterscheidung zwischen Input und Output.

---

6. Warum „100 Millionen Tokens“ fast nichts über die Kosten aussagt

Angenommen, ein Coding Agent meldet für einen Arbeitstag:

Processed Tokens: 100'000'000

Die naheliegende Rechnung wäre:$$100 \times Preis\ pro\ Million\ Tokens$$

Diese Rechnung kann völlig falsch sein.

Entscheidend ist der Token Mix.

Beispielsweise:

Gesamt verarbeitet       100 Mio.

Cache Read                82 Mio.
Fresh Input               10 Mio.
Cache Write                3 Mio.
Output                     5 Mio.

Ein anderer Agent könnte ebenfalls 100 Millionen Tokens melden:

Gesamt verarbeitet       100 Mio.

Cache Read                20 Mio.
Fresh Input               35 Mio.
Cache Write                5 Mio.
Output                    40 Mio.

Beide Systeme haben nominell 100 Millionen Tokens verarbeitet.

Ihre Kosten können trotzdem um ein Vielfaches auseinanderliegen.

Der zweite Fall enthält wesentlich mehr neuen Input und vor allem wesentlich mehr Output.

Die Kennzahl

Total Tokens

ist deshalb für sich genommen keine brauchbare Kostenkennzahl.

Wesentlich aussagekräftiger ist:

Token Mix

also die Verteilung der Tokens auf ihre jeweiligen Abrechnungskategorien.

---

7. Ein Test kostet nicht deshalb Geld, weil er lange läuft

Bei Coding Agents entsteht eine weitere häufige Fehlinterpretation.

Angenommen, der Agent führt aus:

dotnet test

Die Tests benötigen drei Minuten.

Während dieser drei Minuten muss das Sprachmodell nicht zwangsläufig aktiv sein. Der Test Runner läuft als externes Werkzeug.

Die Laufzeit des Tests ist deshalb nicht automatisch LLM-Laufzeit.

Man muss zwischen zwei Dingen unterscheiden:

Tool Execution

Das Werkzeug selbst wird ausgeführt.

Beispiele:

dotnet build
dotnet test
git diff
grep
npm test
mvn test

Die Kosten dafür entstehen auf der Infrastruktur, auf der das Tool ausgeführt wird.

Bei einem lokalen Entwicklungsrechner sind die zusätzlichen direkten Kosten häufig vernachlässigbar.

Tool Observation

Anschließend erhält der Agent das Ergebnis des Tools.

Beispielsweise:

Agent
  │
  ├── dotnet test
  │
  ▼
Test Runner
  │
  ├── 8'000 Zeilen Ausgabe
  │
  ▼
Agent analysiert Ausgabe

Jetzt werden die Daten wieder für das Sprachmodell relevant.

Die 90 Sekunden Testlaufzeit sind für die Tokenrechnung weitgehend irrelevant.

Die 8’000 Zeilen Testoutput können dagegen relevant sein.

Das führt zu einer wichtigen Regel:

Nicht die Laufzeit eines Tools bestimmt primär die LLM-Kosten, sondern die Menge und Art der Informationen, die anschließend in den Modellkontext gelangen.

---

8. Warum Testing trotzdem teuer werden kann

Automatisiertes Testing ist ein zentraler Bestandteil agentischer Softwareentwicklung.

Ein typischer Zyklus sieht so aus:

Code ändern
    ↓
Tests ausführen
    ↓
Fehler analysieren
    ↓
Code ändern
    ↓
Tests erneut ausführen
    ↓
Fehler analysieren
    ↓
Code ändern

Die Tests selbst sind nicht das eigentliche Tokenproblem.

Problematisch können ihre Ergebnisse werden.

Ein kompakter Testreport:

Passed: 834
Failed: 2

FooServiceTests.ShouldReturnValue
Expected: 42
Actual: 41

ist günstig zu verarbeiten.

Ein Testsystem, das bei jedem Durchlauf mehrere Megabyte Logs erzeugt, kann dagegen erheblichen Kontext produzieren.

Dasselbe gilt für Builds.

Ein Compileroutput mit drei konkreten Fehlern ist etwas völlig anderes als ein Buildsystem, das tausende Warnungen und Diagnosemeldungen zurückliefert.

Für Coding Agents ist deshalb nicht nur die Qualität des Codes relevant.

Auch die Informationshygiene der Entwicklungswerkzeuge wird wirtschaftlich relevant.

---

9. Tool Output ist Teil der Agentenarchitektur

Traditionell betrachtet man ausführliche Logs häufig primär als Speicher- oder Usability-Problem.

Bei agentischer Entwicklung kommt eine weitere Dimension hinzu.

Wenn ein Coding Agent Tool-Ergebnisse verarbeitet, können unnötige Informationen direkt oder indirekt Kosten verursachen.

Das betrifft beispielsweise:

• Compilerlogs,
• Testlogs,
• CI-Ausgaben,
• Git-Diffs,
• statische Analyse,
• Datenbankresultate,
• Suchergebnisse,
• Browserinhalte,
• API-Antworten.

Ein Agent sollte deshalb nach Möglichkeit nicht blind zehn Megabyte Logdatei konsumieren, wenn die eigentliche Information in zwanzig Zeilen steckt.

Statt:

gesamte Logdatei
       ↓
      LLM

ist häufig sinnvoller:

Logdatei
   ↓
Filter / Search / Parser
   ↓
relevanter Ausschnitt
   ↓
LLM

Das reduziert nicht nur Kosten.

Es verbessert häufig auch das Signal-Rausch-Verhältnis für das Modell.

---

10. Context Compaction

Agentische Sitzungen können sehr lange dauern.

Der Kontext wächst währenddessen:

Aufgabe
  +
gelesene Dateien
  +
Entscheidungen
  +
Tool-Ergebnisse
  +
Codeänderungen
  +
Testergebnisse
  +
weitere Anweisungen

Irgendwann nähert sich dieser Kontext dem verfügbaren Context Window.

Ein möglicher Mechanismus dagegen ist Context Compaction.

Dabei wird älterer Kontext verdichtet.

Vereinfacht:

Lange Sitzung
     ↓
Kontext wächst
     ↓
Context Limit nähert sich
     ↓
Compaction
     ↓
verdichteter Kontext
     ↓
Sitzung wird fortgesetzt

Beispielsweise können viele ältere Nachrichten und Zwischenschritte durch eine kompaktere Zusammenfassung ersetzt werden.

Das reduziert den notwendigen Kontext.

Compaction besitzt allerdings eine zweite Dimension: Informationsverlust.

Aus:

50'000 Tokens detaillierter Verlauf

werden vielleicht:

5'000 Tokens Zusammenfassung

Die wesentlichen Entscheidungen können erhalten bleiben. Einzelheiten können verloren gehen.

Context Management ist deshalb nicht nur Kostenoptimierung, sondern Teil der Zuverlässigkeit eines Coding Agents.

---

11. Reasoning Effort und Thinking Budget

Moderne Modelle können neben der Kontextgröße unterschiedliche Mengen an Rechenaufwand für die eigentliche Problemlösung einsetzen.

Dafür existieren je nach Anbieter unterschiedliche Begriffe, beispielsweise:

• Reasoning Effort,
• Thinking Budget,
• Extended Thinking,
• Reasoning Tokens.

Das zugrunde liegende Konzept sollte nicht mit dem Context Window verwechselt werden.

Das Context Window beantwortet vereinfacht:

Wie viel Information kann das Modell berücksichtigen?

Das Reasoning Budget beantwortet eher:

Wie viel Verarbeitungsaufwand darf das Modell in die Lösung investieren?

Ein großes Context Window bedeutet deshalb nicht automatisch tiefes Reasoning.

Und ein hohes Reasoning Budget bedeutet nicht, dass automatisch mehr Projektdateien in den Kontext passen.

Beides sind unterschiedliche Dimensionen eines Modells.

---

12. Warum Output besonders wichtig ist

Bei vielen kommerziellen Modellen ist erzeugter Output teurer als Input.

Eine typische Preisrelation sieht abstrakt ungefähr so aus:$$P_{output} > P_{fresh-input} > P_{cache-read}$$

Die konkreten Verhältnisse unterscheiden sich nach Anbieter und Modell.

Für die Kostenanalyse ist die Konsequenz wichtiger als der jeweilige Preis:

Ein Agent, der sehr viel Kontext wiederverwendet und relativ kompakte Ergebnisse erzeugt, besitzt ein anderes Kostenprofil als ein Agent, der große Mengen neuer Tokens generiert.

Deshalb ist diese Information:

Der Agent hat 50 Millionen Tokens verarbeitet.

weniger nützlich als:

Fresh Input:   4 Mio.
Cache Read:   42 Mio.
Cache Write:   1 Mio.
Output:        3 Mio.

---

13. Warum acht Stunden Coding keinen festen Preis haben

Damit lässt sich die Ausgangsfrage beantworten.

Was kostet ein achtstündiger Arbeitstag mit einem Coding Agent?

Es gibt keinen festen Preis pro Stunde, solange der Dienst nicht ausdrücklich zeitbasiert abgerechnet wird.

Die menschliche Arbeitszeit und die Modellnutzung sind unterschiedliche Größen.

Ein Entwickler könnte acht Stunden lang hauptsächlich:

• Architektur diskutieren,
• kleine Änderungen durchführen,
• gezielt Dateien öffnen,
• kurze Tests ausführen.

Ein anderer könnte im gleichen Zeitraum:

• mehrere große Refactorings durchführen,
• tausende Dateien durchsuchen,
• Integrationstests ausführen,
• große Logs analysieren,
• lange autonome Agent-Loops laufen lassen.

Beide arbeiten acht Stunden.

Die Tokenkosten können völlig unterschiedlich sein.

Mathematisch gilt deshalb nicht:$$Kosten = Arbeitsstunden \times LLM-Stundensatz$$

sondern:$$Kosten = \sum_{i=1}^{n} Kosten(Inference_i)$$

Die Arbeitszeit beeinflusst lediglich indirekt, wie viele Aufgaben und Inferenzzyklen innerhalb dieser Zeit stattfinden.

---

14. Parallel arbeitende Agents verschärfen diesen Effekt

Agentische Softwareentwicklung löst die Verbindung zwischen menschlicher Arbeitszeit und Maschinenarbeitszeit noch weiter auf.

Ein Entwickler kann mehrere Agents parallel einsetzen:

                 Entwickler
                     │
          ┌──────────┼──────────┐
          ▼          ▼          ▼
       Agent A    Agent B    Agent C
       Feature      Tests     Analyse

Der Entwickler arbeitet weiterhin acht Stunden.

Innerhalb dieser acht Stunden können aber mehrere Agenten gleichzeitig:

• Dateien lesen,
• Code erzeugen,
• Tests ausführen,
• Fehler analysieren,
• Dokumentation untersuchen.

Acht Stunden menschliche Arbeit bedeuten damit nicht mehr zwangsläufig acht Stunden sequenzielle Maschinenarbeit.

Das macht eine Kennzahl wie „KI-Kosten pro Entwicklerstunde“ zwar für Budgetierung brauchbar, technisch aber unpräzise.

---

15. Cost per Task ist häufig die bessere Kennzahl

Für Software Engineering ist der Preis einer Million Tokens letztlich nur eine technische Eingangsgröße.

Wirtschaftlich interessanter ist:$$Cost\ per\ Task = \frac{LLM-Kosten}{abgeschlossene\ Aufgaben}$$

Je nach Organisation können konkretere Kennzahlen sinnvoll sein:$$Cost\ per\ Feature$$$$Cost\ per\ Bugfix$$$$Cost\ per\ Pull\ Request$$$$Cost\ per\ Migration$$

Dadurch wird auch sichtbar, warum der günstigste Tokenpreis nicht automatisch das günstigste Modell ergibt.

Angenommen:

Modell A

Kosten pro Lösungsversuch: 2
Benötigte Versuche:        5

Gesamtkosten:             10

und:

Modell B

Kosten pro Lösungsversuch: 5
Benötigte Versuche:        1

Gesamtkosten:              5

Modell B ist pro Inferenz deutlich teurer.

Für die Aufgabe ist es trotzdem günstiger.

Noch wichtiger: Die fünf Fehlversuche von Modell A können zusätzlich menschliche Arbeitszeit verbrauchen.

Damit wird aus einer reinen Tokenrechnung eine Engineering-Rechnung.

---

16. Tokenpreis ist nicht gleich Entwicklungskosten

Die vollständige Betrachtung umfasst mehr als LLM-Tokens.

Für eine einzelne Aufgabe kann man zunächst schreiben:$$C_{Task} = C_{LLM} + C_{Tools} + C_{Infrastructure}$$

Für die tatsächliche Softwareentwicklung kommt die menschliche Arbeitszeit hinzu:$$C_{Engineering} = C_{Human} + C_{LLM} + C_{Tools} + C_{Infrastructure}$$

Diese Gleichung verändert die wirtschaftliche Bewertung erheblich.

Angenommen, ein stärkeres Modell kostet für eine Aufgabe fünf Dollar mehr, spart einem Entwickler aber zwanzig Minuten Arbeit.

Dann ist die Frage nicht:

Welches Modell verbraucht weniger Geld?

Sondern:

Welche Variante erzeugt das gewünschte Ergebnis mit den niedrigsten Gesamtkosten und der erforderlichen Qualität?

Bei professioneller Softwareentwicklung sind Lohnkosten häufig wesentlich größer als die reinen Inferenzkosten.

Eine isolierte Optimierung auf möglichst wenige Tokens kann deshalb wirtschaftlich kontraproduktiv sein.

---

17. Qualität gehört ebenfalls in die Rechnung

Selbst Cost per Task reicht nicht immer aus.

Ein Agent kann eine Aufgabe formal abschließen und trotzdem schlechte Software erzeugen.

Beispielsweise:

• fehlende Tests,
• falsche Architektur,
• unnötige Komplexität,
• Sicherheitsprobleme,
• schlechte Wartbarkeit,
• versteckte Regressionen,
• unzureichende Dokumentation.

Damit benötigt die wirtschaftliche Betrachtung eigentlich eine Qualitätsdimension.

Zwei Lösungen für fünf Dollar sind nicht gleichwertig, wenn die eine später mehrere Stunden Nacharbeit verursacht.

Eine sinnvollere Betrachtung lautet deshalb:$$Effizienz = \frac{brauchbares\ Ergebnis}{Gesamtaufwand}$$

„Brauchbar“ muss dabei im Software Engineering mehr bedeuten als „kompiliert“.

---

18. Was man bei einem Coding Agent tatsächlich messen sollte

Eine brauchbare Kostenanalyse sollte mindestens folgende Größen auseinanderhalten:

Kennzahl	Aussage
Fresh Input Tokens	tatsächlich neuer Modellinput
Cache Read Tokens	wiederverwendeter Kontext
Cache Write Tokens	neu gecachter Kontext
Output Tokens	neu erzeugte Modellinformationen
Inferences	Anzahl der Modellaufrufe
Tool Calls	Anzahl externer Aktionen
Tool Output	Menge zurückgelieferter Werkzeugdaten
Compactions	Verdichtungen langer Kontexte
Cost per Task	Kosten einer abgeschlossenen Aufgabe
Human Intervention	notwendige Eingriffe des Entwicklers
Retries	Wiederholungsversuche bis zur Lösung

Erst diese Kombination beschreibt halbwegs zuverlässig, was ein agentischer Workflow tatsächlich kostet.

---

19. Ein allgemeines Kostenmodell

Für die reinen Modellkosten lässt sich ein anbieterneutrales Modell formulieren:$$C_{LLM} = \frac{ T_fP_f + T_wP_w + T_rP_r + T_oP_o }{1\,000\,000}$$

mit:

Variable	Bedeutung
$T_f$	Fresh Input Tokens
$P_f$	Preis für Fresh Input
$T_w$	Cache Write Tokens
$P_w$	Preis für Cache Writes
$T_r$	Cache Read Tokens
$P_r$	Preis für Cache Reads
$T_o$	Output Tokens
$P_o$	Preis für Output

Für einen gesamten Arbeitstag werden die einzelnen Inferenzschritte addiert:$$C_{Day} = \sum_{i=1}^{n} C_{LLM,i}$$

Werden zusätzlich externe Dienste verwendet:$$C_{Technical} = C_{LLM} + C_{Compute} + C_{ExternalTools}$$

Und für eine vollständige wirtschaftliche Betrachtung:$$C_{Engineering} = C_{Human} + C_{Technical}$$

Dieses Modell bleibt gültig, auch wenn sich konkrete Modelle, Anbieter und Preise ändern.

---

20. Ein hypothetisches Rechenbeispiel

Angenommen, ein intensiver agentischer Arbeitstag erzeugt folgenden Token Mix:

Fresh Input:     8 Mio.
Cache Write:     3 Mio.
Cache Read:     70 Mio.
Output:          5 Mio.

Insgesamt wurden damit:$$8 + 3 + 70 + 5 = 86\ Millionen\ Tokens$$

verarbeitet.

Angenommen, ein fiktiver Anbieter verlangt:

Fresh Input:   2.00 pro Mio.
Cache Write:   2.50 pro Mio.
Cache Read:    0.20 pro Mio.
Output:       10.00 pro Mio.

Dann ergibt sich:$$8 \times 2.00 = 16.00$$$$3 \times 2.50 = 7.50$$$$70 \times 0.20 = 14.00$$$$5 \times 10.00 = 50.00$$

Gesamt:$$C = 16 + 7.50 + 14 + 50$$$$C = 87.50$$

Das Beispiel zeigt gleichzeitig, warum die Gesamtzahl der Tokens irreführend sein kann.

70 der insgesamt 86 Millionen Tokens stammen aus dem Cache. Obwohl sie mehr als 80 Prozent des gesamten Tokenvolumens ausmachen, verursachen sie in diesem Beispiel nur einen kleinen Teil der Gesamtkosten.

Der Output umfasst dagegen nur rund sechs Prozent des Tokenvolumens, verursacht aber mehr als die Hälfte der Rechnung.

Der Token Mix ist damit wesentlich wichtiger als die bloße Tokenmenge.

---

21. Kostenoptimierung bedeutet nicht, möglichst wenig Kontext zu verwenden

Aus der Kostenstruktur könnte man eine falsche Schlussfolgerung ziehen:

Weniger Tokens sind immer besser.

Das stimmt nicht.

Ein Agent benötigt ausreichend Kontext, um korrekte Entscheidungen zu treffen.

Wer relevante Architekturinformationen, Tests oder Schnittstellendefinitionen entfernt, kann zwar einzelne Inferenzschritte billiger machen. Wenn das Modell dadurch häufiger Fehler produziert, entstehen zusätzliche Agentic Loops.

Dann wird aus:

genügend Kontext
     ↓
eine korrekte Änderung

möglicherweise:

zu wenig Kontext
     ↓
falsche Änderung
     ↓
Buildfehler
     ↓
Analyse
     ↓
zweite Änderung
     ↓
Testfehler
     ↓
Analyse
     ↓
dritte Änderung

Die billigste Inferenz ist nicht zwangsläufig der billigste Workflow.

Das Ziel lautet deshalb nicht:

Tokenverbrauch minimieren.

Sondern:

Unnötigen Tokenverbrauch minimieren, ohne entscheidungsrelevanten Kontext zu verlieren.

---

22. Gute Engineering-Praktiken werden zu Kostenoptimierungen

Interessanterweise sind viele sinnvolle Maßnahmen zur Reduktion von Agentenkosten keine speziellen KI-Tricks.

Es sind klassische Engineering-Praktiken.

Ein sauber strukturiertes Repository erleichtert die gezielte Navigation.

Klare Modulgrenzen reduzieren die Menge des notwendigen Kontextes.

Kleine Dateien lassen sich gezielter laden als gigantische God Classes.

Präzise Tests liefern bessere Fehlersignale.

Strukturierte Logs reduzieren Rauschen.

Gute Fehlermeldungen verhindern unnötige Diagnosezyklen.

Eine dokumentierte Architektur reduziert wiederholte Exploration.

Deterministische Builds verhindern sinnlose Wiederholungsversuche.

Ein schneller Testzyklus ermöglicht gezieltere Validierung.

Agentische Entwicklung verstärkt damit den wirtschaftlichen Wert guter Softwarearchitektur.

Eine Codebasis, die für Menschen schwer zu verstehen ist, ist häufig auch für einen Agenten teuer zu verstehen.

---

23. Lokale Modelle ändern die Abrechnung, nicht die Grundprinzipien

Bei einem lokalen Modell gibt es möglicherweise keinen Preis pro Token.

Die Kosten verschwinden dadurch jedoch nicht.

Statt API-Kosten entstehen unter anderem:

• Anschaffungskosten für Hardware,
• Stromverbrauch,
• GPU-Zeit,
• Wartung,
• Speicher,
• Infrastruktur,
• Opportunitätskosten der Hardware.

Das Kostenmodell verschiebt sich damit von:$$Tokens \times API-Preis$$

in Richtung:$$Hardware + Energie + Betrieb + Zeit$$

Die grundlegenden technischen Konzepte bleiben jedoch relevant.

Auch ein lokaler Coding Agent profitiert von:

• effizientem Kontext,
• kleinen Tool-Ergebnissen,
• guten Tests,
• gezielter Dateiauswahl,
• kurzen Agentic Loops.

Ineffizienter Kontext kostet lokal vielleicht keine zusätzlichen API-Dollar, dafür aber Rechenzeit und Durchsatz.

---

24. Die eigentliche Einheit ist nicht der Token

Tokens sind die technische Abrechnungseinheit vieler Anbieter.

Für Software Engineering sind sie aber nicht die eigentliche wirtschaftliche Einheit.

Entscheidend ist das Ergebnis.

Ein Unternehmen kauft keine Tokens, weil es Tokens besitzen möchte. Es bezahlt für eine technische Fähigkeit, mit der Software schneller oder besser entwickelt werden soll.

Deshalb führt die Betrachtung zwangsläufig von:

Cost per Token

über:

Cost per Inference

und:

Cost per Task

hin zu:

Cost per useful engineering outcome

Erst auf dieser Ebene lassen sich unterschiedliche Modelle, Agenten und Entwicklungsprozesse sinnvoll miteinander vergleichen.

---

Glossar

Agent

Ein Softwaresystem, das ein Sprachmodell mit Werkzeugen und einem Ablauf zur selbstständigen Bearbeitung von Aufgaben kombiniert.

---

Agentic Loop

Iterativer Ablauf eines Agenten aus Analyse, Aktion, Beobachtung des Ergebnisses und erneuter Analyse.

Vereinfacht:$$Reasoning \rightarrow Action \rightarrow Observation$$

---

Cache Read

Wiederverwendung bereits gecachten Prompt- oder Kontextinhalts. Kann abhängig vom Anbieter günstiger abgerechnet werden als neuer Input.

---

Cache Write

Aufnahme von Kontext in einen Prompt Cache zur späteren Wiederverwendung.

---

Context Compaction

Verdichtung eines langen Arbeitskontextes, damit eine Sitzung innerhalb des verfügbaren Context Windows fortgesetzt werden kann.

---

Context Window

Maximale Anzahl Tokens, die ein Modell innerhalb eines Inferenzschritts berücksichtigen kann.

---

Cost per Task

Gesamtkosten, die für die Bearbeitung einer abgeschlossenen Aufgabe entstehen.

---

Fresh Input

Input Tokens, die neu verarbeitet werden und nicht aus einem wiederverwendbaren Prompt Cache stammen.

---

Inference

Ein einzelner Ausführungsvorgang eines Sprachmodells: Kontext wird übergeben und das Modell erzeugt daraus eine Ausgabe.

---

Input Token

Token, das dem Modell als Teil seines Eingabekontexts übergeben wird.

---

LLM

Large Language Model. Ein Sprachmodell, das auf großen Datenmengen trainiert wurde und unter anderem natürliche Sprache und Quellcode verarbeiten und erzeugen kann.

---

Output Token

Token, das vom Modell neu erzeugt wird.

---

Prompt Cache

Mechanismus zur Wiederverwendung bereits verarbeiteter Teile eines Prompts oder Kontextes.

---

Reasoning Effort

Konfigurierbarer oder modellabhängiger Aufwand, den ein Reasoning-Modell für die Bearbeitung einer Aufgabe einsetzen kann.

---

Reasoning Token

Token beziehungsweise interne Verarbeitungseinheit, die bei bestimmten Modellarchitekturen oder Abrechnungsmodellen mit dem Reasoning-Prozess verbunden ist. Die genaue technische und kommerzielle Bedeutung ist anbieterspezifisch.

---

Thinking Budget

Begrenzung oder Steuerung des Rechen- beziehungsweise Reasoning-Aufwands eines Modells. Der konkrete Mechanismus unterscheidet sich zwischen Modellen und Anbietern.

---

Token

Verarbeitungseinheit eines Sprachmodells. Tokens entsprechen nicht exakt Wörtern oder Zeichen.

---

Token Mix

Verteilung des gesamten Tokenverbrauchs auf unterschiedliche Kategorien wie Fresh Input, Cache Read, Cache Write und Output.

---

Tool Call

Vom Agenten ausgelöster Aufruf eines externen Werkzeugs, beispielsweise eines Compilers, Test Runners, Terminals oder einer Suchfunktion.

---

Tool Execution

Tatsächliche Ausführung eines vom Agenten aufgerufenen Werkzeugs.

---

Tool Observation

Verarbeitung des Ergebnisses eines Tool Calls durch den Agenten beziehungsweise das zugrunde liegende Sprachmodell.

---

Fazit

Die Frage „Was kostet ein Coding Agent für acht Stunden Softwareentwicklung?“ besitzt keine allgemeingültige Antwort.

Zeit ist bei tokenbasierter Abrechnung nicht die primäre Einheit. Entscheidend sind die Inferenzschritte und deren Token Mix.

Die grundlegende Kostenstruktur lautet:$$Fresh\ Input + Cache\ Writes + Cache\ Reads + Output$$

Darüber liegt die agentische Struktur:$$Reasoning \rightarrow Action \rightarrow Observation \rightarrow Reasoning$$

Und darüber liegt schließlich die für Software Engineering relevante wirtschaftliche Betrachtung:$$C_{Engineering} = C_{Human} + C_{LLM} + C_{Tools} + C_{Infrastructure}$$

Millionen verarbeiteter Tokens können deshalb günstig oder teuer sein. Acht Stunden Agentennutzung können wenig oder viel kosten. Ein Modell mit höherem Tokenpreis kann für eine konkrete Aufgabe wirtschaftlicher sein als ein günstigeres Modell.

Die entscheidende Frage lautet nicht, wie viele Tokens ein Coding Agent verbraucht.

Die entscheidende Frage lautet, welchen Engineering-Aufwand er benötigt, um ein brauchbares Ergebnis zu erzeugen.