Vertraue großen Kontextfenstern nicht

• Das Kontextfenster eines LLM kann in einen smarten Bereich unterteilt werden, in dem das Modell präzise arbeitet, und in einen stumpfen Bereich, in dem die Aufmerksamkeit nachlässt und es frühere Anweisungen zu vergessen beginnt
• Der Übergangspunkt liegt bei etwa 100k Tokens; selbst wenn größere Kontextfenster beworben werden, bedeutet das nicht automatisch einen entsprechend nutzbaren Arbeitsbereich
• Coding-Agenten können allein durch Dateizugriffe, langes Debugging und das Ausführen großer Tests schnell Tokens verbrauchen und die Marke von 100k Tokens erreichen
• Berichte von RULER und Chroma über context rot zeigen, dass der effektive Kontext nur ein Teil der beworbenen Zahl ist und die Leistung allmählich nachlässt, je voller das Fenster wird
• Statt lange Sitzungen automatisch zusammenzufassen, hilft es mehr, Informationen mit selbst verfassten Spezifikationen und kleinen Artefakten außerhalb der Sitzung zu hinterlassen, damit die Arbeit im smarten Bereich bleibt

---

Die tatsächlichen Grenzen des Kontextfensters

• Das Kontextfenster eines LLM lässt sich in einen scharfen smarten Bereich und einen stumpfen Bereich mit nachlassender Aufmerksamkeit aufteilen
  • Im stumpfen Bereich beginnt das Modell zu vergessen, was ihm erst vor wenigen Minuten mitgeteilt wurde
  • Der Übergangspunkt liegt bei ungefähr 100k Tokens
  • Auch ein größer beworbenes Kontextfenster beseitigt diesen Übergangspunkt nicht
• Coding-Agenten verbrauchen in moderner Nutzung Tokens sehr schnell
  • Schon ein paar Dateilesungen, lange Debugging-Sitzungen und breit angelegte Testläufe können 100k Tokens erreichen
  • Anbieter werben mit Kontextfenstern von 200k, 1M oder 2M, aber diese Zahlen entsprechen nicht der tatsächlich nutzbaren Arbeitsmenge
• Große Kontextfenster sind größtenteils eher Marketing-Zahlen
  • Die Architektur dahinter funktioniert, verdeckt aber Probleme, die der grundlegende Aufmerksamkeitsmechanismus praktisch nicht löst
  • Die in Produkten angezeigten Zahlen wachsen mit jeder Veröffentlichung, aber der nutzbare Teil hält nicht im gleichen Tempo mit
• RULER und Chromas Bericht zu context rot zeigen, dass der effektive Kontext nur einen Teil der beworbenen Zahl ausmacht
  • Je stärker das Kontextfenster gefüllt wird, desto mehr sinkt die Leistung schrittweise

Arbeitsweise, um Sitzungen kurz zu halten

• Neuere Agenten beginnen, automatische Komprimierungsfunktionen für lange Sitzungen zu integrieren
  • Claude Code führt bei langen Sitzungen ein auto-compact aus, bei dem der Verlauf zusammengefasst und neu gestartet wird
  • Das hilft zwar, setzt aber erst ein, nachdem bereits Zeit im stumpfen Bereich verbracht wurde
  • Auch die Zusammenfassung selbst wird von einem Modell erzeugt, dessen Leistung bereits nachgelassen hat
• Eine bessere Übergabe besteht darin, eine neue Sitzung zu starten und eine selbst geschriebene Spezifikation zu übergeben
  • Eine von Hand geschriebene Spezifikation ist ein stärkeres Übergabedokument als eine automatische Zusammenfassung
  • Denn ein Mensch kann selbst entscheiden, was nach vorn hin wichtig ist
  • Dieser Ansatz entspricht dem breadcrumb-Prinzip, bei dem Artefakte hinterlassen werden, die von der nächsten Sitzung oder der nächsten Person sauber übernommen werden können
• obra/superpowers und mattpocock/skills strukturieren Agenten-Workflows rund um kleine, benannte Artefakte
  • Dazu gehören PRDs, Pläne, Skills und Übergaben an Sub-Agenten
  • Jedes Artefakt verlagert Informationen aus der Live-Sitzung heraus, damit die nächste Sitzung sie lesen kann
  • Das hilft dabei, Arbeitssitzungen im smarten Bereich zu halten
