GPT-5.5 low vs. medium vs. high vs. xhigh: Die Reasoning-Kurve anhand von 26 realen Aufgaben in einem Open-Source-Repository

 (reddit.com)
5 Punkte von GN⁺ 7 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Als GPT-5.5 Codex mit den Einstellungen low, medium, high, xhigh auf 26 reale Aufgaben in GraphQL-go-tools angesetzt wurde, zeigte sich der Unterschied beim Reasoning-Aufwand deutlicher bei der semantischen Gleichwertigkeit mit menschlichen Patches und der Bestehensquote im Code-Review als beim Bestehen von Tests
  • Beim Bestehen von Tests lagen die Werte bei low 21/26, medium 21/26, high 25/26, xhigh 24/26, doch die semantische Gleichwertigkeit stieg von 4/26 → 11/26 → 18/26 → 23/26 und das Bestehen im Code-Review von 3/26 → 5/26 → 10/26 → 18/26
  • high verbesserte gegenüber medium Test-Bestehen, Gleichwertigkeit und Review-Bestehen gleichermaßen, während die durchschnittlichen Kosten von $3.13 auf $4.49 und damit um das 1,43-Fache stiegen; in diesem Datensatz wirkt es daher wie die praktischste Standardeinstellung
  • xhigh steigerte Gleichwertigkeit und Review-Qualität gegenüber high deutlich, ließ aber die durchschnittlichen Kosten auf $9.77 und die mittlere Laufzeit auf 753,3 Sekunden ansteigen und erhöhte außerdem durch zusätzliche Änderungen an Tests, Fixtures und Expected Outputs das Footprint-Risiko
  • Die Wirkung des Reasoning-Aufwands war je nach Aufgabe nicht monoton: Mitunter schlug high xhigh oder höhere Einstellungen erzeugten zwar plausibel wirkende, aber falsche Implementierungen; Teams sollten daher nicht an globalen Benchmarks messen, sondern mit dem eigenen Harness und den eigenen Aufgaben

Ziel des Experiments und Bewertungsmethode

  • GPT-5.5 Codex wurde für dieselben 26 Aufgaben in einem Open-Source-Repository jeweils mit den Reasoning-Aufwandseinstellungen low, medium, high, xhigh ausgeführt, um nicht nur das Bestehen von Tests, sondern auch die semantische Gleichwertigkeit mit menschlich gemergten PRs und die Review-Tauglichkeit zu vergleichen
  • Das untersuchte Repository ist das Go-basierte GraphQL-go-tools; jede Aufgabe wurde aus einem tatsächlich gemergten PR oder Commit abgeleitet
  • Jede Aufgabe bestand aus einem festen Snapshot des Repositorys, einem Änderungswunsch als Prompt und einem einzigen Versuch, in einem Docker-Container einen Patch zu erzeugen
  • Stet wendete den erzeugten Patch an und führte in einem isolierten Container aufgabenspezifische Tests aus, um zu prüfen, ob sie bestanden wurden
  • Nach den Tests erfolgte eine zusätzliche Bewertung nach folgenden Kriterien
    • Gleichwertigkeit: ob der Kandidaten-Patch dieselbe Verhaltensänderung erreicht wie der ursprüngliche, von Menschen erstellte Patch
    • Bestehen im Code-Review: ob ein Reviewer den Patch unter Berücksichtigung von Korrektheit, Risiko für neue Bugs, Wartbarkeit und Edge Cases akzeptieren würde
    • Footprint-Risiko: wie viel zusätzlichen Code der Agent im Vergleich zum menschlich erstellten Patch angefasst hat
    • Handwerk-/Disziplin-Rubrik: bewertet werden Klarheit, Einfachheit, Konsistenz, Zielgerichtetheit, Robustheit, Befolgung von Anweisungen, Disziplin beim Umfang und minimale Diffs
  • Alle Modelle wurden pro Aufgabe einmal mit einem einzelnen Seed ausgeführt
  • Das LLM für die Bewertung war GPT-5.4; der Bewerter sah nur Patch und Aufgabe, nicht aber, welches Modell oder welche Reasoning-Einstellung den Patch erzeugt hatte
  • Repräsentative Beispiele wurden zusätzlich manuell geprüft, aber es gab keine separate menschliche Kalibrierung für dieses Aufgabenset; deshalb sollte man eher der Richtung der Veränderungen vertrauen als einzelnen absoluten Punktwerten
  • Ausführungsdetails
    • Modell: GPT-5.5
    • Harness: Codex 0.128.0
    • Datensatz: 26 reale Aufgaben aus GraphQL-go-tools
    • Zentrale Metriken: Test-Bestehen, semantische Gleichwertigkeit, Bestehen im Code-Review, Footprint-Risiko, benutzerdefinierte Bewertung für Handwerk/Disziplin, Kosten und Laufzeit
  • Interaktive Charts und detaillierte Analysen pro Aufgabe gibt es unter https://stet.sh/blog/gpt-55-codex-graphql-reasoning-curve
  • Dieselbe Bewertung wird auch in einer automatisierten Forschungsschleife zur Verbesserung von AGENTS.md verwendet
    • Der Agent erstellt einen Verbesserungsvorschlag für AGENTS.md des Repositorys, führt dann mit Stet frühere Aufgaben aus und iteriert darauf, wo sich Ergebnisse verbessert oder verschlechtert haben

