Kontextfenster

Wenn Gespräche wachsen, näherst du dich irgendwann den Grenzen des Kontextfensters. Für lang laufende Gespräche und agentische Workflows ist die serverseitige Komprimierung die primäre Strategie für das Kontextmanagement.

Wie das Kontextfenster funktioniert

Das „context window“ (Kontextfenster) bezieht sich auf den gesamten Text, auf den ein Sprachmodell beim Generieren einer Antwort verweisen kann, einschließlich der Antwort selbst. Dies unterscheidet sich vom großen Datenbestand, auf dem das Sprachmodell trainiert wurde, und stellt stattdessen einen „Arbeitsspeicher“ für das Modell dar. Ein größeres Kontextfenster ermöglicht es dem Modell, komplexere und längere Prompts zu verarbeiten, aber mehr Kontext ist nicht automatisch besser. Mit wachsender Token-Anzahl nehmen Genauigkeit und Abrufleistung ab, ein Phänomen, das als context rot (Kontextverfall) bekannt ist. Dadurch wird die Auswahl dessen, was sich im Kontext befindet, genauso wichtig wie die Menge des verfügbaren Platzes.

Das folgende Diagramm veranschaulicht das Standardverhalten des Kontextfensters für API-Anfragen¹:

¹ Chat-Oberflächen wie claude.ai können das Kontextfenster auch rollierend nach dem Prinzip „first in, first out“ verwalten.

• Fortschreitende Token-Ansammlung: Während das Gespräch über mehrere Runden fortschreitet, sammeln sich jede Benutzernachricht und jede Assistentenantwort im Kontextfenster an, und vorherige Runden bleiben vollständig erhalten.
• Kapazität des Kontextfensters: Das Kontextfenster (bis zu 1M Token, je nach Modell) enthält den Gesprächsverlauf sowie die neue Ausgabe, die Claude generiert.
• Eingabe-Ausgabe-Fluss: Jede Runde besteht aus:
  • Eingabephase: Enthält den gesamten bisherigen Gesprächsverlauf sowie die aktuelle Benutzernachricht
  • Ausgabephase: Generiert eine Textantwort, die Teil der Eingabe für die nächste Runde wird

Alles in der Anfrage wird auf das Kontextfenster angerechnet: der System-Prompt, jede Nachricht in messages (einschließlich Tool-Ergebnissen, Bildern und Dokumenten) sowie deine Tool-Definitionen. Die Ausgabe, die Claude für die Runde generiert, einschließlich des erweiterten Nachdenkens, zählt ebenfalls. Jede Antwort gibt in ihrem Feld usage an, was die Anfrage verbraucht hat. Wenn du Prompt-Caching verwendest, wird die Eingabeanzahl auf input_tokens, cache_read_input_tokens und cache_creation_input_tokens aufgeteilt, und alle drei werden auf das Fenster angerechnet. Um eine Anfrage vor dem Senden abzuschätzen, verwende die Token-Counting-API.

Kontextfenstergrößen nach Modell

Claude Fable 5.1, Claude Mythos 5.1, Claude Fable 5, Claude Mythos 5, Claude Opus 5.5, Claude Opus 5, Claude Opus 4.8, Claude Opus 4.7, Claude Opus 4.6, Claude Sonnet 5.5, Claude Sonnet 5, Claude Sonnet 4.6 und Claude Mythos Preview haben ein Kontextfenster von 1M Token. Eine einzelne Anfrage an eines dieser Modelle kann bis zu 128k Ausgabe-Token (max_tokens) generieren. Andere Claude-Modelle, einschließlich Claude Sonnet 4.5, haben ein Kontextfenster von 200k Token.

Für jedes Modell mit einem Kontextfenster von 1M Token ist 1M der Standard: Du benötigst keinen Beta-Header, und Anfragen mit langem Kontext werden zu Standardpreisen abgerechnet.

Eine einzelne Anfrage kann bis zu 600 Bilder oder PDF-Seiten enthalten (100 bei Modellen mit einem Kontextfenster von 200k Token). Wenn du viele Bilder oder große Dokumente sendest, erreichst du möglicherweise die Größenlimits für Anfragen, bevor du das Token-Limit erreichst.

In der Tabelle zum Modellvergleich findest du eine Liste der Kontextfenstergrößen nach Modell.

Das Kontextfenster mit Nachdenken

Mit Nachdenken werden alle Eingabe- und Ausgabe-Token, einschließlich der Denk-Token, auf das Limit des Kontextfensters angerechnet, mit einigen Nuancen in Situationen mit mehreren Runden.

Denk-Token sind eine Teilmenge deines Parameters max_tokens, werden als Ausgabe-Token abgerechnet und auf Ratenlimits angerechnet. Mit adaptivem Nachdenken bestimmt Claude seine Denkzuteilung dynamisch, sodass die Nutzung von Denk-Token von Anfrage zu Anfrage variiert.