• Das Kontextfenster sollte wie ein Budget behandelt werden
  • Man sollte davon ausgehen, dass nur einige frühe Chunks tatsächlich hilfreich sind
  • Informationen, die in der Live-Sitzung in schriftliche Artefakte ausgelagert werden, verringern die Menge dessen, worum die Aufmerksamkeit des Modells konkurrieren muss

[baam12]

Was sind schon 100.000 — man sieht doch, dass selbst 40.000 bis 50.000 Token schon schwer zu verkraften sind.

[GN⁺]

Hacker-News-Kommentare

• Die Grundlagen von AI zu lernen, macht ziemlich viel Spaß, aber ich bin mit der Richtung, in die das gerade läuft, nicht einverstanden.
  Es ist schwer in Worte zu fassen, wie unerquicklich sich die Kommentare in solchen Threads anfühlen. Gut gemeinte Erfahrungsberichte nach dem Muster „XYZ hat bei mir so funktioniert“ wirken wie Ratschläge in Facebook-Threads über Haustierpflege oder Kochen.
  In Facebook-Gruppen zum 3D-Druck ist es noch schlimmer; wer zwar druckt, aber auch verstehen will, was tatsächlich passiert, weiß vermutlich, was ich meine.
  In der LLM-Welt, besonders in der Cloud-LLM-Welt, scheint die geteilte Strenge völlig zusammengebrochen zu sein und sich am Ende auf magisches Nachahmen zu reduzieren. Niemand ist richtiger oder falscher als irgendjemand sonst.
  Es hat etwas von: „Hast du schon versucht, den Kontext mit Dawn-Spülmittel zu reinigen, trocknen zu lassen und dann eine Schicht Klebestift aufzutragen?“
  Ich will Leuten, die helfen wollen, nicht zu hart kommen. Aber es fühlt sich einfach so anders an als Threads zu anderen Themen. Normalerweise wird der Vorschlag von jemandem von anderen diskutiert oder verfeinert, und manchmal erklärt jemand so etwas wie die Auswahlmethode der bash-History und das verändert dein Leben; solche Threads laufen dagegen am Ende auf „Ist es nicht seltsam, dass es funktioniert, wenn man es bedroht?“ hinaus.

  • Der willkürliche und nichtdeterministische Charakter von LLM-Workflows fühlt sich wirklich unangenehm an. Als jemand aus der alten Embedded-/Systeme-Ecke habe ich Determinismus und Reproduzierbarkeit immer priorisiert.
    Trotzdem sind Agenten großartig, und „Architekt von Denkvorgängen“ zu sein, macht auch Spaß. Ich werde nicht zurückgehen. Selbst wenn die AI-Entwicklung heute stoppen würde, wäre meine Karriere wohl nicht mehr wie früher.
  • So etwas gab es in der Tech-Branche schon lange vor LLMs immer wieder.
    Ich habe viel zu viele Meetings erlebt, in denen nicht nach objektiven und messbaren Kriterien entschieden wurde, sondern nach dem Motto: „Die etwas bekanntere Firma macht es so.“ Selbst Belege dafür, dass diese Firma den betreffenden Ansatz gar nicht allgemein verfolgt, hatten erstaunlich wenig Wirkung.
  • IT-Ratschläge hatten schon immer bis zu einem gewissen Grad diese Seite. Je komplexer Systeme und Ergebnisse sind, desto schwerer wird es, „besser“ und „schlechter“ klar zu definieren.
    Wenn dann noch dazukommt, dass LLMs stark nichtdeterministisch sind, werden LLM-Ratschläge im Grunde zu Gartenbau-Ratschlägen.
    Sogar „Benchmarks“ sind meist eher der Versuch, das Gefühl von irgendjemandem mit einigem Erfolg zu verfestigen.
  • Ich kann die Frustration sehr gut nachvollziehen und stimme größtenteils zu. Jedes Mal, wenn ich versuche, LLM-basierte Workflows zu formalisieren, bin ich erneut enttäuscht, weil niemand wirklich zu wissen scheint, warum manches funktioniert und anderes nicht.
    Also lande ich am Ende wieder bei /plan und sage: „Schreib das vor der wiederholten Implementierung für später in ein Markdown-Dokument“, in der Hoffnung, dass es nächsten Monat etwas mit mehr Strenge und rationalerer Begründung gibt.
    Ich benutze übrigens überhaupt keinen Klebestift, weil ich ihn nicht brauche. Aber Dawn scheint ziemlich wirksam zu sein, damit eine Bambu-Build-Plate wieder gut haftet. Ich habe es nicht eigens dafür besorgt, es war einfach ohnehin zum Abwaschen da. IPA hat nicht funktioniert, also habe ich Dawn ausprobiert, und es hat mehrmals dafür gesorgt, dass Drucke wieder gut hafteten. Bei N=30 bin ich allerdings noch nicht.
  • Vielleicht ist die „geteilte Strenge“ in unseren Köpfen selbst eine Illusion, und LLMs mit ihrem Kontextproblem legen das nur offen.
    In den Jahrzehnten, die ich in der Tech-Branche verbracht habe, habe ich nicht viel Strenge gesehen. Werkzeuge nehmen zu, Paradigmen entstehen, sterben und tauchen wieder auf, und für jeden Maßstab gibt es einen konkurrierenden mit anderen Einheiten. Jenseits der Physik von Leistung und Signalen und der dominierenden Kosten von Siliziumwafern sind wir im Vergleich zu viel älteren kleinen Disziplinen fast alle eher Bastler mit unterschiedlichem Könnensgrad.
    Mit Kontextgrenzen sind wir vergleichsweise leicht umgegangen. Man legt Spezifikationen fest und begrenzt den Umfang. Damit LLMs gute Ergebnisse liefern, brauchen sie klare Spezifikationen und starke Führung.
    Aber auch das ist nur das aktuelle praktische Flickwerkgefühl. Vielleicht verschwindet selbst diese Last in 90 Tagen, und ein einziger einfacher Prompt erzeugt dann ein Betriebssystem und eine Programmiersprache von Weltklasse samt mathematisch-formaler Grundlage für beides.

