1 Million Token Kontext: so fütterst du den Agenten richtig

Seit Ende Juni ist Sonnet 5 der Default in Claude Code — mit einem nativen Kontextfenster von einer Million Token. Das sind, grob gerechnet, mehrere zehntausend Zeilen Code plus Doku plus Tickets, in einem einzigen Aufruf.

Und trotzdem beobachte ich in fast jedem Team denselben Arbeitsstil wie vor zwei Jahren: eine Datei öffnen, einfügen, fragen. Der Agent bekommt Schlüssellöcher, wo er das ganze Gebäude sehen könnte. Wer mit 1 Million Token Kontext so arbeitet wie mit 8'000, verschenkt nicht ein bisschen Leistung — er verschenkt die eigentliche Kategorie des Sprungs.

Was grosser Kontext wirklich ändert

Der Unterschied ist nicht „mehr vom Gleichen". Es sind Aufgaben, die vorher schlicht nicht gingen:

• Subsysteme statt Dateien übergeben. Das ganze Modul, seine Tests, seine Migrationen, die angrenzenden Interfaces — der Agent sieht die Beziehungen, statt sie zu raten. Die typischen „das kompiliert, passt aber nicht zur Architektur"-Fehler entstehen genau dort, wo dem Modell der Rand fehlte.
• Architektur-Review über die echte Codebase. „Hier sind unsere Schichten — wo verletzen wir sie?" war mit kleinen Fenstern ein Sampling-Spiel. Jetzt ist es eine ehrliche Frage über den tatsächlichen Code.
• Migrationsarbeit mit Gedächtnis. Ein Upgrade über dutzende Dateien, bei dem der Agent Konvention und Sonderfälle aus dem ganzen bisherigen Diff kennt, statt sie pro Datei neu zu erfinden.
• Dokumente und Code zusammen. Spezifikation, ADRs, das Ticket und der betroffene Code in einem Kontext — die Übersetzungsverluste zwischen „was gemeint war" und „was gebaut wird" schrumpfen messbar.

Wo grosser Kontext schadet

Ehrlicherweise: Eine Million Token ist ein Werkzeug, kein Default. Drei Gegenkräfte, die man kennen muss:

1. Verwässerung. Relevanz ist keine Funktion der Menge. Wer wahllos das Repo hineinkippt, macht die entscheidenden zwanzig Zeilen zur Nadel im Heuhaufen — Modelle gewichten prominent Platziertes und Wiederholtes, nicht automatisch das Wichtige.
2. Kosten und Latenz. Grosse Kontexte kosten linear Geld und Zeit, bei jedem Aufruf. Ein 800k-Kontext für eine Ein-Zeilen-Änderung ist Verschwendung mit Ansage. (Bis Ende August gilt für Sonnet 5 noch Aktionspreis — danach rechnet sich Disziplin doppelt.)
3. Falsche Sicherheit. „Er hat ja alles gesehen" ersetzt kein Review. Der Agent mit vollem Kontext macht plausiblere Fehler — die schwerer auffallen. Die Review-Disziplin wird wichtiger, nicht unwichtiger.

Und: Retrieval ist nicht tot. Für Frage-Antwort über grosse Wissensbestände bleibt gezielte Suche billiger und oft präziser. Grosser Kontext gewinnt dort, wo Zusammenhang die Aufgabe ist — nicht Nachschlagen.

Die Faustregel: Kontext folgt Blast-Radius

Meine Arbeitsregel, die sich bewährt hat:

Gib dem Agenten so viel Kontext, wie die Änderung Schaden anrichten kann.

• Tippfehler, Ein-Datei-Fix: die Datei. Fertig.
• Feature innerhalb eines Moduls: das Modul + seine Tests + die Interfaces, die es berührt.
• Querschnitt (Auth, Logging, Datenmodell): die betroffenen Subsysteme + Architektur-Doku + ein, zwei Referenz-Implementierungen der Konvention.
• Architektur-Entscheid oder Review: so viel echte Codebase wie möglich, plus ADRs — hier zahlt sich die Million aus.

Der Nebeneffekt dieser Regel: Sie zwingt dich, den Blast-Radius vor dem Prompt zu bestimmen — und genau diese Überlegung ist die halbe Spezifikation.

Was du diese Woche tun kannst

Nimm eine echte Aufgabe mit Querschnitt-Charakter und fahr sie doppelt: einmal in deinem gewohnten Datei-für-Datei-Stil, einmal mit dem ganzen betroffenen Subsystem im Kontext. Vergleich nicht nur das Ergebnis, sondern die Zahl deiner Korrektur-Prompts. Der Unterschied ist das Argument — in die eine oder die andere Richtung.

Mehr davon — Agenten-Workflows, MCP, Engineering-Disziplin im KI-Alltag — gibt es regelmässig im Blog und im Newsletter: dort anmelden, wo der nächste Deepdive zuerst landet.