Gesamtmetriken und Einordnung

  • Die Gesamtmetriken zeigen: Mit höherem Reasoning-Aufwand werden die Unterschiede bei semantischer Gleichwertigkeit und Review-Bestehensquote deutlicher als beim Bestehen von Tests
  • Kernergebnisse
    • Test-Bestehen: low 21/26, medium 21/26, high 25/26, xhigh 24/26
    • Gleichwertig mit menschlichem Patch: low 4/26, medium 11/26, high 18/26, xhigh 23/26
    • Bestehen im Code-Review: low 3/26, medium 5/26, high 10/26, xhigh 18/26
    • Durchschnitt Handwerk/Disziplin: low 2.311, medium 2.604, high 2.736, xhigh 3.071
    • Durchschnittliche Kosten pro Aufgabe: low $2.65, medium $3.13, high $4.49, xhigh $9.77
    • Durchschnittliche Laufzeit des Agenten: low 286,9 Sekunden, medium 411,0 Sekunden, high 579,0 Sekunden, xhigh 753,3 Sekunden
  • low und medium lagen beim Test-Bestehen beide bei 21/26, doch die Gleichwertigkeit stieg von 4/26 auf 11/26 und das Review-Bestehen von 3/26 auf 5/26
  • Gegenüber medium erhöhte high das Test-Bestehen um +15,4 Prozentpunkte, die Gleichwertigkeit um +26,9 Prozentpunkte und das Review-Bestehen um +19,2 Prozentpunkte und liefert damit die deutlichste praktische Verbesserung
  • Gegenüber high lag xhigh beim Test-Bestehen um -3,8 Prozentpunkte niedriger, steigerte aber die Gleichwertigkeit um +19,2 Prozentpunkte und das Review-Bestehen um +30,8 Prozentpunkte
  • Der Reasoning-Aufwand verändert also nicht nur die Test-Bestehensquote, sondern auch die Art der Patches, die Codex erzeugt
  • Öffentliche Benchmarks beantworten oft nur die binäre Frage, ob eine Aufgabe gelöst wurde; in echter Softwareentwicklung ist aber auch wichtig, ob ein Patch gemergt und anschließend gewartet werden kann
  • Terminal-Bench fokussiert sich vor allem auf schwierige Coding-Probleme, bei SWE-bench verified könnten Modelle die Antwort bereits gesehen haben, und SWE-bench Pro ist zwar nützlich, aber eher allgemein gehalten
  • Im Zentrum dieses Experiments steht die Frage: „Hat der Agent in meiner Codebasis dieselbe Art von Änderung vorgenommen wie ein von Menschen gemergter Patch?“ und „Würde ich diesen Patch später selbst besitzen wollen?“