• Sie vermeiden das Problem der Kontextgröße, indem sie dem Agenten-Loop eine einzige einfache Einschränkung auferlegen. Im obersten Gesprächsthread mit dem Nutzer werden alle Tool-Aufrufe blockiert. Alles, was Tool-Aufrufe benötigt, passiert nur innerhalb rekursiver Aufrufe des Agenten, und nur das Ergebnis wird an den Aufrufer zurückgegeben.
  Selbst in Codebasen mit mehr als 1 Million LOC haben sie den ganzen Tag dieselbe hochrangige Unterhaltung weitergeführt, ohne an eine relevante Token-Grenze zu stoßen. Weder Komprimierung noch Zusammenfassungs-Tricks sind nötig. Selbst wenn in rekursiven Aufrufen 50 Millionen Token verbrannt werden, kann der Root-Gesprächsthread unter 100.000 Token bleiben.
  Jedes Mal, wenn der Agent wieder nach Narnia hinabsteigt, ist zwar erneute „Bootstrap“-Arbeit nötig, aber das ist viel effizienter, als ständig einen großen flachen Kontext mit sich herumzutragen, der immer alles enthalten soll.
  Rekursion ist sehr effektiv, um den Token-Verbrauch zu kontrollieren, hat aber auch Grenzen. Sie haben nie einen Vorteil aus einer Rekursionstiefe über 1 hinaus gesehen. Sie haben beobachtet, dass Agenten es ein paarmal versucht haben, aber die tatsächliche Performance war nicht gut. Externe symbolische Rekursion scheint nichts zu sein, worauf Frontier-Modelle trainiert wurden. Darin, Rekursion innerhalb des Kontexts nachzuahmen, sind sie großartig, aber wenn das Ziel darin besteht, den Token-Verbrauch zu senken, ist das genau die falsche Richtung.

  • Wer Claude Code nutzt, kann ihm einfach sagen, dass es alle Aufgaben innerhalb eines Workflows erledigen soll. Dafür gibt es ein Tool, und es ist eine Funktion, die zusammen mit Opus 4.8 erschienen ist; es scheint auch längere Aufgaben etwas besser zu bewältigen.
    Ab diesem Punkt übernimmt die Hauptkonversation nur noch die Rolle, die Arbeit zu koordinieren.
  • Klingt intuitiv plausibel. Ich frage mich, welches Harness solche Einschränkungen setzen kann und wie man das konfiguriert.
  • Claude Code scheint das in manchen Fällen automatisch zu tun. Es wirkt, als gäbe es eine Heuristik wie „das wird viel Kontext verbrauchen“, und dann entscheidet es, an einen Unteragenten zu übergeben.
    Ich sehe das oft in Problemlösungs- oder Datenanalyse-Abläufen: Datensammlung und Aggregation werden an Unteragenten delegiert, und es wird nur das zusammengefasste Ergebnis zurückgeholt.
    Ähnlich lässt der Hauptagent den Kontext in einem Design-Dokument oder einer Markdown-Datei weiterführen und beim Fortschritt aktualisieren. Dadurch wird es jederzeit möglich, zu löschen, neu zu starten oder zu übergeben.
  • Ich nutze einen anderen Ansatz und versuche noch herauszufinden, wie gut er funktioniert. Statt in Rekursion zu gehen, lässt man den Agenten, wenn der Kontext zu groß wird oder feststeckt, einen Zusammenfassungs-/Berichts-/Reflexionsschritt durchlaufen, den Thread neu starten, zentrale Erkenntnisse in persistenten Speicher schreiben und den Prompt neu formulieren.
    So etwas wie Rekursion mit Tail-Call-Optimierung.
    In gewisser Weise ist das eine Verallgemeinerung eines spezifikationsgetriebenen Ansatzes: Zusätzlich zur formalen Spezifikation bleibt ein vererbter Puffer im Speicher erhalten.
  • Interessant ist das auch deshalb, weil weniger Kontext und geringerer Token-Verbrauch für den Nutzer von Vorteil sind, aber den finanziellen Interessen des AI-Anbieters widersprechen.
    Auch ohne Experte zu sein klingt dieser „einfache Trick“ so, als könnte er das Kontextproblem beheben und eine viel feinere Kontrolle über den Token-Verbrauch ermöglichen. Danke, dass du diesen Tipp in einem HN-Kommentar geteilt hast. Das könnte die Art verändern, wie informierte Leute künftig AI-Agenten einsetzen. Es ist schwer, mitzuhalten.

