LLM-Kontextfenster-Vergleich 2026: Max. Ein- und Ausgabe-Token für alle großen Modelle

Anbieter geben zwei unterschiedliche Kontextzahlen an. Das Eingabefenster ist die Gesamtzahl der Token, die das Modell in einer einzigen Anfrage akzeptiert, inklusive System-Prompt, Gesprächsverlauf, Tool-Definitionen und der aktuellen Nutzernachricht. Die Ausgabebegrenzung ist die maximale Anzahl von Token, die das Modell in einer einzigen Antwort zurückgeben bereit ist – eine separate, üblicherweise kleinere, vom Anbieter gesetzte Grenze.

Die beiden zu verwechseln ist die häufigste Kostensurprise, die wir sehen. Claude Sonnet 4.6 hat ein 500k-Eingabefenster, begrenzt aber die Ausgabe auf 64k; wenn Sie es bitten, ein 200k-Token-Dokument in eine andere Sprache zu übersetzen, können Sie die ganze Übersetzung nicht in einer Antwort bekommen – die Ausgabe stoppt bei 64k. Sie müssen die Anfrage aufteilen.

Reasoning-Modelle komplizieren die Ausgabeseite zusätzlich. OpenAIs o4-reasoning teilt sein 100k-Ausgabebudget zwischen versteckten Reasoning-Token und sichtbarer Ausgabe; ein Modell, das für 80k Token denkt, hat nur noch 20k für die sichtbare Antwort. Planen Sie Ausgabebudgets entsprechend. Für die Eingabe-Fenster-Strategie speziell hilft unser Code-Prompt-Builder, lange technische Prompts zu strukturieren, die sauber in engere Fenster passen.

Token-zu-Wort-Umrechnung verwendet die Faustregel 1 Token ≈ 0,75 Wörter auf Englisch. Das tatsächliche Verhältnis variiert – Code und nicht-englischer Text laufen niedriger, strukturierte Daten laufen höher – aber zur Planung funktioniert die Regel.

200k Token ≈ 150.000 Wörter ≈ 500 Seiten dichter Prosa. Beispiele: Der vollständige Text von Krieg und Frieden (1.200 Seiten) passt nicht, aber die meisten vollständigen Softwarebücher (300–450 Seiten) schon. Ein durchschnittliches Tech-Company-Mitarbeiterhandbuch plus seine referenzierten Richtlinien passt bequem.

1.000.000 Token ≈ 750.000 Wörter ≈ 2.500 Seiten dichter Prosa. Beispiele: Die ganze Harry-Potter-Serie (~1,1M Wörter in 7 Büchern) passt mit Spielraum. Ein 200-Seiten-Finanzbericht (10-K) plus 50 unterstützende Transkripte. Eine mittelgroße Codebasis mit 50–80k Codezeilen.

2.000.000 Token ≈ 1.500.000 Wörter ≈ 5.000 Seiten. Beispiele: 4–5 vollständige Romane auf einmal, die vollständigen Werke Shakespeares mit Anmerkungen oder eine 300-Datei-Codebasis mit 200k Codezeilen. Bei dieser Größe übertrumpft Retrieval-Augmented Generation (RAG) fast immer das Vollstopfen in den Kontext – günstiger, schneller und normalerweise genauer nach veröffentlichten Benchmarks.

10.000.000 Token (Llama 4 Scout): grob 7,5M Wörter oder 25.000 Seiten. Die Recall-Benchmarks über 500k sind gemischt; behandeln Sie die Überschriftenzahl als 'wir akzeptieren diese viel Eingabe' mehr als 'wir werden zuverlässig über diese viel Eingabe nachdenken.'

Der Needle-in-Haystack-Benchmark platziert eine einzige spezifische Tatsache an zufälligen Positionen innerhalb eines langen Dokuments und testet, ob das Modell sie abrufen kann. Die meisten Modelle erzielen nahe 100% bei kürzeren Eingaben und verschlechtern sich mit zunehmender Eingabe – normalerweise fallen sie zwischen 50k und 200k Token dichter Inhalte ab.