Von low zu medium: von Heuristiken zu Domain-Modellierung

  • low und medium liegen beim Test-Bestehen beide bei 21/26 und wirken nur anhand der Tests wie ein Gleichstand
  • medium erhöht jedoch die semantische Gleichwertigkeit von 4/26 auf 11/26, und auch der Durchschnitt für Handwerk/Disziplin steigt von 2.311 auf 2.604
  • In diesem Bereich verpasst man bei Messung nur über Tests den Großteil des Unterschieds im Reasoning-Aufwand
  • low blieb selbst bei erfolgreichen Patches teils bei Heuristiken oder Teilimplementierungen stehen, während medium stärker in Richtung einer besseren Modellierung von Repository und Domain-Semantik ging
  • Beispiel PR #1297
    • Es geht um die Validierung nullable externer @requires-Abhängigkeiten in GraphQL Federation
    • Wenn ein nullable required field mit einem Fehler zusammen null zurückliefert, darf diese kontaminierte Entität nicht an nachgelagerte abhängige Fetches weitergegeben werden
    • Der Kern der Aufgabe war nicht das einfache Hinzufügen eines Validierungszweigs, sondern die Modellierung subtiler Regeln für Datenabhängigkeiten in Federation
    • low bestand zwar die Tests, behandelte das Matching von required field und Fehlern jedoch heuristisch und übersah strukturierte nullable-@requires-Metadaten, war daher nicht gleichwertig und bestand auch das Review nicht
    • medium verfolgte kontaminierte Objekte und filterte Eingaben für nachgelagerte Fetches, bestand damit Gleichwertigkeit und Review, und die Qualität bei Handwerk/Disziplin stieg von 1.350 auf 3.225
    • high und xhigh blieben in derselben Qualitätsklasse, daher zeigt diese Aufgabe vor allem die Verbesserung beim Übergang von low zu medium

high: Der Punkt nahe an einem praktischen Standardwert

  • high verbessert gegenüber medium sowohl bestandene Tests als auch semantische Gleichwertigkeit und bestandene Reviews, während der Kostenanstieg groß, aber nicht überzogen bleibt
  • Vergleich von high und medium
    • Bestandene Tests: Anstieg von 21/26 auf 25/26
    • Gleichwertigkeit: Anstieg von 11/26 auf 18/26
    • Bestandene Code-Reviews: Anstieg von 5/26 auf 10/26
    • Durchschnittliches Footprint-Risiko: Anstieg von 0.268 auf 0.314
    • Durchschnitt für Umsetzung/Disziplin: Anstieg von 2.604 auf 2.736
    • Durchschnittliche Aufgabenkosten: Anstieg von $3.13 auf $4.49, also um das 1.43-Fache
    • Durchschnittliche Laufzeit: Anstieg von 411.0 Sekunden auf 579.0 Sekunden
  • high wirkt wie der Punkt, an dem zusätzliche Token in realen Nutzen umgewandelt werden und die Trefferquote bei Integrationsdetails steigt
  • Beispiel PR #1209
    • Es geht um die Aufgabe, dass die gRPC datasource GraphQL-Aliase im Antwort-JSON beachten, referenzierte protobuf-Nachrichtentypen vorab validieren und die Mapping-Abdeckung für union/interface-Mutationspfade aktualisieren muss
    • low und medium bestanden beide die Tests, waren aber nicht gleichwertig und fielen auch im Review durch
    • medium behandelte Alias-Serialisierung und die Validierung fehlender Nachrichten weitgehend korrekt, übersah aber das Update des createUser-Mutations-Mappings und lud JSONPath zu stark mit der Semantik von Response-Keys auf
    • high führte eine explizite Behandlung von Response-Key/Alias ein und reichte Aliase durch Planning und JSON-Marshaling durch, wodurch erstmals ein strenger Durchlauf gelang
    • Die benutzerdefinierte Qualität von high stieg auf 3.625; es wurde also nicht einfach nur mehr Code hinzugefügt, sondern die Integrationsanforderungen wurden präzise getroffen
    • xhigh bestand ebenfalls, verbesserte aber die Interpretation auf Aufgabenebene nicht, und die Laufzeit des Agenten nach dem Maßstab der neu generierten Zusammenfassung lag mit 790.7s über high mit 314.0s
  • Beispiel PR #1155
    • Es handelt sich um eine Hardening-Aufgabe für die gRPC datasource, einschließlich Support für repeated scalar fields, Vermeidung von Panics bei null/ungültigen Nachrichten, Weitergabe von gRPC-Statuscodes, Deaktivierung der datasource und Support für dynamic clients
    • low und medium bestanden die Tests, waren aber nicht gleichwertig
    • medium verbesserte die Robustheit, serialisierte aber ungültige repeated fields als leeres Array, übersah das Planning-Verhalten für aliased roots und ließ Risiken im Lebenszyklus des dynamic clients bestehen
    • high bestand Gleichwertigkeits- und Review-Prüfung dank sichererer Behandlung von nil/ungültigen Werten, Weitergabe von Statuscodes, Verhalten bei deaktivierter datasource und Abdeckung für dynamic client-provider
    • Bei dieser Aufgabe trat bei xhigh eine Umkehr ein: Die Tests wurden zwar bestanden, aber die Semantik deaktivierter datasources und das Verhalten ungültiger Listen wurden falsch behandelt, sodass weder Gleichwertigkeit noch Review bestanden wurden

