Ein Context Window ist die maximale Textmenge, gemessen in Tokens, die ein Modell in einem einzigen Aufruf lesen und verarbeiten kann. Alles, was das Modell während dieses Aufrufs kennt, Prompts, Verlauf, abgerufene Dokumente, Tool-Ausgaben, muss darin Platz finden.
Tokens, nicht Wörter
Modelle verarbeiten keine Zeichen oder Wörter direkt. Sie verarbeiten Tokens, also Textabschnitte, die von einem Tokenizer erzeugt werden. Als grobe Faustregel gilt: Ein Token entspricht etwa drei bis vier Zeichen im Englischen, oder ungefähr 0,75 Wörtern. Ein Context Window mit 128.000 Tokens fasst etwa 90.000 bis 100.000 Wörter, wobei die genauen Zahlen vom Modell und dem verwendeten Tokenizer abhängen.
Code wird anders tokenisiert als Fließtext. Variablennamen, zeichenschwere Syntax und nicht-lateinische Zeichen können Tokens schneller verbrauchen als normaler englischer Text.
Was sich innerhalb des Fensters befindet
Jedes Token in einem einzelnen Modell-Call konkurriert um denselben Platz:
- System-Prompt
- Gesprächsverlauf
- Abgerufene Dokumente oder Chunks (siehe was ist RAG)
- Tool-Definitionen und Tool-Call-Ergebnisse
- Die aktuelle Nachricht des Nutzers
- Reservierter Platz für die Antwort des Modells
In einem agentischen Loop fließen Tool-Ausgaben bei jeder Iteration wieder in den Kontext ein. Eine mehrstufige Aufgabe kann ein großes Fenster schneller füllen, als Entwickler erwarten.
Warum die Größe nicht die ganze Geschichte ist
Längere Kontextfenster lösen nicht alle Probleme, und zwar aus mehreren Gründen.
Erstens: Kosten. Die meisten Anbieter berechnen Gebühren pro Token, für Eingabe und Ausgabe. Bei großem Volumen ist das Senden von 100.000 Tokens pro Call teuer.
Zweitens: Latenz. Größere Payloads benötigen länger zur Verarbeitung, was bei interaktiven oder Echtzeit-Anwendungen eine Rolle spielt.
Drittens: Abrufqualität. Forschungsergebnisse und Engineering-Erfahrung legen nahe, dass Modelle den Überblick über Informationen verlieren können, die in der Mitte eines sehr langen Kontexts eingebettet sind. Das Platzieren des relevantesten Materials am Anfang oder Ende des Prompts führt tendenziell zu besseren Ergebnissen.
Viertens ist das Kontextfenster flüchtig. Nichts darin bleibt zwischen Aufrufen erhalten, sofern die Anwendung es nicht explizit verwaltet. Gedächtnis über Sitzungen hinweg muss auf der Anwendungsebene gehandhabt werden und kann nicht vom Modell erwartet werden.
Praktische Konsequenzen für Entwickler
Entwickler, die auf der Anwendungsebene arbeiten, müssen regelmäßig Entscheidungen zum Kontextmanagement treffen:
- Welche Teile eines Gesprächs behalten und welche zusammengefasst oder verworfen werden sollen
- Wie viele abgerufene Chunks übergeben werden und wie diese zu priorisieren sind
- Ob ein großes Dokument aufgeteilt oder Anfragen auf kleinere, fokussierte Aufrufe verteilt werden sollen
- Wie werkzeuglastige agentische Aufgaben bewältigt werden, ohne während der Ausführung an Token-Grenzen zu stoßen
Das sind keine Konfigurationsentscheidungen. Sie erfordern ein Verständnis davon, was das Modell tatsächlich mit den empfangenen Informationen macht. Ein Entwickler, der das Kontextfenster schlicht als größeren Behälter betrachtet, neigt dazu, Systeme zu entwickeln, die unter realistischer Last langsam, teuer oder unzuverlässig sind.
Context Engineering ist die Disziplin, bewusste und begründete Entscheidungen darüber zu treffen, was in ein Kontextfenster gehört, wie es zu strukturieren ist und was weggelassen werden soll.
Bezug zu anderen Komponenten
Eine Vektordatenbank existiert zum Teil, weil Kontextfenster begrenzt sind. Anstatt eine gesamte Wissensdatenbank in einen Prompt zu laden, ermitteln Retrieval-Systeme die relevantesten Chunks und übergeben nur diese. Die Qualität dieses Abrufs beeinflusst direkt, worüber das Modell schlussfolgern kann.
In Setups mit agentischem Coding bestimmt das Kontextfenster auch, wie viel einer Codebasis ein Modell gleichzeitig im Blick behalten kann. Entwickler, die an großen Repositories arbeiten, müssen oft bewusst entscheiden, welche Dateien, Funktionen oder Diffs sie einbeziehen.
Was wir prüfen
Einen Kontextfenster gut zu verwalten ist etwas, worauf wir bei der Bewertung von Engineers direkt achten. In der AI-native-Bewertung unter how we vet bewerten wir Prompt- und Kontext-Engineering genau danach: ob ein Engineer den Aufgabenkontext so aufbereitet, dass das Tool nutzbaren Output liefert, anstatt alles Verfügbare zu übergeben und bei einem Fehlschlag neu zu prompten. Wir achten auch auf Spec-Driven Development, da ein Engineer, der ein vages Ticket in klar abgegrenzte Teile zerlegt, dieselbe Art von Entscheidung trifft: was das Modell braucht auswählen und weglassen, was es nicht benötigt.
Kurze Antworten
Bedeutet ein größeres Kontextfenster bessere Ergebnisse?
Nicht automatisch. Größere Fenster erhöhen Kosten und Latenz, und Modelle können den Überblick über Informationen verlieren, die tief in langen Prompts vergraben sind. Eine sorgfältige Auswahl dessen, was in den Kontext einfließt, ist oft wichtiger als die reine Fenstergröße.
Was passiert, wenn das Kontextfenster überschritten wird?
Die API gibt einen Fehler zurück, oder der Anbieter kürzt die Eingabe stillschweigend, je nach Implementierung. In beiden Fällen gehen Inhalte verloren. Entwickler müssen diesen Fall in Produktivsystemen explizit behandeln und dürfen ihn nicht als Sonderfall abtun.
Ist die Kontextfenstergröße bei allen Modellen gleich?
Nein. Sie variiert je nach Modell und Version erheblich, von einigen tausend Token bis zu über einer Million in manchen Fällen. Die relevante Grenze für Ihr System ist das Modell, das Sie tatsächlich aufrufen, nicht die größte Zahl, die Sie irgendwo genannt gesehen haben.
