Context Rot in LLMs: RAG vs. Long Context 2026

Was Context Rot in LLMs bedeutet

Context Rot ist der gemessene Rückgang der Genauigkeit eines großen Sprachmodells, wenn seine Eingabe wächst, und zwar lange bevor das Kontextfenster voll ist. Er entsteht durch Aufmerksamkeit, die sich auf mehr Tokens verteilt, durch Ablenker, die wie die Antwort aussehen, und durch ein Training, das Schlussfolgern bei extremen Längen selten belohnt. Die Abhilfe besteht darin, weniger zu senden: abrufen und reranken, veraltete Tool-Ausgaben löschen, lange Sessions kompaktieren oder neu starten und Ihr eigenes sicheres Budget messen, statt dem Datenblatt zu vertrauen.

Chroma Research hat das im Juli 2025 an 18 Modellen mit Zahlen belegt, und der Begriff ist so weit im Mainstream angekommen, dass Anthropics eigene Dokumentation ihn inzwischen definiert: „Mit wachsender Token-Zahl verschlechtern sich Genauigkeit und Recall, ein Phänomen, das als Context Rot bekannt ist." Ein größeres beworbenes Fenster hebt die Obergrenze dessen an, was Sie senden können. Es verspricht am oberen Ende dieses Bereichs nicht dieselbe Genauigkeit wie am unteren.

Die praktische Fassung für alle, die entscheiden müssen, was sie bauen: Das dokumentierte Kontextfenster gibt an, wie viel Sie senden dürfen. Ihr nutzbares Fenster reicht so weit, wie das Modell Ihre Qualitätsschwelle noch erreicht. Das sind zwei verschiedene Zahlen, und die zweite ist meist ein Bruchteil der ersten.