xhigh: Eher ein Qualitätsmodus als ein Standardwert

  • xhigh erhöhte gegenüber high die semantische und Review-Qualität, ist aber kein Fall, in dem durch bloßes Hochdrehen der Einstellung automatisch alles besser wird
  • Vergleich von xhigh und high
    • Bestandene Tests: Rückgang von 25/26 auf 24/26
    • Gleichwertigkeit: Anstieg von 18/26 auf 23/26
    • Bestandene Code-Reviews: Anstieg von 10/26 auf 18/26
    • Durchschnittliches Footprint-Risiko: Anstieg von 0.314 auf 0.365
    • Durchschnitt für Umsetzung/Disziplin: Anstieg von 2.736 auf 3.071
    • Durchschnittliche Aufgabenkosten: Anstieg von $4.49 auf $9.77, also um das 2.18-Fache
    • Durchschnittliche Laufzeit: Anstieg von 579.0 Sekunden auf 753.3 Sekunden
  • xhigh deckt tendenziell mehr Grundlagen ab, trifft die menschliche Intention besser und erzeugt vollständigere Änderungen, verbraucht dafür aber deutlich mehr Token
  • Nach der Review-Rubrik liegt xhigh mit einem Durchschnitt von 3.365 und einem Median von 3.500 über high mit einem Durchschnitt von 2.817 und einem Median von 2.750
  • Auch der Median liegt über dem Durchschnitt, was darauf hindeutet, dass die Verbesserung bei xhigh nicht nur durch ein oder zwei herausragende Patches den Durchschnitt nach oben gezogen hat
  • xhigh ist semantisch vollständiger, greift im Vergleich zu von Menschen erstellten Patches aber auch mehr Code an, wodurch das Footprint-Risiko steigt
  • xhigh fügte über 26 Aufgaben insgesamt 13,144 Zeilen hinzu, aufgeteilt in 5,918 Zeilen Implementierungscode und 7,226 Zeilen für Tests, Fixtures und erwartete Ausgaben
  • Verglichen mit high fügte xhigh 2,631 zusätzliche Zeilen hinzu, davon 2,436 in Dateien für Tests, Fixtures und erwartete Ausgaben
  • Der Anstieg des Footprints liegt also nicht nur daran, dass riesiger Production-Code geschrieben wurde; ein großer Teil kommt auch daher, dass xhigh mehr Validierung und Fixture-Abdeckung erzeugte
  • Änderungen an Tests, Fixtures und erwarteten Ausgaben sind jedoch ebenfalls reale Oberfläche, die reviewt und gewartet werden muss
  • Beispiel PR #1076
    • Es geht um die Umstrukturierung der subscription-Verarbeitung, um eine Race Condition bei einem gemeinsam genutzten Mutex zu vermeiden
    • Zu den Anforderungen gehörten serialisierte Writes pro subscription, Heartbeat-Steuerung pro subscription, Abdeckung durch den Race Detector und die Korrektur der WebSocket-Close-Semantik
    • medium bestand die Tests, war aber nicht gleichwertig und fiel auch im Review durch
    • high erreichte Gleichwertigkeit und Befolgung der Anweisungen, scheiterte im Review jedoch, weil die neue Worker-Queue die globale subscription-Event-Loop blockieren konnte, das Shutdown hinter einem hängenden Worker stoppen konnte, hängende Updates unbegrenzt blieben und ein Unsubscribe auf Client-Ebene weiterhin die interne subscription übersprang
    • xhigh war der erste strenge Durchlauf und hob die benutzerdefinierte Qualität auf 3.475
    • Diese Aufgabe ist das beste Beispiel dafür, dass xhigh bei stark nebenläufigen Aufgaben als Qualitätsmodus funktioniert, der für das Bereinigen von Review-Risiken bezahlt wird
  • Beispiel PR #1308
    • Es geht um die Implementierung von GraphQL-@oneOf-Input-Objects
    • Erforderlich sind das Hinzufügen einer built-in directive, die Sichtbarkeit in der Introspection, Validierung von Operation-Literalen und Runtime-Variablen sowie eine verbesserte Source-Location für undefinierte Variablen
    • medium und high bestanden die Tests, verfehlten aber wichtige @oneOf-Semantik bei Runtime-Variablen, Nullable-Variablen, Payloads mit übergebenem null und der Introspection-Form; daher waren sie weder gleichwertig noch review-tauglich
    • xhigh war der erste strenge Durchlauf und erzielte Robustheit 3.7, Befolgung der Anweisungen 4.0 und benutzerdefinierte Qualität 3.525
    • Der Unterschied liegt nicht in oberflächlichem Feinschliff, sondern in der Abdeckung von Edge Cases über mehrere Systemteile hinweg
  • Beispiel PR #1240
    • Es geht darum, das Merging von GraphQL-AST-Field-Selections und das Merging von Inline-Fragment-Selections in einem einzigen Normalisierungsdurchlauf zusammenzuführen
    • low und high bestanden den strengen Durchlauf
    • xhigh war nach dem semantischen Bewertungsmaßstab gleichwertig, fiel aber im Review durch, weil es einen priorisierten Subpass beibehielt, die Reihenfolge von AbstractFieldNormalizer änderte und eine veraltete Field-Merge-Registrierung stehen ließ
    • Auch eine höhere Reasoning-Einstellung kann raffiniertere und plausiblere Refactorings erzeugen und dabei dennoch das exakte Laufzeitverhalten verfehlen, auf das Tests und Reviewer Wert legen