• Seit Anthropic im Abo-Plan ein Kontextfenster von 1 Million Token anbietet, habe ich diese Erfahrung mit Opus nicht mehr gemacht. Ich liege im Alltag oft über 500.000 Token, manchmal auch nahe an 800.000, ohne dieses Problem zu sehen.
  Wirklich nahe an der Grenze, also jenseits von 900.000 Token, habe ich es teilweise gesehen, aber nicht so stark, wie der Autor es beschreibt.
  Bei einzelnen Aufgaben oder Bündeln von Aufgaben, die eng genug zusammenhängen, um denselben Kontext beizubehalten, füllt man das Kontextfenster ohnehin selten so weit; meist liegt es eher bei 200.000 bis 600.000.
  Das heißt nicht, dass niemand diese Erfahrung macht, aber dass es bei manchen so häufig vorkommt, dass sie ihm sogar einen Namen geben, wirkt seltsam.

  • Ich lese solche Aussagen oft, aber für mich klingt das absurd, weil ich bei Opus-Modellen schon mehrfach grundlegende Erinnerungsfehler unterhalb von 100.000 Token gesehen habe.
    Persönlich würde ich sagen, dass der wirklich kluge Bereich von Opus bei unter 60.000 Token liegt. Opus 4.7 und 4.8 sind wegen des stärker segmentierten Tokenizers noch schlechter.
  • Opus 4.6 wirkte oberhalb von 200.000, als stünde es unter Drogen, 4.7 habe ich übersprungen, 4.8 war bis etwa 350.000 in Ordnung, und Fable war in begrenzten Tests selbst oberhalb von 400.000 hervorragend.
    Die Qualität scheint also aufwärts zu gehen.
  • Nicht alle verwenden dasselbe Modell und dasselbe Harness, und auch nicht dieselbe Art, das Modell zu nutzen.
    Verschiedene Modelle und Modellversionen verwenden unterschiedliche Attention-Architekturen, und das beeinflusst die Leistung bei langem Kontext. Auch Menge und Art des Trainings auf Langkontext unterscheiden sich sicher.
    Ebenso unterscheiden sich die Agenten darin, wie sie Kontext aufbauen und wie Kontextkompression implementiert ist.
    Wenn es nicht dasselbe Modell, derselbe Agent/dasselbe Harness und sehr ähnliche Aufgaben sind, gibt es keinen Grund anzunehmen, dass die Erfahrungen mit dem Modellverhalten in Bezug auf Kontextgröße gleich sein sollten.
  • Ich komme auch oft über 300.000 und habe schon bei 800.000 gearbeitet, aber das Problem ist definitiv beobachtbar.
    Je nach Problem kann ein großes Kontextfenster funktionieren, aber ich habe das Gefühl, dass es effektiver ist, eher in Richtung kleinerer Kontexte unter 300.000 zu gehen.
  • Stimme zu. Die Claude-Familie wird in dieser Hinsicht von Release zu Release besser.
    Bei Opus 4.5 begannen Tool-Aufrufe zu scheitern, wenn man sich dem Limit von 200.000 näherte; Opus 4.6 kam auf etwa 300.000, bevor es verwirrt wurde; Opus 4.7 ließ sich auf ungefähr 400.000 strecken, danach begann aber der dumme Bereich; mit Opus 4.8 hatte ich auch Sitzungen, die problemlos über 500.000 gingen.
    Mit Fable habe ich nur begrenzt Zeit verbracht, aber ich hatte einige Sitzungen, die bis 800.000–900.000 ohne Probleme liefen.

