Kapazität wird gemessen, sie ist keine Million-Token-Zahl

Die Zeile «1M Tokens» auf einer Modellkarte ist eine Obergrenze für das, was die API akzeptiert, keine Garantie dafür, was das Modell gut nutzt. Im August 2026 schickte ofox.ai ein identisches 420-Wort-englisches Dokument an neun Flaggschiffmodelle und maß eine 1,56x-Spreizung der Tokenzahl — 614 Tokens bei Grok 4.20, 957 bei Claude Opus 5 — für exakt denselben Text. Das beworbene Fenster ist eine Behauptung der Modellkarte; die echte Kapazität ist eine Messung, und nach Theorem 3 ist eine Eigenschaft genau dann garantiert, wenn ihr Mechanismus implementiert ist und misst. Der Mechanismus hier ist der Tokenizer plus die Retrieval-Genauigkeitskurve, und keiner von beiden erscheint in der Kopfzahl.

Was ein Kontextfenster tatsächlich ist

Ein Kontextfenster ist das Token-Budget für eine einzelne API-Anfrage. Alles, was das Modell liest, und alles, was es schreibt, muss in eine einzige Zahl passen, und die API ist zustandslos — sie erinnert sich nicht an den letzten Aufruf. In jedem Zug sendet Ihre Anwendung die gesamte Unterhaltung erneut, und das Fenster ist die Decke dafür, wie groß dieser Resend plus die kommende Antwort sein darf.

Deshalb ist das Fenster in keinem nützlichen Sinne ein Gedächtnis. Ein Chat-Produkt, das Ihren Namen über Sitzungen hinweg zu erinnern scheint, speichert diesen Text irgendwo und fügt ihn bei jeder Anfrage wieder in das Fenster ein. Die Persistenz liegt in Ihrer Anwendung, nicht im Modell.

Was zum Fenster zählt

Alles in der Anfrage plus alles in der Antwort. Die Teile, die Leute vergessen, sind meist die teuersten:

• System-Prompt. Wird in jedem Zug gezählt, nicht einmal pro Sitzung.
• Voller Nachrichtenverlauf. Jeder vorherige Nutzer- und Assistenten-Zug, den Sie erneut senden.
• Werkzeugdefinitionen. Namen, Beschreibungen und JSON-Schemata für jedes Werkzeug, das Sie deklarieren. Bei Claude fügen diese außerdem einen modellspezifischen System-Prompt für Werkzeugnutzung hinzu, von 286 Tokens bei Opus 5 bis 675 bei Opus 4.7.
• Werkzeugergebnisse. Oft der größte Einzelposten in einer Agentenschleife; eine Verzeichnisauflistung oder eine API-Antwort kann Tausende Tokens umfassen.
• Reasoning-Tokens. Bei Modellen mit aktiviertem Denken zählt das Reasoning und wird abgerechnet, auch wenn der Text nicht an Sie zurückgegeben wird.
• Die Antwort selbst. Deshalb interagieren max_tokens und das Kontextfenster: Eine Anfrage, die keinen Raum für die Ausgabe lässt, wird abgeschnitten.

«1M Tokens» sind neun verschiedene Zahlen

[UNIQUE INSIGHT] Das beworbene Fenster ist eine Obergrenze für das, was die API akzeptiert, nicht für das, was das Modell gut nutzt — und die Lücke zwischen beiden ist eine Benchmark-Frage, keine Karten-Frage. Der Mechanismus, der die echte Kapazität bestimmt, ist der Tokenizer plus die Retrieval-Genauigkeitskurve, und keiner von beiden erscheint in der Kopfzahl.

Über die neun Flaggschiffmodelle, die ofox.ai am 2026-08-12 katalogisierte, löst sich «1M» in neun verschiedene Ganzzahlen auf: von einer runden 1.000.000 (Claude Opus 5, Grok 4.20, DeepSeek V4 Flash) bis 1.131.072 (Qwen 3.8 Max). Das ist eine 13%-Spreizung, bevor Sie irgendetwas gemessen haben. Im gesamten Katalog von 119 Textmodellen ist das häufigste Fenster 256K (25 Modelle), mit 22 bei 1M.

