Woher deine LLM-Token-Rechnung wirklich kommt

Die kurze Antwort: Die Token-Rechnung eines Agenten hat fünf Posten. Den System-Prompt, die Tool-Schemas, den Gesprächsverlauf, den Kontext, den er neu aufbaut, weil er vergessen hat, und die Retries. Die meisten Spar-Ratschläge greifen den ersten Posten an, der meist der kleinste ist. Die Rechnung lebt in den anderen vier, und zwei davon wachsen strukturell mit deinem Setup.

Schlüsseln wir sie auf wie eine Rechnung, denn sobald du die Posten siehst, wählen sich die Fixes von selbst.

Die fünf Posten

Der System-Prompt. Deine Anweisungen, Persona, Regeln. Ein paar hundert bis ein paar tausend Tokens, gesendet bei jedem Request. Es ist der Posten, den alle zuerst optimieren, weil er der sichtbare ist. Kürzen hilft, ein bisschen, einmal.

Tool-Schemas. Jeder verbundene MCP-Server liefert Definitionen seiner Tools, und das Modell hält sie alle im Kontext, um zu wissen, was es aufrufen kann. Ein Schema kostet grob 200 bis 500 Tokens. Das ist eine Standgebühr: bezahlt bei jedem Schritt, ob ein Tool aufgerufen wird oder nicht, und sie wächst mit jedem verbundenen Server. Wir nennen das die Context Tax, und sie hat [einen eigenen Artikel](/de/blog/the-context-tax) verdient.

Gesprächsverlauf. Agenten-Schleifen senden das Transkript bei jedem Schritt neu. Schritt zwanzig trägt die Schritte eins bis neunzehn, inklusive jedes Tool-Ergebnisses unterwegs. Deshalb kosten lange Agenten-Läufe überproportional mehr, als ihre Länge vermuten lässt: Jeder neue Schritt bezahlt alle alten noch einmal.

Neu aufgebauter Kontext. Der leise Posten. Jede neue Session rekonstruiert der Agent, was er gestern wusste: Dateien neu lesen, Datensätze neu holen, dich neu nach dem Projekt-Hintergrund fragen. Nichts davon produziert neue Arbeit. Es reproduziert altes Wissen, zum vollen Preis, weil das Verständnis der letzten Session gelöscht wurde.

Retries und Sackgassen. Ein gescheiterter Tool-Aufruf, ein falscher Pfad, ein kaputtes Output-Format, das einen zweiten Versuch braucht. Jeder spielt eine volle Kontext-Ladung neu ab. Einzeln billig, in Summe real.

Ein durchgerechnetes Beispiel, damit die Form sichtbar wird

Nimm eine bescheidene Agenten-Session: 1.500 Tokens System-Prompt, sechs verbundene Server mit 90 Tools bei 350 Tokens pro Schema (31.500 Tokens) und 20 Schritte Arbeit.

Allein die Schemas steuern 31.500 Tokens zum Input jedes Schritts bei. Über 20 Schritte sind das 630.000 Input-Tokens für Tool-Definitionen, noch vor dem eigentlichen Gespräch. Dazu ein Verlauf, der um, sagen wir, 1.000 Tokens pro Schritt wächst: Die Schritte 1 bis 20 tragen im Schnitt rund 10.000 Tokens Transkript, weitere 200.000. Der System-Prompt, 20-mal gesendet: 30.000.

Und jetzt die Zahl, die niemand budgetiert: Wenn die ersten zehn Minuten der Session daraus bestanden, dass der Agent das Repo neu liest und die Entscheidungen von letzter Woche neu herleitet, war alles in diesem Abschnitt (die Abrufe, die Zusammenfassungen, das Hin und Her) neu aufgebauter Kontext. In langlaufenden Projekten ist dieser Abschnitt routinemäßig der größte Posten der Session, und er wiederholt sich jede Session.

Prompt-Caching, wo verfügbar, rabattiert wiederholte Präfixe wie Schemas und System-Prompts, und das hilft wirklich. Aber gecachte Tokens belegen weiter das Kontextfenster, der Rabatt verschwindet, sobald sich die Tool-Liste ändert, und gegen neu aufgebauten Kontext tut Caching nichts, denn dieser Inhalt wird jedes Mal frisch erzeugt.

Welche Posten wachsen, und welche Fixes die Rechnung bewegen

Der System-Prompt ist flach. Der Verlauf wächst mit der Session-Länge. Aber zwei Posten wachsen mit dem Setup selbst, und das sind die strukturellen:

• Tool-Schemas wachsen mit jedem verbundenen Server. Der Fix ist weniger pro Schritt laden: weniger Server pro Projekt, beschneiden, was lädt, oder ein Gateway davor, das Server bündelt und Tools bei Bedarf bereitstellt. Die Taktiken stehen gesammelt in [MCP-Token-Verbrauch senken](/de/blog/reduce-mcp-token-usage).
• Neu aufgebauter Kontext wächst damit, wie viel dein Agent vergessen darf. Der Fix ist Memory: Entscheidungen, IDs und Projekt-Fakten einmal speichern, nächste Session abrufen und von einer destillierten Zusammenfassung starten statt vom vollen Neuaufbau. Warum Vergessen direkt auf Ausgaben abbildet, ist das Argument [unseres Essays über Agenten, die ständig vergessen](/de/blog/agents-keep-forgetting-token-bill-pays-for-it).

Wir bauen bei Tulimoa ein Gateway mit Memory-Schicht, neutral sind wir hier also nicht, und eine erfundene Prozentzahl geben wir dir auch nicht. Was wir dir geben können, ist die Audit-Methode: Deine eigene Rechnung, aufgeschlüsselt gegen diese fünf Posten, sagt dir binnen einer Stunde, welcher Posten dich frisst.

Häufige Fragen

Was verbraucht in einem Agenten-Setup die meisten Tokens?

Es hängt vom Setup ab, aber die zwei chronisch unterschätzten Posten sind Tool-Schemas (eine Standgebühr pro Schritt, die mit verbundenen Servern skaliert) und neu aufgebauter Kontext (das Wissen von gestern jede Session rekonstruieren). Der Gesprächsverlauf dominiert nur in sehr langen Einzel-Sessions.

Löst Prompt-Caching das Token-Kosten-Problem?

Es dämpft es. Caching rabattiert wiederholte Präfixe wie Schemas und System-Prompts, aber gecachter Inhalt füllt weiter das Kontextfenster, der Cache bricht, wenn sich die Tool-Liste ändert, und frisch neu hergeleiteter Kontext ist nie gecacht. Strukturelle Fixes bleiben wichtig.

Wie finde ich heraus, wohin meine eigene Token-Rechnung geht?

Protokolliere eine repräsentative Session und ordne jedes Input-Stück einem der fünf Posten zu: System-Prompt, Schemas, Verlauf, neu aufgebauter Kontext, Retries. Die meisten Anbieter zeigen Token-Zahlen pro Request, die Arithmetik ist ein Nachmittag, und das Ergebnis überrascht das Team fast immer.