Wer KI-Funktionen in Webprojekte oder interne Werkzeuge einbaut, kalkuliert früher oder später mit Tokens. Ein Token ist die kleinste Abrechnungseinheit von Sprachmodellen – ungefähr ein Wortteil, den das Modell liest oder schreibt. Diese Einheit ist über die letzten Monate zur zentralen Kostengröße geworden, und die Verteilung dahinter hat sich verschoben.

Laut einer Analyse des OpenRouter-Analysten Peter Walker verbrauchen KI-Agenten seit dem 6. Februar 2025 mehr Tokens als menschliche Nutzung. Der Anstieg beim Agentenverbrauch lag dabei beim Vierzehnfachen, während die menschliche Nutzung sich auf das 2,8-Fache erhöhte. Die Software ist damit selbst zum größten Abnehmer der Modelle geworden.

Warum Agenten so viel mehr verbrauchen

Der Grund liegt in der Arbeitsweise. Ein Mensch stellt eine Frage, liest die Antwort und stellt vielleicht eine Rückfrage. Ein Agent – also ein Programm, das eine Aufgabe in mehreren Schritten selbstständig abarbeitet – macht daraus eine Kette: Kontext einlesen, Plan entwerfen, Werkzeug aufrufen, Ergebnis prüfen, korrigieren, erneut prüfen.

Jeder dieser Schritte trägt den bisherigen Kontext mit. Dateien, Vorgaben, Zwischenergebnisse und Fehlermeldungen wandern immer wieder mit in den Prompt. Aus einer Aufgabe, die ein Mensch mit zwei Anfragen erledigt, werden so zwanzig oder mehr Modellaufrufe mit jeweils erheblichem Vorlauf. In der Softwareentwicklung fällt das besonders auf, weil dort Codebasen, Testausgaben und Logs als Kontext gebraucht werden.

Die Rechnung wächst langsamer als die Zahl

Entscheidend für Budgets ist ein zweiter Befund der Analyse: Fast 70 Prozent des Agentenverbrauchs entfallen auf gecachte Prompts, die günstiger abgerechnet werden. Prompt-Caching bedeutet, dass ein gleichbleibender Teil der Eingabe – etwa Systemanweisungen oder eine Projektdatei – beim Anbieter vorgehalten und bei erneuter Verwendung nicht zum vollen Preis berechnet wird.

Die realen Kosten steigen dadurch deutlich langsamer als die Token-Zahlen. Für die Budgetplanung heißt das zweierlei: Erstens ist eine Hochrechnung allein über die Token-Menge irreführend und führt zu unnötig hohen Puffern. Zweitens ist der Cache-Anteil kein Naturgesetz, sondern eine Eigenschaft der Architektur. Wer ihn nicht bewusst herstellt, zahlt für jeden Durchlauf den vollen Preis.

Woran sich der Cache-Anteil entscheidet

Caching greift dort, wo Eingaben stabil und wiedererkennbar sind. Das lässt sich beim Bau einer Anwendung beeinflussen:

  • Stabile Präfixe: Systemanweisungen, Rollenbeschreibungen und wiederkehrende Referenzdaten gehören an den Anfang des Prompts und sollten sich zwischen zwei Aufrufen nicht ändern.
  • Variables nach hinten: Zeitstempel, Nutzerkennungen oder wechselnde Parameter am Prompt-Anfang zerstören die Wiederverwendbarkeit des gesamten Kontexts.
  • Kontext bewusst schneiden: Nicht die vollständige Historie mitschleppen, sondern gezielt zusammenfassen oder nur relevante Ausschnitte nachladen.
  • Modellwahl nach Aufgabe: Routinehafte Zwischenschritte wie Klassifizieren oder Formatieren brauchen selten das teuerste Modell.
  • Abbruchkriterien: Agenten, die ohne Obergrenze an Iterationen arbeiten, drehen im Zweifelsfall Schleifen. Ein Limit für Schritte und Ausgaben pro Aufgabe ist eine Kostenmaßnahme.

Konsequenzen für Angebote und Verträge

Die Verschiebung vom menschlichen zum maschinellen Verbrauch verändert, wie Kosten in Projekten auftreten. Bei interaktiver Nutzung skalieren Ausgaben mit der Zahl der Nutzerinnen und Nutzer, also relativ berechenbar. Bei agentischen Workflows skalieren sie mit der Zahl der verarbeiteten Vorgänge und mit der Komplexität jedes einzelnen Vorgangs – und beides lässt sich vorab schlechter abschätzen.

Sinnvoll ist deshalb, laufende Modellkosten von Anfang an als eigene Position zu behandeln, getrennt von Entwicklungsaufwand und Hosting. Dazu gehört eine Messung im Betrieb: Kosten pro erledigter Aufgabe, Cache-Trefferquote, Anteil der Aufrufe, die keinen verwertbaren Beitrag geliefert haben. Ohne diese Kennzahlen bleibt jede Optimierung Vermutung.

Für Pilotprojekte hat sich bewährt, zunächst einen abgegrenzten Anwendungsfall mit realen Daten zu vermessen, statt aus Benchmarks zu extrapolieren. Ein Durchlauf über einige hundert echte Vorgänge liefert eine belastbarere Grundlage als jede Modellrechnung – und zeigt meist auch, an welcher Stelle der Kontext unnötig groß ist.

Nicht jede Aufgabe braucht einen Agenten

Die Zahlen laden dazu ein, agentische Architekturen als Standard zu betrachten. Das greift zu kurz. Ein einzelner, gut formulierter Modellaufruf mit klarer Ausgabestruktur ist für viele Aufgaben günstiger, schneller und leichter zu testen als eine mehrstufige Schleife. Agenten lohnen sich dort, wo der Lösungsweg vorab nicht bekannt ist und Werkzeuge eingebunden werden müssen.

Umgekehrt gilt: Wo der Weg bekannt ist, gehört er in Code. Klassische Programmlogik verbraucht keine Tokens, ist deterministisch und lässt sich mit gewöhnlichen Tests absichern. Die interessante Frage in Projekten ist deshalb weniger, wie viele Tokens ein Agent verbraucht, sondern welche Teilschritte überhaupt ein Sprachmodell benötigen.

Einordnung

Für Web- und Softwareprojekte bedeutet die Entwicklung, dass Modellkosten von einem Nebenposten zu einer eigenen Planungsgröße mit Betriebscharakter werden – vergleichbar mit Traffic oder Rechenzeit, nur schwerer vorhersagbar. Wer Prompt-Struktur, Kontextgröße und Abbruchkriterien früh als Architekturentscheidungen behandelt, hält den Unterschied zwischen Token-Menge und tatsächlicher Rechnung groß. Und wer den Verbrauch pro Vorgang messbar macht, kann Budgets verhandeln, statt sie zu schätzen.

Quellen