Eine Vorsichtshinweis, woher diese Zahlen kommen. Gateway-Kataloge und Herstellerdokumentation stimmen nicht immer überein: Am 2026-08-12 listete der ofox-Katalog Grok 4.20 mit 2.000.000, während xAIs eigene Modelldokumente 1.000.000 angeben. Der ehrliche Vergleich verwendet die Herstellerzahl, und Sie prüfen die Herstellerseite, wenn die Zahl wichtig ist. Eine Modellkarte ist eine Behauptung; die Herstellerdokumentation ist eine stärkere Behauptung; der gemessene prompt_tokens auf Ihrem Inhalt ist die einzige, die Ihre Frage beantwortet.

Die 1,56x-Spreizung bei identischer Eingabe

Die tiefere Überraschung ist, dass der Tokenizer — nicht die Fensterzahl — der tragende Mechanismus ist. ofox schickte ein identisches 2.638-Zeichen-englisches Dokument (einen 420-Wort-Service-Postmortem) an neun Modelle über einen Endpunkt und las prompt_tokens aus jeder Antwort:

• Grok 4.20: 614 Tokens (4,30 Zeichen/Token)
• GPT-5.6 Sol: 626 (4,21)
• GLM-5.2: 632 (4,17)
• DeepSeek V4 Flash: 634 (4,16)
• Gemini 3.1 Pro: 684 (3,86)
• Claude Opus 4.6: 698 (3,78)
• Qwen 3.8 Max: 706 (3,74)
• Kimi K3: 716 (3,68)
• Claude Opus 5: 957 (2,76)

Eine 1,56x-Spreizung bei identischer Eingabe. Claude Opus 5 ist der Ausreißer, weil Anthropic dokumentiert, dass Claude 4.7 und später einen neueren Tokenizer verwenden, der für denselben Text etwa 30 % mehr Tokens erzeugt.

Kombinieren Sie die beiden Tabellen und das beworbene Fenster hört auf, die nützliche Zahl zu sein. Kopien dieses 420-Wort-Dokuments, die tatsächlich passen, reichen von 1.045 bei Claude Opus 5 bis 1.677 bei GPT-5.6 Sol — eine 1,60x-Lücke bei Modellen, die alle «etwa 1M» bewerben.

Das Verhältnis ist nicht über Inhaltstypen hinweg konstant. Bei einer TypeScript-Datei lag die Spreizung bei 1,53x und GLM-5.2 war sparsamer als Grok. Bei chinesischem Text weitete sich die Spreizung auf 1,88x, und beide Claude-Modelle landeten nahe einem Token pro chinesischem Zeichen gegenüber 1,87 bei Grok. Behandeln Sie das als Stichprobe, nicht als Regel: Bei einer zweiten, zeichensetzungsreicheren chinesischen Passage kamen dieselben zwei Modelle auf 0,98 und 0,96 Zeichen/Token, was bedeutet, dass manche Zeichen mehr als ein Token kosten. Wenn Ihre Eingabe Code oder nicht-englisch ist, messen Sie sie, anstatt anzunehmen.

Warum Token-Preise zwischen Herstellern nicht vergleichbar sind

Weil ein Token keine feste Textmenge ist, sind Token-Preise nicht direkt vergleichbar. Ein Hersteller, der weniger pro Token verlangt, kann pro Wort teurer sein, wenn sein Tokenizer dichter ist. Anthropic berechnet das volle 1M-Fenster zu Standardtarifen ohne Aufpreis für langen Kontext, sodass eine 900K-Token-Anfrage pro Token dasselbe kostet wie eine mit 9K. Gemini 3.1 Pro steigt von 2 $ auf 4 $ pro Million Input-Tokens über 200K, und Grok 4.20 von 1,25 $ auf 2,50 $ bei derselben Schwelle. Das Modell mit dem günstigeren Kopfpreis kann für Langdokumentarbeit das teurere sein, und der Tokenizer-Unterschied liegt obendrauf, in welchem Tarif Sie auch landen.

