1M-Kontext-Fenster in Claude Code

Kontext-Limits waren der laufende Ärger in Claude Code seit dem Launch. Dieser Schmerz ist gerade kleiner geworden. Anthropic hat das 1-Mio.-Token-Fenster für Opus 4.6 und Sonnet 4.6 aktiviert, ohne Beta-Flag, ohne Aufpreis und ohne Warteliste. Max-, Team- und Enterprise-Pläne haben es bereits aktiviert.

Denk daran weniger als Versions-Bump und mehr als 5x den Arbeitsspeicher, den dein Agent mit sich trägt. Dieser Speicher hält deine Codebasis, deine Tool-Call-Historie und die Reasoning-Kette über lange Läufe. Preise bleiben auch gleich. Eine 900-K-Token-Anfrage kostet gleich viel pro Token wie eine 9-K-Anfrage.

Nutze diese Seite, um zu verstehen, was das 1-Mio.-Fenster auf Produkt- und Workflow-Ebene geändert hat. Wenn deine eigentliche Frage ist, wann Kompaktierung feuert und wie der reservierte Puffer sich verhält, lies Claude Code Context Buffer. Wenn deine Frage ist, ob du eine Session fortsetzen, kompaktieren, zurückspulen oder neu starten sollst, lies Context Management.

200K vs. 1M auf einen Blick

Was sich bei GA wirklich geändert hat

Das große Fenster war monatelang in der Beta. GA geht darum, die Friction zu beseitigen, die Beta wie zweite Klasse anfühlen ließ.

Flat Pricing über das gesamte Fenster. Long Context trägt keinen Aufpreis mehr. Opus 4.6 ist $5/$25 pro Million Token (Input/Output). Sonnet 4.6 ist $3/$15. Deine 10-K-Anfrage und deine 950-K-Anfrage werden zum gleichen Pro-Token-Satz abgerechnet.

Volle Rate-Limits überall. Längere Anfragen wurden während der Beta stärker gedrosselt. Diese Begrenzung ist weg. Ein 1-Mio.-Token-Aufruf zieht denselben Durchsatz wie ein kurzer.

600 Medienelemente in einer Anfrage. Bilder und PDF-Seiten hatten früher eine Obergrenze von 100. Die neue Obergrenze ist 6x höher bei 600. Für Design-System-Arbeit, Dokument-Review oder Vertragssammlungen ist das ein echter Gewinn.

Kein Header-Toggle. Anfragen über 200K brauchten früher einen anthropic-beta-Header. Bestehende Header werden jetzt einfach ignoriert. Die API übernimmt es.

Live auf Multi-Cloud. Du bekommst das 1-Mio.-Fenster auf Claude Platform, Microsoft Azure Foundry und Google Cloud Vertex AI.

Warum Claude Code sich jetzt anders anfühlt

API-Nutzer bekommen hier einen Preis- und Komfort-Gewinn. Claude Code-Nutzer bekommen etwas Strukturelles.

Kompaktierung feuert seltener

Jeder, der Claude Code bei echter Arbeit gefordert hat, kennt die Kompaktierungssteuer. Du lädst Dateien, kettst Tool-Calls, baust Reasoning auf, und dann feuert Auto-Kompaktierung. Claude quetscht die Konversation, um Platz zu schaffen. Nuancen gehen verloren. Edge Cases verschwinden. Multi-Step-Aufgaben verlieren den Faden mittendrin.

Jon Bell, Anthropics CPO, hat eine Zahl genannt: Kompaktierungsereignisse sind seit dem großen Fenster um 15% gesunken. Kein Lab-Benchmark. Das ist an echtem Claude Code-Traffic gemessen. Agenten behalten ihren Kontext und arbeiten stundenlang durch, ohne zu vergessen, was sie am Anfang geladen haben.

Neugierig auf die Mechanik, wann Kompaktierung feuert? Schau dir den Context-Buffer-Management-Guide an. Die Kurzversion: Claude Code hält einen Puffer von ungefähr 33K Token zurück, dann kompaktiert es, wenn die Nutzung ungefähr 83,5% erreicht. Eine 1-Mio.-Obergrenze bedeutet, du hast ungefähr 5x den Raum, bevor du diese Linie erreichst.

Ganze Codebasen auf einmal

Bei 200K hattest du ungefähr 150K Token Arbeitsraum, sobald der Puffer reserviert war. Für ein kleines Repo okay. Schmerzhaft bei allem Größeren, weil du ständig Dateien aussuchen musstest.

Erhöhe das auf 1M und dein nutzbarer Spielraum ist ~830K. Das sind Tausende von Source-Dateien. Ein ganzes Monorepo. Vollständige Docs neben dem Code, den sie beschreiben. Claude kann den API-Layer und das Frontend, das ihn aufruft, halten; die Migration und das Schema, das sie ändert; die Test-Datei und den Code, der getestet wird. Alles auf einmal. Du hörst auf, von Hand auszuwählen, welche Dateien geladen werden sollen.