Umsetzung·Disziplin, Kosten, Grenzen und Fazit

  • Auch die benutzerdefinierte Bewertung für Umsetzung·Disziplin steigt insgesamt ähnlich wie die Review-Rubrik mit zunehmendem Reasoning-Aufwand
  • Der all-custom-Score liegt bei xhigh mit einem Durchschnitt von 3.071 und einem Median von 3.087 höher als bei high mit einem Durchschnitt von 2.736 und einem Median von 2.688
  • Da bei sowohl Umsetzung als auch Disziplin auch die Medianwerte höher sind, lässt sich das so deuten, dass xhigh nicht nur einige herausragende Beispiele erzeugt hat, sondern die Patch-Qualität insgesamt verbessert hat
  • Durchschnitts-/Median-Metriken
    • Craft aggregate: low 2.327 / 2.338, medium 2.618 / 2.525, high 2.781 / 2.787, xhigh 3.126 / 3.100
    • Discipline aggregate: low 2.295 / 2.325, medium 2.590 / 2.588, high 2.691 / 2.688, xhigh 3.015 / 3.013
    • All custom graders: low 2.311 / 2.338, medium 2.604 / 2.550, high 2.736 / 2.688, xhigh 3.071 / 3.087
  • Detaillierte Einordnung
    • low ist schwach bei Robustheit und Einhaltung von Anweisungen
    • medium verbessert diesen Bereich deutlich, ohne die Gesamtzahl bestandener Tests zu erhöhen
    • high verbessert die tatsächliche Korrektheit und Robustheit
    • xhigh verbessert nahezu alle Dimensionen, einschließlich Scope und diff-Disziplin
  • Kosten und Zeit
    • low: durchschnittliche Kosten $2.65, Median $1.91, durchschnittliche Laufzeit 286.9s, Median 294.6s
    • medium: durchschnittliche Kosten $3.13, Median $2.87, durchschnittliche Laufzeit 411.0s, Median 371.8s
    • high: durchschnittliche Kosten $4.49, Median $3.99, durchschnittliche Laufzeit 579.0s, Median 572.9s
    • xhigh: durchschnittliche Kosten $9.77, Median $6.39, durchschnittliche Laufzeit 753.3s, Median 732.7s
  • Die Kosten sind bei low und besonders bei xhigh verzerrt verteilt; die durchschnittlichen Kosten von xhigh werden von einigen teuren Aufgaben beeinflusst
  • Auch nach Median ist xhigh teurer und langsamer als high
  • high kostet gegenüber medium pro Aufgabe etwa das 1,43-Fache, xhigh gegenüber high etwa das 2,18-Fache
  • Grenzen
    • Pro Aufgabe wurde nur ein einzelner Seed verwendet
    • Es wurden nur 26 reale GraphQL-go-tools-Aufgaben einbezogen
    • Der LLM-Judge war GPT-5.4 und sah die Patches und Aufgaben, aber nicht die Labels
    • Es gab keine Grader-Kalibrierung für dieses Aufgabenset
    • Die Ergebnisse sollten nicht als statistisch signifikante allgemeingültige Resultate oder als direkt auf andere Repositories übertragbar betrachtet werden
  • Verwandte Vergleiche
    • Auch das Real-Task-Leaderboard von Voratiq zeigt trotz anderer Methodik eine ähnliche Richtung
    • Bei Voratiq liegt GPT-5.5 xhigh bei 1994, GPT-5.5 high bei 1807, also bei +187 Punkten bzw. +10.3%
    • Die Kosten liegen bei $4.23 gegenüber $2.52, also +67.9%, die Zeit bei 11.9m gegenüber 7.8m, also +52.6%
    • Im Stet-Experiment fiel high → xhigh stärker aus: Äquivalenz +19.2%p, relativ +27.8%, Code-Review-Bestehen +30.8%p, relativ +80.0%; das Umsetzung-/Disziplin-Aggregat liegt mit +12.2% ähnlich
    • Voratiq ist ein Preference-/Selection-Stil-Leaderboard für ongoing work, während dieses Experiment nur ein Ausschnitt eines Repositorys mit 26 Aufgaben ist; ein direkter Vergleich ist daher nicht möglich
  • Praktisches Fazit
    • xhigh eignet sich für mehrdeutige Aufgaben, Aufgaben über mehrere Bereiche hinweg, nebenläufigkeitslastige Aufgaben oder Aufgaben mit hohem Review-Risiko
    • high wirkt in diesem Datensatz als praktischste Standardeinstellung für den täglichen Einsatz
    • Einstellungen auf medium oder darunter eignen sich, wenn Kosten wichtiger sind und die Aufgaben alltäglich oder gut definiert sind
    • Der Effekt des Reasoning-Aufwands ist je nach Aufgabe weder glatt noch monoton; es gibt auch Umkehrungen, bei denen high xhigh schlägt oder eine höhere Einstellung eine plausibel wirkende, aber falsche Implementierung erzeugt
    • Teams sollten nicht einfach globale Benchmark-Defaults kopieren, sondern mit dem eigenen Harness und den eigenen Aufgaben messen
  • Offenlegung
    • Es wird Stet.sh entwickelt, und mit diesem lokalen Evaluierungstool wurde das Experiment durchgeführt
    • In der Produktversion erstellt der Coding-Agent Kandidatenänderungen wie Verbesserungen an AGENTS.md und bewertet sie mit Stet anhand historischer Repository-Aufgaben
    • Es werden Teams gesucht, die gemeinsam repository-spezifische Tests durchführen wollen, wenn sie vor konkreten Entscheidungen stehen wie high vs xhigh, Codex vs Claude Code, Updates an AGENTS.md oder der Einschätzung, welche Aufgaben sich sicher delegieren lassen
    • Stet läuft vollständig lokal unter Nutzung eines LLM-Abonnements; die Warteliste ist unter https://www.stet.sh/private verfügbar

