Context Window: Was ins Kontextfenster passt

Das Context Window, auf Deutsch Kontextfenster, ist der gesamte Token-Rahmen, den ein großes Sprachmodell (LLM) für eine Anfrage nutzen kann: für die Eingabe, die es liest, und die Ausgabe, die es erzeugt. Bei einem Fenster von 1M Tokens müssen sich Anweisungen, Dokumente und Gesprächsverlauf diesen Platz mit der Antwort teilen – einschließlich der internen Denkschritte, sofern das Modell solche nutzt. Dass alles ins Fenster passt, heißt noch nicht, dass das Modell jedes Detail richtig berücksichtigt.

Was ist ein Context Window bei KI-Modellen?

Ein Kontextfenster lässt sich mit einer Werkbank vergleichen. Dokumente, Anweisungen und angefangene Arbeiten belegen die Fläche. Auf einer größeren Werkbank lässt sich mehr Material ausbreiten. Platz zum Arbeiten braucht es trotzdem – und auch wenn alle Dokumente offen daliegen, fällt die entscheidende Klausel nicht automatisch ins Auge.

Ein Token ist eine Verarbeitungseinheit des Modells, häufig ein Wortfragment statt eines ganzen Wortes. Text, Code und andere Eingaben werden nach den Regeln des jeweiligen Modells in Tokens umgewandelt. Maßgeblich ist die Token-Zahl der tatsächlichen Anfrage, keine Schätzung anhand von Seitenzahl oder Dateigröße. Googles Leitfaden zu Tokens erläutert diesen Unterschied.

Zur Eingabe kann auch Material gehören, das nie ins Chatfeld eingegeben wurde:

• Systemanweisungen, die das Verhalten des Assistenten festlegen.
• Die aktuelle Nachricht und der beibehaltene Gesprächsverlauf.
• Tool-Definitionen, die die verfügbaren Aktionen des Modells beschreiben.
• Tool-Ergebnisse, abgerufene Textpassagen, Bilder und Dokumente.

Anthropic zählt diese Bestandteile ausdrücklich zur Berechnung des Kontextumfangs. Hinter einer kurzen Nutzerfrage kann daher eine sehr große Anfrage stecken.

Kontextfenster und Token-Limit: Wo liegt der Unterschied?

Das Kontextfenster begrenzt die gesamte Anfrage; das Ausgabelimit begrenzt den erzeugten Anteil. Reasoning-Modelle können einen Teil dieses Ausgabebudgets für interne Denkschritte verbrauchen, bevor sie die sichtbare Antwort formulieren. OpenAI beschreibt, wie Eingabe, Ausgabe und Reasoning dasselbe Fenster belegen.

Für ein gemeinsam genutztes Fenster gilt bei der Planung:

Eingabe-Tokens + reservierte Tokens für die Generierung müssen zusammen ins Kontextfenster passen.

Wenn das Modell seine Denkschritte diesem Budget zurechnet, müssen auch sie in die Reserve einfließen. Zusätzlich gilt das separate Ausgabelimit des Modells. Ein hoch angesetztes Ausgabelimit schafft keinen zusätzlichen Platz.

Was bestimmt das Kontextfenster eines KI-Tools?

Es bestimmt, wie viel Material das Modell bei dieser Anfrage gemeinsam berücksichtigen kann. Es sagt nichts darüber aus, wie zuverlässig das Modell dieses Material nutzt, was die Anwendung zwischen Sitzungen speichert oder welche gespeicherten Inhalte sie beim nächsten Mal wieder mitsendet.

Im Support ist diese Unterscheidung unmittelbar relevant: Ein Ticket kann im Helpdesk gespeichert sein und trotzdem in der aktuellen Eingabe des Assistenten fehlen. Für die Entwicklung bedeutet das: Einen Gesprächsverlauf zu speichern und die nächste Modellanfrage zusammenzustellen, sind getrennte Aufgaben.