Nach veröffentlichten 2026-Benchmarks: Gemini 3.1 Pro Preview behält 95%+ Abruf bis etwa 600k Token, bevor es sich verschlechtert. Claude Opus 4.8 bleibt über 90% bis ~300k. gpt-5.5 bleibt über 90% bis ~200k. Llama 4 Scout zeigt trotz seiner 10M-Token-Überschrift gemischte Ergebnisse über 500k.

Die praktische Folgerung: Gestalten Sie Ihren Prompt um effektiven Abruf, nicht um beworbenes Fenster. Wenn die zuverlässige Reichweite des Modells 300k Token ist, Sie aber 500k abfragen müssen, teilen Sie das Dokument auf, bewerten Sie Chunks auf Relevanz und übergeben Sie nur die Top-k-Matches im Kontext. Das ist RAG, und es schlägt fast immer Raw-Context-Stuffing über eine bestimmte Dokumentengröße.

Für RAG speziell dominiert die Embedding-Kosten die Index-Build-Rechnung – siehe unseren Embedding-Kostenrechner für aktuelle Pro-Modell-Embedding-Preise.

Sagen Sie, Sie müssen ein 250.000-Token-Dokument überprüfen – ein 600-seitiges Vertragspaket mit Anlagen. Welches Fenster passt?

Berechtigt nach Fensterrohmass: alle Modelle in der Tabelle außer OpenAI o4-reasoning (200k) und Claude Haiku 4.5 (200k). Berechtigt nach effektivem Abruf (bei Annahme dichter Inhalte): gpt-5.5-pro, Claude Opus 4.8, Claude Sonnet 4.6, Claude Fable 5, Gemini 3.x, Gemini 2.5 Pro, Qwen 3 Max.

Kostenvergleich für eine einzige Überprüfung mit einem 250k-Eingabe- und 2k-Ausgabebudget. gpt-5.5: $1,31 ($1,25 Eingabe + $0,06 Ausgabe). Claude Sonnet 4.6: $0,78 ($0,75 + $0,03). Gemini 2.5 Pro: $0,33 ($0,3125 + $0,02). Claude Opus 4.8: $1,30 ($1,25 + $0,05). Gemini 3.1 Pro Preview: $0,52.

Gleiche Inhalte, $0,33–$1,31 pro Überprüfung je nach Modellwahl. Wenn Sie 1.000 Überprüfungen pro Monat durchführen, verstärkt sich die Differenz zu $330 vs. $1.310 pro Monat – ein $980-Monatsunterschied für die gleiche Arbeitslast. Stimmen Sie das Modell auf erforderliche Abruftiefe ab und wählen Sie dann die günstigste Option, die die Abrufleiste trifft. Für Prompt-Qualitätsstrategien, die auf einer billigeren Stufe überleben, hilft unser Meta-Beschreibungs-Generator, Abrufattragen zu komprimieren.

Sie müssen ein 50.000-Token-Dokument generieren – einen Langformbericht, einen übersetzten Roman, eine generierte Codebasis. Welche Modelle können das in einer Antwort zurückgeben?

Modelle, die 50k Token in einem einzigen Aufruf zurückgeben können: Claude Opus 4.8 (64k-Ausgabebegrenzung), Claude Sonnet 4.6 (64k), Claude Fable 5 (128k), Gemini 2.5/3.x-Familie (65k), OpenAI o4-reasoning (100k geteilt mit Reasoning, also ~30–50k sichtbar nach Reasoning). Die meisten anderen begrenzen auf 8–32k Ausgabe.

Wenn Ihr Modell unter 50k begrenzt ist, müssen Sie aufteilen: Generieren Sie die ersten 16k, bitten Sie das Modell, von dort an fortzufahren, wiederholen Sie. Aufteilen führt Kontinuitätsrisiko ein – der zweite Chunk kann Inhalte wiederholen, den Faden verlieren oder die Stimme ändern. Single-Shot-Generierung in einem Modell mit einer höheren Ausgabebegrenzung ist fast immer sauberer.

Kostennotiz: Bei 50k Ausgabe rechnet Claude Sonnet 4.6 $0,75 pro Generierung ab ($0,003 Eingabe auf einem kleinen Prompt + $0,75 Ausgabe). Bei 50k Ausgabe auf gpt-5.5 müssten Sie dreimal aufteilen, bezahlen zusätzliche Eingabe zweimal; die tatsächliche Rechnung landet bei etwa $1,00–$1,20 je nach Kontext-Wiedergabe.

