Tokenisierung und Context Window: Was Agent-Latenz und -Kosten treibt

Tokenisierung zerlegt Text in Tokens, die kleinsten Verarbeitungseinheiten eines LLM; das Context Window ist die maximale Tokenzahl, die ein Modell pro Anfrage gemeinsam verarbeiten kann. Bei AI-Agenten bestimmen beide direkt Kosten und Latenz, weil jeder Agent-Schritt den gesamten bisherigen Kontext erneut an das Modell sendet. Wer Agenten produktiv betreibt, steuert über diese zwei Grössen den grössten Teil der laufenden Kosten und der Antwortzeit.

• Tokens sind die Abrechnungs- und Verarbeitungseinheit. Kosten und Latenz hängen an der Tokenzahl, nicht an der Zeichenzahl. Deutscher Text erzeugt pro Wort tendenziell mehr Tokens als englischer.
• Das Context Window ist endlich. Multi-Step-Agenten füllen es schnell, weil jeder Schritt System-Prompt, gesamte Historie und alle Tool-Ergebnisse mitschleppt. Die pro Lauf abgerechnete Tokenmenge wächst dadurch überproportional.
• Voller Kontext heißt nicht besserer Kontext. Bei sehr langen Eingaben sinkt die Qualität messbar (Lost-in-the-Middle). Kontext-Management ist kein Nice-to-have, sondern Kosten- und Qualitätshebel zugleich.

Was Tokens sind und warum sie der Kostentreiber sind

Ein LLM verarbeitet keinen Klartext, sondern Tokens. Der Tokenizer zerlegt Eingabetext in Einheiten, die meist einem Wortteil, einem kurzen ganzen Wort oder einem Satzzeichen entsprechen. Das Modell rechnet ausschließlich mit diesen Tokens, und alle Anbieter rechnen pro Token ab, getrennt nach Input (was hineingeht) und Output (was generiert wird).

Für die Praxis sind zwei Eigenschaften entscheidend. Erstens ist die Token-Dichte sprachabhängig: Im Deutschen entspricht ein Token grob 0,6 bis 0,8 Wörtern. Lange Komposita, Umlaute und Flexionsendungen führen dazu, dass derselbe Sachverhalt auf Deutsch oft mehr Tokens benötigt als auf Englisch. Für DACH-Workloads heißt das: gleiche Aufgabe, höherer Tokenverbrauch, höhere Kosten und schnellere Füllung des Context Windows.

Zweitens ist Output meist deutlich teurer als Input. Bei den am Markt verfügbaren Modellen liegt der Output-Preis typisch beim Drei- bis Sechsfachen des Input-Preises - bei einzelnen günstigen Workhorse-Modellen ist der Aufschlag kleiner, bei Frontier-Modellen eher am oberen Rand. Ein Agent, der lange, ausführliche Antworten produziert, ist daher überproportional teuer im Verhältnis zur Menge an Output-Tokens.

Wie das Context Window funktioniert

Das Context Window ist die maximale Anzahl Tokens, die ein Modell in einer Anfrage gemeinsam sehen kann - Input und generierter Output zusammen. Alles, was das Modell für eine Antwort berücksichtigen soll, muss in dieses Fenster passen: System-Anweisung, Konversationsverlauf, eingespielte Dokumente, Tool-Definitionen und Tool-Ergebnisse.

Die Fenstergrössen sind in den letzten Jahren stark gewachsen. Aktuelle Frontier-Modelle bieten sehr große Kontexte: Claude Opus 4.7 und Gemini 3.1 Pro arbeiten mit rund 1 Million Tokens, Gemini je nach Bereitstellung mit bis zu 2 Millionen, Mistral Large 3 mit 256K, Llama 4 Scout sogar mit bis zu 10 Millionen Tokens (alle Angaben Stand 2026). Ein größeres Fenster verschiebt die harte Obergrenze - es macht das Mitschleppen von Kontext aber nicht gratis. Zwei Effekte bleiben: Kosten und Latenz steigen mit der Inputlänge, und die Antwortqualität degradiert bei sehr langen Eingaben.

Kontext-Wachstum bei Multi-Step-Agenten

Ein einzelner Chat-Aufruf ist kostenmäßig unkritisch. Das Problem entsteht beim agentischen Muster: Ein Agent löst eine Aufgabe nicht in einem Aufruf, sondern in vielen Schritten - planen, ein Tool aufrufen, Ergebnis bewerten, nächstes Tool aufrufen, und so weiter. Bei jedem dieser Schritte wird der gesamte bisherige Verlauf erneut als Input gesendet, weil das Modell zustandslos ist und sich nichts merkt.

Daraus folgt das zentrale ökonomische Muster von Agenten: ein überproportional wachsender Token-Verbrauch. Wenn Schritt 1 noch 2.000 Input-Tokens hat, Schritt 2 bereits 5.000, Schritt 3 dann 9.000 und so weiter, summiert sich der abgerechnete Token-Verbrauch über den Lauf nicht linear, sondern weit überproportional - jeder Schritt schleppt ja den gewachsenen Kontext aller vorherigen Schritte mit. Jeder zusätzliche Tool-Output - eine API-Antwort, ein durchsuchtes Dokument, ein Suchergebnis - vergrößert den Kontext für alle folgenden Schritte. Lange Tool-Ausgaben sind hier der häufigste stille Kostentreiber.

Latenz folgt derselben Logik. Die Zeit bis zum ersten Token und die Gesamt-Antwortzeit steigen mit der Inputlänge, weil das Modell den kompletten Kontext einlesen muss, bevor es antwortet. Ein Agent, der gegen Ende eines langen Laufs 80.000 Tokens Kontext mitführt, ist pro Schritt spürbar langsamer als am Anfang - genau dann, wenn der Nutzer ohnehin schon wartet.