Ob Thinking-Blöcke aus vorherigen Assistentenrunden im Kontextfenster verbleiben, hängt vom Modell ab. Bei Claude Opus 4.5 und späteren Opus-Modellen, Claude Sonnet 4.6 und späteren Sonnet-Modellen, Claude Fable 5.1, Claude Mythos 5.1, Claude Fable 5, Claude Mythos 5 und Claude Mythos Preview behält die API vorherige Thinking-Blöcke standardmäßig bei, und sie werden wie alle anderen Eingabe-Token auf das Kontextfenster angerechnet. Bei früheren Opus- und Sonnet-Modellen sowie allen Haiku-Modellen entfernt die API vorherige Thinking-Blöcke automatisch aus dem Gesprächsverlauf, wenn du sie zurückgibst, wodurch Token-Kapazität für Gesprächsinhalte erhalten bleibt. Die Standardwerte pro Modell findest du unter Beibehaltung von Thinking-Blöcken nach Modell. Um den Standard in die eine oder andere Richtung zu überschreiben, verwende das Löschen von Thinking-Blöcken.

Das folgende Diagramm zeigt, wie Token verwaltet werden, wenn Nachdenken auf einem Modell aktiviert ist, das vorherige Thinking-Blöcke entfernt:

• Entfernen von Thinking-Blöcken: Bei Modellen, die vorherige Thinking-Blöcke entfernen, werden Thinking-Blöcke (dunkelgrau dargestellt) während der Ausgabephase jeder Runde generiert, aber nicht als Eingabe-Token in nachfolgende Runden übernommen. Du musst die Thinking-Blöcke nicht selbst entfernen: Wenn du sie zurückgibst, entfernt die Claude API sie automatisch.
• Abrechnung: Denk-Token werden einmalig als Ausgabe-Token abgerechnet, wenn sie generiert werden. Bei Modellen, die vorherige Thinking-Blöcke beibehalten, sind die beibehaltenen Blöcke dann Teil der Eingabe späterer Anfragen und werden wie der Rest des Gesprächsverlaufs als Eingabe-Token abgerechnet.

Das Kontextfenster mit Nachdenken und Tool-Nutzung

Das folgende Diagramm veranschaulicht, wie Token verwaltet werden, wenn du Nachdenken mit „tool use“ (Tool-Nutzung) auf einem Modell kombinierst, das vorherige Thinking-Blöcke entfernt:

1. 1

   Architektur der ersten Runde

   • Eingabekomponenten: Tool-Konfiguration und Benutzernachricht
   • Ausgabekomponenten: Nachdenken + Textantwort + Tool-Nutzungsanfrage
   • Token-Berechnung: Alle Eingabe- und Ausgabekomponenten werden auf das Kontextfenster angerechnet, und alle Ausgabekomponenten werden als Ausgabe-Token abgerechnet.
2. 2

   Verarbeitung von Tool-Ergebnissen (Runde 2)

   • Eingabekomponenten: Jeder Block der ersten Runde und das tool_result. Du musst den Thinking-Block zusammen mit den entsprechenden Tool-Ergebnissen zurückgeben. Dies ist der einzige Fall, in dem du Thinking-Blöcke zurückgeben musst.
   • Ausgabekomponenten: Nachdem die Tool-Ergebnisse an Claude zurückgegeben wurden, antwortet Claude nur mit Text (kein zusätzliches Nachdenken bis zur nächsten user-Nachricht, es sei denn, verschachteltes Nachdenken ist aktiviert).
   • Token-Berechnung: Alle Eingabe- und Ausgabekomponenten werden auf das Kontextfenster angerechnet, und alle Ausgabekomponenten werden als Ausgabe-Token abgerechnet.
3. 3

   Neue Benutzerrunde (Runde 3)

   • Eingabekomponenten: Alle Eingaben und die Ausgabe der vorherigen Runde werden übernommen. Der Thinking-Block aus dem abgeschlossenen Tool-Nutzungszyklus muss nicht mehr im Kontext bleiben: Bei Modellen, die vorherige Thinking-Blöcke entfernen, verwirft die API ihn automatisch, wenn du ihn zurückgibst, und bei Modellen, die vorherige Thinking-Blöcke beibehalten, bleibt er erhalten, sofern du ihn nicht mit dem Löschen von Thinking-Blöcken entfernst. Hier fügst du auch die nächste user-Runde hinzu.
   • Ausgabekomponenten: Da es eine neue user-Runde außerhalb des Tool-Nutzungszyklus gibt, generiert Claude einen neuen Thinking-Block und fährt von dort aus fort.
   • Token-Berechnung: Bei Modellen, die vorherige Thinking-Blöcke entfernen, werden die vorherigen Denk-Token nicht mehr auf das Kontextfenster angerechnet. Alle anderen vorherigen Blöcke werden weiterhin auf das Kontextfenster angerechnet, ebenso wie der Thinking-Block in der aktuellen assistant-Runde.