Die Faustregel für 2026: Unter 100k Token relevantem Inhalt ist das Stuffing-Context normalerweise einfacher und gibt bessere Antworten. Zwischen 100k und 500k hängt es von der Abfrage-Dichte ab – eine einzige gezielte Frage wird am besten durch RAG bedient, während eine vielschichtige Analyse von vollständigem Kontext profitiert. Über 500k gewinnt RAG fast immer auf Kosten, Latenz und Genauigkeit.

Kostenrechnung: Ein einzelner Gemini 2.5 Pro-Aufruf bei 1M Eingabe-Token kostet $1,25 Ein. Die gleiche Dokumentenabfrage 10-mal in einer Sitzung kostet $12,50. Der Aufbau eines Embedding-Index desselben 1M Token mit text-embedding-3-small ($0,02/1M) kostet $0,02 einmalig, dann rufen Abfragen nur die Top-k-Chunks ab (normalerweise 5–20k Token) bei $0,0063–$0,025 pro Abfrage – eine 100–1.000x-Kostenreduktion in der Sitzungskala.

Latenzrechnung: Long-Context-Aufrufe dauern Sekunden bis zum ersten Token (oft 5–20 Sekunden bei 1M-Token-Eingaben). RAG-Abfragen mit einer 10k-Token-Abrufung geben normalerweise das erste Token in unter 1 Sekunde zurück. Der kumulatif UX-Unterschied in der Skalierung ist groß.

Wann die Regel brechen: Dokumente mit übergreifenden Verweisen, die keine Chunk-Level-Abrufung aufdeckt – lange Rechtskontakte, bei denen Klauseln sich im Dokument aufeinander beziehen, Multi-Dokument-Finanzanalysen, bei denen Sie Korrelationen über alle Quellen benötigen, Code-Reviews auf eng gekoppelten Systemen. Dort kauft Ihnen der volle Kontext etwas, das RAG nicht kann.

Die meisten Anbieter berechnen eine pauschale Pro-Token-Rate unabhängig von der Fenstergröße, aber einige wenden einen Aufschlag über einem Schwellenwert an. Im Juni 2026 berechnet OpenAI seine Standardrate bis zum vollen Fenster bei den meisten Modellen. Anthropic berechnet den gleichen Satz über das ganze 500k-Fenster bei Sonnet 4.6 und Opus 4.8. Google berechnet den gleichen Satz bis zu 200k Eingabe bei Gemini 2.5 Pro und Gemini 3.1 Pro Preview, mit einem bescheidenen Aufschlag über diesem Schwellenwert (bestätigen Sie auf Gemini-Preisgestaltung).

Der größere Kostenfaktor ist einfach, dass Long-Context-Aufrufe mehr Token verarbeiten. Ein 1M-Token-Gemini-2.5-Pro-Aufruf kostet $1,25 nur für die Eingabe, unabhängig davon, wie viele Token das Modell tatsächlich verwendet. Wenn Sie das Fenster bei jedem Aufruf füllen, skaliert sich Ihre Eingaberechnung linear mit der Fenstergröße – bei 100k Aufrufen pro Monat $125.000.

Prompt-Caching ändert dies dramatisch. Anthropic und OpenAI bieten beide Cache-Rabatte an, die den zwischengespeicherten Teil mit 10% der Standardrate abrechnen. Für wiederholte Abfragen gegen das gleiche große Dokument – eine Wissensbasis, ein Vertrag, eine Codebasis – verwandelt das Caching einen $1,25-Aufruf in $0,125. Siehe Anthropic-Claude-Preisgestaltung und OpenAI-API-Preisgestaltung für die Cache-Mechanik im Detail.