Aktuelle Kontextgrößen: Claude, GPT-6 und Gemini 4

Die folgenden zentralen API-Modelle bieten Kontextfenster von ungefähr einer Million Tokens. Ihre Ausgaberegeln sind aber ebenso wichtig wie diese Kapazitätsangabe. Am 16. Oktober 2026 anhand der aktuellen Modellseiten der Hersteller geprüft. Jede Zeile verlinkt direkt zum jeweiligen Hersteller. Es handelt sich um API-Spezifikationen, nicht um Zusagen zu Chat-Abonnements für Endnutzer oder zu den eigenen Grenzen einer Anwendung.

Die aktuelle Modellseite von Claude nennt für alle aufgeführten Modelle dieselbe Fenstergröße und dasselbe Ausgabelimit. Die Kontextgröße eignet sich deshalb kaum als Auswahlkriterium zwischen diesen Modellen. Aussagekräftiger ist ein Vergleich ihrer Antworten auf die konkrete Aufgabe.

Auch GPT-6 Astra, GPT-6.1 Sol und GPT-6 Luna teilen sich die angegebene Kapazität. Trotz gleich großer Kontextfenster können sich Modelle bei der Informationsextraktion, Planung oder Programmierung unterschiedlich verhalten. Die Spezifikation legt fest, was hineinpasst; sie ist keine Qualitätsrangliste.

Bei Gemini 4 Argon ist das Long-Decode-Budget Teil des gemeinsam genutzten Fensters. Laut Google begrenzt die API die angeforderte Ausgabe auf den Platz, der nach der Eingabe übrig bleibt. Auch interne Denkschritte verbrauchen dieses Budget. Eine große Ausgabe lässt sich nicht zusätzlich auf ein bereits volles Eingabefenster aufschlagen. Die genaue Regel steht in der Dokumentation zur Token-Berechnung bei Gemini.

Rechenbeispiel: Der Prompt passt, die Antwort nicht

Ein Prompt mit einer Million Tokens lässt weniger Platz für die Antwort, als das maximale Ausgabelimit des Modells vermuten lässt.

Als Beispiel dienen die dokumentierten Grenzen von GPT-6 Astra. Angenommen, die zusammengestellte Anfrage enthält 1,000,000 Eingabe-Tokens, einschließlich Anweisungen, Tools, Verlauf und Quelldokumenten. Das ist eine beispielhafte Budgetrechnung, keine gemessene Arbeitslast. Für die Generierung sollen die vollen 128,000 Tokens reserviert werden, die das Modell zulässt.

Die Rechnung:

• Kontextfenster: 1,050,000 Tokens.
• Verbleibender Platz nach der Eingabe: 1,050,000 − 1,000,000 = 50,000 Tokens.
• Geplante Eingabe plus Ausgabe: 1,000,000 + 128,000 = 1,128,000 Tokens.
• Fehlender Platz: 78,000 Tokens.

Die Eingabe passt hinein, das geplante Antwortbudget nicht. Der verbleibende Platz muss sowohl die internen Denkschritte als auch die sichtbare Antwort abdecken.

Für die volle Ausgabereserve darf die Eingabe höchstens 922,000 Tokens umfassen, berechnet als 1,050,000 − 128,000. Ein zusätzlicher Sicherheitspuffer für den jeweiligen Workflow ist dabei noch nicht berücksichtigt. Nicht jede Aufgabe braucht die maximale Reserve; entscheidend ist der erwartete Umfang der Ausgabe.

Warum ein größeres Kontextfenster keine bessere Informationsnutzung garantiert

Eine Anfrage kann ins Fenster passen und trotzdem eine Antwort liefern, die enthaltene Belege übersieht. Das ist ein Qualitätsfehler, auch wenn die API den Prompt akzeptiert.