Ein Budgetvergleich, der den Aufkleberpreis und das beworbene Fenster liest, liest zwei Behauptungen. Ein Budgetvergleich, der prompt_tokens auf dem echten Dokument misst und mit dem anwendbaren Tarif multipliziert, liest eine Messung. Das erste ist eine Schätzung; das zweite ist eine Zahl, gegen die Sie fakturieren können.

Das Fenster ist nicht der nutzbare Kontext

Der wichtigste Vorbehalt ist, dass ein Modell, das 1M Tokens akzeptiert, nicht dasselbe ist wie ein Modell, das verlässlich die Tatsache findet, die Sie bei Token 800.000 vergraben haben. Die Retrieval-Genauigkeit nimmt mit der Distanz bei jedem öffentlichen Modell ab, und die Größe dieser Lücke ist eine Benchmark-Frage, keine Karten-Frage. ofox verweist auf RULER, MRCR v2 und NoLiMa als die Benchmarks, die das tatsächlich messen: RULER testet Retrieval bei kontrollierten Tiefen in synthetischen Kontexten, MRCR v2 verfolgt Multi-Hop-Retrieval in langen Dokumenten, und NoLiMa prüft, ob ein Modell noch eine Antwort findet, wenn die lexikalische Überschneidung zwischen Frage und Evidenz entfernt wurde. Keine dieser Werte erscheint auf einer Modellkarte neben «1M-Kontext».

Behandeln Sie das beworbene Fenster als Obergrenze für das, was die API akzeptiert, und die Benchmark-Zahlen als Leitfaden dafür, was das Modell gut nutzen wird. Die erste Zahl ist ein Vertrag; die zweite ist eine Messung. Ein Modell, das eine Million Tokens akzeptiert, aber bei 500K Tiefe mit 60 % Genauigkeit retriet, hat einen nutzbaren Kontext weit unter dem beworbenen, und kein Fenster behebt die Lücke — das tut nur ein anderer Mechanismus (Routing, Retrieval oder Umstrukturierung).

Der Mechanismus ist die Messung, nicht die Karte

[ORIGINAL DATA] Bei Everythink behandeln wir das Kontextfenster wie jede beanspruchte Eigenschaft: nach Theorem 3 ist eine Eigenschaft genau dann garantiert, wenn ihr Mechanismus implementiert ist und misst. Die Zeile «1M Tokens» hat keinen Mechanismus dahinter; prompt_tokens auf Ihrem eigenen Inhalt ist der Mechanismus. Wir messen, bevor wir uns für einen Anbieter entscheiden, und wir messen neu, wenn ein Anbieter einen neuen Tokenizer veröffentlicht, weil die Kopfzahl bis zu 1,6x in beliebige Richtung abgewichen ist.

Das ist die Disziplin der Nachmessung. Ein Tokenizer ist keine stabile Eigenschaft der Physik; er ist ein Software-Artefakt, das ein Anbieter durch ein neueres ersetzen kann, das 30 % mehr Tokens für denselben Text erzeugt, wie Anthropic es mit Claude 4.7 tat. Wenn das passiert, ist jede Kapazitätsschätzung, die Sie vom alten Tokenizer gecacht haben, um dieselben 30 % falsch, und ebenso jede Kostenschätzung, die darauf aufbaut. Die Teams, die erwischt werden, sind diejenigen, die einmal maßen, die Zahl in eine Konfigurationsdatei schrieben und nie zurückkamen. Die, die ehrlich bleiben, messen nach einem Zeitplan neu, wie Sie jedes Instrument neu kalibrieren würden.