• Neuere Versionen von Opus kommen auch oberhalb von 100.000 noch klar, aber normalerweise versuche ich, unter 200.000 zu bleiben.
  Deshalb halte ich sogenannte Memory-Systeme meist für einen Fehler, der das Modell dümmer macht. Das Modell hat kein Gedächtnis, sondern nur Kontext, und je mehr irrelevante Fakten man in den Kontext hineindrückt, desto weniger Kontext bleibt für das eigentliche Problem. Je weniger Ablenkung, desto besser das Ergebnis.
  Wenn ein Agent sich etwas merken soll, dann sollte man ihn die Arbeit dokumentieren lassen, so wie menschliche Entwickler ein Projekt für andere Entwickler freundlich gestalten. Gute Entwicklungsdokumentation mit einer Index-Seite und gute Pläne mit Checklisten in kompakten Markdown-Dateien zu speichern und ins Repository zu committen, ist der ideale Speicher für das Modell und zugleich die ideale Dokumentation, um nachzuvollziehen, was das Modell überhaupt gemacht hat. Das hilft auch Menschen oder anderen Modellen beim Code-Review und hat keine Nachteile.

  • Zumindest bei mir schreibt Opus ständig irgendetwas in den Speicher, vergisst dann aber zuverlässig, diesen Speicher zu prüfen, bevor es denselben Fehler wiederholt.
    Deshalb landet dann wieder „Denk daran, den Speicher zu prüfen!“ im Speicher. Das ist eindeutig kein gut funktionierendes System.
  • „Memory“-Systeme sind eine Methode, mit der Entwickler das Gefühl haben, sie würden etwas zu AI beitragen.

• Fast alle Kommentare hier berufen sich auf persönliche Erfahrungen. Der ursprüngliche Beitrag verweist dagegen auf zwei Studien, die eine Art standardisierte Testleistung über mehrere Modelle hinweg vergleichen
  Ich kann nicht sagen, wie gut diese Tests sind, aber sie können kaum schlechter sein als anekdotische Evidenz zu etwas so Vagem und Subjektivem wie der Leistung von LLMs

  • Um noch mehr anekdotische Evidenz hinzuzufügen: In allen meinen Tests war die Llama-Familie miserabel darin, Anweisungen zu befolgen. Über die anderen Modelle in RULER weiß ich nicht viel
    In den Chroma-Ergebnissen taucht Sonnet 4 auf, und auch meiner Erfahrung nach war Sonnet 4 miserabel. Derselbe Prompt, der in Sonnet 4.5 perfekt funktionierte, ist in Sonnet 4 katastrophal gescheitert
    Ich würde gern neue Tests sehen, die sowohl die aktuell leistungsstärksten Modelle als auch Open-Weights-Modelle umfassen. Die Spitzenmodelle scheinen Anweisungen immer besser zu befolgen und seltener vom Thema abzuweichen, und es wäre gut, Daten zu haben, die das untermauern
  • Diese Studien basieren auf Daten aus 2024 und 2025. Auf die aktuellen Claude-Modelle lassen sie sich nicht anwenden