Jede Schätzung in der Tabelle oben setzt englische Prosa bei grob 0,75 Wörtern pro Token voraus. Dieses Verhältnis ist praktisch für Napkin-Mathematik, aber es ist eine Zahl aus einer Verteilung, die je nach Sprache, Zeichensatz und Inhaltstyp grob 3x breit läuft. Wenn Sie ein 200k- oder 1M-Token-Fenster für eine mehrsprachige Arbeitslast budgetieren, wird eine Planung mit der englischen Rate regelmäßig die echte Token-Zählung um 50–200% unterschätzen. Das gleiche Fenster, das 150.000 englische Wörter hält, hält nur 60–80.000 chinesische Zeichen, 40–50.000 Zeilen hübsch gedrucktes JSON und irgendwo zwischen 8.000 und 12.000 Zeilen Python je nach Stil.

Beginnen Sie mit den Tokenizern selbst. Die OpenAI-GPT-Familie verwendet cl100k_base für GPT-4 und GPT-5.x, eine Byte-Pair-Codierung (BPE), die hauptsächlich auf englischem Webtext mit ungefähr 100.277 Token im Vokabular trainiert wurde. Anthropics Claude verwendet seinen eigenen BPE-Tokenizer mit vergleichbaren, aber nicht identischen Merges – Token-Zählungen zwischen OpenAI und Claude für die gleiche englische Passage unterscheiden sich normalerweise um 1–4% in jeder Richtung. Googles Gemini-Familie verwendet SentencePiece mit einem Vokabular von grob 256k Token, das nicht-lateinische Schriften aggressiver komprimiert als cl100k_base. Llama 4 verwendet eine 128k SentencePiece-Variante. Die Vokabulgröße und Trainingsverteilung bestimmen, wie effizient sich eine bestimmte Sprache komprimiert, und die Lücke zwischen Modellen auf dem gleichen nicht-englischen Text kann 30–40% treffen.

Englisch komprimiert gut, weil BPE-Tokenizer riesige englische Trainingstexte sehen und häufige Substrings ('ing', 'tion', 'the ') in einzelne Token zusammenführen. Die empirische englische Rate liegt bei 0,73–0,78 Wörtern pro Token über modernen Frontier-Tokenizern oder etwa 4 Zeichen pro Token. Romanische Sprachen (Spanisch, Französisch, Italienisch, Portugiesisch) sitzen etwas schlechter – 0,65–0,72 Wörter pro Token – da BPE-Trainingsdaten Englisch bevorzugen. Deutsch läuft 0,55–0,65, weil lange Komposita oft in 2–4 Token fragmentieren. Russisch und andere kyrillische Sprachen laufen normalerweise 0,4–0,55 Wörter pro Token. Arabisch mit morphologisch reichen Wörtern und Rechts-nach-Links-Schrift läuft oft 0,35–0,5.

Logographische und syllabische Schriften sind der harte Fall. Auf cl100k_base kostet ein typisches chinesisches Zeichen 1,5–2,5 Token – 100k Token chinesisch passt also nur 40.000–65.000 Zeichen oder grob die Länge eines einzelnen 200-Seiten-Romans statt der 500-Seiten-Sammlung, die das gleiche Fenster auf Englisch hält. Japanisch ist etwas schlechter als Chinesisch, da Kanji, Hiragana und Katakana alle unterschiedlich tokenisieren. Koreanisch Hangul läuft 1,2–1,8 Token pro Silbenblock auf cl100k_base. SentencePiece-Tokenizer (Gemini, Llama 4) schneiden dies grob in der Hälfte – Gemini behandelt ein chinesisches Zeichen näher an 0,8–1,2 Token – was ein echter Grund ist, warum Teams CJK-Arbeitslastgravitation zu Gemini oder Modellen mit ähnlichen Tokenizern durchführen.

Der Inhaltstyp zählt genauso wie die Sprache. Code ist zeichendicht aber token-dünn pro Zeichen (grob 1 Token pro 3,5–4,5 Zeichen), doch token-schwer pro Zeile, da Bezeichner, Interpunktion und Leerzeichen alle Token verbrauchen. Eine pragmatische Regel: Ein 200k-Token-Fenster hält 1.600–2.400 Zeilen dicht kommentiertes Python, 1.200–1.800 Zeilen Java oder C#, 800–1.400 Zeilen TypeScript mit JSX oder 6.000–10.000 Zeilen minifiziertes JavaScript. JSON und XML drücken die andere Richtung – sie sind token-teuer, da jedes Anführungszeichen, jede Klammer und jedes Tag sein eigenes Token oder zwei ist. Ein 200k-Token-Fenster hält grob 40–55k Zeilen formatiertes JSON oder 25–35k Zeilen XML. Markdown sitzt zwischen Prosa und Code; mathematische Notation in LaTeX gehört zu den schlechtesten, läuft 0,3–0,5 'Konzepte' pro Token, weil jeder Backslash-Befehl, jedes Klammer-Paar und jeder Index stark fragmentiert.