Das ist für uns keine neue Disziplin. Der HAI Engine ist seit 2016 in Produktion, und jede Vorhersage verzweigt an mehrere Sisters — jede ein typisierter KI-Agent mit eigener Persönlichkeit und eigener Kontextbudget-Entscheidung — bevor der Oracle ihre Entwürfe zu einem kalibrierten Ensemble verschmilzt. Eine Vorhersage ist kein einziger riesiger Prompt; sie ist eine geroutete Menge begrenzter Prompts, und die Grenze ist eine Messung, keine Karten-Zeile.

[PERSONAL EXPERIENCE] Wir messen seit einem Jahrzehnt Agenten-Kontextbudgets, und der zuverlässigste Fehler, den wir sehen, ist, dass Teams ein Modell nach beworbener Fenstergröße wählen und dann in Produktion feststellen, dass ihre echte Arbeitslast 35 % weniger Dokumente fasst, als die Karte implizierte. Die Lösung ist nie ein größeres Fenster. Die Lösung ist, Ihren eigenen Inhalt auf den Modellen zu messen, zwischen denen Sie wählen — eine Anfrage mit max_tokens: 1 liefert prompt_tokens und kostet einen Bruchteil eines Cents — und entsprechend zu routen.

Routing geht vor Retrieval

Das ist dasselbe Prinzip wie «the space is the router»: bei Everythink routet die Network→Community→Room-Topologie eine Anfrage, bevor irgendetwas antwortet. Sie kippen nicht die ganze Welt in ein Fenster und hoffen, dass das Modell die richtige Tatsache bei Token 800.000 findet; Sie routen in den Room, der den relevanten Kontext hält, sodass das Fenster, das das Modell tatsächlich sieht, klein, frisch und gemessen ist. Kapazität ist ein Routing-Problem, bevor sie ein Retrieval-Problem ist, und Retrieval ist ein Messproblem, bevor sie ein Karten-Problem ist.

The 21 papers kodifizieren das. Theorem 3 sagt nicht «größer ist besser»; es sagt, dass eine Eigenschaft genau dann gilt, wenn der Mechanismus, der sie garantiert, vorhanden ist und misst. Für Kapazität ist dieser Mechanismus ein Tokenizer, der Ihren Inhalt liest, und ein Benchmark, der das Retrieval des Modells bei Tiefe misst. Die beworbene Zahl ist keiner von beiden.

Kundensouveränität läuft über Messung

Kundensouveränität — Ihr Network, Ihre Marke, Ihre Daten — hat eine stille Abhängigkeit von Kapazitätsmessung. Wenn Sie die Network→Community→Room-Topologie besitzen, entscheiden Sie, welcher Kontext welchen Agenten erreicht, und diese Entscheidung ist nur so gut wie Ihre Schätzung dessen, was passt. Ein souveräner Betreiber, der der Modellkarte vertraut, übergibt die echte Entscheidung an das Marketing-Copy des Anbieters. Ein souveräner Betreiber, der seinen eigenen Korpus misst, behält die Routing-Entscheidung im Haus, wo sie hingehört. Dasselbe gilt für Inklusion by Design: ein Nutzer mit geringer Konnektivität auf einem getakteten Datenplan wird am besten mit einem kleinen, gut gerouteten Fenster bedient, nicht mit einer Million-Token-Flut, und «klein und gut geroutet» ist eine Messung, die Sie nur durchführen können, wenn Sie gemessen haben.

Mehr ins Fenster passen, das Sie haben

Keines davon macht das Fenster größer; alle reduzieren, was Sie darin ausgeben. In grober Reihenfolge des Ertrags:

