Kontextfenster

Was ist ein Kontextfenster?

Ein Kontextfenster ist die maximale Textmenge, die ein KI-Modell in einer einzelnen Anfrage verarbeiten kann, gemessen in Token – dazu gehören System-Prompt, Gesprächsverlauf, abgerufene Dokumente, Tool-Ergebnisse und die eigene Ausgabe des Modells. Es fungiert als Arbeitsgedächtnis des Modells: Alles, was darin enthalten ist, kann die Antwort beeinflussen – alles außerhalb existiert für das Modell schlicht nicht.

Die wichtigsten Punkte

• Alles teilt sich ein Budget. Anweisungen, Verlauf, Dateien, Tool-Ausgaben und die generierte Antwort greifen alle auf denselben Token-Pool zurück, sodass ein langer Verlauf direkt Platz zum „Nachdenken“ verdrängt.
• Kontextfenster sind innerhalb weniger Jahre von wenigen Tausend Token auf über eine Million angewachsen – das verändert, was möglich ist, aber nicht zwangsläufig, was sinnvoll ist. Anthropics Erweiterung von Claude Sonnet 4 auf 1 Million Token im August 2025 war ein Sprung um das 5-Fache, genug, um eine Codebasis mit über 75.000 Zeilen in einer einzigen Anfrage unterzubringen [1].
• Beworbene und tatsächlich nutzbare Größe unterscheiden sich. Abruf- und Reasoning-Qualität verschlechtern sich bei sehr langen Eingaben, sodass die letzten hunderttausend Token selten so nützlich sind wie die ersten.
• Das Fenster hat keine Persistenz. Endet eine Sitzung oder wird der Verlauf gekürzt, ist diese Information verloren – es sei denn, ein Mechanismus wie Agent Memory schreibt sie gezielt fest.

So funktioniert es

Modelle lesen Text als Token – Einheiten von etwa drei bis vier englischen Zeichen –, und die Architektur legt eine maximale Anzahl fest, der das Modell in einer Anfrage Aufmerksamkeit schenken kann. Diese Obergrenze verschiebt sich ständig: Google brachte Gemini 1.5 Pro 2024 mit einem Standardfenster von 128.000 Token auf den Markt und berichtete, im Forschungskontext erfolgreich bis zu 10 Millionen Token getestet zu haben [2]. Innerhalb dieser Grenze erlaubt der Attention-Mechanismus jedem Token, sich auf jeden anderen zu beziehen – das macht es möglich, dass eine Antwort in der letzten Zeile ein Detail aus der ersten Zeile aufgreift. Derselbe Mechanismus erklärt auch die Obergrenze: Die Attention-Kosten wachsen mit der Länge steil an, sodass das Bereitstellen langer Fenster echten Speicher und echte Rechenleistung kostet – Anbieter holen sich das mit Tricks wie dem Zwischenspeichern des unveränderten Präfixes wiederholter Anfragen zurück. Daraus ergeben sich unmittelbare praktische Konsequenzen: etwa, warum lange Eingaben mehr kosten und warum es günstiger ist, den stabilen Teil eines Prompts über mehrere Aufrufe hinweg identisch zu halten, statt ihn zu verändern.

Das Fenster ist eine fortlaufende Beschränkung, keine einmalige Prüfung. In einer Konversation oder Agent-Sitzung verpackt jede Anfrage den bisherigen Verlauf plus die neue Runde neu, und sobald sich die Gesamtmenge der Grenze nähert, muss etwas nachgeben: Alte Runden werden verworfen, per Compaction zusammengefasst oder in externen Speicher ausgelagert und bei Bedarf über RAG-artigen Abruf wieder geholt. Das ist die mechanische Realität hinter Context Engineering, der Disziplin, das Budget klug einzusetzen.

Kapazität und Qualität driften mit wachsenden Eingaben zudem auseinander. Ein Modell mit einem Ein-Millionen-Token-Fenster akzeptiert auch eine Million Token, doch das Auffinden bestimmter Details aus der Mitte riesiger Eingaben ist nachweislich unzuverlässiger als an den Rändern, und irrelevanter Ballast lenkt aktiv ab – dieses Verschlechterungsmuster wird Context Rot genannt. Der Unterschied ist erheblich: Der NoLiMa-Benchmark von 2025 testete 13 LLMs mit angeblich 128K+ Fenstern und stellte fest, dass GPT-4o von einer Kurzkontext-Baseline von 99,3 % auf 69,7 % bei nur 32K Token abfiel [3]. Praktiker denken deshalb in Begriffen eines effektiven Fensters – der Länge, bei der das Modell noch nahe an seiner Bestleistung arbeitet – und behandeln den Spielraum darüber hinaus als Reserve für Notfälle, nicht als Ziel, das es auszufüllen gilt.