Praktisches Beispiel. Ein 200k-Token-Kontextfenster hält ungefähr: 150.000 englische Wörter (etwa 500 Seiten), 100.000–120.000 spanische Wörter, 65.000–80.000 chinesische Zeichen unter cl100k_base, 110.000–130.000 chinesische Zeichen unter Geminis Tokenizer, 8.000–12.000 Zeilen Python, 4.000–6.000 Zeilen XML oder 45.000–55.000 Zeilen kompaktes JSON. Ein 1M-Token-Gemini-2.5-Pro-Fenster hält grob 750.000 englische Wörter, aber nur 550.000–650.000 chinesische Zeichen – immer noch weitaus mehr als cl100k_base passt, aber weit unter der naiven englischen Extrapolation. Die praktische Regel für mehrsprachige Arbeitslast ist, bei 1,5–2x der englischen Token-Rate für nicht-lateinische Schriften bei OpenAI und Claude zu budgetieren, und grob 1,2–1,5x bei Gemini und Llama 4.

Der praktische Rat: Begehen Sie sich nie auf eine Fenstergröße basierend auf Zeichenzählung oder Wortanzahl allein. Führen Sie Ihren echten Inhalt durch den Tokenizer des Modells selbst – OpenAI-tiktoken-Bibliothek für GPT, Anthropics count_tokens-Endpunkt für Claude, Googles count_tokens-API für Gemini – bei einer repräsentativen Stichprobe von 5–10 echten Dokumenten, dann planen Sie mit einer 20–30%-Sicherheitspuffer oben auf der gemessenen Rate. Die Kosten einer Fehlschätzung sind konkret: Ein Workflow für 150k englische Wörter, die tatsächlich auf Chinesisch läuft, wird bei Dokument 1 das 200k-Fenster treffen, schweigend fehlschlagen oder abschneiden und fehlerhafte Antworten an Benutzer liefern. Zuerst messen, dann fenstergrößße wählen.

Beginnen Sie mit dem größten einzelnen Inhalt, den Ihre Arbeitslast verarbeitet – ein Dokument, ein Gesprächsverlauf, eine Codebasis-Chunk. Addieren Sie den System-Prompt, Tool-Definitionen, Konversationsspeicher und einen 20%-Sicherheitspuffer. Das ist Ihr minimales erforderliches Fenster.

Wenn die Antwort unter 50k liegt, funktioniert fast jedes Modell. Wenn 50k–200k, beseitigen Sie Haiku 4.5 und o4-reasoning; alles andere qualifiziert sich. Wenn 200k–500k, beseitigen Sie Mistral Large 3, DeepSeek V4 und Grok 4. Wenn 500k+, machen nur die Gemini-Familie, Claude Fable 5, gpt-5.5-pro (1M) und Llama 4 (1M–10M) den Schnitt.

Testen Sie dann effektiven Abruf. Platzieren Sie eine bekannte Tatsache bei den 50%-, 75%- und 90%-Positionen Ihrer typischenmax. Eingabe, bitten Sie das Modell, es abzurufen und zu überprüfen. Wenn Recall über 85% über Ihrer Betriebsfenster fällt, wechseln Sie stattdessen zu RAG, anstatt das Modell an seine beworbene Grenze zu drücken.

Für die meisten Teams ist die richtige Maßnahme: Wählen Sie ein Modell, dessen effektiver Abruf 80% der erwarteten Dokumentgrößen abdeckt, verwenden Sie RAG für den langen Ende. Siehe unseren GPT vs. Claude vs. Gemini-Kostenrechner für einen nebeneinander-Kostenaufschlüsselung bei jeder Fenstergröße.