Agent-Traces, die wirklich fertig werden

Das ist die Auszahlung für Agent-Teams und komplexe Orchestrierungs-Läufe. Jeder Tool-Call, jeder Reasoning-Schritt, jedes File-Read stapelt sich in den Kontext. Bei 200K hat eine Multi-Agent-Session bei echter Arbeit das Budget in 20 bis 30 Minuten durchgekaut.

Anton Biryukov, ein Software-Engineer bei Ramp, beschrieb das alte Muster: "Claude Code kann 100K+ Token verbrauchen, wenn es Datadog, Braintrust, Datenbanken und Source Code durchsucht. Dann setzt Kompaktierung ein." Bei 1M sucht er, sucht nochmal, sammelt Edge Cases und liefert Fixes. Alles in einer Session. Nichts geht auf dem Weg verloren.

Kann das Modell wirklich 1M Token nutzen?

Ein riesiger Kontext ist wertlos, wenn das Modell nicht wirklich über das abrufen und reasoning kann, was darin steckt. Anthropic hat zwei Benchmarks laufen lassen, die genau das bei der 1-Mio.-Marke testen.

Opus 4.6 erzielt 78,3% auf MRCR v2 bei 1M Token. MRCR (Multi-Round Coreference Resolution) prüft, ob ein Modell Entitäten und die Verbindungen zwischen ihnen über einen riesigen Prompt hinweg verfolgen kann. Nahezu 80% Genauigkeit über eine Million Token bedeutet, das Modell speichert nicht nur die Wörter. Es weiß noch, wie weit entfernte Teile verbunden sind.

Sonnet 4.6 erzielt 68,4% auf GraphWalks BFS bei 1M Token. Dieser Test misst, wie gut das Modell Graphstrukturen traversiert, die tief in langen Inputs vergraben sind. Kann es Referenzketten über Hunderttausende von Token hinweg verfolgen? Beide Werte werden als Top-Ergebnisse für Frontier-Modelle bei diesen Kontextlängen aufgeführt.

In der Praxis bedeutet das, dass Claude die Helper-Funktion, die du vor 500K Token definiert hast, noch lokalisieren und sehen kann, wie sie in die Komponente einhakt, die du gerade bearbeitest.

So nutzt du es in deinem Workflow

Ändere, was du tust

Hör auf, Datei-Inklusionen manuell zu verwalten. Jeder @file-Aufruf war bei 200K ein Tradeoff. Bei 1M lad einfach, was du brauchst, und mach weiter. Zieh die Test-Datei mit der Implementierung rein. Zieh die Types mit der Komponente. Gib Claude das gesamte Bild.

Lass Sessions länger laufen. Die Gewohnheit, alle 30 Minuten neu zu starten, kam aus dem Überlebenstrieb, nicht aus Präferenz. Mit dem 5-fachen Ceiling kann eine Session stundenlang bei schwierigen Aufgaben laufen. Starte neu, wenn du den Fokus wirklich wechselst, nicht weil du nervös wegen des Puffers bist. Für Regeln, wann zu kompaktieren und wann weiterzumachen, schau dir den Context-Management-Guide an.

Setz auf Multi-Step-Agenten. Die eigentliche Auszahlung ist nicht das schnelle Edit. Es ist die Art von Arbeit, bei der Claude recherchieren, planen, implementieren und über viele Dateien hinweg prüfen muss. Diese Kette brach früher, wenn Kompaktierung mitten in der Aufgabe feuerte. Sie passt jetzt in ein Fenster ohne Drama.

Überdenke dein Context-Engineering-Playbook. Deine Lade- und Preservation-Strategien zählen weiterhin. Sie haben nur mehr Sauerstoff. Die Grundlagen aus unserem Context-Management-Guide gelten weiterhin. Der Druck verschiebt sich von "unter 200K am Leben bleiben" zu "1M gut nutzen".

Wo das 1-Mio.-Fenster wirklich Ergebnisse verändert

Der beste Weg, über 1M Kontext nachzudenken, ist nicht "Claude kann mehr lesen." Es ist "ganze Klassen von Aufgaben hören auf, sich brüchig anzufühlen."

1. Cross-Layer-Bug-Jagden

Altes Muster bei 200K:

• Frontend laden
• bemerken, dass das Problem vielleicht in der API liegt
• einige Dateien entladen
• API laden
• erkennen, dass der Bug auch vom Schema oder einer Migration abhängt
• Kompaktierung mitten drin und frühe Hinweise verlieren

Bei 1M kannst du oft die Seiten-Komponente, den API-Handler, das Schema, die Migration und den fehlschlagenden Test alle in einer Session halten. Das ist nicht nur bequem. Es verändert die Root-Cause-Qualität.

