OpenAI reduziert die Kontextgröße des Codex-Modells von 372k auf 272k

 (github.com/openai)
1 Punkte von GN⁺ 1 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • OpenAI hat beim Aktualisieren der gebündelten Modell-Metadaten von Codex eine Änderung in den Branch release/0.144 zurückportiert, die die Kontextgröße des Modells von 372k auf 272k reduziert
  • PR #33972 überträgt die Änderungen aus dem Branch agent/hotfix-0.144-model-metadata in das Codex-0.144-Release
  • Der Änderungsumfang betrifft eine JSON-Datei, die Diff-Statistik zeigt 64 hinzugefügte und 54 entfernte Zeilen
  • Der Merge erfolgte ohne separate Diskussion oder Review-Inhalte mit 1 Commit und nach 36 Checks
  • Auf der bereitgestellten Seite wird der Datei-Diff nicht geladen, daher lassen sich außer der Kontextverkleinerung keine konkreten weiteren Änderungen an den Metadaten verifizieren

Zweck und Umfang der Änderung

  • Der PR-Titel beschreibt die Aufgabe als Rückport der aktualisierten gebündelten Modell-Metadaten auf Codex 0.144
  • Laut Hacker-News-Titel wurde die Modell-Kontextgröße von 372k auf 272k reduziert
  • Der Ziel-Branch ist openai:release/0.144, der Quell-Branch sayan-oai:agent/hotfix-0.144-model-metadata

Ergebnis des Merges

  • PR #33972 besteht aus 1 Commit b06f4fa
  • Der Commit-Titel lautet Backport refreshed bundled model metadata
  • Der Merge erfolgte am 18. Juli 2026; angezeigt werden 36 Checks und eine geänderte Datei
  • Das Änderungsvolumen beträgt 64 hinzugefügte und 54 entfernte Zeilen, das Dateiformat ist JSON

Verifizierbare Grenzen

  • Im Datei- und Kommentarbereich der Seite tritt ein Ladefehler auf, daher ist der tatsächliche JSON-Diff im bereitgestellten Inhalt nicht einsehbar
  • Schritte zur Reproduktion, Grund der Änderung, Kompatibilitätsauswirkungen und Review-Feedback sind im Inhalt nicht enthalten

Verwandte Beiträge

