4. Tokens, Kontextfenster und Kosten

Tokens, Kontextfenster und Kosten

Sprachmodelle rechnen nicht in Zeichen und nicht in Wörtern, sondern in Tokens. An dieser Einheit hängen drei Größen zugleich: der Preis einer Anfrage, die Textmenge, die ein Modell in einem Aufruf verarbeiten kann, und die Antwortqualität in langen Sitzungen.

Das Kapitel behandelt, wie Text in Tokens zerlegt wird, was alles in das Kontextfenster zählt, wie sich die Kosten über eine mehrstufige Unterhaltung entwickeln und mit welchen Verfahren sich das steuern lässt: Prompt Caching, Compaction und die bewusste Auswahl dessen, was im Kontext steht.

Was ein Token ist

Ein Modell sieht keine Buchstaben und keine Wörter, es sieht Tokens: Zeichenstücke aus einem festen Vokabular von typischerweise 50.000 bis 200.000 Einträgen. Das Verfahren, das den Text zerlegt, heißt Tokenizer und arbeitet meist nach dem Prinzip Byte Pair Encoding: Häufige Zeichenfolgen werden zu einem Token zusammengefasst, seltene in mehrere zerlegt.

"Der Server antwortet"     ->  ["Der", " Server", " antwort", "et"]
"unauthenticated"          ->  ["un", "authent", "icated"]
"Benutzerverwaltung"       ->  ["Ben", "utzer", "verwalt", "ung"]
"const x = 42;"            ->  ["const", " x", " =", " ", "42", ";"]

Drei Beobachtungen daran:

• Häufige englische Wörter sind oft ein einziges Token, das Leerzeichen davor eingeschlossen.
• Deutsch ist teurer als Englisch. Zusammensetzungen und Umlaute zerfallen in mehr Stücke. Derselbe Inhalt braucht auf Deutsch grob 30 bis 50 Prozent mehr Tokens.
• Code hat sein eigenes Muster: Schlüsselwörter sind ein Token, Einrückung und Zeichenketten fressen überraschend viele.

Als Faustregel für Schätzungen: rund 4 Zeichen pro Token für englischen Prosatext, etwa 3 für deutschen, weniger für Code. Ein Token entspricht im Englischen etwa 0,75 Wörtern.

Nicht mit dem falschen Werkzeug zählen

Für belastbare Zahlen zählen Sie mit dem Tokenizer des Modells, das Sie tatsächlich verwenden. Jeder Modellhersteller hat einen eigenen, und mehrere Anbieter stellen dafür einen Endpunkt bereit (bei Anthropic etwa count_tokens). Ein Zähler eines anderen Anbieters liefert für Claude-Modelle systematisch falsche Werte, bei Code und bei Deutsch besonders deutlich. Tokenizer wechseln außerdem zwischen Modellgenerationen: Zahlen, die Sie letztes Jahr gemessen haben, sind kein Maßstab für das aktuelle Modell.

Das Kontextfenster ist ein Budget

Das Kontextfenster ist die maximale Anzahl Tokens, die ein Modell in einem Aufruf verarbeiten kann: System-Prompt, gesamte Unterhaltung, eingelesene Dateien, Werkzeugbeschreibungen, Werkzeugergebnisse und die zu erzeugende Antwort, alles zusammen. Zusätzlich gibt es eine getrennte Obergrenze für die Ausgabe.

Zur Größenordnung, Stand Sommer 2026: Aktuelle Spitzenmodelle liegen bei etwa einer Million Tokens Kontext und rund 128.000 Tokens Ausgabe; kleinere und ältere Modelle bei 200.000 oder deutlich weniger. Eine Million Tokens sind grob 3.000 bis 4.000 Seiten Text, oder eine mittelgroße Codebasis vollständig.

Das klingt nach so viel, dass man nicht darüber nachdenken müsste. Zwei Effekte sorgen dafür, dass man es doch muss.

Erstens füllt sich das Fenster schneller als man denkt. Eine Agentensitzung, die eine Stunde arbeitet, liest dutzende Dateien und erzeugt hunderte Werkzeugergebnisse. Jedes davon bleibt im Kontext.

Was	Grobe Größe in Tokens
Diese Seite als Text	~4.000
Eine mittlere Quelldatei (300 Zeilen)	~3.000 bis 5.000
Ausgabe von npm install	~1.000 bis 3.000
Ein Stacktrace	~500 bis 2.000
Eine package-lock.json	50.000 und mehr
Werkzeugbeschreibungen eines Agenten	2.000 bis 20.000

