Context Window verstehen: Warum Größe nicht alles ist

1. Was ein Context Window wirklich ist

Ein Context Window ist die maximale Menge an Tokens, die ein Sprachmodell wie Claude in einer einzigen Anfrage gleichzeitig verarbeiten und aufeinander beziehen kann. Dazu zählen der System-Prompt, der komplette Gesprächsverlauf, alle Werkzeugausgaben und jeder Dateiinhalt, der in die Anfrage eingebettet wird. Wichtig ist die Abgrenzung zu einem Gedächtnis: Ein Context Window ist kein persistenter Speicher zwischen Sitzungen, sondern ein Arbeitsspeicher pro Anfrage, der bei jedem neuen Request aus den mitgesendeten Daten neu aufgebaut wird. Nichts außerhalb dieses Fensters beeinflusst die aktuelle Antwort, egal wie relevant es wäre.

Der Unterschied zwischen Tokens und Wörtern ist für die Praxis entscheidend. Ein Token entspricht im Englischen ungefähr vier Zeichen, im Deutschen durch Komposita und Umlaute oft etwas weniger. Quellcode tokenisiert noch einmal anders als Fließtext: Einrückungen, Klammern, Sonderzeichen und lange Variablennamen erzeugen mehr Tokens pro Zeile als natürliche Sprache. Wer die Größe seines Kontexts nur in Zeichen oder Zeilen denkt, unterschätzt regelmäßig, wie schnell ein Fenster bei größeren Dateien oder langen Log-Ausgaben gefüllt ist.

2. Context-Window-Größen im Überblick

Aktuelle Claude-Modelle bieten standardmäßig ein Context Window von 200.000 Tokens, für ausgewählte Modelle und Anwendungsfälle ist über eine Beta-Funktion ein erweitertes Fenster von bis zu einer Million Tokens verfügbar. Zum Vergleich: 200.000 Tokens entsprechen grob 500 Seiten Text oder mehreren tausend Zeilen Quellcode, je nach Sprache und Formatierung. Das klingt großzügig, füllt sich aber überraschend schnell, sobald mehrere große Dateien, ein langer Gesprächsverlauf und Tool-Ausgaben wie Testprotokolle oder Build-Logs zusammenkommen.

Wichtig ist die Trennung zwischen Input-Kontext und maximaler Output-Länge. Das Context Window begrenzt, wie viel der Assistent lesen und in seine Antwort einbeziehen kann, die Output-Grenze begrenzt unabhängig davon, wie lang eine einzelne Antwort ausfallen darf. Beide Werte teilen sich nicht denselben Topf, aber beide zusammen bestimmen, wie ein Modell in einer einzigen Anfrage überhaupt sinnvoll strukturierten Code liefern kann. Wer ein riesiges Refactoring in einer einzigen Antwort erwartet, stößt eher an die Output-Grenze als an das Context Window selbst.

#!/usr/bin/env bash
# Claude Code: current token usage and session cost for the active session
claude
> /cost
# Token usage:  118,432 / 200,000 (59%)
# Cache reads:   84,120 tokens (cached, cheap)
# Cache writes:  12,300 tokens
# Session cost:  $0.94

# Compact the conversation when it grows large but the topic is still relevant
> /compact
# Summarizing conversation history into a condensed context...
# Context reduced from 118,432 to 21,050 tokens

3. Warum Größe nicht gleich Qualität ist

Ein größeres Context Window bedeutet nicht, dass das Modell jeden Token gleich gut versteht oder gleich stark gewichtet. Intern verteilt der Attention-Mechanismus Aufmerksamkeit über alle Tokens im Fenster, und je mehr davon vorhanden sind, desto mehr konkurriert jeder einzelne Token um Relevanz. Untersuchungen zu diesem Effekt, oft unter dem Namen „Lost in the Middle" bekannt, zeigen, dass Modelle Informationen am Anfang und Ende eines langen Kontexts zuverlässiger wiederfinden als Informationen, die in der Mitte vergraben sind.

