Clustering von Reasoning-Tokens bei GPT-5.5 Codex könnte zu Leistungseinbußen führen

 (github.com/openai)
1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • OpenAI-Codex-Issue #30364 berichtet, dass sich die reasoning_output_tokens in Antworten von gpt-5.5 auf feste Werte wie 516, 1034 und 1552 konzentrieren und dass dies mit Qualitätsverlusten bei komplexen Codex-Aufgaben zusammenhängen könnte
  • Analysiert wurden Codex-token_count-Metadaten vom 1. Februar bis 27. Juni 2026 UTC; dabei wurden 390.195 Antwortdatensätze und 3.363 Exact-516-Ereignisse in 865 Sessions festgestellt
  • gpt-5.5 machte 19,3 % aller Antworten aus, stellte aber 82,0 % der Exact-516-Ereignisse; unter reasoning_output_tokens >= 516 lag der Exact-516-Anteil bei 44,0 % und damit deutlich höher als die 1,3 % bei Nicht-GPT-5.5
  • Der monatliche Exact-516-Anteil stieg von 0,11 % im Februar 2026 auf 53,30 % im Mai und 35,84 % im Juni; im selben Zeitraum sanken jedoch der durchschnittliche und der P90-Wert der Reasoning-Tokens, sodass es sich nicht einfach um eine gestiegene Nutzung von Reasoning-Tokens handelte
  • In späteren Kommentaren wurden ähnliches 516-Clustering und einige reproduzierte falsche Antworten in Codex CLI, Codex Desktop und OpenCode geteilt; als temporäre Gegenmaßnahme wurde außerdem ein lokaler Proxy vorgeschlagen, der das Muster 518·n−2 erkennt und das Reasoning fortsetzt

Kernproblem des Issues

  • Codex-Issue #30364 berichtet über ein Muster in den token_count-Metadaten von gpt-5.5-Antworten, bei dem sich Werte übermäßig bei reasoning_output_tokens = 516 häufen
  • Zusätzlich sollen auch in der Nähe von 1034 und 1552 Peaks auftreten, die wie feste Grenzen wirken
  • Die vorgebrachte Aussage lautet nicht, dass damit ein Abschneiden versteckter Chain-of-Thoughts bewiesen sei
    • Die engere Behauptung ist, dass in der Codex-Telemetrie eine gpt-5.5-spezifische Anomalie mit Clustering auf festen Tokenwerten zu sehen ist
    • Es handelt sich um den Hinweis, dass dieses Muster mit einem schwellenwertbasierten Verhalten beim Reasoning-Budget konsistent wirkt
  • Das verwandte Issue #29353 behandelte eine Reproduktion auf Arbeitseinheitenebene, bei der eine gpt-5.5-Ausführung genau bei 516 Reasoning-Tokens endete und eine falsche Antwort zurückgab; das aktuelle Issue ergänzt aggregierte Evidenz über einen längeren Zeitraum

Analyseumgebung und Daten

  • Das Produkt ist Codex, das relevanteste Modell ist gpt-5.5
  • Datenquelle sind Codex-token_count-Metadaten
  • Der Analysezeitraum ist 1. Februar bis 27. Juni 2026 UTC
  • Aggregierte Kennzahlen:
    • Token-Datensätze auf Antwortebene: 390.195
    • Sessions: 865
    • Exact-reasoning_output_tokens = 516-Ereignisse: 3.363
    • Anteil von gpt-5.5 an allen Antworten: 19,3 %
    • Anteil von gpt-5.5 an Exact-516-Ereignissen: 82,0 %
    • Verhältnis Exact-516 / >=516 bei gpt-5.5: 44,0 %
    • Verhältnis Exact-516 / >=516 bei Nicht-GPT-5.5: 1,3 %