Beispiel

Ein Coding-Agent beginnt eine große Migration in einem 200.000-Token-Fenster. Der Sitzungsstart ist günstig: Anweisungen und Aufgabenbeschreibung verbrauchen 6.000 Token. Drei Stunden später enthält der Verlauf Dutzende Dateizugriffe, Testläufe und Diffs, und das Fenster ist zu 85 Prozent gefüllt. Symptome zeigen sich, bevor ein harter Fehler auftritt: Der Agent liest Dateien erneut, die er bereits gesehen hat, und diskutiert eine Designentscheidung aus Stunde eins noch einmal, weil der Vermerk dazu zweihundert Seiten weiter hinten begraben liegt. Das Harness komprimiert daraufhin: Der älteste Verlaufsteil wird durch eine Zusammenfassung der getroffenen Entscheidungen und bearbeiteten Dateien ersetzt, was 60 Prozent des Budgets freigibt. Der Agent wird sofort wieder präziser, und das Team führt eine Regel ein, bereits bei 60 Prozent zu komprimieren statt zu warten, plus eine Scratchpad-Datei, in der der Agent zentrale Entscheidungen festhält, damit nichts Entscheidendes nur im Verlauf existiert.

Häufige Missverständnisse

Der verbreitete Fehler ist, ein riesiges Fenster als Lösung für das Gedächtnisproblem zu behandeln – nach der Logik, dass eine Million Token bedeutet, man könne einfach die gesamte Codebasis hineinkopieren. Das scheitert doppelt. Innerhalb einer Sitzung verschlechtert das Vollstopfen des Fensters die Präzision des Modells bei den Teilen, die zählen, während gleichzeitig die Kosten steigen – der Rundumdump ist also schlechter als eine kuratierte Auswahl relevanter Dateien. Über Sitzungen hinweg löst das Fenster gar nichts, denn es ist Arbeitsgedächtnis, kein Speicher: Die morgige Sitzung startet unabhängig von der Fenstergröße leer. Dauerhaftes Wissen braucht einen echten Mechanismus – Anweisungsdateien, Memory-Systeme, Retrieval –, und ein größeres Fenster ändert daran nichts. Fenstergröße ist Kapazität; Memory ist Architektur.

FAQ

Was passiert, wenn ein Kontextfenster voll ist? Die Anfrage wird entweder wegen Überschreitung des Limits abgelehnt, oder in verwalteten Chat- und Agent-Produkten wird älterer Inhalt stillschweigend verworfen oder zusammengefasst, um Platz zu schaffen. Dieses Kürzen ist der Grund, warum lange Sitzungen frühe Details „vergessen“: Die Token sind schlicht nicht mehr im Blickfeld des Modells.

Ist ein größeres Kontextfenster immer besser? Größer bedeutet leistungsfähiger, aber nicht automatisch besser genutzt. Lange Eingaben kosten pro Anfrage mehr, verlangsamen die Antwort und verwässern die Aufmerksamkeit, und Modelle rufen Informationen aus der Mitte riesiger Kontexte weniger zuverlässig ab. Relevante 20.000 Token schlagen routinemäßig wahllose 500.000.

Wie unterscheidet sich ein Kontextfenster von Memory? Das Fenster ist flüchtiges Arbeitsgedächtnis innerhalb eines Anfragezyklus; es speichert nichts dauerhaft. Memory in Agentensystemen bedeutet explizite Mechanik – Dateien, Datenbanken, Retrieval –, die Informationen außerhalb des Fensters festhält und später wieder lädt. Wer beides verwechselt, ist überrascht, wenn der Agent sich morgen an nichts mehr erinnert.

Quellen

1. Anthropic. "Erweiterung des Claude-Sonnet-4-Kontextfensters auf 1 Million Token – eine Verfünffachung, die Codebasen mit über 75.000 Zeilen abdeckt." https://claude.com/blog/1m-context. Abgerufen im August 2026.
2. Google (offizieller Blog). "Gemini 1.5 Pro eingeführt mit einem Standard-Kontextfenster von 128.000 Token; im Forschungskontext wurden bis zu 10 Millionen Token getestet." https://blog.google/technology/ai/google-gemini-next-generation-model-february-2024/. Abgerufen im August 2026.
3. Modarressi et al., arXiv (NoLiMa). "13 LLMs mit angeblich 128K+ Fenstern getestet; GPT-4o fiel von einer Kurzkontext-Baseline von 99,3 % auf 69,7 % bei 32K Token." https://arxiv.org/abs/2502.05167. Abgerufen im August 2026.