Degradation: Lost-in-the-Middle bei vollem Kontext

Ein verbreiteter Trugschluss lautet: Wenn das Fenster groß genug ist, kann man einfach alles hineinpacken. Das stimmt technisch, aber nicht qualitativ. LLMs nutzen Informationen am Anfang und am Ende einer langen Eingabe zuverlässiger als Informationen in der Mitte - ein Effekt, der als Lost-in-the-Middle bekannt ist. Je länger der Kontext, desto höher das Risiko, dass die entscheidende Information schlechter gewichtet wird oder untergeht.

Für Agenten ist das doppelt relevant. Erstens füllt ein Agent seinen Kontext oft mit Historie, die für den aktuellen Schritt irrelevant ist. Zweitens kann ein überfüllter Kontext dazu führen, dass das Modell ältere Anweisungen oder frühe Tool-Ergebnisse aus der Mitte des Verlaufs ignoriert - mit dem Resultat, dass die Antwortqualität trotz technisch ausreichendem Platz sinkt. Mehr Kontext ist also nicht automatisch mehr Leistung; ab einem Punkt ist weniger, aber kuratierter Kontext besser.

Begriffe und ihre Agent-Implikation

Beispielrechnung: Tokens zu Kosten

Ein Support-Agent löst eine Anfrage in 6 Schritten. Pro Schritt sendet er den gesamten Kontext erneut. Vereinfachte Annahme zum Input-Verlauf: 2.000, 5.000, 9.000, 14.000, 20.000, 27.000 Tokens - in Summe rund 77.000 Input-Tokens. Dazu generiert er pro Schritt etwa 500 Output-Tokens, also rund 3.000 Output-Tokens insgesamt.

Rechnen wir das mit drei Preisniveaus durch (Preise pro 1 Mio. Tokens, Input/Output, Stand 2026):

Ein einzelner Lauf wirkt billig. Aber bei 50.000 solcher Läufe pro Monat ergeben sich grob 23.000 US-Dollar mit dem Frontier-Modell gegenüber rund 2.150 US-Dollar mit dem EU-Sovereign-Modell und rund 600 US-Dollar mit dem günstigen Workhorse-Modell. Der Faktor zwischen Frontier- und Workhorse-Tier liegt je nach Modell zwischen 8 und 100 (Stand 2026). Zwei Lehren: Erstens dominiert bei Agenten der mitgeschleppte Input das Budget, nicht der Output. Zweitens ist die Modellwahl pro Teilschritt ein massiver Kostenhebel.

Hinzu kommt ein Long-Context-Aufschlag. Gemini 3.1 Pro etwa wird oberhalb von 200.000 Tokens teurer: Der Input-Preis verdoppelt sich, der Output-Preis steigt ebenfalls deutlich ($4 / $18 statt $2 / $12 pro 1 Mio. Tokens, Stand 2026). Wer den Kontext eines Agenten unkontrolliert über diese Schwelle wachsen lässt, zahlt nicht nur für mehr Tokens, sondern auch einen höheren Tarif pro Token.

Gegenstrategien: Kontext klein und fokussiert halten

Die Kunst des Agent-Engineerings besteht darin, dem Modell pro Schritt nur das zu geben, was es wirklich braucht. Drei Strategien, die sich kombinieren lassen:

• Kontext-Kompression und Summarisierung. Ältere Schritte werden zu einer kurzen Zusammenfassung verdichtet, statt den Volltext-Verlauf mitzuschleppen. Lange Tool-Outputs werden auf das Ergebnis reduziert. Das senkt Input-Tokens, Latenz und das Lost-in-the-Middle-Risiko gleichzeitig.
• Retrieval statt Volltext (RAG). Statt ganze Wissensdatenbanken oder Dokumente in den Prompt zu laden, werden per Suche nur die relevanten Snippets eingespielt. Das hält den Kontext klein und erhöht die Trefferqualität, weil das Modell nicht durch Irrelevantes abgelenkt wird.
• Modell-Routing und Prompt-Caching. Einfache Teilschritte (Klassifikation, Extraktion, Formatierung) laufen auf günstigen Workhorse- oder Open-Weight-Modellen; teure Frontier-Modelle werden nur für die komplexen Schritte reserviert. Prompt-Caching reduziert zusätzlich die Kosten für wiederkehrende, stabile Kontextteile wie System-Prompts.

Ergänzend gilt: Output gezielt begrenzen (knappe, strukturierte Antworten statt ausschweifender Prosa) und Tool-Ergebnisse auf das Nötige zuschneiden. In der Summe entscheiden diese Maßnahmen darüber, ob ein Agent in der Pilotphase elegant aussieht und im Produktivbetrieb wirtschaftlich bleibt.

Für Agenturen und B2B-Entscheider

Tokenisierung und Context Window sind keine technischen Randthemen, sondern die zwei wichtigsten Stellschrauben für die Wirtschaftlichkeit eines AI-Agenten. Wer eine Agent-Lösung budgetiert, sollte die Kosten nicht pro Anfrage, sondern pro vollständigem Multi-Step-Lauf und hochgerechnet auf das erwartete Monatsvolumen kalkulieren - inklusive des überproportionalen Kontext-Wachstums. Für Agenturen liegt der Beratungswert darin, Kunden vor der bösen Überraschung zu bewahren, dass ein im Pilot günstiger Agent unter Last unkalkulierbar teuer oder langsam wird. Blck Alpaca unterstützt DACH-Unternehmen dabei, Agent-Architekturen so zu konzipieren, dass Kontext-Management, Modell-Routing und Retrieval von Anfang an eingebaut sind - für planbare Kosten, akzeptable Latenz und stabile Antwortqualität im Produktivbetrieb.