Anthropic beschreibt in seinem Leitfaden zum Context Engineering, dass die Fähigkeit zum Wiederfinden von Informationen bei wachsendem Kontext nachlässt. Das muss sich nicht als auffällige Verweigerung äußern. Ein Assistent kann eine Ausnahme übersehen, eine alte Richtlinie mit ihrer Nachfolgefassung vermischen oder aus einer benachbarten Passage antworten, die nur relevant wirkt.

Die Forschungsarbeit Lost in the Middle von Nelson F. Liu und Kollegen zeigte: Sowohl beim Beantworten von Fragen zu Dokumenten als auch beim Abrufen von Schlüssel-Wert-Paaren hing die Leistung davon ab, an welcher Stelle die relevanten Informationen standen. Belege in der Mitte konnten schwerer zu nutzen sein als Belege nahe den Enden. Das sind frühere Forschungsergebnisse, kein Benchmark der aktuellen Modelle in der Tabelle.

Die Qualität bei langen Kontexten muss an der eigenen Aufgabe gemessen werden. Es gibt hier keine allgemeingültige Token-Zahl, ab der jedes Modell plötzlich unzuverlässig wird.

Für einen Support-Assistenten eignet sich ein kleiner Testsatz mit Ausnahmen von Richtlinien, deren korrekte Antworten bereits bekannt sind. Verglichen werden eine gezielte Anfrage mit der einschlägigen Richtlinie und eine längere Anfrage, die zusätzlich sachfremde Richtlinien enthält. Die entscheidende Passage wird nacheinander weiter vorn, in der Mitte und weiter hinten platziert. Anschließend wird geprüft, ob die Antwort die richtige Ausnahme anwendet und die passende Quelle nennt.

Bei einem Programmierassistenten bietet sich eine Frage an, deren Antwort sowohl von einer Implementierungsdatei als auch vom aufrufenden Code abhängt. Erst wenn die gezielte Anfrage zuverlässig beantwortet wird, kommen unbeteiligte Dateien hinzu. Wird die längere Variante schlechter, erklärt zusätzliche eingekaufte Kapazität nicht die Fehlerursache.

Findet das Modell einen markanten Satz erfolgreich wieder, ist das ein nützlicher Hinweis auf seine Abruffähigkeit. Es beweist aber nicht, dass es widersprüchliche Dokumente miteinander abgleichen oder alle Vorgaben über eine lange Aufgabe hinweg einhalten kann.

Was tun, wenn der Kontext zu lang wird?

In der Entwicklung muss die vollständig zusammengestellte Anfrage geprüft werden. Wer mit dem Assistenten arbeitet, sollte vor dem Fortsetzen der Sitzung den aktuellen Aufgabenstand sichern. In beiden Fällen ist zu unterscheiden: Wurde die Eingabe abgewiesen, oder brach die Antwort ab, weil kein Platz mehr übrig war?

Für aktuelle Claude-Modelle dokumentiert Anthropic einen Fehler wegen eines zu langen Prompts, wenn bereits die Eingabe allein das Fenster überschreitet. Passt die Eingabe hinein, erreicht aber die Generierung die Grenze, kann die Antwort stattdessen mit model_context_window_exceeded enden. Maßgeblich ist der tatsächliche Fehler oder Abbruchgrund. Es sollte nicht einfach unterstellt werden, dass das System alte Nachrichten stillschweigend entfernt hat. Claudes Verhalten bei Kontextüberschreitung.

1. 1

   Alles zählen, was die Anwendung sendet

   Anweisungen, Gesprächsnachrichten, Tool-Definitionen, abgerufene Passagen und Tool-Ergebnisse müssen gemeinsam betrachtet werden. Unterstützt die Token-Zählfunktion des Anbieters das verwendete Anfrageformat, lässt sich ihre Schätzung anschließend mit den Verbrauchsangaben der Antwort abgleichen. Anthropics Zähl-Endpunkt akzeptiert strukturierte Nachrichten und viele Eingabetypen, hat aber Einschränkungen bei serverseitigen Tools und manchen Dateiquellen.