Verwandte Beiträge

1 Kommentare

 
GN⁺ 7 시간 전
Reddit-Meinungen
  • Dieser Vergleich ist gut, und ich würde auch gern einen Vergleich mit 5.4 sehen
    Nach meinem bisherigen Eindruck ist 5.5 den Aufpreis nicht wert. 5.4-high liefert in den meisten Inferenzstufen von 5.5 bessere Ergebnisse, kostet nur die Hälfte und braucht in der Praxis deutlich weniger Zeit. 5.5-medium konnte die Aufgaben nicht zu Ende bringen, und 5.5-high hat durch Overengineering Bugs und Regressionen erzeugt
  • Für die meisten ernsthaften Arbeiten scheint high passend zu sein
    Darüber hinausgehende Verbesserungen wirken im Verhältnis zu den Kosten wie abnehmende Erträge
  • Mit einem Pro-Konto lasse ich 5.5 xHigh Codex Terminal CLI als Haupt-Lead laufen und die Codex Desktop App 5.5 xhigh als unterstützenden Lead
    Beide bekommen vollen, riskanten Zugriff und arbeiten am selben Projekt. An jedem hängen im Schnitt sechs 5.5-Sub-Agenten, und CLI oder App entscheiden, welche Stufe der Sub-Agenten sie verwenden. Es ist gemischt, aber die CLI hängt meist 5.5 Medium an
    Die CLI hat Admin-Rechte und übernimmt Dinge wie GitHub, Supabase, Vercel, Clerk, Linear und Symphony; außerdem erledigt nur die CLI Push, Merge, PR und Deploy. Ich mache selbst nichts, und es gibt auch keine P0/P1/P2-Issues. Bei GitHub, Vercel und Supabase ist alles grün, es gibt keine Issues, der Code und das Produkt sind sauber, und allein mit einem Referenzbild kommt erstaunlich gutes Frontend heraus
    Der Nachteil ist, dass man an einem Tag 30 % des Wochenlimits verbrennen kann
    • Nach diesem Experiment habe ich für einige Aufgaben xhigh ausprobiert; das ist ziemlich effektiv, verbraucht aber wahnsinnig viele Token
      Inzwischen bin ich wieder zu high zurückgekehrt
  • Mein größter Kritikpunkt an 5.5 xhigh ist, dass es einfach von selbst loslegt, ohne überhaupt zu fragen
    Dadurch habe ich gefühlt ein paar Lebensjahre und eine Menge Token gespart
    • Ich nutze meistens high, und es verhält sich genauso
      Ich suche immer noch nach einer Formulierung für agents.md, damit es nicht eigenmächtig Annahmen trifft. Wenn ich vor einer Coding-Anweisung zu etwas erst mehr wissen muss und deshalb eine Frage stelle, fängt es manchmal einfach mit dem Coden an statt zu antworten. Hinterher packt es die Antwort auf die Frage zwar in die Antwort mit hinein, aber es scheint zwar auf meine Worte zu achten, versteht aber nicht, dass eine Frage bedeutet, noch nicht mit dem Coden anzufangen
  • Ich frage mich, ob ihr denselben PR mehrfach ausgeführt habt
    Ich würde gern wissen, wie stark die Schwankung zwischen einzelnen Läufen des Modells ist. Selbst wenn high im obigen Fall besser codiert hat, könnte xhigh dennoch die bessere Wahl sein, falls die Lauf-zu-Lauf-Varianz groß ist
    Als weiteres Experiment wäre es interessant, nach einem Lauf Feedback zum Arbeitsergebnis zu geben, es mit den von Menschen vorgenommenen Änderungen zu vergleichen und dann AGENTS.md, Skills, Rules usw. aktualisieren zu lassen, bevor man es in einer frischen Session erneut mit high/xhigh laufen lässt. Wenn man das ein paar Mal wiederholt und verbessert und danach bei allen Effort-Stufen erneut testet, könnte man mit sauber abgestimmtem AGENTS.md und Skills/Rules die Gesamtqualität der Ausgaben anheben
    • Ich habe nicht jede Variante mehrfach laufen lassen. Der Hauptgrund sind Kosten- und Token-Beschränkungen. Mein Geldbeutel ist nicht unendlich, aber als Anschlussforschung ist das eine gute Idee
      Die Optimierung von AGENTS.md gefällt mir wirklich sehr, und ich habe Stet, das ich für die Durchführung von Experimenten gebaut habe, genau das machen lassen. Es lässt Codex auf einige Aufgaben laufen, schaut sich Scores und Fehlermuster an, passt dann AGENTS.md an und führt alles erneut aus — komplett autonom. Es funktioniert wie automatisierte Forschung für AGENTS.md, und es ist ziemlich spannend zu sehen, wie datenbasierte Verbesserungsvorschläge wieder in AGENTS.md einfließen
  • Wir brauchen jetzt auch einen CPI-Index für die Preisinflation. Der monatliche CPI fühlt sich fast wie 100 % an