Zweitens ist ein voller Kontext nicht so gut wie ein leerer. Die Grenze ist eine technische Zusage, kein Qualitätsversprechen. In langen Kontexten sinkt die Treffsicherheit messbar, besonders für Information in der Mitte. Der praktische Rat lautet deshalb: Ein Kontextfenster ist ein Budget, das man verwaltet, und kein Lagerraum, den man füllt.

Kosten

Abgerechnet wird pro Token, getrennt nach Eingabe und Ausgabe. Ausgabe ist deutlich teurer, meist um den Faktor vier bis fünf, weil sie Token für Token erzeugt werden muss, während die Eingabe in einem Durchgang verarbeitet wird.

Ein Rechenbeispiel mit den Listenpreisen eines Spitzenmodells im Sommer 2026, 5 USD pro Million Eingabe-Tokens und 25 USD pro Million Ausgabe-Tokens:

Anfrage: 20.000 Tokens Kontext, 2.000 Tokens Antwort

Eingabe:  20.000 / 1.000.000 × 5,00 USD = 0,100 USD
Ausgabe:   2.000 / 1.000.000 × 25,00 USD = 0,050 USD
                                          ---------
                                           0,150 USD

Fünfzehn Cent für eine Anfrage klingt harmlos. Die Falle steckt im Gespräch.

Warum Unterhaltungen quadratisch teuer werden

Das Modell ist zustandslos (Kapitel 3). Bei jeder Runde schickt die Anwendung die gesamte Unterhaltung erneut. Runde 10 bezahlt also die Runden 1 bis 9 mit.

Runde  1:   2.000 Tokens Eingabe
Runde  2:   4.000
Runde  3:   6.000
...
Runde 20:  40.000
           -------
Summe:    420.000 Tokens Eingabe für 20 Runden à 2.000

Bei linear wachsender Unterhaltung wächst die Summe quadratisch. Zwanzig Runden kosten nicht zwanzig, sondern gut zweihundert Einzelanfragen. Das ist der Hauptgrund, warum eine lange Agentensitzung überraschend teuer wird, und die Erklärung für die beiden Gegenmaßnahmen der nächsten Abschnitte.

Der billigste Hebel ist der Neustart

Wenn ein Thema abgeschlossen ist, beginnen Sie eine neue Sitzung. Ein frischer Kontext ist billiger und besser: keine Altlasten, keine irrelevanten Werkzeugergebnisse, keine Fehlspur von vor einer Stunde. Die Neigung, eine Sitzung „weil sie schon so viel weiß” endlos weiterzuführen, kostet Geld und Qualität gleichzeitig.

Prompt Caching

Weil derselbe Anfang immer wieder geschickt wird, kann er zwischengespeichert werden. Prompt Caching heißt: Der Anbieter behält den verarbeiteten Zustand des Prompt-Anfangs vor und rechnet ihn beim nächsten Mal deutlich billiger ab, in der Größenordnung von einem Zehntel des Eingabepreises. Das Schreiben in den Cache kostet einen kleinen Zuschlag, ab dem zweiten Zugriff rechnet es sich.

Entscheidend ist die Bedingung: Der Cache greift auf einem Präfix. Er passt nur, solange der Anfang Byte für Byte identisch ist. Ein einziges verändertes Zeichen weit vorne macht alles dahinter wertlos.

Daraus folgt eine Bauregel für jede Anwendung, die ein Modell aufruft: Stabiles zuerst, Veränderliches zuletzt.

[ System-Prompt, unverändert          ]  <- cachebar
[ Werkzeugbeschreibungen, sortiert    ]  <- cachebar
[ Projektdokumentation                ]  <- cachebar
------------------------------------------ Cache-Grenze
[ Unterhaltungsverlauf                ]
[ Aktuelle Frage                      ]  <- immer neu

Die typischen Fehler, die einen Cache still zerstören, sind immer dieselben: ein Zeitstempel oder eine Anfrage-ID im System-Prompt, eine Werkzeugliste, die pro Aufruf in anderer Reihenfolge serialisiert wird, oder ein Benutzername, der vorne eingesetzt wird. Der Fehler meldet sich nicht, er zeigt sich nur in der Rechnung. Ob der Cache wirkt, steht in der Antwort der API: Anbieter melden zurück, wie viele Tokens aus dem Cache gelesen und wie viele neu verarbeitet wurden. Wenn dieser Wert über wiederholte Anfragen hinweg null bleibt, gibt es einen solchen Zerstörer im Prompt.

Compaction: wenn das Fenster nicht reicht