Genau diese Lücke ist der Grund, warum das Argument, das Ende 2024 und Anfang 2025 durch die Engineering-Kanäle lief („RAG ist jetzt überflüssig, einfach alles hineinkopieren"), schlecht gealtert ist. Die Fenster sind tatsächlich gekommen. Anthropic macht 1M Tokens bei Claude Opus 5.5, Sonnet 5.5 und dem neuen Haiku 5.5 zum Standard. Die GPT-6-Modelle von OpenAI bringen ein Fenster von 1,05M mit, von dem 922K auf den Input entfallen können. Googles Gemini 3.1 Pro und Gemini 3.8 Flash nehmen rund 1M Input-Tokens an. Metas Llama 4 Scout dokumentiert 10M. Nicht gekommen ist ein Modell, das jeden Teil seines Fensters gleich gut nutzt.

Die interessante Frage lautet deshalb nicht mehr „welches Verfahren gewinnt", sondern „welches Muster passt zu dieser Datenform, diesem Latenzbudget, dieser Aktualitätsanforderung und dieser Rechnung". Genau das beantwortet der Rest dieses Textes, angefangen damit, was die Forschung gemessen hat und wie sich das Problem beheben lässt.

---

Was Chromas Context-Rot-Forschung gezeigt hat

Die Schlagzeile („Context Rot existiert") wird der Arbeit nicht gerecht. In Context Rot: How Increasing Input Tokens Impacts LLM Performance, einem am 14. Juli 2025 veröffentlichten technischen Report und der Studie, die die meisten meinen, wenn sie vom „Context-Rot-Paper" sprechen, führten Kelly Hong, Anton Troynikov und Jeff Huber kontrollierte Experimente über 18 Modelle hinweg durch: Claude Opus 4, Sonnet 4, Sonnet 3.7, Sonnet 3.5 und Haiku 3.5; o3, GPT-4.1 samt den Varianten mini und nano, GPT-4o, GPT-4 Turbo und GPT-3.5 Turbo; Gemini 2.5 Pro, 2.5 Flash und 2.0 Flash; sowie drei Größen von Qwen3. Wegen Grenzen beim Kontextfenster und beim Thinking-Budget lief nicht jedes Modell in jedem Experiment. Mit ihrem Replikations-Kit auf GitHub können Sie alles nachstellen.

Vier Befunde sind für die Architektur relevant.

Die Leistung degradiert ungleichmäßig, wenn die Eingabe wächst. Falls Sie auf der Suche nach dem Context-Rot-Graphen hierhergekommen sind: Gerade auf die Form kommt es an, denn es gibt nicht die eine Kurve. Chroma fasst selbst zusammen, dass Modelle „ihren Kontext nicht gleichmäßig nutzen; stattdessen wird ihre Leistung mit wachsender Eingabelänge zunehmend unzuverlässig". Wie schnell und wo das geschieht, hängt vom Modell und von der Aufgabe ab, und genau deshalb sagt eine Stichprobe bei einer Kontextgröße fast nichts über das Verhalten bei einer anderen aus. Anthropics Engineering-Team beschreibt dasselbe Muster als „einen Leistungsgradienten statt einer harten Klippe".

Der Einbruch ist groß. Auf LongMemEval, einem Benchmark für dialogbasiertes Question-Answering, filterte das Team auf 306 Prompts herunter und verglich von jedem zwei Fassungen. Die fokussierte Fassung enthält nur das relevante Material und umfasst im Schnitt rund 300 Tokens. Die vollständige Fassung vergräbt dieselbe Antwort im umgebenden Gespräch und umfasst im Schnitt rund 113K Tokens. Bei den vollständigen Fassungen degradierte die Leistung durchgängig. Die Claude-Modelle zeigten den größten Abstand, und Chroma führt einen Großteil davon auf Antwortverweigerung zurück: Claude Opus 4 und Sonnet 4 verzichteten oft lieber auf eine Antwort, als zu raten. Gleiche Frage, gleiches Modell, gleiche Antwort in der Eingabe. Verändert hat sich vor allem, wie viel irrelevanter Text mitkam.

Ähnlichkeit prägt den Verfall. Ist die Nadel der Frage semantisch weniger ähnlich (Chroma hat das über Embedding-Ähnlichkeit bewertet), fällt die Genauigkeit mit wachsender Eingabe schneller. Auch Ablenker, die der Antwort ähneln, schaden: Schon ein einziger senkt die Leistung gegenüber der Baseline mit nur einer Nadel, vier verstärken den Effekt. Die Position dagegen machte bei dieser Aufgabe kaum einen Unterschied. Chroma sah über 11 Nadelpositionen hinweg keine nennenswerte Schwankung, obwohl Liu et al. (2024), „Lost in the Middle", in TACL beim Question-Answering über mehrere Dokumente eine U-förmige Kurve gefunden hatte, bei der die Mitte eines langen Kontexts systematisch untergewichtet wird.

Kohärenter Fülltext schadete mehr als durchmischter. Das ist das Ergebnis, das die Denkweise von Engineers verändern sollte. Die Intuition sagt, ein kohärenter Heuhaufen müsste sich leichter durchsuchen lassen als ein durcheinandergewürfelter. Chroma fand das Gegenteil, und zwar durchgängig über alle 18 Modelle: Die Sätze des Heuhaufens zu mischen und seinen logischen Fluss zu zerstören verbesserte die Leistung. Warum das so ist, bleibt offen; Chroma geht nur so weit zu sagen, dass die Struktur einer Eingabe beeinflussen könnte, wie der Attention-Mechanismus angewendet wird. Der handlungsrelevante Teil braucht keinen Mechanismus: Kohärente, themennahe Polsterung ist nicht automatisch harmlos.

Noch ein Detail für den Produktivbetrieb: Fehlermodi sind modellspezifisch. Unter Ablenkern zeigten die Claude-Modelle die niedrigsten Halluzinationsraten, wobei Claude Sonnet 4 und Opus 4 besonders konservativ waren und sich bei Unsicherheit eher enthielten, während die GPT-Modelle die höchsten zeigten und eher selbstbewusst falsch antworteten. Wenn Sie zwischen beiden wählen, wählen Sie zum Teil auch, welchen Fehler Sie lieber debuggen.

Chroma ist nicht das einzige Team, das das misst. Wenn Sie einen Context-Rot-Benchmark suchen, der Ihrem Workload ähnelt, sind das die wichtigsten:

Merken Sie sich vor allem die letzte Zeile: Selbst wenn ein Modell jede relevante Passage perfekt abruft, kostet eine längere Eingabe trotzdem Genauigkeit.

Einen sanfteren Einstieg bietet Hamel Husain: Er hat Kelly Hong eingeladen, die Forschung durchzugehen, und eine kommentierte Mitschrift dieses Vortrags veröffentlicht. Die Schlussfolgerungen decken sich mit dem Report: Die Leistung ist über Kontextlängen hinweg nicht einheitlich, die Art der Präsentation von Informationen zählt, und bewusstes Context Engineering ist der Hebel.

---

Warum Long Context versagt: der Mechanismus

Der Mechanismus ist wichtig, weil er vorhersagt, welche Workloads brechen.

Transformer-Attention rechnet ein Softmax über Token-Paare. Wächst die Sequenzlänge, verteilt sich die Aufmerksamkeit auf mehr Positionen. Selbst mit relativen Positionskodierungen wie RoPE oder ALiBi wächst der Nenner des Softmax, und das Gewicht, das für ein einzelnes Token übrig bleibt, schrumpft. Bei 1M Tokens konkurriert das richtige Token mit 999.999 anderen um ein endliches Budget. Die Engineers von Anthropic nennen das ein „Aufmerksamkeitsbudget": „Jedes neu eingeführte Token verringert dieses Budget um einen gewissen Betrag."

Positionskodierungen dehnen den Bereich, beseitigen das Problem aber nicht. RoPE degradiert, wenn weit über die Trainingslänge hinaus extrapoliert wird; ein Modell, das auf 32K-Sequenzen trainiert und bei 1M eingesetzt wird, betreibt also eine Extrapolation, die die zugrunde liegende Mathematik nicht vollständig trägt. Meta zum Beispiel hat das Pre- und Post-Training von Llama 4 Scout mit 256K durchgeführt und dokumentiert ein Fenster von 10M; alles jenseits von 256K stützt sich also auf Längengeneralisierung. YaRN, Positionsinterpolation und NTK-aware Scaling helfen alle, und keines davon erzeugt ein Modell, das 1M Tokens so gut nutzt wie 32K.

Hinzu kommt ein Problem mit den Trainingsdaten. Selbst wenn ein Modell auf langen Sequenzen trainiert, sind Beispiele, die echtes Schlussfolgern über 800K Tokens verlangen, selten. Modelle lernen, jene Teile des Kontexts zu nutzen, deren Nutzung ihnen ihre Trainingsdaten beigebracht haben.

Context Rot ist damit eine Eigenschaft der Architektur und der Trainingsverteilung und kein Bug, den das nächste Release wegpatcht. Künftige Modelle werden die Grenze weiter verschieben, und die Form der Degradation wird bleiben.

---

Premature Termination: was die Forschung 2026 ergänzt hat

Das nützlichste neue Ergebnis seit der Erstveröffentlichung dieses Artikels stammt aus der Arbeit an Long-Horizon-Agenten, nicht aus der Benchmark-Forschung.

In Diagnosing and Mitigating Context Rot in Long-horizon Search, erstmals im Juni 2026 veröffentlicht und im August grundlegend überarbeitet, untersuchten Shijie Xia, Yikun Wang, Zhen Huang und Pengfei Liu vier Open-Weight-Flaggschiffmodelle (GLM-4.7, GLM-5.0, Qwen3.5-397B-A17B und MiniMax-M2.5) auf drei Deep-Search-Benchmarks: BrowseComp, xbench-DeepSearch und BrowseComp-Plus, das ein festes lokales Korpus durchsucht. Geschlossene Modelle blieben außen vor, weil ihre Reasoning-Traces verschlüsselt sind. Die überarbeitete Fassung benennt einen Fehlermodus, den die frühere Literatur übersprungen hatte: premature termination, den vorzeitigen Abbruch. Bei großem Kontext geben Modelle auf oder liefern eine falsche Antwort zurück, die sie selbst als unsicher kennzeichnen, lange bevor sie das Fenster ausgeschöpft haben. Auch bei kontrollierter Schwierigkeit der Anfrage stellten die Autoren fest, dass die Rate vorzeitiger Abbrüche mit der Kontextlänge steigt.

Das rahmt das Problem neu. Context Rot umfasst zwei verschiedene Fehler, und sie verlangen unterschiedliche Korrekturen. Findet das Modell die Nadel nicht mehr, muss die Präzision steigen. Hört das Modell auf zu suchen, braucht es Raum und Anlass, weiterzusuchen. Bei einem Agenten mit mehrstufiger Suche kostet es Wochen, beides zu vermengen.

Der zweite Befund ist der, den Sie sich abschauen sollten. Die Autoren testeten sieben Methoden des Kontextmanagements aus drei Familien (Compaction, Trimming und Isolation über Sub-Agenten) und kamen zu dem Schluss, dass diese Methoden vor allem als Test-Time-Scaling-Strategien wirken: Indem sie die Rate vorzeitiger Abbrüche senken, verschaffen sie dem Modell mehr Exploration. Welche Familie hilft, hängt vom Modell ab. Beim stärkeren der verglichenen agentischen Modelle, Qwen3.5-397B-A17B, schnitt die Isolation der Arbeit in Sub-Agenten am besten ab. Beim schwächeren, GLM-4.7, gehörten Sub-Agenten zu den schlechtesten Optionen, und nur die jüngsten Tool-Ergebnisse plus eine Zusammenfassung zu behalten ergab das beste Verhältnis von Genauigkeit und Kosten. Zusätzlich bauten die Autoren eine verhaltensbewusste Filterstrategie für paralleles Sampling, die die durchschnittliche Genauigkeit über drei Aggregationsmethoden hinweg um 2,6 bis 4,9 Prozentpunkte steigerte.

Wenn Sie Agenten über lange Sessions laufen lassen, verfolgen Sie, wie oft Ihre Agenten früh aufgeben. Das ist eine billige Metrik, und fast niemand instrumentiert sie.

Drei weitere Preprints von 2026, veröffentlicht zwischen Juli und Anfang Oktober, weisen in dieselbe Richtung. Context as an Environment hält Tool-Ausgaben als Variablen in einer persistenten Python-Session und lässt nur das in den Kontext des Agenten, was dieser ausgibt; mit demselben Qwen3.8-Max als zugrunde liegendem Modell erreichte der Ansatz auf dem LOCA-Benchmark bei 256K Tokens 86,7 Prozent, gegenüber 65,3 Prozent für einen Agenten, der seine Historie zusammenfasst. Stateless Language Agents baut den Kontext bei jedem Aufruf aus dem Zustand neu auf, den das Harness verwaltet, statt das Gespräch fortzuschreiben, und erreichte bei der Kernel-Optimierung die Endleistung der stärksten Baseline mit über 84 Prozent weniger Tokens. Und CompactionRL behandelt Compaction als Fähigkeit, die man trainiert, statt als Feature, das man nachträglich anschraubt: Das damit trainierte GLM-4.5-Air-Modell erzielte auf SWE-bench Verified 6,6 Punkte mehr als dasselbe Basismodell mit zur Inferenzzeit ergänzter Compaction. Das sind Preprints, aber in der Richtung sind sie sich einig: das Working Set klein halten und dem Modell beibringen, es klein zu halten.

---

Wie Sie Context Rot in Agenten und Chat-Tools beheben

Jede Lösung, die funktioniert, macht im Kern dasselbe: Das Modell bekommt weniger, aber bessere Tokens vorgelegt. Anthropics Engineering-Team bringt es in Effective context engineering for AI agents in einem Satz auf den Punkt: „Kontext muss daher als endliche Ressource mit abnehmendem Grenznutzen behandelt werden." Was sich unterscheidet, ist nur, wo Sie diese Regel anwenden.

Wenn Sie LLM-Apps oder Agenten bauen:

• Weniger senden und gut auswählen. Abrufen, reranken und weglassen, was die Aufgabe nicht braucht. Googles Long-Context-Leitfaden sagt dasselbe: „Wenn Sie Tokens nicht an das Modell übergeben müssen, ist es im Allgemeinen am besten, darauf zu verzichten."
• Lange Dokumente zuerst, die Frage zuletzt. Bei Eingaben ab 20K Tokens empfiehlt Anthropics Prompting-Leitfaden, die Dokumente an den Anfang und die Anfrage ans Ende zu stellen, und merkt an, dass Anfragen am Ende „die Antwortqualität in Tests um bis zu 30 Prozent verbessern können". Außerdem rät er, das Modell vor der Antwort die relevanten Passagen zitieren zu lassen. Google gibt für Gemini dieselbe Empfehlung zur Platzierung.
• Veraltete Tool-Ergebnisse löschen. Alte Suchergebnisse und Datei-Dumps sind die Tokens, die sich am billigsten streichen lassen. Anthropic nennt das Löschen von Tool-Ergebnissen „eine der sichersten, schonendsten Formen der Compaction" und liefert es als Context Editing aus, das standardmäßig ab 100.000 Input-Tokens mit dem Löschen beginnt und die drei jüngsten Tool-Aufrufe behält.
• Kompaktieren, bevor das Fenster voll ist, und die Zusammenfassung prüfen. Anthropics API bietet schwellenbasierte Compaction (Standard-Auslöser: 150.000 Input-Tokens) und seit September 2026 auch Compaction auf Abruf. OpenAIs Responses API kompaktiert serverseitig, wenn Sie unter context_management einen compact_threshold setzen, und bietet außerdem einen eigenständigen Compact-Endpunkt. Eine Zusammenfassung ist verlustbehaftet, prüfen Sie also, was dabei wegfällt. Anthropic rät, zunächst den Recall zu maximieren und danach Überflüssiges zu streichen.
• Regeln und Zustand außerhalb der Zusammenfassung halten. The Compaction Cliff in Long-Running AI Agent Memory, ein CIKM-2026-Paper, das im August auf arXiv erschien, stellte fest, dass der Compact-Prompt von Claude Code auf Sonnet 4.6 von den Sicherheitsregeln in produktiven Agentenkonfigurationen nach einer Runde 53 Prozent behielt und nach fünf Runden 10 Prozent. Die Lösung der Autoren fixiert Sicherheitsregeln und Abläufe wortgetreu und komprimiert den Rest nach Typ; sie hielt über fünf Runden einen Recall von 96 Prozent. Verankern Sie Regeln also dort, wo der Agent sie erneut liest, und halten Sie den Fortschritt in Notizen, einem Memory-Tool oder git fest statt im Chatverlauf.
• Exploration an Sub-Agenten auslagern. Ein Sub-Agent verbraucht für die Suche seinen eigenen Kontext und gibt, in Anthropics Worten, „eine verdichtete, destillierte Zusammenfassung seiner Arbeit (oft 1.000-2.000 Tokens)" zurück. Testen Sie das aber an Ihrem Modell: Im Paper zur premature termination schnitten Sub-Agenten beim stärkeren der beiden verglichenen Modelle am besten ab und beim schwächeren mit am schlechtesten. Wie Sub-Agenten, Skills und Hooks zusammenspielen, behandeln wir in unserem Leitfaden zu Agentic Engineering.
• Nach Kontextgröße messen. Werten Sie Ihr eigenes Eval bei mehreren Eingabelängen aus und protokollieren Sie frühe Abbrüche. Ohne das ist jede der obigen Maßnahmen nur eine Vermutung.

Anthropic hat für die Kombination Zahlen veröffentlicht. In einer internen Evaluation zur agentischen Suche verbesserte das Memory-Tool zusammen mit Context Editing die Leistung gegenüber der Baseline um 39 Prozent, Context Editing allein um 29 Prozent. In einem Websuche-Test über 100 Züge senkte Context Editing den Token-Verbrauch um 84 Prozent. Das sind Zahlen eines Anbieters über sein eigenes Produkt; lesen Sie sie also als Richtung, nicht als Versprechen.

Wenn Sie Chat-Assistenten oder Coding-Agenten nutzen:

• Ein Chat pro Aufgabe. Der Best-Practices-Leitfaden von Claude Code sagt: „Eine saubere Session mit einem besseren Prompt schlägt fast immer eine lange Session mit angesammelten Korrekturen." OpenAIs Codex-Leitfaden sieht es genauso: „Führen Sie einen Chat pro zusammenhängende Arbeitseinheit."
• Nach zwei gescheiterten Korrekturen neu starten. Das ist die Faustregel von Claude Code selbst: /clear ausführen und einen besseren ersten Prompt schreiben, der enthält, was Sie dabei gelernt haben.
• Zu Ihren Bedingungen kompaktieren. Claude Code, Codex und Cursor fassen nahe am Limit alle automatisch zusammen. Wenn Sie früher und mit einer Fokus-Anweisung kompaktieren (zum Beispiel /compact Focus on the API changes), bestimmen Sie mit, was erhalten bleibt. Claude Code warnt, dass „detaillierte Anweisungen vom Anfang des Gesprächs verloren gehen können"; dauerhafte Regeln gehören deshalb in eine Datei, die der Agent erneut liest, etwa CLAUDE.md, und nicht in den Chat.
• Den Füllstand im Blick behalten. /context zeigt in Claude Code, was das Fenster füllt, und /status zeigt in Codex, wie viel davon Sie schon verbraucht haben. Cursor platziert neben dem Eingabefeld einen Kontext-Ring, der per Klick eine Aufschlüsselung öffnet.

Befehle und Standardwerte ändern sich von Release zu Release; betrachten Sie die Tabelle daher als Stand Oktober 2026 und prüfen Sie nach einem Upgrade die Dokumentation Ihres Tools.

---

Wo RAG weiterhin gewinnt

Vor diesem Hintergrund behauptet Retrieval-Augmented Generation weiterhin ihren Platz. Hier gewinnt RAG nach wie vor.

Große Korpora aus vielen Dokumenten. Umfasst Ihre Wissensbasis 50.000 Dokumente mit insgesamt 500M Tokens, passt sie in kein Fenster. Retrieval ist dann die einzig tragfähige Architektur.

Aktualität und Frische. Vektorspeicher aktualisieren inkrementell. Ein Long-Context-Prompt muss neu gebaut werden, sobald sich Inhalte ändern. Bei allem, was stündlich aktualisiert wird (News, Kataloge, Support-Tickets, Code), verarbeitet Retrieval Änderungen günstig.

Kosten. Die Input-Kosten skalieren mit den Input-Tokens, und oberhalb bestimmter Schwellen skalieren sie schlechter als linear. Wenn sich 95 Prozent Ihrer Anfragen aus 5K relevanten Tokens beantworten lassen, ist Retrieval um ein Vielfaches günstiger, ohne Genauigkeit einzubüßen.

Zitate und Provenienz. Retrieval liefert Ihnen eine strukturierte Liste von Quellen, die sich anzeigen, verlinken und ranken lässt, während es zusätzlichen Aufwand braucht, um eine Long-Context-Antwort in konkreten Quellen zu verankern. Aus demselben Grund schlägt ein Lesewerkzeug, das die Passage samt Quelle behält, eines, das nur eine Zusammenfassung behält: Wenn Sie in Glasp Fragen über alles stellen, was Sie gespeichert haben, kann jede Antwort auf die Quelle zurückzeigen, aus der sie stammt.

Zugriffskontrolle und Mandantenfähigkeit. Wenn Ihr Korpus Sichtbarkeiten pro Nutzer, pro Mandant oder pro Rolle kennt, können Sie es nicht komplett hineinkippen. Retrieval filtert nach Richtlinie, bevor das Modell überhaupt etwas sieht. Im B2B ist das nicht verhandelbar.

Reasoning über mehrere Korpora. Wenn die Antwort einen Slack-Thread, eine Notion-Seite, ein Linear-Issue und einen GitHub-PR umspannt, ist Retrieval die Brücke.

Trifft auch nur einer dieser Punkte zu, ist RAG nicht optional. Die Frage lautet dann, wie man Retrieval gut macht, nicht ob man es einsetzt.

---

Wo Long Context gewinnt

Für manche Workloads ist Long Context schlicht die richtige Antwort.

Tiefes Reasoning über ein einzelnes Dokument. Einen 100-seitigen Vertrag lesen und klauselübergreifend antworten. Ein Paper analysieren. Einen Earnings Call durcharbeiten. Wenn die Antwort zwei Absätze verbindet, die 80 Seiten auseinanderliegen, zerschneidet Chunking diese Verbindung oft.

Code-Verständnis innerhalb eines Repositories. Viele Code-Aufgaben brauchen Imports, Typen, Definitionen und Aufrufstellen gleichzeitig. Chunking pro Datei verliert die Beziehungen zwischen den Dateien.

Gesprächskontinuität. Lange Agenten-Sessions profitieren von echter Historie. Retrieval über den Gesprächsverlauf ist brüchig, weil meist die letzten 50 Züge gebraucht werden und nicht die 50 semantisch ähnlichsten.

Exploratives Reasoning, wenn die Anfrage noch nicht feststeht. Wenn Sie die Anfrage nicht vorab formulieren können, lässt sich Retrieval kaum gezielt einsetzen. Long Context lässt das Modell stöbern.

Querverweise innerhalb einer zusammenhängenden Einheit. Ein Lehrbuchkapitel, ein Paper, ein juristischer Schriftsatz. Diese zu zerteilen und wieder zusammenzusetzen kostet meist die Argumentation.

Grobe Heuristik: Bilden Ihre Daten ein logisches Dokument und passen sie in Ihr gemessenes sicheres Budget, ist Long Context die sauberere Architektur.

---

Das Hybrid-Muster, bei dem die meisten Teams landen

Der Standard für ernsthafte Systeme im Jahr 2026 ist weder reines RAG noch reiner Long Context. Man ruft eine substanzielle, aber begrenzte Menge an Tokens ab und schlussfolgert dann darüber.

User query
   |
   v
[Retrieval Stage]
   - Vector search (top 100 chunks)
   - Optional keyword/BM25 search merged in (hybrid retrieval)
   - Optional reranker (cross-encoder over top 100, keep top 30)
   |
   v
[Assembly Stage]
   - Concatenate retrieved chunks
   - Add metadata, source headers, structural hints
   - Target total: 50K to 200K tokens
   |
   v
[Long-Context Reasoning Stage]
   - Send to frontier model with reasoning prompt
   - Model uses the full retrieval set as its context
   |
   v
Answer + citations

Jede Stufe deckt den Fehlermodus der anderen ab. Retrieval verengt ein Korpus, das für jedes Fenster zu groß ist, auf etwas Handhabbares. Das Reasoning über die gesamte abgerufene Menge stellt jenes chunk-übergreifende Schlussfolgern wieder her, das klassisches Top-5-RAG wegwirft.

Die tragende Entscheidung ist die Größe der Retrieval-Menge. Zu wenige Tokens, und Sie haben nur Top-5-RAG nachgebaut. Zu viele, und Sie stecken in der Context-Rot-Zone und zahlen mehr für eine schlechtere Antwort. Eine brauchbare Faustregel, die der nächste Abschnitt in eine Messung überführt: Planen Sie ein sicheres Budget von etwa 20 bis 40 Prozent des dokumentierten Fensters und prüfen Sie es an Ihren eigenen Daten nach. Bei einem Modell mit 200K-Fenster sind das 40K bis 80K. Bei einem Modell mit 1M-Fenster sind es 200K bis 400K, was zufällig ziemlich genau dort liegt, wo sich bei OpenAI und bei Gemini 3.1 Pro die Abrechnung ändert.

---

Den Hybrid tunen: Zahlen und Heuristiken

Das sind keine universellen Wahrheiten, sondern Startpunkte, die sich im Produktivbetrieb bewähren.

Chunk-Größe. 500 bis 1.500 Tokens für Fließtext. 200 bis 500 für Code, pro Funktion oder logischem Block. 1.500 bis 3.000 für juristische oder akademische Texte, in denen der Kontext innerhalb eines Chunks Bedeutung trägt. 10 bis 20 Prozent Überlappung.

Top-k-Retrieval. Mehr abrufen, als am Ende gesendet wird. Top 50 bis 200 abrufen, dann reranken. Ein Cross-Encoder kostet pro Paar mehr als ein Embedding-Modell und ist bei feingranularer Relevanz dramatisch besser.

Verhältnis von Rerank zu Kontext. Nach dem Reranking die besten 20 bis 100 Chunks behalten. Die genaue Zahl ergibt sich aus der Chunk-Größe und Ihrem sicheren Budget.

Hybrides Retrieval. Dichte und spärliche Verfahren (BM25, SPLADE) per Reciprocal Rank Fusion kombinieren. Rein dichtes Retrieval verpasst exakte Treffer wie SKUs, Fehlercodes und Eigennamen. Rein spärliches Retrieval verpasst Umschreibungen.

Zwei dieser Stellschrauben verdienen mehr als einen Aufzählungspunkt, denn an ihnen verlieren Teams unbemerkt Genauigkeit.

Die erste ist Ihr sicheres Kontextbudget, und der einzig ehrliche Weg, es festzulegen, ist Messen. Bauen Sie ein kleines Eval-Set aus Fragen, die chunk-übergreifendes Schlussfolgern verlangen, und bewerten Sie die Genauigkeit bei 16K, 32K, 64K, 128K und 256K vollgestopftem Kontext. Nehmen Sie die größte Kontextgröße, bei der die Genauigkeit Ihre Schwelle noch erreicht, und arbeiten Sie 20 Prozent darunter, um Luft zu behalten. Dieser gemessene Wert sollte ungefähr bei der obigen Regel von 20 bis 40 Prozent landen; tut er es nicht, gilt Ihr Eval und nicht die Heuristik. Falls Sie noch kein Eval-Harness haben, behandelt unser Leitfaden zum LLM-Evals-Stack die nötigen Werkzeuge.

Die zweite ist das, was beim Modell-Upgrade passiert, und genau das hat Teams 2026 erwischt. Mit Claude Opus 4.7 hat sich Anthropics Tokenizer geändert: Derselbe Text ergibt nun je nach Inhalt ungefähr das 1,0- bis 1,35-Fache an Tokens, was Anthropic mit rund 30 Prozent mehr zusammenfasst. Auch Haiku 5.5, erschienen am 7. Oktober, nutzt den neueren Tokenizer; eine Pipeline, die von Haiku 4.5 umsteigt, zählt für denselben Text also rund 30 Prozent mehr Tokens. Ihre Dokumente sind nicht gewachsen. Ihr Budget ist geschrumpft. Wenn Sie vor einem Jahr eine Token-Obergrenze festgezurrt und darunter das Modell getauscht haben, bedeutet diese Obergrenze heute etwas anderes, und nichts in Ihren Logs wird das ankündigen.

Retrieval ganz überspringen, wenn die Anfrage es nahelegt. „Das gerade hochgeladene Dokument zusammenfassen" ist eine Einzeldokument-Aufgabe. Erkennen Sie solche Fälle mit einem kleinen Klassifikator, überspringen Sie das Retrieval, sparen Sie Latenz und vermeiden Sie, dass themenfremdes Rauschen in den Kontext gelangt.

Schichten für Zusammenfassung und Pruning. Bei sehr langen Historien älteres Material vor dem Zusammenbau komprimieren. Auch Zusammenfassungen kosten Tokens, also messen, ob sie tatsächlich helfen.

---

Anti-Patterns, die Engineers immer wieder ausliefern

Einige Fallen wiederholen sich oft genug, um sie zu benennen.

„Einfach alles in den Kontext kippen." Nach jedem Release, das das Fenster verdoppelt, ist das verlockend. Es degradiert stillschweigend, also bestehen Sie die Stichproben und scheitern im Produktivbetrieb genau an den Anfragen, die kontextübergreifendes Schlussfolgern gebraucht hätten. Führen Sie vor dem Ausliefern ein Eval bei Ihrer Zielgröße durch.

„Immer RAG verwenden." Reflexhaftes Retrieval verfehlt die Einzeldokument-Fälle. Ein 50-seitiges PDF zu indexieren und die Top-5-Chunks zu ziehen ist meist besser als nichts, verliert aber gegen das schlichte Senden des PDF.

„Die zusammengebaute Token-Zahl ignorieren." Teams setzen top-k auf „was gerade passt" und stellen drei Monate später fest, dass ihr durchschnittlicher Prompt 350K Tokens umfasst, die Genauigkeit still gesunken ist und sich die Rechnung an einer Schwelle verdoppelt hat, die niemand gelesen hatte. Behandeln Sie die Größe des zusammengebauten Kontexts als vollwertige Kernmetrik und richten Sie einen Alert dafür ein.

„Die automatische Compaction wird das schon regeln." Automatische Compaction hält eine Session am Leben. Für Genauigkeit sorgt sie nicht. Zusammenfassungen verlieren Anweisungen, und das Compaction-Cliff-Paper beobachtete, wie der Anteil erhaltener Regeln Runde um Runde sank. Entscheiden Sie, was überleben muss, und speichern Sie es außerhalb des Gesprächs.

„Evals weglassen, weil das Modell jetzt gut ist." Modell-Upgrades verändern die richtige Architektur und manchmal auch unbemerkt Ihre Token-Buchhaltung. Bewerten Sie neu, wenn sich Modelle ändern.

„Ein stiller Fehler ist ein harmloser Fehler." Unter Ablenkern halluzinieren manche Modelle und andere enthalten sich, und bei Aufgaben mit langem Horizont hören manche einfach früh auf. Finden Sie heraus, welches Verhalten Ihr Modell zeigt, und instrumentieren Sie Ihr System entsprechend.

---

Was sich 2026 geändert hat: Modelle, Preise und Compaction

Das meiste von dem, was folgt, hat sich zwischen September und Anfang Oktober 2026 geändert, als Anthropic, OpenAI und Google allesamt neue Modelle auslieferten, und nicht alles davon weist in dieselbe Richtung.

Die Modellpalette hat sich erneuert. Anthropic veröffentlichte Claude Fable 5.1 am 1. September, Opus 5.5 am 22. September, Sonnet 5.5 am 28. September und Haiku 5.5 am 7. Oktober, alle mit Fenstern von 1M Tokens. OpenAI brachte GPT-6 Astra am 3. September, GPT-6 Sol und Luna am 22. September und GPT-6.1 Sol am 29. September heraus, jeweils mit einem Fenster von 1,05M und bis zu 922K Input-Tokens. Google machte Gemini 3.8 Flash am 2. September allgemein verfügbar, während Gemini 3.1 Pro weiterhin ein Preview-Modell ist.

Die besten Retrieval-Werte sind sprunghaft gestiegen, und die Spreizung zwischen den Modellen ist enorm. Auf OpenAI MRCR v2, dem hauseigenen 8-Needle-Test, meldet OpenAI für GPT-6 Astra 96,3 Prozent zwischen 512K und 1M Tokens, gegenüber 73,8 Prozent für GPT-5.6 Sol. Googles Model Card bewertet Gemini 3.1 Pro auf Googles eigenem MRCR v2 (8-Needle), das trotz des gleichen Namens ein anderer Datensatz ist: 84,9 Prozent im Mittel bis 128K und 26,3 Prozent bei 1M. Der Abstand zwischen den Anbietern ist also ein Signal, kein direkter Vergleich. Beide Zahlenreihen haben die Anbieter selbst erhoben (OpenAI meldet den besten Wert über alle Reasoning-Effort-Stufen hinweg), und MRCR misst, ob die richtige Passage gefunden und wiedergegeben wird, nicht das Schlussfolgern über ein Dokument hinweg. Context Rot ist nicht verschwunden, sondern zu etwas geworden, das Sie Modell für Modell messen müssen.

Die Preisklippen unterscheiden sich inzwischen bei jedem Anbieter. OpenAI bepreist die gesamte Anfrage oberhalb von 272K Input-Tokens weiterhin neu, und bei den GPT-6-Modellen heißt das „2x Input- und Cache-Tarife und 1,5x Output". GPT-6.1 Sol steigt von $2 und $10 pro Million Input- bzw. Output-Tokens auf $4 und $15, GPT-6 Astra von $10 und $50 auf $20 und $75. Die $4 und $20 von GPT-5.6 Sol sind ein Aktionspreis, der mindestens bis zum 21. November 2026 gilt, und jenseits derselben Linie steigt der Preis auf $8 und $30. Google rechnet Gemini-3.1-Pro-Prompts über 200K mit $4 und $18 statt $2 und $12 ab, während Gemini 3.8 Flash keine solche Stufe kennt. Anthropic rechnet bei Claude 4.6 und neueren Modellen das volle 1M-Fenster zu Standardtarifen ab („Eine Anfrage mit 900k Tokens wird zum gleichen Preis pro Token abgerechnet wie eine Anfrage mit 9k Tokens", heißt es auf der Preisseite), mit einer Ausnahme: Bei Haiku 5.5 kosten Prompts über 100.000 Tokens fünfmal so viel, $0.50 und $2.50 statt $0.10 und $0.50.

Compaction ist zum Produkt geworden. Die Einstellungen sind oben bei den Lösungen beschrieben. Neu ist, dass die Anbieter die Compaction inzwischen für Sie übernehmen. Anthropics Dokumentation empfiehlt die neue Compaction auf Abruf „überall dort, wo sie verfügbar ist". OpenAIs Responses API gibt kompaktierten Kontext als opakes Element zurück, das nicht für Menschen lesbar sein soll, und zu seiner Agents API, seit dem 10. September in der Public Beta, heißt es: „OpenAI übernimmt Session-Orchestrierung, Kontext-Compaction und Wiederherstellung." Beachten Sie allerdings den Standardwert: Ein Anbieter mit einem Fenster von einer Million Tokens startet die schwellenbasierte Compaction bei 150K.

Caching ist günstiger geworden. Context Rot behebt es trotzdem nicht. Cache-Lesevorgänge kosten bei den meisten Anthropic-Modellen ein Zehntel des Basis-Input-Preises, bei Opus 5.5 und Sonnet 5.5 ein Zwanzigstel und bei Fable 5.1 ein Vierzigstel. OpenAI verlangt bei den meisten Modellen ein Zehntel und bei GPT-6.1 Sol ein Zwanzigstel und berechnet seit GPT-5.6 Cache-Schreibvorgänge mit dem 1,25-Fachen des Input-Tarifs. Caching macht wiederholte Anfragen gegen stabile Inhalte deutlich günstiger. Es ändert nichts daran, was das Modell mit einer langen Eingabe macht, und bei OpenAI verdoppelt sich der Preis gecachter Tokens jenseits von 272K genauso wie der von ungecachtem Input.

Unverändert bleibt das zugrunde liegende Ergebnis. Bessere Modelle verschieben die Kurve, ein größeres Fenster allein behebt nichts, und für aktuelle, mandantenfähige Workloads aus vielen Quellen brauchen Sie weiterhin Retrieval.

Das ist dieselbe Disziplin, die sich generell beim Context Engineering zeigt: Was aus dem Prompt herausgelassen wird, zählt genauso viel wie das, was hineinkommt. Und es ist auch der Grund, warum die Retrieval-Schicht dieselbe Prüfung verdient wie jeder andere Eingabepfad, denn indirekte Prompt Injection kommt über abgerufene Dokumente herein und nicht über Ihre Nutzer.

---

Ein Entscheidungsrahmen für den sofortigen Einsatz

Gehen Sie das bei jedem neuen LLM-Feature von oben nach unten durch.

Schritt 1: Wie groß ist Ihr Korpus?

• Insgesamt unter 100K Tokens: Retrieval überspringen, Long Context verwenden.
• 100K bis 1M Tokens: hängt von der Aktualität ab, weiter zu Schritt 2.
• Über 1M Tokens: Retrieval ist Pflicht.

Schritt 2: Wie aktuell müssen die Daten sein?

• Stündlich oder schneller: Retrieval. Lange Prompts neu zu bauen ist zu teuer.
• Täglich bis wöchentlich: Beide Muster funktionieren.
• Statisch: Long Context mit Prompt Caching ist günstig und sauber.

Schritt 3: Welche Form hat die Anfrage?

• Tiefes Reasoning über ein einzelnes Dokument: eher Long Context.
• Synthese über mehrere Dokumente: eher hybrid.
• Nachschlagen oder Faktenabruf: eher klassisches RAG.
• Explorativ: Long Context, wenn die Dokumentmenge begrenzt ist, sonst hybrid.

Schritt 4: Brauchen Sie Zitate oder Zugriffskontrolle?

• Ja bei einem von beiden: Retrieval ist Pflicht. Zitate und nutzerbezogene Filter nachträglich in ein reines Long-Context-Design einzubauen ist schmerzhaft.

Schritt 5: Wie hoch ist Ihr Latenzbudget?

• Unter 1 Sekunde: klassisches RAG.
• 1 bis 5 Sekunden: Hybrid ist machbar.
• Über 5 Sekunden: Jedes Muster funktioniert.

Schritt 6: Wo liegt Ihre Genauigkeitsuntergrenze bei langen Anfragen?

• Hohe Genauigkeit bei mehrstufigem Reasoning jenseits von 50K Tokens: hybrid mit Reranker.
• Best Effort: Klassisches RAG genügt meist.

Schritt 7: Wo landet Ihr zusammengebauter Prompt relativ zur Preisklippe?

• Unter 272K bei OpenAI, unter 200K bei Gemini 3.1 Pro, unter 100K bei Claude Haiku 5.5 oder anderswo unter Ihrem gemessenen sicheren Budget: unproblematisch.
• Knapp an einer dieser Linien: Reranker ergänzen und die Retrieval-Menge kürzen. Meist bekommen Sie so gleichzeitig eine bessere Antwort und eine kleinere Rechnung.

Schritt 8: Läuft das als lange Session oder als Agent?

• Ja: Legen Sie vorab fest, was gelöscht wird (alte Tool-Ergebnisse), was kompaktiert wird, was außerhalb des Gesprächs liegt (Regeln, Fortschritt) und wann der Agent neu beginnt. Protokollieren Sie frühe Abbrüche.
• Nein: Für Einzelanfragen genügen die Schritte 1 bis 7.

Die meisten Produktivsysteme landen beim Hybrid, weil reale Workloads mindestens eine Einschränkung mitbringen, die reinen Long Context bricht (Mandantenfähigkeit, Aktualität, Kosten, Zitate), und mindestens eine, die reines Top-k-RAG bricht (Reasoning über ein Dokument, kontextübergreifende Anfragen, Exploration).

Es gibt eine menschliche Version derselben Fähigkeit. Aufmerksame Leser haben immer schon von Hand entschieden, welches Material es verdient, vor einen Denkprozess zu gelangen, und Highlighting ist genau diese Entscheidung, explizit gemacht. Glasps Web-Highlighter behält die Passagen, die Sie für behaltenswert hielten, statt der ganzen Seite, und das ist Retrieval mit menschlichem Reranker. Wenn Sie Ihre eigenen Werkzeuge auf diese Menge richten möchten, stellt Glasps MCP-Connector Ihre Highlights einem LLM direkt zur Verfügung. Mehr zu diesem Setup haben wir in Ihre Notizen in einen MCP-Server verwandeln geschrieben.

---

Häufig gestellte Fragen

Was ist Context Rot in LLMs?

Context Rot ist der gemessene Rückgang darin, wie gut ein LLM seine Eingabe nutzt, wenn diese wächst, und zwar lange bevor das Kontextfenster voll ist. Die Genauigkeit bei Retrieval und Reasoning sinkt ungleichmäßig, je nach Modell unterschiedlich stark, und schneller, wenn Ablenkertext der Antwort ähnelt. Chroma fand bei allen 18 getesteten Modellen, dass ein kohärenter Heuhaufen mehr schadete als ein durchmischter, und Anthropics Dokumentation definiert den Begriff inzwischen direkt: „Mit wachsender Token-Zahl verschlechtern sich Genauigkeit und Recall, ein Phänomen, das als Context Rot bekannt ist." Ein Fenster von 1M Tokens zu füllen erkauft keine Antwort in 1M-Token-Qualität.

Wie lässt sich Context Rot beheben?

Senden Sie weniger, aber bessere Tokens. Für Apps und Agenten heißt das: abrufen und reranken statt vollstopfen, lange Dokumente vor die Frage stellen, veraltete Tool-Ergebnisse löschen, kompaktieren, bevor das Fenster voll ist, Regeln und Fortschritt außerhalb des Gesprächs halten und Exploration an Sub-Agenten übergeben. Für Chat- und Coding-Tools heißt es: ein Chat pro Aufgabe, nach zwei gescheiterten Korrekturen neu starten, früh mit einer Fokus-Anweisung kompaktieren und dauerhafte Regeln in einer Datei ablegen, die der Agent erneut liest, etwa CLAUDE.md.

Beheben neuere Modelle wie Claude Opus 5.5 oder GPT-6 Context Rot?

Kein Modell ist immun, aber die Spreizung zwischen den Modellen ist groß. OpenAI meldet für GPT-6 Astra auf seinem 8-Needle-MRCR 96,3 Prozent zwischen 512K und 1M Tokens, während Googles Model Card für Gemini 3.1 Pro auf Googles eigener Version des Tests 26,3 Prozent bei 1M ausweist. Die Datensätze unterscheiden sich, doch der Abstand ist zu groß, um ihn zu ignorieren. Anthropics Dokumentation beschreibt Context Rot als allgemeine Eigenschaft wachsender Eingaben, und die Dokumentation von Claude Code hält fest, dass die Leistung „nachlässt, je voller der Kontext wird". Messen Sie das Modell, das Sie tatsächlich einsetzen, an Eingaben, die Ihren ähneln.

Ist RAG 2026 noch relevant?

Ja. Retrieval bleibt erforderlich für Korpora, die jedes Fenster übersteigen, für Daten, die sich stündlich ändern, für mandantenbezogene Zugriffskontrolle und für Zitate. Veraltet ist das klassische Top-5-RAG als einziges Muster. Der aktuelle Standard ist hybrid: eine begrenzte Menge abrufen und dann über alles davon schlussfolgern. Größere Kontextfenster haben verändert, wie viel Sie abrufen, nicht ob Sie abrufen.

Ersetzt Long Context RAG?

Im allgemeinen Fall nicht. Chromas Context-Rot-Report zeigte, dass die Leistung lange vor dem Füllen des Fensters degradiert, und die Anbieter bauen, als stimmten sie dem zu: Anthropics schwellenbasierte Compaction greift bei 1M-Token-Modellen standardmäßig bei 150K, OpenAI bepreist Anfragen oberhalb von 272K Input-Tokens neu, und Google verlangt für Gemini-3.1-Pro-Prompts über 200K mehr. Long Context ersetzt RAG dort, wo es um ein einzelnes, begrenztes Dokument geht, das in Ihr gemessenes sicheres Budget passt.

Wie groß darf meine Retrieval-Menge sein, bevor Context Rot einsetzt?

Testen Sie Ihr konkretes Modell, aber ein vernünftiger Startpunkt sind 20 bis 40 Prozent des dokumentierten Fensters. Das sind 40K bis 80K bei einem 200K-Modell und 200K bis 400K bei einem 1M-Modell, wobei Sie aus Abrechnungsgründen bei OpenAI unter 272K, bei Gemini 3.1 Pro unter 200K und bei Claude Haiku 5.5 unter 100K bleiben sollten. Bauen Sie ein kleines Eval aus mehrstufigen Fragen, messen Sie die Genauigkeit über Kontextgrößen hinweg und nehmen Sie die größte Kontextgröße, bei der die Genauigkeit Ihre Schwelle noch erreicht.

Behebt Prompt Caching Context Rot?

Nein. Caching behebt Kosten, nicht Genauigkeit. Gecachte Lesevorgänge kosten je nach Modell inzwischen zwischen einem Zehntel und einem Vierzigstel des normalen Input-Preises, sodass Long-Context-Anfragen gegen stabile Inhalte deutlich günstiger werden und der Kostenvorteil von RAG schrumpft. Das Modell liest weiterhin denselben langen Kontext und degradiert auf dieselbe Weise; Sie zahlen also weniger für dieselbe schwächere Antwort. Bei OpenAI verdoppelt sich oberhalb von 272K außerdem auch der Preis gecachter Tokens.

Sollte ich vor dem Senden an Long Context einen Reranker einsetzen?

Für die meisten hybriden Produktivsysteme: ja. Ein Cross-Encoder, der die abgerufenen Top-50- bis Top-200-Chunks bewertet, verbessert deutlich, was die Reasoning-Stufe erreicht. Auf das Reranking zu verzichten bedeutet meist, mehr Tokens hineinzustopfen, um die schwächere Präzision auszugleichen, und das schiebt Sie sowohl Richtung Context-Rot-Zone als auch Richtung Preisklippe. Es ist eine der wirkungsvollsten Änderungen, die sich an einer hybriden Pipeline vornehmen lassen.

Mein Agent bricht bei langen Aufgaben früh ab. Ist das Context Rot?

Wahrscheinlich, und es hat inzwischen einen Namen. Das Paper von 2026, Diagnosing and Mitigating Context Rot in Long-horizon Search, nennt es premature termination: Bei sehr großem Kontext geben Modelle auf oder liefern eine falsche Antwort zurück, die sie selbst als unsicher kennzeichnen, bevor sie das Fenster ausgeschöpft haben, und zwar mit einer Rate, die mit der Kontextlänge steigt. Kontextmanagement (Compaction, Trimming oder Sub-Agenten) hilft vor allem, indem es diese Rate senkt, sodass der Agent weiter exploriert. Erfassen Sie frühe Abbrüche als eigene Metrik.

---

Abschließende Gedanken

Jedes Release mit einem größeren Fenster trägt dasselbe implizite Versprechen: Schluss mit dem Engineering, einfach alles hineinkippen. Chroma hat mit harten Zahlen belegt, warum dieses Versprechen nicht eingelöst wurde, die Arbeiten von 2026 haben einen zweiten Fehlermodus ergänzt, nach dem niemand gesucht hatte, und die zugrunde liegende Mathematik (Softmax-Verdünnung, Positions-Extrapolation, Trainingsverteilung) sagt, dass es auch bei 100M Tokens nicht sauber eingelöst wird.

Übrig bleibt die langweilige, produktive Antwort. Bauen Sie Retrieval. Tunen Sie es. Ergänzen Sie einen Reranker. Löschen Sie, was das Modell nicht mehr braucht, und halten Sie, was es nie verlieren darf, außerhalb des Gesprächs. Wählen Sie ein sicheres Kontextbudget durch Messen statt durch Vertrauen in ein Datenblatt, und messen Sie neu, wenn sich das Modell oder sein Tokenizer ändert, was zwischen September und Anfang Oktober 2026 bei Anthropic, OpenAI und Google gleichermaßen geschah. Senden Sie die kleinste, relevanteste Token-Menge, die die Antwort enthält. Lassen Sie das Modell darüber schlussfolgern. Nennen Sie die Quellen.

Die Wendung von 2026 ist, dass die Anbieter inzwischen so bauen, als stimmten sie Ihnen zu. OpenAIs Linie bei 272K, Googles bei 200K für Gemini 3.1 Pro, die von Haiku 5.5 bei 100K und eine Compaction-Voreinstellung bei 150K auf Claude-Modellen mit einer Million Tokens sind allesamt Eingeständnisse, dass das nutzbare Fenster nur ein Bruchteil des beworbenen ist. Anthropics einheitliche Preise für seine größeren Modelle beseitigen die Preisklippe, aber nicht die Genauigkeitskosten, und auch bei einheitlichem Tarif kosten weniger Tokens weniger. Die disziplinierte Architektur ist also zugleich die günstige, und diese beiden zeigen selten in dieselbe Richtung.

Wenn Sie eine breitere Übersicht suchen, welches Modell zu welcher Aufgabe passt, finden Sie sie in unserer Matrix aus KI-Aufgaben und Modellen. Architekturentscheidungen überdauern Modell-Releases. Treffen Sie sie richtig, ist das nächste Upgrade eine kostenlose Verbesserung statt einer erzwungenen Neuentwicklung.