2. 2

   Platz für die Generierung reservieren

   Fenstergröße, Ausgabelimit und benötigte Ausgabereserve des Modells werden festgehalten. Gegebenenfalls sind interne Denkschritte einzubeziehen. Das Eingabebudget muss entsprechend kleiner ausfallen; nicht jedes freie Token steht für ein weiteres Dokument zur Verfügung.

3. 3

   Das ständig wachsende Material finden

   Typische Kandidaten sind wiederholte Suchergebnisse, vollständige Logs, doppelte Dokumente und nicht weiterverfolgte Gesprächszweige. Ein Programmieragent braucht womöglich den fehlgeschlagenen Test und die relevante Funktion. Die vollständige Ausgabe jedes zuvor erfolgreichen Befehls benötigt er dagegen selten in jedem Schritt erneut. Erhalten bleiben sollten die Belege, mit denen sich die nächste Aktion überprüfen lässt.

4. 4

   Den Arbeitsstand für die Fortsetzung festhalten

   Vor einem Neustart oder einer Verdichtung werden Ziel, bestätigte Entscheidungen, offene Fragen, relevante Fundstellen und die nächste Aktion gesichert. Bei einem Kundenfall gehören die aktuelle Anfrage und die einschlägige Ausnahme von der Richtlinie dazu. Kommt es auf den genauen Wortlaut an, muss die Originalquelle erneut geöffnet werden.

5. 5

   Nach der Änderung die Richtigkeit prüfen

   Die fehlgeschlagene Aufgabe wird mit der kleineren Anfrage wiederholt. Dabei ist zu prüfen, ob die erforderlichen Belege noch enthalten sind und die Antwort stimmt. Passt der Prompt nun hinein, übersieht aber weiterhin das entscheidende Detail, müssen Auswahl und Wiederfinden der Informationen untersucht werden, statt blind weiter zu kürzen.

Liefert ein kurzer, stabiler Workflow bereits korrekte Antworten und hält seine Grenzen ein, besteht kein Anlass, die Modellwahl zu ändern. Ein größeres beworbenes Kontextfenster allein rechtfertigt keinen Wechsel.

Retrieval, Zusammenfassung, Verdichtung oder Caching: Was hilft wann?

Die passende Maßnahme hängt davon ab, was den Platz belegt. Diese Verfahren lösen unterschiedliche Probleme und lassen sich kombinieren.

Retrieval eignet sich, wenn die Quellensammlung viel größer ist als die für die Frage benötigte Belegmenge. Retrieval-Augmented Generation (RAG) stellt dem Modell ausgewähltes Quellenmaterial bereit, bevor es antwortet. Ein Support-Assistent sollte die zutreffende Rückgaberichtlinie und den Bestelldatensatz abrufen, statt die gesamte Wissensdatenbank zu lesen. Der Leitfaden zu agentischem RAG erklärt, wie ein Agent erneut suchen kann, wenn die ersten Belege nicht ausreichen.

Die Grenze liegt in der Auswahl: Übersieht das Retrieval die entscheidende Ausnahme, kann das Modell sie nicht nutzen. Erfordert die Aufgabe tatsächlich einen fortlaufenden Detailvergleich, sollte eine begrenzte Auswahl vollständiger Dokumente im Kontext bleiben. Dabei ist zu prüfen, ob eine weitere Eingrenzung notwendige Belege entfernt.

Eine Zusammenfassung hilft, wenn frühere Details in einen dauerhaft nutzbaren Aufgabenstand überführt werden können. Sie sollte festhalten, was entschieden wurde, was noch unklar ist und wo die zugehörigen Quellen liegen. Bei einer Codeänderung können das der gewählte Ansatz, das aktuell fehlerhafte Verhalten und die relevanten Dateipfade sein. Eine exakte Vertragsklausel oder Fehlermeldung darf nicht durch eine freie Umschreibung ersetzt werden, wenn die nächste Entscheidung von ihrem Wortlaut abhängt.