Für die Praxis bedeutet das: Wer eine gesamte Codebase mit hunderten Dateien in eine Anfrage kopiert und dann nach einem einzelnen Bug in einer bestimmten Funktion fragt, erhöht das Risiko, dass genau diese Funktion in der Aufmerksamkeitsverteilung untergeht. Ein kleinerer, gezielt kuratierter Kontext mit den tatsächlich relevanten Dateien liefert häufig präzisere Antworten als ein riesiger, aber unstrukturierter Kontext, selbst wenn das Token-Budget theoretisch ausreichen würde. Größe ersetzt keine Relevanz.

4. Wie Tokenisierung den Context Window füllt

Claude nutzt einen Byte-Pair-Encoding-basierten Tokenizer, der Text in Teilwörter oder einzelne Zeichen zerlegt, abhängig davon, wie häufig eine Zeichenfolge im Trainingskorpus vorkam. Häufige englische Wörter werden oft zu einem einzigen Token, seltene Fachbegriffe, Variablennamen in camelCase oder generierte IDs zerfallen dagegen in mehrere Tokens. Ein Pfad wie node_modules/@vendor/paket/dist/index.min.js kann allein schon ein Dutzend Tokens verbrauchen, bevor überhaupt Nutzcode gelesen wurde.

Deshalb lohnt es sich, vor einer großen Anfrage grob abzuschätzen, wie viele Tokens eine Datei oder ein Verzeichnis tatsächlich benötigt, statt sich auf die Dateigröße in Kilobyte zu verlassen. Die Anthropic API bietet dafür einen eigenen Zähl-Endpunkt, der die exakte Tokenanzahl eines geplanten Requests zurückgibt, bevor überhaupt Kosten entstehen. Wer regelmäßig mit großen Repositories arbeitet, sollte generierte Verzeichnisse wie vendor, node_modules oder Build-Artefakte konsequent aus dem Kontext ausschließen, da sie Tokens verbrauchen, ohne inhaltlichen Mehrwert zu liefern.

# Estimate token usage before sending a large request
import anthropic

client = anthropic.Anthropic()

with open("app/code/Mironsoft/SeoSuite/Model/MetaGenerator.php") as f:
    file_content = f.read()

response = client.messages.count_tokens(
    model="claude-sonnet-4-5",
    system="You are a senior PHP/Magento developer.",
    messages=[
        {"role": "user", "content": f"Review this file:\n\n{file_content}"}
    ],
)

print(f"Estimated input tokens: {response.input_tokens}")
# Estimated input tokens: 3842
# Run this check before dumping an entire directory into a prompt

5. Prompt Caching: Kosten und Latenz bei wiederverwendetem Kontext

Prompt Caching adressiert ein praktisches Problem: Wer in mehreren aufeinanderfolgenden Anfragen denselben großen Systemkontext, etwa eine CLAUDE.md-Datei oder mehrere Referenzdateien, erneut mitschickt, zahlt und wartet jedes Mal für die vollständige Verarbeitung dieses Kontexts. Mit cache_control markierte Blöcke werden serverseitig zwischengespeichert, sodass nachfolgende Anfragen mit identischem Präfix diesen Teil nicht erneut vollständig verarbeiten müssen. Das reduziert sowohl Latenz als auch Kosten spürbar, besonders bei iterativen Coding-Sessions mit stabilem Projektkontext.

Wichtig ist, dass Prompt Caching kein Ersatz für ein durchdachtes Context Window ist, sondern eine Optimierung obendrauf. Der zwischengespeicherte Kontext muss weiterhin innerhalb des Context Windows Platz finden, und ein aufgeblähter, unstrukturierter Kontext bleibt auch mit Caching ein Aufmerksamkeitsproblem. Caching lohnt sich vor allem für stabile, selten wechselnde Inhalte am Anfang eines Prompts, während sich häufig wechselnde Nutzeranfragen ans Ende gehören, da jede Änderung vor einem Cache-Block dessen Wiederverwendbarkeit zunichtemacht.