• Ich habe recht gute Ergebnisse damit erzielt, die AI zu zwingen, sich wie ein Produktmanager zu verhalten und für jede zu bauende Funktion ein kurzes PRD zu schreiben
  So kann ich auch mit der Zeit noch nachschlagen, was gebaut wurde, und es driftet bei jeder Funktion weniger ab. Ich führe für jede Funktion eine eigene Unterhaltung
  Für mich ist das ein brauchbarer Kompromiss: Es verhindert Abschweifungen, lässt mich aber bei Bedarf auf frühere Entscheidungen zurückgreifen. Was mir an Pococks Ansatz nicht gefällt, ist, dass dabei weniger PRDs geschrieben und stattdessen zuerst tiefgehende Diskussionen geführt werden, um die Ausrichtung abzustimmen; dabei wird in diesem anfänglichen Hin und Her zu viel von der besten Phase verschwendet

  • Ich frage mich, ob du das ad hoc machst oder einen stärker strukturierten Ansatz wie openspec verwendest
    Ich plane auch eher zuerst, aber am Ende bleibt es als Aufgabenliste innerhalb der Sitzung zurück und ist später schwer nachzuschlagen

• Sich damit zu beschäftigen, was im Inneren des Agenten passiert, wird wahrscheinlich nicht mehr lange Teil der Softwareentwicklung bleiben
  Ich persönlich betrachte LLMs und Agenten bereits als Blackbox. Ich gebe dieselbe Funktionsanforderung an mehrere LLMs und vergleiche die Ergebnisse. „Sitzungen“ schreibe ich nicht manuell. Ich schaue nur auf das Ergebnis. Wenn es mir nicht gefällt, mache ich git reset --hard, ändere den Prompt und starte die Funktionsanforderung erneut
  Ich protokolliere alles, um fortlaufend ein Gefühl dafür zu bekommen, welcher Agent am besten ist, und berechne den ELO-Score des Agenten, der meine Anforderungen am besten erfüllt. Für mich ist dieser Wert wichtig; wie der Agent ihn erreicht hat, ist mir ziemlich egal

  • Wenn man die tatsächlichen Inferenzkosten bedenkt, ist das wirklich absurd verschwenderisch und nichts, womit man angeben sollte
  • Ich frage mich, für welche Art von Projekten oder Codearbeit du das einsetzt
    Ich vermute, für bestimmte Arten von Frontend-Arbeit, bei denen Sicherheit oder andere Prüfungen nicht stark ins Gewicht fallen, könnte das in Ordnung sein
    Aber für regulierte Branchen oder Arbeiten, bei denen extreme Vorsicht nötig ist, wirkt es ungeeignet
  • Welches Modell liegt derzeit vorn?

• Ja, Kontextmanagement ist der Kernpunkt
  Ich baue mein eigenes Framework und verbringe viel Zeit damit, dieses Problem zu debuggen. Das größere Problem als die absolute Kontextgröße ist die Wahrscheinlichkeit, dass sich im Fenster Müll oder fehlleitende Anweisungen befinden, die das überdecken, was der Nutzer für wichtig hält
  Das zeigt sich darin, dass das LLM immer wieder versucht, Dinge zu tun, an denen es beim letzten Ansatz schon gescheitert ist. Wenn etwas im Kontextfenster häufig auftaucht, bekommt es Gewicht, selbst wenn es falsch ist
  Es gibt auch viele Tricks, etwa dem LLM nicht Unmengen an Tools zu geben, sondern ihm ein Tool zu geben, mit dem es nach Tools suchen kann
  Aber die größere Lösung liegt im Prozess. Man muss das LLM mit Dingen wie superpowers in Schritte zwingen und den Kontext kontrollieren, der weitergetragen wird

• Ich habe für Pi eine winzige persönliche Erweiterung gebaut und den Befehl /last hinzugefügt. Er löscht die gesamte Sitzung und lässt nur die letzte Ausgabenachricht des Agenten stehen
  Damit wird manuelle „Komprimierung“ möglich. Im Grunde sage ich dem Agenten dann: „Fasse den besprochenen Plan zusammen, inklusive Verweisen auf die zu bearbeitenden Dateien“, rufe danach /last auf und weise ihn dann an, zu implementieren
  [1] https://pi.dev/

• Mir gefällt nicht, dass hier pauschal von „Modellen“ gesprochen wird. Modelle haben unterschiedliche Attention-Architekturen, und deshalb kann sich ihr Verhalten bei langem Kontext stark unterscheiden
  Dass langer Kontext ein Problem ist und dass die Qualität bei den meisten Modellen nachlässt, stimmt schon, aber ich würde das Verhalten älterer Modelle nicht einfach auf neue Modelle verallgemeinern