Verdichtung, auch Compaction genannt, hilft, wenn der Gesprächsverlauf selbst den meisten Platz beansprucht. Dabei wird der angesammelte Verlauf durch einen kleineren Kontext für die Fortsetzung ersetzt. Anthropic warnt davor, dass eine zu starke Komprimierung wichtige Details verlieren kann. Entscheidend ist deshalb zu prüfen, was erhalten bleibt, statt das verdichtete Gespräch als verlustfreies Archiv zu behandeln. Anthropics Erläuterung zur Verdichtung beschreibt diesen Zielkonflikt.

Der weiterführende Leitfaden zum Context Engineering zeigt, wie sich diese Inhalte über die Arbeit eines Agenten hinweg auswählen und pflegen lassen.

Prompt Caching hilft, wenn nützliche Eingaben wiederholt vorkommen. Es verwendet die bereits geleistete Verarbeitung eines übereinstimmenden Prompt-Präfixes erneut, also des unveränderten Anfangs der Anfrage. Stabile Anweisungen und gemeinsam genutztes Material gehören vor wechselnde Inhalte. Dabei gelten die Cache-Regeln des jeweiligen Modells: OpenAIs aktueller Leitfaden beschreibt auch das Verhalten expliziter Breakpoints, während die Modellseite von Gemini 4 Argon ausschließlich implizites Caching aufführt. Caching bei OpenAI, Caching-Unterstützung bei Gemini.

Lange Prompts erhöhen die Zahl der abrechenbaren Eingabe-Tokens. Cache-Treffer können die Kosten wiederholter Eingaben senken, wobei die Regeln für das Schreiben in den Cache zu beachten sind. Die Tokens belegen trotzdem weiterhin das Kontextfenster. Die Funktionsweise des Cachings behandelt ein eigener Beitrag.

Wird der Anfang eines Prompts verdichtet oder umgeschrieben, kann das die Wiederverwendung des Caches verringern. Ein stabiles Präfix sollte erhalten bleiben, solange es nützlich ist. Irrelevanter Verlauf sollte entfernt werden, sobald er die Anfrage beeinträchtigt. Eine hohe Cache-Trefferquote ist kein Beleg für eine gute Antwort.

Was wird bei langen Kontexten übertrieben dargestellt?

Die Kapazitätsangabe soll oft Dinge belegen, die sie gar nicht misst. Sie garantiert weder lückenloses Wiederfinden noch ein dauerhaftes Gedächtnis. Ebenso wenig zeigt sie, dass sich jeder Retrieval-Workflow durch einen größeren Prompt ersetzen lässt.

Ein größeres Fenster ist dann sinnvoll, wenn die Aufgabe mehr relevante Belege gleichzeitig benötigt, die kleinere Anfrage wesentliche Zusammenhänge verliert und die größere Variante in der eigenen Evaluation korrekte Ergebnisse liefert. Das ist ein belastbarer Grund, die Kapazität zu nutzen.

Handlungsbedarf besteht, wenn Logs, Verlauf oder Quellensammlungen den Platz für die Antwort verdrängen. Zuerst sollte verbessert werden, was überhaupt in die Anfrage gelangt. Ein größeres Modellfenster kommt infrage, wenn das relevante Material weiterhin nicht hineinpasst. Läuft der bestehende Workflow zuverlässig und reizt lediglich die größere Zahl im Datenblatt, kann der Wechsel warten.

Häufige Fragen zum Kontextfenster

Was ist das Kontextfenster eines KI-Sprachmodells?

Es ist die Token-Kapazität des Modells pro Anfrage für die berücksichtigte Eingabe und die erzeugte Ausgabe. Bei Reasoning-Modellen müssen nach den Regeln des Herstellers auch interne Denkschritte eingerechnet werden.