Muster nach Modell und Monat

  • Das Verhältnis Exact 516 / >=516 ist bei gpt-5.5 am auffälligsten
    • gpt-5.5: 75.401 Datensätze, 44,0 %
    • gpt-5.4: 25.214 Datensätze, 19,8 %
    • gpt-5.2: 247.575 Datensätze, 0,34 %
    • gpt-5.3-codex: 13.333 Datensätze, 0,0 %
    • gpt-5.3-codex-spark: 26.179 Datensätze, 0,0 %
  • Das monatliche Exact-516-Clustering stieg im Mai 2026 stark an
    • Februar: 0,11 %
    • März: 2,45 %
    • April: 4,25 %
    • Mai: 53,30 %
    • Juni: 35,84 %
  • Im selben Zeitraum nahm die gesamte Reasoning-Token-Intensität ab
    • Durchschnittliche Reasoning-Tokens: Februar 268,1 → Mai 106,9 → Juni 168,5
    • P90 Reasoning-Tokens: Februar 772 → Mai 344 → Juni 515
  • Aufgrund dieser Kombination wird die Frage aufgeworfen, dass der Anstieg bei Exact-516 schwer als bloße Zunahme der Reasoning-Token-Nutzung zu erklären ist

Angeforderte interne Prüfungen

  • Das Codex-Team wurde gebeten zu untersuchen, ob Reasoning-Budget, Routing, Abschneiden, Fallback oder Scheduler-Verhalten von gpt-5.5 ein Ende in der Nähe von 516/1034/1552 verursachen
  • Falls dieses Verhalten beabsichtigt ist, enthält die Anfrage die Bitte zu erklären, ob Exact 516 ein normaler Endpunkt, eine Budgetobergrenze, ein degraded tier oder ein anderer interner Schwellenwert ist
  • Vorgeschlagene Prüfschritte:
    • Abfrage von token_count-Events einschließlich reasoning_output_tokens nach Modell
    • Vergleich der Exact-Value-Zählungen für 0, 516, 1034, 1552
    • Berechnung von count(reasoning_output_tokens = 516) / count(reasoning_output_tokens >= 516) nach Modell und Datum
    • Vergleich von gpt-5.5 mit gpt-5.2, gpt-5.4 und Codex-spezifischen Varianten
    • Komplexe Aufgaben erneut mit GPT-5.2 und GPT-5.5 ausführen und Exact-516-Antworten sowie Antworten mit längerem Reasoning getrennt qualitativ bewerten

Zusätzliche Reproduktionen und Querschnittsdaten aus den Kommentaren

  • GitHub Actions markierte #29353 als möglichen verwandten Duplikatskandidaten
  • Mehrere Nutzer kommentierten, dass sie dasselbe Problem erlebt hätten; ein Nutzer bewertete dieses Issue im Vergleich zu früheren Issues als stärker datenbasierten Bericht
  • sinnet3000 legte clientübergreifende Daten aus lokalen Session-Speichern von Codex CLI und OpenCode vor
    • In rund 22,7k token_count-Events aus Codex ~/.codex/sessions und archived_sessions hatte gpt-5.5 4.300 records, 156 >=516, 88 exact 516, Verhältnis 56,4 %
    • In rund 32,1k assistant messages aus OpenCode opencode.db hatte gpt-5.5 6.977 records, 126 >=516, 90 exact 516, Verhältnis 71,4 %
    • Bei zusammen etwa 24k records volumenstarker Nicht-OpenAI-Modelle wie Kimi, DeepSeek, MiMo, MiniMax, Gemini, Qwen und GLM gab es 0 Exact-516-Fälle
    • Zu diesen Daten wurde als Caveat angemerkt, dass nicht die Richtigkeit der Antworten bewertet, sondern nur das Vorhandensein von Exact-516-Clustering geprüft wurde
  • kyleboddy berichtete über einen entsprechenden Verhaltensunterschied in Codex Desktop unter Windows 11
    • Derselbe candy prompt wurde in 5 frischen projektlosen Codex-Desktop-Threads ausgeführt
    • Schnelle direct-final_answer-Ausführungen gaben 29 zurück und waren falsch
    • Langsamere Ausführungen, bei denen zuerst commentary erschien, gaben 21 zurück und waren richtig
    • Aus frischen Windows-host Desktop-Threads konnten keine exakten reasoning_output_tokens extrahiert werden, daher könne man nicht sagen, dass die fehlerhafte Ausführung genau bei 516 lag
  • Derselbe Nutzer aggregierte außerdem Clustering auf festen Werten für gpt-5.5 / xhigh aus lokalen Session-Metadaten
    • records 16.141, sessions 51, durchschnittliches Reasoning 149,7, P90 429
    • =516 438 Fälle, >=516 1.298 Fälle, Verhältnis 33,74 %
    • =1034 52 Fälle, =1552 14 Fälle, =2070 16 Fälle, =2588 12 Fälle, =3106 5 Fälle