1. Prompt-Caching. Ein stabiles Präfix — System-Prompt, Werkzeugdefinitionen, ein Dokument, zu dem Sie immer wieder fragen — wird bei einem Cache-Treffer bei Anthropic und mehreren anderen Anbietern mit etwa 10 % des Input-Tarifs berechnet, wobei der genaue Rabatt variiert und bei manchen tiefer ausfällt. Das ist der größte Hebel für wiederholte Aufrufe, und es ändert Kosten, nicht Kapazität.
2. Compaction. Serverseitige Zusammenfassung früherer Züge, wenn sich die Unterhaltung dem Limit nähert, sodass eine lange Agentensitzung weiterläuft, statt abzubrechen.
3. Kontext-Editierung. Entfernen veralteter Werkzeugergebnisse und alter Reasoning-Blöcke aus dem Transkript. Agentenschleifen füllen sich mit Werkzeugausgabe mehr als mit Unterhaltung.
4. Den richtigen Tokenizer für Ihren Inhalt wählen. Wie die Messungen oben zeigen, ist diese Entscheidung allein bis zu 1,6x effektive Kapazität wert, bevor Sie irgendetwas anderes optimieren.

Die ersten drei verwalten das Budget. Das vierte wählt, gegen welches Budget Sie messen. Alle vier sind Mechanismen; keines ist eine größere Zahl auf einer Karte.

Was passiert, wenn Sie das Fenster überschreiten

Sie erhalten einen HTTP 400 und keine Ausgabe. Nichts wird still abgeschnitten. ofox schickte eine zu große Anfrage an ein 32.000-Token-Modell und erhielt:

{"error":{"code":null,
  "message":"<400> InternalError.Algo.InvalidParameter: Range of input length should be [1, 30720]",
  "type":"invalid_request_error"}}

Lesen Sie dieses Limit sorgfältig: Das Modell bewirbt 32.000, und die erzwungene Eingabe-Decke ist 30.720, wobei der Rest für die Ausgabe reserviert ist. Das beworbene Fenster ist das Gesamte, nicht Ihre Eingabe-Zulage, und die erzwungene Zahl kann unter der Marketing-Zahl liegen.

Fehlerformen unterscheiden sich nach Anbieter, also kein Pattern-Matching auf der Meldungs-Zeichenkette. OpenAI-kompatible Endpunkte geben im Allgemeinen eine 400 mit einem Code im Stil context_length_exceeded zurück. Claude kann stattdessen den Zug mit stop_reason: "model_context_window_exceeded" beenden, was sich von max_tokens unterscheidet und einen eigenen Zweig in Ihrem Code braucht. Behandeln Sie beide. Eine Antwort, die früh stoppte, weil das Fenster voll war, ist nicht derselbe Fehlschlag wie eine, die stoppte, weil Ihr max_tokens klein war, und die Lösungen unterscheiden sich.

Wichtigste Erkenntnisse

• Das beworbene Fenster ist eine Obergrenze für das, was die API akzeptiert, nicht für das, was das Modell gut nutzt. Echte Kapazität ist eine Messung, und die Messung ist der Tokenizer plus die Retrieval-Genauigkeitskurve.
• «1M Tokens» sind neun verschiedene Zahlen, und dasselbe 420-Wort-Dokument fasst 1,6x mehr Kopien in einem Flaggschiff als in einem anderen. Token-Preise sind zwischen Herstellern nicht vergleichbar, ohne die Tokenizer-Dichte zu berücksichtigen.
• Messen Sie Ihren eigenen Inhalt. Eine Anfrage mit max_tokens: 1 liefert prompt_tokens und kostet einen Bruchteil eines Cents. Führen Sie sie auf Ihrer echten Arbeitslast aus, bevor Sie ein Modell nach Fenstergröße wählen, und wiederholen Sie das, wenn ein Anbieter einen neuen Tokenizer veröffentlicht.
• Der Mechanismus ist die Messung, nicht die Karte. Nach Theorem 3 ist eine Eigenschaft genau dann garantiert, wenn ihr Mechanismus implementiert ist und misst. Die «1M»-Zeile hat keinen Mechanismus; prompt_tokens ist der Mechanismus.
• Routing geht vor Retrieval. Kippen Sie nicht die Welt in ein Fenster. Routen Sie zuerst zum relevanten Kontext — die Network→Community→Room-Topologie bei Everythink ist dasselbe Prinzip auf Produktebene — sodass das Fenster, das das Modell sieht, klein, frisch und gemessen ist.