Wie viel passt in ein Kontextfenster mit 200K Tokens?

200K steht für 200,000 Tokens. Daraus ergibt sich keine feste Zahl von Wörtern oder Seiten. Ein gemeinsam genutztes Fenster muss außerdem Platz für die erzeugte Ausgabe lassen. Das Material sollte mit dem Tokenizer des gewählten Modells oder einem unterstützten Zähl-Endpunkt gezählt werden.

Was bedeutet Kontext beim Programmieren?

Kontext bezeichnet die umgebenden Informationen, die einer Operation zur Verfügung stehen. In einer LLM-Anwendung sind das die Anweisungen, Nachrichten und ergänzenden Materialien, die für die aktuelle Modellanfrage zusammengestellt werden.

Wie sieht Context Engineering in der Praxis aus?

Ein Support-Assistent erhält das aktuelle Ticket, die zutreffende Richtlinie und eine knappe Aufzeichnung früherer Entscheidungen. Bei Bedarf ruft er weitere Belege ab, statt das gesamte Ticketarchiv zu erhalten.

Wie viel verdienen Context Engineers?

Aus der Spezifikation eines Kontextfensters lässt sich kein Gehalt ableiten. Für eine Stellenbesetzung muss zunächst klar sein, ob die Arbeit Retrieval, Anwendungsentwicklung, Evaluationen oder Infrastruktur umfasst. Danach lassen sich Rollen mit diesem Aufgabenprofil am jeweiligen Standort vergleichen.

Wie lässt sich Context Engineering lernen?

Ein guter Einstieg ist, die vollständigen Anfragen einer kleinen Anwendung zu untersuchen. Anweisungen, abgerufene Belege und beibehaltener Verlauf werden jeweils einzeln verändert. Die Antworten werden mit bekannten korrekten Ergebnissen verglichen. Entscheidend ist erklären zu können, warum eine Änderung die Richtigkeit verbessert hat – nicht nur, warum der Prompt kürzer geworden ist.

Was unterscheidet Context Engineering von Prompt Engineering?

Prompt Engineering konzentriert sich auf die Anweisungen und Beispiele, die das Modell erhält. Context Engineering umfasst darüber hinaus die Auswahl von Belegen, die Bereitstellung von Tools und das Bewahren des passenden Arbeitsstands im weiteren Verlauf.

Welche Vorgehensweisen haben sich beim Context Engineering bewährt?

Die gesamte Anfrage braucht ein Token-Budget mit reserviertem Platz für die Ausgabe. Relevante Belege müssen erhalten bleiben; Zusammenfassungen sollten auf die Quellen verweisen. Nach dem Kürzen oder Verdichten ist zu prüfen, ob die Antwort weiterhin stimmt.

Welche Fähigkeiten brauchen Agenten für gutes Context Engineering?

Ein Agent braucht gezielte Möglichkeiten, Quellen zu finden, relevante Passagen zu prüfen und den Aufgabenstand zu sichern. Der Maßstab für diese Tools ist, ob ihre Ergebnisse die nächste Entscheidung unterstützen, ohne die Anfrage mit unnötigem Material zu überladen.

Der nächste praktische Schritt

Ausgangspunkt ist eine Anfrage, die gescheitert ist oder ein wichtiges Detail übersehen hat. Die vollständige Eingabe wird gezählt, Platz für die erwartete Ausgabe reserviert und der größte Inhaltsblock gesucht, der nichts zur Beantwortung der Frage beiträgt. An seine Stelle treten ausgewählte Belege oder eine Notiz zum Arbeitsstand. Anschließend wird die Aufgabe erneut ausgeführt und mit einer bekannten richtigen Antwort abgeglichen. Die kleinere Anfrage sollte nur beibehalten werden, wenn sie die Belege und das Ergebnis bewahrt.

Praktische Anleitungen für zuverlässige KI-Workflows gibt es im Newsletter.