Läuft eine Sitzung lange, wird der Verlauf irgendwann zu groß. Zwei Verfahren räumen auf, und sie sind nicht dasselbe.

Compaction fasst zusammen. Der ältere Teil der Unterhaltung wird durch eine Zusammenfassung ersetzt, die Sitzung läuft weiter. Der Kontext bleibt inhaltlich verbunden, aber Details gehen verloren, und zwar solche, die niemand ausgewählt hat.

Context Editing löscht. Alte Werkzeugergebnisse fliegen ganz heraus, die Gesprächsstruktur bleibt. Das ist das sauberere Verfahren, wenn die Ergebnisse tatsächlich erledigt sind, etwa das Resultat eines Verzeichnislistings von vor einer Stunde.

Beide Verfahren werden heute serverseitig angeboten, und in Agentenwerkzeugen laufen sie meist automatisch. Für die Praxis ist wichtig, dass sie Notmaßnahmen sind: Nach einer Compaction weiß der Agent verlässlich weniger als vorher, und Fehler nach einer Compaction sind häufig Folgefehler des Informationsverlusts. Wenn Sie merken, dass eine Sitzung komprimiert wurde, ist das ein guter Moment für einen Neustart mit einer sauberen Aufgabenstellung.

Kontext-Engineering

Aus allem Vorigen folgt die Disziplin, die den größten Unterschied im Umgang mit Agenten macht: bewusst zu entscheiden, was im Kontext steht.

1. Was das Modell für die Aufgabe wissen muss, gehört hinein. Nicht mehr. Die betroffenen Dateien, nicht das Repository.

2. Was oft gleich ist, gehört nach vorne. Projektregeln, Konventionen, Architekturbeschreibung. Das ist der cachebare Teil, und er ist genau deshalb der Ort für Dinge, die immer gelten.

3. Was einmal gebraucht wurde, gehört heraus. Ein Agent, der eine Datei gelesen und verstanden hat, braucht sie nicht dreimal im Kontext.

4. Was strukturiert vorliegt, gehört strukturiert hinein. Ein Auszug mit Zeilennummern schlägt eine ganze Datei; ein Schema schlägt zehn Beispieldatensätze.

5. Was eine Nebenaufgabe ist, gehört in eine eigene Sitzung. Genau das leisten Subagenten (Kapitel 8): Sie erledigen eine abgegrenzte Recherche in eigenem Kontext und liefern nur das Ergebnis zurück, statt den Hauptkontext mit dem Weg dorthin zu füllen.

Häufige Stolperfallen

1. Tokens mit Wörtern gleichsetzen. Bei Deutsch und bei Code liegt man damit deutlich daneben.
2. Mit einem fremden Tokenizer zählen. Systematisch falsche Werte, und die Fehler wachsen mit der Länge.
3. Das Kontextfenster für eine Qualitätszusage halten. Es sagt, was hineinpasst, nicht was verlässlich gefunden wird.
4. Die quadratische Kostenkurve nicht einrechnen. Der Preis pro Runde ist nicht konstant, er steigt mit jeder Runde.
5. Den Cache mit einem Zeitstempel zerstören. Und den Verlust nie bemerken, weil kein Fehler auftritt.
6. Alles Vorhandene mitschicken. Kostet Geld und verschlechtert die Antwort. Kein Kompromiss, beides zugleich.
7. Nach einer Compaction weiterarbeiten wie vorher. Der Agent weiß jetzt weniger, und zwar unkontrolliert.

Lernergebnisse: Was Sie nach diesem Kapitel können sollten

• Erklären: erklären, was ein Token ist, und begründen, warum deutscher Text und Code anders tokenisieren als englischer Prosatext.
• Anwenden: die Tokenzahl eines Textes oder einer Datei mit dem Tokenizer des verwendeten Modells bestimmen.
• Erklären: benennen, was alles in das Kontextfenster zählt, und erklären, warum eine hohe Grenze keine Qualitätszusage ist.
• Anwenden: die Kosten einer Anfrage und einer mehrstufigen Unterhaltung aus Token- und Preisangaben berechnen.
• Erklären: begründen, warum die Kosten einer Unterhaltung überproportional wachsen, und die Gegenmaßnahmen benennen.
• Anwenden: einen Prompt so aufbauen, dass Prompt Caching greift, und im Antwortobjekt prüfen, ob es greift.
• Erklären: Compaction und Context Editing unterscheiden und die jeweiligen Nachteile benennen.
• Beurteilen: für eine Agentensitzung entscheiden, welche Information in den Kontext gehört, welche in eine eigene Sitzung, und welche gar nicht, und die Entscheidung begründen.