1 Kommentare

 
GN⁺ 1 일 전
Hacker-News-Meinungen

  • Es heißt zwar, Komprimierung löse das Problem, aber bei meiner Arbeit gehen dabei zu viele Details verloren
    Wenn der Plan einfach ist oder man keine sehr detaillierten Diskussionen führt, mag das in Ordnung sein, aber wegen des fehlenden langen Kontexts bleibe ich am Ende doch bei Anthropic
    Wenn sich das Modell mehrere Paper oder große, komplexe Materialien vollständig merken muss, bleibt der Kontext ständig bei 16 %. Nach etwa 5 Minuten Gespräch wird komprimiert, dann lasse ich das Material erneut einlesen, bis wieder 16 % erreicht sind, und das wiederholt sich
    Auch der 372k-Kontext war nicht perfekt, aber er hat den Spielraum von 12–20 % auf etwa 40 % erhöht, was enorm geholfen hat

    • Man kann die automatische Komprimierung nicht abschalten und auch nicht zum Gesprächsverlauf vor der Komprimierung zurückkehren, daher kann ich Codex bei Codebasen mit mehr als 5.000 Zeilen nicht verwenden
      Sie wird zufällig ausgelöst, wenn noch 10–20 % Kontext übrig sind, sodass praktisch nur 80 % von 272k nutzbar sind. Nach der Komprimierung nehmen Halluzinationen stark zu, schlechter als neu anzufangen, und man gerät in eine Schleife, in der die Codebasis erneut gelesen und dann wieder komprimiert wird
    • Mein Designprozess ist anders. Die mehrfach überarbeitete plan.md ist der Speicher; eine Session neu zu starten, den Plan erneut zu lesen und zu prüfen, liefert oft eine gute neue Perspektive
    • Die Komprimierung ist so schlecht, dass ich ein Tool gebaut habe, mit dem ein LLM Teile des Kontexts selektiv löschen und bei Bedarf wiederherstellen kann. Wenn man häufig an die Grenzen der automatischen Komprimierung stößt, ist context bonsai einen Versuch wert
      https://github.com/Vibecodelicious/context-bonsai-agents
    • Anthropic-Modelle bieten 1 Million Token Kontext. Ich wollte nächsten Monat zu OpenAI wechseln, aber wenn sie immer noch bei etwa 300k festhängen, muss ich mich wohl an die neue Realität anpassen
    • Normalerweise wird empfohlen, dass ein Agent gelegentlich .md-Dateien erstellt oder aktualisiert, damit neu auftauchende wichtige Informationen festgehalten werden. Wenn der Agent aber wirklich genau wüsste, was wichtig ist, müsste auch /compact gut funktionieren

  • Große Kontextfenster haben dazu geführt, dass man nicht mehr auswählt, was hineinkommt, und Komprimierung wendet auf alles auf einmal eine verlustbehaftete Komprimierung an, wodurch auch benötigte Details verloren gehen
    Ich sehe das ständige erneute Senden des gesamten Gesprächs selbst als das grundlegende Problem. Mit einem von mir entwickelten Speicher- und Kontext-Plugin leere ich den Kontext jedes Mal und injiziere nur relevante Informationen neu; so liest das Modell statt eines Gesprächsverlaufs von 200.000 Token nur einige Tausend ausgewählte Token Zustand, und ein kleiner Kontext war kein Problem
    Bei Coding-Agenten habe ich das noch nicht gelöst, aber eine Aufbewahrungsrichtlinie, die nur behält, was für den Abschluss der Aufgabe oder die nächste Aufgabe nötig ist, und den Rest verwirft, ist die eigentliche Lösung und lässt sich meiner Ansicht nach mit einem dedizierten LLM umsetzen

    • Viele NLP-Experten, die sich mit LSTM, GRU usw. beschäftigt haben, sahen das erneute Senden des gesamten Gesprächs ebenfalls als grundlegendes Problem, aber empirisch hat der Transformer gewonnen
      Es ist interessant, ob künftige Modellarchitekturen dieses Problem wieder aufgreifen. Am Menschen gemessen fehlt noch die Fähigkeit, Informationen effizient vom Kurzzeit- ins Langzeitgedächtnis zu übertragen; Fine-Tuning tut prinzipiell etwas Ähnliches, ist aber nicht effizient

  • Ich weiß nicht, ob das der Grund für diese Änderung ist, aber ich halte es grundsätzlich meist für einen Fehler, überhaupt größere Kontexte als diesen zu verwenden
    Man unterschätzt, wie sehr die Modellleistung mit wachsendem Kontext sinkt und wie stark die Token-Kosten steigen. Bei Claude nutze ich nicht mehr als 300k und komprimiere, sondern teile die Arbeit auf und halte Dokumentation sowie modulare Codebasen knapp
    Für Einmalaufgaben kann ein großer Kontext nützlich sein, aber wenn man dauerhaft über 300k liegt, verliert man wahrscheinlich viel oder die Codebasis ist schlecht entworfen

    • Ich komprimiere oder starte ebenfalls bei 250k neu. Da die nötige Kontextgröße proportional zur Projektgröße ist, scheinen diejenigen, die ein größeres Fenster brauchen, einfach größere Projekte zu bearbeiten
    • Mein Eindruck ist derselbe, wobei ich die Grenze eher bei 100–150k ziehen würde. Auch wenn das Modell langen Kontext unterstützt, ist die tatsächliche Leistung nicht gut
    • Dass ein größerer Kontext das Modell merklich dümmer macht, entspricht nicht meiner Erfahrung. Es wird langsamer und teurer, aber bei komplexen Aufgaben ist das ein notwendiger Preis
      Der Hauptagent lässt Unteragenten die nötigen Punkte recherchieren und einen Plan erstellen; anschließend prüfen andere Unteragenten diesen adversarial und verbessern ihn. Am Ende sind 30–40 % eines Fensters mit 1 Million Token gefüllt, ein Ablauf, der mit 272k unmöglich ist
      Bei 5.6 Sol musste dieser Prozess stark reduziert werden, und vermutlich ist das auch der Grund für die schlechteren Ergebnisse

  • Als diese Änderung geschah, veröffentlichte Tibo eine Erklärung dazu: https://x.com/thsottiaux/status/2076543065045795309

    • Die Antworten kann man hier sehen: https://xcancel.com/thsottiaux/status/2076543065045795309
      Der verlinkte Tweet ist eine inoffizielle Antwort auf Tibos offizielle Informationen, und Tibo korrigierte den Inhalt in den Antworten
    • Ich verstehe dieses Diagramm nicht. Warum steigt die Linie trotz Komprimierung weiter, oder steckt in „overall trajectory size“ eine mir unbekannte Bedeutung?
    • Ich weiß nicht, ob die gesamte Trajektorienlänge gleich sein kann, obwohl die Reasoning-Intensität unterschiedlich ist. Selbst wenn man Reasoning-Token aus der Trajektorienlänge ausschließt, scheint das nicht möglich

  • Ich mag deren Kontext-Komprimierung nicht und finde, sie sollten inzwischen mindestens 1 Million Tokens anbieten.
    GPT 5.5 und 5.6 geraten jedes Mal ins Stocken, wenn komprimiert wird, bis sie wieder ihr Tempo finden, und sie fokussieren sich mitunter zu stark auf alte Anweisungsnachrichten, die im komprimierten Kontext verblieben sind.

    • GPT-5.6-Sol ist etwa doppelt so token-effizient wie Opus/Fable, daher entsprechen maximal 258k ungefähr 516k bei Claude.
      Kontextverfall bleibt dennoch ein Problem[1][2], und es gibt auch Hinweise darauf, dass Komprimierung bei Agenten-Aufgaben einem langen Kontext gleichwertig oder sogar überlegen ist[3]. Am besten wäre es, wenn Modelle mit einem 1-Million-Kontext genauso inferieren würden wie mit 256k, aber das ist derzeit noch nicht möglich.
      [1] https://arxiv.org/abs/2605.12366
      [2] Vergleich von GraphWalks 256K und 1M F1 in der Opus 4.8 System Card: https://www-cdn.anthropic.com/0b4915911bb0d19eca5b5ee635c80f...
      [3] https://context-folding.github.io/
    • Anders als bei anderen Coding-Tools ist es frustrierend, dass man die automatische Komprimierung nicht deaktivieren kann. Da sie unregelmäßig ausgelöst wird, wenn noch 10–20 % Kontext übrig sind, sind effektiv nur 80 % der 272k garantiert nutzbar.
      Wenn man in einer großen Codebase fast fertig ist und nur noch etwa 2.000 Tokens Antwort fehlen, erscheint nach längerer Verarbeitung Context compacted, sobald man unter 20 % fällt. Man kann nicht auf den Zustand vor der Komprimierung zurück, untersucht die Codebase erneut, wird wieder komprimiert und verbraucht am Ende alle Tokens.
    • Ich hoffe, dass die Token-Reduktion nicht ein Umweg ist, um die Nutzung zu erhöhen, sondern hauptsächlich der Kostensenkung dient. Auch bei uns im Unternehmen haben die Kostenverantwortlichen den Kontext so stark begrenzt, dass ein internes LLM, das anfangs brauchbar war, nahezu nutzlos wurde.
      Es wirkt fast, als gäbe es ein Treffen, bei dem Führungskräfte die schlimmsten Praktiken austauschen.
    • Arbeitsgedächtnis kann man in Markdown-Dateien speichern; dafür braucht man keinen großen Kontext. Wenn der Kontext wächst, verteilt sich die Attention und die Leistung des LLM sinkt, daher ist es für die Qualität besser, ihn klein zu halten.

  • Ich nutze im Alltag Opus und führe häufig /clear aus. Selbst ein Kontext von 1 Million verschlechtert sich schnell, wenn er sich 50 % nähert; normalerweise bekommt man deutlich bessere Ergebnisse, wenn man bei 30–40 % zurücksetzt.
    Neu zu starten und den nötigen Kontext von Anfang an einzubringen funktioniert besser als Komprimierung. Es ist effektiv, funktionsbezogene Markdown-Dokumente in mehreren Techniksammlungen zu organisieren und beim ersten Laden mitzuteilen, wo die arbeitsrelevanten Informationen zu finden sind.

  • Bei Codex hatte ich nie das Gefühl, dass die Kontextgröße ein Problem ist. Ich weiß nicht, wie die Komprimierung funktioniert, aber es läuft weiter, als gäbe es keine Grenze.

    • Du scheinst Codex erst seit Kurzem zu nutzen. Anfangs gab es heftige model context size exceeded-Fehler, die auch durch Komprimierung nicht behebbar waren und erst vor wenigen Monaten verschwunden sind.
      Heute ist es deutlich besser, aber nach der Komprimierung wird nicht gezeigt, was in der concise summary gelandet ist, sodass schwer zu erkennen ist, ob wichtige Inhalte erhalten blieben.
      Codex scheint in Richtung maximaler Verbergung vor dem Nutzer zu gehen; so wie kürzlich die Prompts zwischen Agent und Sub-Agent verschlüsselt wurden, könnte künftig offenbar auch das gesamte Sitzungslog verschlüsselt werden. Schade, aber unter allem, was ich bisher ausprobiert habe, ist es immer noch die beste Tool-/Modell-Kombination.
    • Wenn bei Codex eine Komprimierung passiert, vergisst es oft, die letzte Aufgabe abzuschließen, besonders wenn man direkt vor der Komprimierung eine Nachricht gesendet hat.
    • Die meisten Probleme lassen sich per Divide and Conquer lösen, daher ist der Unterschied zwischen 300k und 400k kaum ein Problem. Ein Coding-Agent ist kein endloser Chat.

  • Egal wie gut die Komprimierung ist: In großen Projekten müssen viele Dateien gelesen werden. Die ersten 200.000 Tokens sind sehr schnell verbraucht, danach verlangsamt sich das Tempo.
    Fable-Sessions überschreiten meist nicht 500.000 Tokens und brauchen daher keine Komprimierung, aber bei Codex muss in einer Sitzung immer wieder komprimiert werden.

    • Der Grund, warum viele Dateien gelesen werden müssen, liegt meiner Ansicht nach an einem schlechten agents.md. Man sollte nur die eigentlichen Arbeitsdateien und ein paar relevante Dateien lesen müssen; der Rest sollte in der Dokumentation zusammengefasst sein.

  • Für meine Arbeit ist das eine ziemlich kleine Größe. Ich versuche, unter 200k zu bleiben, aber wenn ich in DeepSeek- und MiMo-Sessions die letzte Iteration noch durchdrücke, wächst es manchmal auf 350k Tokens, bevor komprimiert wird.
    Ich frage mich, ob OpenAI nicht die K/V-Cache-Technik von DeepSeek aus deren veröffentlichten Papers übernehmen und die Kosten deutlich senken könnte.

    • Da niemand Caching so gut beherrscht wie DeepSeek, sind die Implementierungsunterschiede wohl groß und schwer nachzuahmen.
      Wenn man DeepSeek zusammen mit Reasonix nutzt, ist es ein zusätzliches spezialisiertes Verfahren, das auf die Cache-Struktur abgestimmt ist; in langen Sessions werden 97–98 % der Tokens gecacht. Ein ohnehin günstiges Modell wird dadurch noch günstiger.
    • Bei lokalen offenen Modellen auf llamacpp-Basis komprimiert der Agent auf Anweisung zwischen 55k und 85k; wenn kein großer Kontext zwingend nötig ist, etwa für komplexes Log-Tracing, kommt man selten bis 120k.
      Ich habe auch den System-Prompt angepasst, damit der Agent passend zum Inferenzbudget und den Nachrichten von llamacpp Sub-Agents erstellt und deren Inhalte anschließend komprimiert. Mit dem dynamischen Kontext-Pruning von opencode bleibt die Richtung erhalten, ohne das Volumen aufzublähen, und für die iterative Entwicklung mehrerer Unterkomponenten funktioniert das insgesamt gut.

  • In den letzten zwei Monaten war es für meine Zwecke deutlich besser, daher bin ich von Claude zu OpenAI gewechselt. Ich bin gespannt, ob man durch diese Änderung einen Unterschied in der Ausgabequalität bemerkt.