Reproduktionsergebnisse mit Codex Linux CLI

  • kyleboddy gab an, die Reproduktion auch mit Codex Linux CLI und demselben candy prompt durchgeführt zu haben
  • Umgebung:
    • Produkt: Codex CLI
    • Version: codex-cli 0.142.5
    • Plattform: Ubuntu Linux 6.8.0-111-generic, x86_64
    • Node: v24.14.0
    • Authentifizierungsmodus: ChatGPT
    • Testmodell: gpt-5.5
    • reasoning efforts: xhigh, high
    • Kontrollmodell: gpt-5.4 xhigh
  • Der prompt fragt ohne externe Tools nach der minimalen Anzahl von Ziehungen in einem candy-bag-Problem, bei dem sich die shape ertasten lässt
  • Die erwartete Antwort wurde per Brute-Force-Enumeration unabhängig als 21 bestätigt
    • Enthalten ist die Erklärung, dass man, da sich die shape ertasten lässt, 9 round + 12 star candies planen kann
  • Ergebnisse:
    • Alle 4 abgeschlossenen Läufe mit gpt-5.5 xhigh hatten reasoning_output_tokens = 516 und lieferten die Endantworten 23, 26, 28, 15, alle falsch
    • Auch 3 Läufe mit gpt-5.5 high lagen alle bei 516; die Antworten waren 22, 21, 27, davon nur eine richtig
    • 3 Läufe mit gpt-5.4 xhigh verwendeten 6211, 12274 und 10876 Reasoning-Tokens und antworteten alle korrekt mit 21
  • Dieses Ergebnis stützt die engere Behauptung, dass gpt-5.5 in Codex auf einen festen 516-Token-Pfad geraten kann und dass dieser Pfad mit einer Qualitätsminderung der Aufgabenbearbeitung korrelieren könnte

