Context Window: Definition, Abgrenzung und Beispiel

Das Context Window ist der Arbeitsspeicher eines KI-Sprachmodells (LLM, Large Language Model) für einen einzelnen Aufruf: die maximale Textmenge, die es auf einmal lesen und beantworten kann. Gemessen wird diese Menge in Tokens (Text-Bausteinen von grob drei bis vier Zeichen). In diesen Speicher zählt alles gemeinsam hinein: die Grundanweisung an das Modell (Systemprompt), der bisherige Gesprächsverlauf, mitgelieferte Dokumente und die generierte Antwort. Aktuelle Modelle liegen zwischen 128.000 Tokens (GPT-4o), 200.000 Tokens (Claude Sonnet 4.5) und 1.000.000 Tokens (Gemini 2.5 Pro).

Was ist ein Context Window?

Ein Sprachmodell zerlegt jeden Eingabetext in kleine Bausteine (Tokens) und vergleicht über den [Attention Mechanism](/insights/glossar/attention-mechanism/) (den Vergleichsschritt zwischen allen Bausteinen) jede Position im Fenster mit jeder anderen. Der Rechenaufwand dafür wächst überproportional (quadratisch) mit der Länge des Fensters: doppelt so viel Text bedeutet grob vierfachen Rechenaufwand. Deshalb sind große Fenster teuer und langsam. Deshalb ist die technische Obergrenze eine harte Grenze, die sich nicht einfach hochschrauben lässt.

Die Zähleinheit im Fenster ist das Token. Ein Token entspricht rund drei bis vier Zeichen im Englischen; deutsche Texte sind bei denselben Zeichen tokenreicher (Faktor 1,3 bis 1,5 je nach Tokenizer), weil Umlaute und lange Komposita in mehrere Teil-Tokens zerlegt werden. Ein 128k-Fenster fasst grob 90.000 bis 100.000 deutsche Wörter. Ein 1M-Fenster entspricht rund 750.000 englischen Wörtern oder etwa 1.000 Buchseiten.

Alles zählt gemeinsam: der Systemprompt, die laufende Chat-Historie, gerenderte Tool- oder Function-Signaturen, RAG-Chunks aus einem Vektorindex, Bilder bei multimodalen Modellen (als Token-Äquivalent umgerechnet) und die generierten Output-Tokens teilen sich denselben Zähler. Sobald ein Prompt das Fenster überschreitet, gibt die API einen Fehler zurück oder das Modell verwirft die ältesten Nachrichten (Sliding-Window-Strategie in Chat-Oberflächen).