{
  "model": "claude-sonnet-4-5",
  "system": [
    {
      "type": "text",
      "text": "Project context: Magento 2.4.8, PHP 8.4, Hyva Theme, PHPStan Level 5. [... full CLAUDE.md content, several thousand tokens ...]",
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "messages": [
    {
      "role": "user",
      "content": "Fix the null pointer issue in MetaGenerator::generate()"
    }
  ]
}

6. Context-Management in Claude Code

Claude Code begegnet dem Problem des überladenen Kontexts strukturell, indem es dem Modell gezielte Werkzeuge statt einer pauschalen Volltextübergabe an die Hand gibt. Statt eine komplette Codebase in den Prompt zu kopieren, nutzt der Agent Grep und Glob, um relevante Dateien anhand von Mustern und Suchbegriffen zu finden, und liest anschließend nur die tatsächlich benötigten Ausschnitte mit gezieltem Offset und Zeilenlimit. Dieser Grep-first-Ansatz hält den Kontext klein und fokussiert, selbst in Repositories mit zehntausenden Dateien.

Eine CLAUDE.md-Datei im Projektroot ergänzt diesen Ansatz, indem sie stabiles Projektwissen wie Coding-Standards, Verzeichnisstruktur und wiederkehrende Befehle einmalig kondensiert bereitstellt, statt es in jeder Sitzung neu zu erklären. Das reduziert den Kontext-Overhead massiv im Vergleich dazu, bei jeder Anfrage denselben Erklärungstext oder gar ganze Referenzdateien erneut einzufügen. Der größte Anti-Pattern in der Praxis bleibt trotzdem verbreitet: ein komplettes Verzeichnis per cat oder Copy-Paste in den Prompt zu werfen, in der Hoffnung, dass „mehr Kontext gleich bessere Antwort" bedeutet.

#!/usr/bin/env bash
# Grep-first: find the relevant file before reading anything into context
rg -l "MetaGenerator" app/code/Mironsoft/SeoSuite --type php

# Read only the matching lines plus a bit of surrounding context
rg -n -A 5 -B 5 "function generate" \
  app/code/Mironsoft/SeoSuite/Model/MetaGenerator.php

# Anti-pattern to avoid: dumping the whole module into the prompt
# cat app/code/Mironsoft/SeoSuite/**/*.php > /tmp/everything.txt

7. Sub-Agents und Kontext-Isolation

Für komplexe Aufgaben wie große Refactorings, Code-Reviews über mehrere Module oder Recherchen über eine unbekannte Codebase bietet sich Kontext-Isolation über Sub-Agents an. Ein Sub-Agent erhält ein eigenes, schlankes Context Window, das nur für seine spezifische Teilaufgabe relevant ist, arbeitet darin unabhängig vom Hauptkontext und liefert am Ende ein kondensiertes Ergebnis zurück, statt den kompletten Rechercheweg in den übergeordneten Kontext zu schreiben. Der Hauptkontext bleibt dadurch über eine lange Session hinweg schlank und fokussiert.

Dieses Muster ist besonders wertvoll, wenn eine Aufgabe viele Zwischenschritte mit hohem Tokenverbrauch benötigt, etwa das Durchsuchen dutzender Dateien nach einem Muster, deren Ergebnis am Ende aber nur wenige Zeilen Zusammenfassung braucht. Ohne Sub-Agent würden all diese Zwischenschritte den Hauptkontext füllen und damit die Aufmerksamkeit für die eigentliche Aufgabe verwässern. Mit Sub-Agent bleibt nur das relevante Endergebnis im Hauptkontext sichtbar, während die aufwendige Suche in einem separaten, wegwerfbaren Kontext stattfindet.

8. Session-Hygiene: Wann komprimieren, wann neu starten

Auch innerhalb des verfügbaren Token-Budgets sammelt sich in langen Sitzungen Ballast an: verworfene Lösungsansätze, veraltete Fehlermeldungen, längst behobene Bugs und Zwischenstände, die für die aktuelle Aufgabe keine Relevanz mehr haben, aber weiterhin Aufmerksamkeit binden. Claude Code bietet dafür den Befehl /compact, der den bisherigen Verlauf zu einer kompakten Zusammenfassung verdichtet und dabei nur die für die weitere Arbeit relevanten Informationen behält. Das unterscheidet sich von /clear, das den gesamten Kontext vollständig zurücksetzt und für einen echten Themenwechsel gedacht ist.

Die Faustregel in der Praxis: Wenn eine neue Aufgabe fachlich nichts mit der vorherigen zu tun hat, etwa der Wechsel von einem Bugfix im Checkout zu einer neuen Funktion im Backend, lohnt sich ein /clear mehr als ein /compact, selbst wenn theoretisch noch reichlich Tokenbudget übrig wäre. Ein sauberer Neustart mit gezielt geladenem Kontext liefert zuverlässigere Ergebnisse als eine lange Session, die zwar noch innerhalb des Limits liegt, aber gedanklich mehrere unzusammenhängende Themen mitschleppt.

// Simple heuristic to flag files that would consume a large token share
// before including them in a prompt (rough estimate: ~4 chars per token)
const fs = require('fs');

function estimateTokens(filePath) {
  const content = fs.readFileSync(filePath, 'utf8');
  return Math.ceil(content.length / 4);
}

function shouldWarnBeforeIncluding(filePath, budgetTokens = 200000) {
  const estimated = estimateTokens(filePath);
  const threshold = budgetTokens * 0.05; // more than 5% of the window
  if (estimated > threshold) {
    console.warn(
      `${filePath}: ~${estimated} tokens, consider reading a slice instead`
    );
  }
  return estimated;
}

shouldWarnBeforeIncluding('var/log/exception.log');

9. Anti-Patterns und bewährte Strategien im Vergleich

Die folgenden Gegenüberstellungen fassen zusammen, welche Gewohnheiten den Context Window unnötig belasten und welche Alternativen in der Praxis zuverlässigere Ergebnisse liefern.

Keines dieser Patterns ist eine Frage der reinen Tokenanzahl. Ein Context Window mit ausreichend freiem Budget kann trotzdem schlechte Antworten liefern, wenn der Inhalt unstrukturiert und irrelevant ist, während ein knapper, aber gezielt kuratierter Kontext oft die präziseren Ergebnisse liefert. Die Wahl der richtigen Strategie hängt von der Aufgabe ab, nicht von der bloßen Verfügbarkeit von Tokens.

10. Zusammenfassung

Ein Context Window ist im Kern ein Token-Budget pro Anfrage, kein Ersatz für Gedächtnis und keine Garantie für Qualität allein durch Größe. 200.000 bis eine Million Tokens klingen großzügig, füllen sich aber schnell durch Quellcode, Logs und lange Gesprächsverläufe, und selbst innerhalb des Budgets sinkt die Zuverlässigkeit, wenn relevante Informationen in einem überladenen Kontext untergehen. Tokenisierung behandelt Code anders als Fließtext, Prompt Caching reduziert Kosten und Latenz bei wiederverwendetem Kontext, ersetzt aber keine durchdachte Kuratierung.

In Claude Code zeigt sich das praktisch: Grep-first-Suche statt Volltextdumps, eine CLAUDE.md für stabiles Projektwissen, Sub-Agents für Kontext-Isolation bei komplexen Teilaufgaben und /compact beziehungsweise /clear für Session-Hygiene halten den Kontext fokussiert. Wer diese Werkzeuge konsequent nutzt, bekommt zuverlässigere Antworten bei geringerem Tokenverbrauch, unabhängig davon, wie groß das theoretische Fenster des verwendeten Modells ist.

11. FAQ: Context Window verstehen