Vorgeschlagener temporärer Workaround

  • dzshzx schlug während des Wartens auf einen upstream fix den lokalen Responses-Proxy codexcomp vor, der vor Codex geschaltet wird
  • Die Funktionsweise betrachtet das Muster 518·n−2 als Abschneiden und setzt das Reasoning fort
    • Runden, die mit reasoning_tokens == 518·n − 2, also 516, 1034, 1552 usw. enden, werden als truncated behandelt
    • Tentative output wird verworfen, und die Reasoning-Items sowie encrypted_content dieser Runde werden als nächste Eingabe erneut abgespielt
    • phase:"commentary" und die Nachricht "Continue thinking..." werden gemeinsam eingefügt
    • Alle Runden werden zu einer einzigen downstream response zusammengefaltet, sodass sie für Codex wie eine vollständige Antwort wirkt
  • Die Konfiguration nutzt den offiziellen Top-Level-Key openai_base_url
    • Beispiel: openai_base_url = "http://127.0.0.1:8787/v1";
    • Der built-in openai provider bleibt erhalten, sodass session grouping, remote compaction und remote-control weiter funktionieren sollen
  • Als reales Log-Beispiel wurde ein Fall gezeigt, bei dem nach zwei aufeinanderfolgenden 516ern die dritte Runde sauber endete und die Endantwort richtig war
    • Runde 1: reason=516 → continue
    • Runde 2: reason=516 → continue
    • Runde 3: reason=291 → clean
  • Caveats:
    • Es handelt sich um einen inoffiziellen Workaround, der auf nicht vertraglich zugesichertem Upstream-Verhalten beruht
    • Continuation-Runden verbrauchen zusätzliche echte Tokens
    • Er ist durch ein n-Fenster und ein Limit von 3 Continuations begrenzt
    • Er ist loopback-only, mit auth passthrough, und soll keine credentials lesen oder speichern

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Meinungen auf Hacker News

  • Das wirkt ziemlich ernst und lässt sich auch mit der codex cli leicht reproduzieren.
    Wenn man einen Puzzle-Prompt gibt, der Schlussfolgern erfordert, bricht es manchmal scheinbar abrupt ab, verwendet exakt 516 Denk-Tokens und liefert eine falsche Antwort.
    In Fällen, in denen 6000 bis 8000 Denk-Tokens verwendet werden, kommt die richtige Antwort heraus.
    Es könnte ein Problem mit Adaptive Thinking sein; ein weiterer Punkt für lokale Modelle ist außerdem, dass man sich keine Sorgen über stille serverseitige Änderungen machen muss.
    Ich habe denselben Prompt 10-mal laufen lassen; 4-mal trat dieses 516-Token-Problem auf, und alle 4 waren falsch. Die Stichprobe ist klein, aber es sieht so aus, als könne 5.5 xhigh mit fast 50 % Wahrscheinlichkeit kurzgeschlossen werden und dadurch an Leistung verlieren.

    • Ich sehe auch ein philosophisches Problem bei Adaptive Thinking. Es ist eine Methode, bei der vor dem Nachdenken geraten wird, welches Denkbudget zugeteilt werden soll; im LLM-Kontext scheint es fast unmöglich zu sein, die benötigte Denkmenge, also die Zahl der zu generierenden Tokens, im Voraus zu kennen.
      Der Problemraum ist unendlich groß, und allein anhand der Ähnlichkeit zwischen Prompts lässt sich schwer beurteilen, wie lange nachgedacht werden muss. Das Modell hört ohnehin schon auf zu denken, bevor es sein Denkbudget erreicht.
      Ich verstehe nicht, warum so viel Aufwand in die Implementierung von Adaptive Thinking gesteckt wird; vielleicht sollte man das Modell stattdessen besser darauf trainieren, ein Denk-Ende-Token auszugeben.
      Es fühlt sich wie Flickwerk an. Das Modell sollte darauf trainiert werden, eine angemessene Menge an Schlussfolgern zu leisten: schlussfolgern → verbleibende Unsicherheit schätzen → entscheiden, ob es weitermacht → weiter schlussfolgern → wiederholen.
    • Auch bei lokalen Modellen muss man sich um Fehlkonfigurationen sorgen. Weil selbst Experten Fehler machen, schwankt die Leistung lokaler Modelle je nach Anbieter stark.
    • Ich frage mich, ob sich bei Tests nach Tageszeit oder Wochentag Muster zeigen. Zum Beispiel könnte man sehen, ob das Kurzschluss-Phänomen zu Spitzenzeiten während der Arbeitszeit häufiger auftritt.
    • Wenn Nutzer auch für diese verschwendeten Tokens zahlen, könnte es sinnvoll sein, eine Rückerstattung zu verlangen.

  • Ich habe fast täglich erlebt, dass die Qualität stufenweise schlechter wurde, und habe normalerweise xhigh verwendet.
    Die Erfahrung von Anfang des Jahres, als ich mich auf das außergewöhnlich gründliche Coding von Codex verlassen konnte, ist weg; wegen gelegentlich absurd dummer Implementierungen bin ich zu Claude gewechselt, bis OpenAI dieses Problem ernsthaft angeht.
    Ich beobachte das persönlich seit Monaten, aber es wirkte nicht so, als nehme OpenAI es ernst.

    • Vor 3 Monaten war Claude so dumm geworden, dass ich zu Codex gewechselt bin, und vor 6 Monaten war es umgekehrt. Ob Codex oder Claude: Irgendwann legen dich beide rein. Trotzdem ist Codex wahrscheinlich die weniger schlimme Option.
    • Seit Anfang Juni habe ich in meiner Erfahrung gespürt, dass die Zuverlässigkeit von 5.5 auf Claude-Niveau gefallen ist.
      Deshalb bin ich von 5.5 high → 5.5 xhigh → 5.4 high gewechselt.
      5.4 high war in den letzten 3 Wochen komplett stabil, und im Moment bin ich damit zufrieden.
      Gelegentlich lasse ich Aufgaben mit 5.5 xhigh laufen, um zu prüfen, ob es wieder zu 100 % stabil ist, aber derzeit gehe ich davon aus, dass sie eher auf den Release von 5.6 warten, statt dieses Zuverlässigkeitsproblem zu beheben.
    • Ich glaube nicht, dass das ein technisches Problem ist. Eine Behebung würde viel Geld kosten, und weil die Nutzer nicht genug zahlen, sehe ich darin eine geschäftliche Entscheidung zur Leistungsreduzierung.

  • Das fühlt sich wie ein Déjà-vu an. Es sieht genauso aus wie die Performance-Regression von Claude Code im April. Damals habe ich mein Claude-Abo gekündigt und bin zu Codex gewechselt.
    Jetzt überlege ich, beide per Token-Abrechnung zu nutzen, für die meisten Aufgaben GLM 5.2 von Fireworks zu verwenden und nur bei Bedarf für große Modelle zu zahlen. Allerdings bin ich nicht sicher, ob sich der Break-even lohnt.

    • Bei der Token-Abrechnung hatte ich dieselbe Reaktion, aber weil es für beide Labore wirtschaftlich vorteilhaft ist, Kunden zum Verbrauch pro Token zu bewegen, möchte ich das aus Prinzip vermeiden.
      Selbst wenn es nicht absichtlich geschieht, möchte ich keine Struktur akzeptieren oder ermöglichen, in der man von einem Produkt mit gesunkener Qualität profitiert.
      Eigentlich wirken Open-Source-Modelle und offene Ausführungsumgebungen, etwa Pi und Ähnliches, attraktiver als je zuvor seit dem Start von ChatGPT.
    • Stimmt. Auch ich habe deswegen Claude Code gekündigt und bin zu Codex gewechselt.
      Jetzt denke ich darüber nach, wie ich zusätzliche 65.000 Dollar verdienen kann, damit ich mir über solchen Unsinn nicht wieder Sorgen machen muss. Die Wirtschaftlichkeit von Dingen wie OpenRouter kenne ich.
      Es erinnert mich an die Zeit um 2008, als „Cloud“ als Marketingbegriff aufkam. Es wirkte wie eine Verpackung, um die Erwartungen an reichhaltige Clients zu senken und die Margen der Unternehmen mit Abo-Modellen zu erhöhen, die lokale Eigentümerschaft aushöhlen.
      Danach hatte ich die Begeisterung und den Absolutismus rund um „wirklich freie und Open-Source-Software“ satt und habe es darauf geschoben, dass ich jung war, und es hinter mir gelassen.
      Tatsächlich kann ich viele Abo-Modelle bis zu einem gewissen Grad verstehen oder tolerieren. Software zu bauen kostet viel Geld, und den Wert jährlicher Photoshop-Upgrades im Jahr 2026 mit 200 Dollar anzusetzen, ist vielleicht nicht fair. Aber eine UI, die 20 Jahre lang gut funktioniert hat, launisch zu verändern und Dinge wie klassische Farbfelder komplett zu entfernen, ist dumm.
      Dann kann ich mit Codex, einem arbeitskritischen Tool für 200 Dollar im Monat, ein Plugin für klassische Farbfelder bauen.
      Sind 200 Dollar im Monat für meine Token-Nutzung fair? In einem Monat mit sehr hoher Nutzung habe ich vielleicht rund 1 Milliarde Tokens verbraucht.
      Aber genau das ist das Problem. Sie werden endlos an Hebeln ziehen, ohne genau zu wissen, welche Profitabilität für sie passt, und wenn man aus Dingen wie Fälligkeiten von Schulden seine Schlüsse zieht, wird das wohl mindestens bis 2030 oder 2032 so weitergehen.
      Über so etwas möchte ich überhaupt nicht nachdenken. Ich möchte nicht ständig Modellpräferenzen und Leistungsabfälle bewerten und die Nuancen, mit denen ich mit der KI spreche, daran anpassen, welche mysteriösen Backend-Experimente gerade auf Outputs laufen, die ich tatsächlich gegen Bezahlung baue und pflege.
      KI liegt irgendwo zwischen Werkzeug und Kollaborateur, aber diese launischen Veränderungen der „Persönlichkeit“, die entstehen, wenn in der Reasoning-Phase an schlecht verstandenen Reglern und Hebeln herumgespielt wird, machen mich wahnsinnig. Deshalb möchte ich auf eine Kiste in der Ecke zeigen und genau wissen, welche Output-Qualität sie liefert, die niemand außer mir verändert.
    • Fireworks?
    • Das ist genau diese „gefühlsbasierte“ Performance-Regression von Claude Code. Bei einem nichtdeterministischen System sollte man keine konsistente Leistung erwarten. Es gibt keinerlei empirische Daten, die einen Leistungsabfall stützen.
      Was sich zuletzt stufenweise verändert hat, ist nicht die Modellleistung, sondern die Menge an Jammern und Beschwerden von Codern.

  • Es ist gut, dass solche Probleme öffentlich sichtbar werden und behandelt werden können, weil Codex Open Source ist.

    • Aber das ist Modellverhalten, und da es einen öffentlichen Issue-Tracker gibt, wirkt es auf mich wie Claude Code, nur ohne den Code. Bei solchen Problemen weiß ich nicht, was daran anders ist als https://github.com/anthropics/claude-code
      Ich bin insgesamt dankbar, dass Codex Open Source ist, aber bei dieser Art von Problem scheint es keine große Bedeutung zu haben, weil das Modell weiterhin geschlossen ist.
    • OpenAI fühlt sich insgesamt viel offener und wie ein echtes Unternehmen an als Anthropic. Anthropic ist einfach eine Black Box.

  • Vielleicht täuscht mich meine Erinnerung, aber gemessen an Token-Verbrauch und Codequalität war 5.3 wohl am besten. 5.5 funktioniert zwar besser, frisst aber Tokens regelrecht weg.

    • Das geht nicht nur mir so. 5.3-codex war meiner Ansicht nach ein hervorragendes Modell, was das Verhältnis von Ausgabequalität zu Kosten betrifft.
      Anders als 5.5 oder Opus war es günstig und effizient genug, um es für fast jede Aufgabe zu nutzen, dabei ziemlich gut, und ich habe es Sonnet vorgezogen.
    • Vor ein paar Wochen wurde 5.3 für mich unbrauchbar. Es blieb einfach hängen oder lieferte miserable Antworten.

  • Hat hier nicht vor ein paar Tagen jemand gesagt, OpenAI habe durch eine bahnbrechende Optimierung die Rechenkosten halbiert? Ist das hier gemeint?

    • Das war ein Artikel von The Information, aber er wirkte nicht besonders gut geschrieben. Ich hatte nicht den Eindruck, dass der Autor ein technischer Experte ist, der ausreichend versteht, wie LLMs funktionieren, um interne Gerüchte zuverlässig einordnen zu können: https://www.theinformation.com/newsletters/ai-agenda/openai-...
      Darin hieß es, „OpenAI-Ingenieure hätten einigen Kollegen Anfang dieses Monats gesagt, sie hätten dank einer neu entdeckten Optimierung einen Weg gefunden, die Kosten für den Betrieb bestehender Modelle, also für Inferenz, um mehr als die Hälfte zu senken“, so eine mit der Diskussion vertraute Person.
    • Ich hatte dieses Gerücht so verstanden, dass nicht OpenAI selbst, sondern eine der Gruppen, die nach den Ereignissen aus OpenAI hervorgegangen sind, vermutlich Thinking Machines, einen Durchbruch erzielt hat und ihn OpenAI anbietet. Ich glaube nicht, dass OpenAI das bereits tatsächlich umgesetzt hat.

  • Bei mir zeigt sich dieser Effekt, wenn man den verschlüsselten Reasoning-Inhalt anhand der Länge des base64-Strings betrachtet. Bei den vom Server gemeldeten Reasoning-Tokens zeigt er sich jedoch nicht.
    Deshalb dachte ich, es sei rein Teil der Verschlüsselung oder Obfuskation und kein echtes Problem.
    Der größte Nachteil von GPT ist, dass der Denkprozess verschlüsselt ist und es dadurch noch mehr Black Box ist als Kimi, GLM oder DeepSeek. Trotzdem bekommt man Zusammenfassungen des Denkprozesses, also ist es zwar ungewohnt, aber nutzbar.

  • Ist das der seltene Fall, in dem „das Modell wurde dümmer gemacht“ nicht der übliche Nutzerwahn ist, sondern tatsächlich das Modell dümmer gemacht wurde?

    • Das wirkt eher wie ein Fehler oder eine Fehlkonfiguration in der Inferenz-Engine oder der Agent-Ausführungsumgebung.
      Die Details des Issues sind kein Beleg für eine absichtliche heimliche Abschwächung, eher im Gegenteil. Die Ursache wirkt grob, und sie ist nicht besonders heimlich, wenn ein normaler Nutzer sie mit genauen, unabhängig überprüfbaren Details melden kann.
      Die Formulierung „üblicher Nutzerwahn“ ist weder fair noch mein Geschmack. Wenn man nur einen magischen Spülbecken-artigen API-Endpunkt hat, der ein Context Window verschluckt und fortlaufenden Output ausspuckt, bleiben nur subjektive Einschätzungen, Vermutungen und Misstrauen.
      Selbst mit standardisierten Modell-Testsuiten läuft die Behauptung einer heimlichen Abschwächung letztlich darauf hinaus, die Absichten der Leute in diesem Unternehmen zu lesen. Die Modellqualität kann auch ohne explizite Absicht oder Downgrade der zugrunde liegenden Infrastruktur sinken.
      Witzelnde Verschwörungstheorien oder die Prüfung der Möglichkeit einer tatsächlichen Abschwächung sind an sich keine Psychose. Mir gefällt dieser Trend nicht, psychologische Diagnosebegriffe so zu missbrauchen.
      Natürlich gibt es Leute, die sich in solchen Einschätzungen zu sicher sind, und auf sie kann das zutreffen, aber das ist eine Minderheit. Letztlich ist es nur Übertreibung und hilft niemandem.

  • Es ist schon lustig, dass Frontier-Modell-Abos verkauft und dann im Laufe der Zeit schnell generft werden, ohne dass jemand darüber spricht.
    Wenn serverseitig stillschweigend die Reasoning-Stärke gesenkt wird, sollte es wenigstens einen Rabatt geben.
    Andererseits nutze ich 5.5-high täglich in parallelen Multi-Task-Workflows und verbrauche mein Wochenlimit nur knapp. Ich bin als Human-as-a-Service nicht schnell genug, um die gesamte Planung und Implementierung mitzulesen. Auch das ist ein Aspekt.

  • Es scheint offensichtlich, dass zur Durchsatzoptimierung Reasoning-Inferenz in Vielfachen von 512 Tokens gebündelt und als Batch verarbeitet wird.

    • Mein erster Gedanke war, dass – ausgehend von llama.cpp – eine Anpassung des Reasoning-Budget-Parameters solche Ergebnisse verursacht haben könnte. Ohne Ankündigung von OpenAI lässt sich das aber nicht genau wissen.
      Es könnte auch eine sehr unehrliche Art sein, auf Nachfrage zu Spitzenzeiten zu skalieren. Ich weiß, dass es in diesem Thema schon Leute gibt, die die Subjektivität der wahrgenommenen Modellleistung belächeln, aber zumindest in meinen Tests im Mai wirkte das Modell zu den Zeiten, in denen die USA online gingen, weniger intelligent.
      In einem Blogbeitrag des Unternehmens vor ein paar Wochen fiel mir das in überlappenden Zeitfenstern als konsistenteres Muster auf, sodass ich dachte, ich sollte darauf hinweisen. Ich hätte die Session-Logs für eine weitere Analyse speichern sollen https://webesque.agency/blog/2026-06-19-llms.html
    • Ist nicht Continuous Batching der Standard? Wenn Continuous Batching verwendet wird, frage ich mich, warum die Länge der generierten Tokens wichtig ist und warum nach Länge gruppiert wird. Falls nicht, frage ich mich, warum es nicht verwendet wird und welche Trade-offs dahinterstehen.