Häufig gestellte Fragen

Ist ein Kontextfenster dasselbe wie Gedächtnis? Nein. Ein Kontextfenster gilt pro Anfrage, ist nicht persistent. Die API ist zustandslos: In jedem Zug senden Sie die gesamte Unterhaltung erneut, und das Fenster ist die Decke für das, was eine Anfrage enthalten darf. Alles außerhalb ist weg, es sei denn, Ihre Anwendung speichert es und sendet es erneut. Produkte, die Sie über Sitzungen hinweg zu erinnern scheinen, injizieren gespeicherten Text in das Fenster, sie ziehen nicht aus dem Modellgedächtnis.

Wie viele Wörter sind 1 Million Tokens? Für englischen Text grob 440.000 bis 685.000 Wörter — eine breitere Spanne, als die übliche Faustregel zugibt. Nach ofox' Messung an einem identischen Dokument landen acht von neun Modellen zwischen 587.000 und 684.000 Wörtern pro Million Tokens; Claude Opus 5 ist der niedrige Ausreißer bei etwa 439.000 wegen seines neueren Tokenizers. Code ist dichter (etwa 2,4 bis 3,6 Zeichen/Token) und Chinesisch noch dichter (0,9 bis 1,9), sodass dasselbe 1M-Fenster weit weniger davon fasst.

Was ist das größte Kontextfenster, das 2026 verfügbar ist? 1M Tokens ist die Spitze der Mainstream-Klasse. Mehrere Hersteller liegen leicht über der runden Zahl: Qwen 3.8 Max bei 1.131.072, GPT-5.6 bei 1.050.000 und Gemini, GLM und Kimi K3 bei 1.048.576. Unter den 119 Textmodellen im ofox-Katalog am 2026-08-12 ist das häufigste Fenster 256K (25 Modelle), mit 22 bei 1M.

Warum verwendet dieselbe Datei mehr Tokens bei Claude als bei GPT? Unterschiedliche Tokenizer. Anthropic merkt an, dass Claude 4.7 und später einen neueren Tokenizer verwenden, der für denselben Text etwa 30 % mehr Tokens erzeugt als frühere Claude-Modelle. Bei ofox' englischem Testdokument verwendete Claude Opus 5 957 Tokens, wo GPT-5.6 Sol 626 verwendete — ein 1,53x-Unterschied bei identischer Eingabe. Nichts ist falsch; die Modelle zählen einfach verschieden, und Token-Preise sind zwischen Herstellern nicht vergleichbar, ohne das zu berücksichtigen.

Kann ich das Kontextfenster eines Modells vergrößern? Nein. Es ist modellfixiert, und es gibt keinen Parameter, um es anzuheben. Was Sie ändern können, ist, wie viel Sie davon ausgeben: Prompt-Caching senkt die Kosten für das erneute Senden eines stabilen Präfixes, Kontext-Editierung entfernt veraltete Werkzeugergebnisse, und Compaction fasst ältere Züge zusammen. Diese verwalten das Budget, anstatt es zu erweitern.

Wenn Sie aufhören möchten, die Kapazität zu raten, und anfangen, sie zu messen, erstellen Sie Ihr Network — die Topologie, die routet, bevor irgendetwas antwortet, sodass das Fenster, das Ihre Agenten tatsächlich sehen, das ist, das Sie gemessen haben.

Sources

• 2026 — ofox.ai, «What Is a Context Window? Token Limits by Model (2026)» — https://ofox.ai/blog/what-is-a-context-window-token-limits-by-model-2026/
• 2026 — Anthropic, «Context windows» — https://platform.claude.com/docs/en/build-with-claude/context-windows
• 2026 — Anthropic, «Pricing, including the tokenizer note» — https://platform.claude.com/docs/en/about-claude/pricing