• Überlegungen zur Tool-Nutzung mit Nachdenken:
  • Wenn du Tool-Ergebnisse sendest, musst du den gesamten unveränderten Thinking-Block, der zu dieser Tool-Anfrage gehört, einschließlich seiner Signatur mitsenden.
  • Die API verwendet kryptografische Signaturen, um die Authentizität von Thinking-Blöcken zu überprüfen. Wenn du einen Thinking-Block veränderst, gibt die API einen Fehler zurück.

Um den von den Tool-Definitionen selbst verbrauchten Kontext zu reduzieren, siehe Tool-Kontext verwalten, oder verschiebe Tool-Definitionen mit dem Tool-Such-Tool.

Kontextbewusstsein

Claude Sonnet 5, Claude Sonnet 4.6, Claude Sonnet 4.5 und Claude Haiku 4.5 verfügen über „context awareness“ (Kontextbewusstsein): Diese Modelle verfolgen ihr verbleibendes Kontextfenster (ihr „Token-Budget“) über ein gesamtes Gespräch hinweg. Dadurch kann das Modell lang laufende Aufgaben anhand des verbleibenden Platzes steuern, anstatt zu raten, wie viele Token noch übrig sind. Kontextbewusstsein ist automatisch: Du musst nichts aktivieren, und du sendest die in diesem Abschnitt gezeigten Tags niemals selbst. Die API fügt sie ein.

So funktioniert es

Im System-Prompt jeder Anfrage teilt die API Claude sein gesamtes Kontextfenster mit:

<budget:token_budget>200000</budget:token_budget>

Das Budget entspricht dem für deine Anfrage verfügbaren Kontextfenster: 1M Token für Claude Sonnet 5 und Claude Sonnet 4.6 sowie 200k Token für Claude Sonnet 4.5 und Claude Haiku 4.5. Die Beispiele in diesem Abschnitt zeigen ein Modell mit einem Kontextfenster von 200k Token.

Nach jedem Tool-Aufruf gibt die API Claude ein Update zu seiner verbleibenden Kapazität:

<system_warning>Token usage: 35000/200000; 165000 remaining</system_warning>

Bild-Token sind in diesen Budgets enthalten.

Claude Opus 4.7 und spätere Opus-Modelle, Claude Sonnet 5.5, Claude Fable 5.1, Claude Mythos 5.1, Claude Fable 5 und Claude Mythos 5 erhalten diese eingefügten Tags nicht. Bei diesen Modellen kannst du dem Modell mit „task budgets" (Aufgabenbudgets), die sich in der Beta-Phase befinden, ein explizites Budget vorgeben.

Hinweise zum Prompting für die Nutzung des Kontextbewusstseins findest du unter Best Practices für das Prompting.

Kontext mit Komprimierung verwalten

Wenn deine Gespräche regelmäßig an die Grenzen des Kontextfensters stoßen, verwende die serverseitige Komprimierung. Die Komprimierung fasst frühere Teile des Gesprächs automatisch auf dem Server zusammen, sodass das Gespräch über das Limit des Kontextfensters hinaus fortgesetzt werden kann. Sie ist in der Beta-Phase für Claude 4.6 und spätere Modelle sowie Claude Mythos Preview verfügbar.

Für speziellere Anforderungen bietet die Kontextbearbeitung zusätzliche Strategien:

• Löschen von Tool-Ergebnissen: Lösche alte Tool-Ergebnisse in agentischen Workflows
• Löschen von Thinking-Blöcken: Verwalte Thinking-Blöcke, wenn du erweitertes Nachdenken verwendest

Gecachte Prompt-Präfixe belegen weiterhin das Kontextfenster: Prompt-Caching ändert, was du für diese Token bezahlst, nicht, ob sie angerechnet werden.

Verhalten bei Überlauf des Kontextfensters

Wenn bereits die Eingabe allein das Kontextfenster des Modells überschreitet, gibt die API bei jedem Modell einen 400 invalid_request_error („prompt is too long“) zurück.

Bei Claude-4.5-Modellen und neueren akzeptiert die API die Anfrage, wenn Eingabe-Token plus max_tokens die Größe des Kontextfensters überschreiten. Erreicht die Generierung dann das Limit des Kontextfensters, stoppt sie mit stop_reason: "model_context_window_exceeded". Bei früheren Modellen gibt die API stattdessen einen Validierungsfehler zurück. Um das Verhalten model_context_window_exceeded bei diesen Modellen zu aktivieren, verwende den Beta-Header model-context-window-exceeded-2025-08-26. Details findest du unter Stop-Gründe und Fallback.

Um innerhalb der Grenzen des Kontextfensters zu bleiben, verwende die Token-Counting-API, um die Token-Nutzung abzuschätzen, bevor du Nachrichten an Claude sendest.

Nächste Schritte