2. Sicherheits-Review über eine echte System-Grenze

Sicherheits-Reviews sind kontexthungrig, weil das Problem selten in einer Datei lebt.

Ein ernsthafter Review braucht vielleicht:

• Auth-Middleware
• Session-Handling
• Reset-Password-Flow
• Rate-Limit-Logik
• Audit-Logs
• die Route-Handler, die die Oberfläche exponieren

Bei 200K wähltest du, welchen Layer du weglässt. Bei 1M kannst du den gesamten Flow reviewen und bessere Fragen über Takeover-Risk, Replay-Risk und Privilege-Boundary-Fehler stellen.

3. Monorepo-Änderungen ohne manuelle Datei-Kuration

Bei 200K wurde große-Repo-Arbeit oft zu Kontext-Buchhaltung. Du verbringst die halbe Session damit zu entscheiden, was Claude sehen darf.

Bei 1M passt eine Migration über:

• shared Types
• API-Contracts
• Frontend-Caller
• Integrationstests

viel natürlicher. Du brauchst weiterhin Scope-Disziplin. Du hörst nur auf, alle zehn Minuten Token-Triage zu machen.

4. Langes Dokument- und Design-Review

Das größere Fenster zählt auch außerhalb von Code. Produkt-Specs, Design-Docs, Architektur-Notizen, PDFs, Screenshots und verwandte Implementierungsdateien können alle in derselben Anfrage bleiben. Das macht "Spec-to-Implementation" und "Design-to-Code"-Arbeit viel stabiler.

Wie du erkennst, ob du wirklich 1M brauchst

Du profitierst wahrscheinlich vom größeren Fenster, wenn deine Sessions regelmäßig eines oder mehrere davon beinhalten:

Wenn deine Arbeit meistens schnelle Edits, kleine Repos oder kurze, fokussierte Sessions ist, ist 1M schön, aber nicht transformativ. Der Gewinn zeigt sich bei breiteren Aufgaben, wo Kontext früher die Haupt-Einschränkung war.

Was sich nicht ändert

Kontext-Hygiene zählt weiterhin. Eine 1-Mio.-Obergrenze ist kein Signal, alles reinzuwerfen und zu hoffen, dass Claude es sortiert. Irrelevante Dateien verbrennen Token und verdünnen das Signal, das Claude nutzt, um sich zu fokussieren.

CLAUDE.md, Skills-First-Loading und sauberes Session-Management sind weiterhin Best Practice. Sie bekommen nur mehr Luft zum Atmen. Wenn du die Nutzungs-Optimierungs-Muster bereits befolgst, zahlt das große Fenster dir noch mehr zurück.

Wer das 1-Mio.-Fenster bekommt

Claude Code-, Max-, Team- und Enterprise-Pläne bekommen das 1-Mio.-Fenster automatisch mit Opus 4.6. Nichts zu aktivieren. Die zusätzliche Nutzungs-Zuweisung, die Long-Context-Anfragen früher brauchten, ist weg.

API-Nutzer bekommen es zu Standard-Per-Token-Raten. Opus 4.6 bei $5/$25 pro Million Token. Sonnet 4.6 bei $3/$15. Keine Premium-Stufe für Long Context.

Das 200K-Fenster ist noch da als Standard für Standard-API-Anfragen und niedrigere Pläne. Die 1-Mio.-Option ist speziell an Opus 4.6 und Sonnet 4.6 gebunden.

Was das signalisiert

Anthropic macht Kontext-Fenster nicht nur größer. Sie streichen die Tradeoffs, die große Fenster nervig zu nutzen machten. Flat Pricing bedeutet, du planst keine langen Anfragen anders. Volle Rate-Limits bedeuten, du verlierst keinen Durchsatz. Den Beta-Header töten bedeutet, bestehender Code läuft einfach.

Die Richtung ist offensichtlich. Kontext-Management verlagert sich von einem Nutzer-Job zu einem Infrastruktur-Job. Modelle werden immer besser darin, Long Context zu nutzen. Preisgestaltung hält die Tür offen. Das Tooling sortiert sich selbst.

Für Claude Code-Nutzer ist das Fazit einfach. Deine Agenten denken länger und erinnern sich mehr. Bau deine Workflows darauf auf, und die Aufgaben, die früher sorgfältiges Session-Management und handverlesene Kontexte verlangten, fangen einfach an zu funktionieren. Von Anfang bis Ende. In einem Fenster.

Verwandte Ressourcen

• Context Buffer Management -- Wie Auto-Kompaktierung funktioniert und der 33K-Token-Puffer
• Context Engineering -- Das Sechs-Säulen-Framework zum strategischen Laden von Kontext
• Context Management -- Strategien, um kritischen Kontext über Sessions hinweg zu erhalten
• Model Selection Guide -- Auswahl zwischen Opus 4.6 und Sonnet 4.6 für verschiedene Aufgaben