Der Begriff existiert, weil er die harte Obergrenze für alle Kontext-Strategien ist. Jede Architektur-Entscheidung für Agenten, RAG-Stacks oder Multi-Turn-Chats hängt daran, wie groß das Fenster ist und wie viel davon effektiv nutzbar bleibt. Die Marketing-Zahl der Anbieter ist dabei nicht identisch mit der praktischen Nutzbarkeit: Der [RULER-Benchmark](https://arxiv.org/abs/2404.06654) (NVIDIA, 2024) und die Studie „[The Maximum Effective Context Window for Real World Applications](https://arxiv.org/abs/2509.21361)" (Paulsen 2025) zeigen, dass viele Modelle bei 32k bis 128k Tokens messbar abfallen. Bei einigen Modellen liegt die faktische Grenze bis zu 99 Prozent unter dem beworbenen Maximum. Der zugrunde liegende Effekt heißt „Lost in the Middle" ([Liu et al. 2023](https://arxiv.org/abs/2307.03172)): Informationen in der Mitte eines langen Fensters werden weniger zuverlässig gefunden als am Anfang und Ende.

Abgrenzung zu Context Length, Long-Context Models, Agent Memory und Context Caching

Fünf Begriffe werden in der Praxis mit Context Window verwechselt. Die relevanten Trennlinien:

Begriff	Ebene	Verhältnis zum Context Window
Context Length	Terminologie	Synonym. OpenAI schreibt „context length", Anthropic „context window". Keine technische Trennlinie.
Long-Context Model	Modell-Kategorie	Eine Klasse von Modellen mit besonders großem Fenster (ab ca. 200k Tokens, oft 1M+). Das Fenster ist die Zahl, das Long-Context Model die Kategorie, die diese Zahl liefert.
Agent Memory	Persistenz-Schicht	Speichert Informationen über einzelne Aufrufe hinaus (Short-Term, Long-Term, Episodic, Semantic). Das Fenster ist die Kapazität eines Aufrufs, Agent Memory die Quelle, aus der für den nächsten Aufruf ein passender Ausschnitt in das Fenster geladen wird.
Context Caching	Kosten-Hebel	Speichert die Modell-Berechnung über identische Prompt-Prefixes. Senkt die Kosten innerhalb eines gegebenen Fensters, verändert die Fenster-Größe aber nicht.
Token	Zähleinheit	Die Einheit, in der das Fenster gemessen wird. Ein Token entspricht rund drei bis vier Zeichen im Englischen. Nicht das Fenster selbst.

Die häufigste Verwechslung ist Context Window vs. Long-Context Model. Ein Long-Context Model ist keine andere Sache als ein Modell mit großem Context Window; es ist die Modell-Klasse, in der dieses Fenster besonders groß ist. Beide Begriffe kursieren nebeneinander, weil die Fenster-Größe zum Marketing-Merkmal geworden ist und die Klasse „Long-Context" (Gemini 1.5/2.5, Claude Sonnet, GPT-4.1) einen eigenen Vergleichsraum aufspannt.

Die zweite häufige Verwechslung ist Context Window vs. Agent Memory. Das Fenster ist flüchtig und wird bei jedem API-Aufruf neu befüllt; das Modell selbst hat kein Gedächtnis darüber hinaus. Agent Memory ist die Persistenz-Schicht, die diesen Zustand über Aufrufe hinweg trägt und bei Bedarf relevante Ausschnitte in das Fenster zurücklädt. Ein größeres Fenster ersetzt Agent Memory nicht, weil es weder persistiert noch selektiert; es erlaubt nur, mehr Kontext pro Aufruf zu tragen.

Die dritte relevante Trennlinie verläuft zwischen advertised und effective Context. Anbieter geben ein maximales Fenster an (200k, 1M, in Forschungsdemos auch 10M). Benchmarks wie RULER, NIAH („Needle in a Haystack") und Longbench messen die tatsächliche Retrieval- und Reasoning-Genauigkeit über die Fenster-Länge. Die Kurven fallen bei fast allen produktiven Modellen deutlich vor der Marketing-Zahl ab. Praktische Auslegung: Die maximale Fenster-Zahl gilt als Ober-Schranke, die verlässliche Arbeits-Zone liegt darunter und muss pro Modell gemessen werden.

Beispiel: RAG-Assistent auf einem 200k-Fenster

Ein Wissensassistent nutzt Claude Sonnet 4.5 mit einem 200.000-Token-Context-Window. Der Systemprompt belegt 4.000 Tokens (Tonalität, Compliance-Regeln, Persona-Definition), die Tool-Definitionen 2.000 Tokens, die Chat-Historie der laufenden Sitzung 12.000 Tokens. Für die aktuelle Frage werden aus einem Vektorindex 40 Top-Chunks à 500 Tokens gezogen (20.000 Tokens). Die Nutzerfrage umfasst 80 Tokens, die erwartete Antwort rund 1.500 Tokens.

Rechnerisch bleiben nach dieser Belegung rund 160.000 Tokens Puffer. Praktisch ist die Rechnung optimistischer als die Realität: RULER- und Paulsen-Ergebnisse zeigen für Sonnet-Klasse-Modelle einen deutlichen Retrieval-Abfall zwischen 64k und 128k Tokens Länge. Der Architektur-Effekt für den Assistenten ist damit klar. Das nominelle 200k-Fenster erlaubt, viele Dokumenten-Chunks unkomprimiert einzuspeisen; die effektive Nutzbarkeit verlangt einen Reranker vor der finalen Chunk-Auswahl und eine kompakte Prompt-Struktur, in der die relevantesten Chunks am Anfang und Ende des Kontexts stehen (die Positionen, die am zuverlässigsten gefunden werden).

Dieselbe Logik gilt auf 1M-Fenstern von Gemini 2.5 Pro und ähnlichen Long-Context Modellen. Das Fenster erlaubt, ganze Codebases oder Buch-Sammlungen in einem Aufruf zu übergeben; die RULER-Kurve fällt vor der Marketing-Zahl. Die Architekturposition des Context Window ist damit: harte Obergrenze für alles, was pro Aufruf gemeinsam gesehen werden kann; die weiche Grenze der zuverlässigen Nutzbarkeit liegt tiefer und muss pro Modell und Aufgabe gemessen werden.