English | Deutsch

Alle Berichte der Lane-Arena · Pilot-Ausgabe

opencode 1.19 gegen opencode 2: gleiches Modell, anderer Harness

Die Lane, das lokal betriebene Modell aus der Pilot-Ausgabe, läuft in opencode. opencode 2 ist seit Wochen in Entwicklung. Vor einem Umstieg haben wir gemessen, ob sich die neue Version gleich verhält, ob sie schneller ist und ob die Ergebnisse besser oder schlechter werden. Modell, Hardware und Server blieben exakt gleich; nur der Agent-Harness wechselte.

Das ist keine Arena-Ausgabe: Es gibt keine konkurrierenden Teilnehmer, keinen blinden Review und keine versteckten Tests. Es ist ein Harness-Vergleich aus zwei Teilen: ein Mikro-Benchmark auf Spielaufgaben und die Wiederholung eines echten Tickets.

1. Ergebnisse auf einen Blick

2. Aufbau

Mikro-Benchmark

Vier Szenarien, je 3 Wiederholungen, v1 und v2 im Wechsel (24 Läufe). Jeder Lauf startet in einer frischen Kopie eines winzigen Git-Repositorys mit einem Nachbarordner outside/.

Echtes Ticket

Das echte Ticket ist eine Wiederholung: ein Ticket, das die Lane bereits produktiv auf 1.19.0 gelöst hatte (erste Implementierungsrunde 605 s), erneut ausgeführt mit dem wörtlichen Original-Brief auf demselben Basis-Commit, ein frischer Klon pro Arm, je ein Lauf. Der Produktivlauf liefert neben der Wiederholung einen dritten Datenpunkt für 1.19. Das Ticket (Backend Hono/Prisma, Frontend Next.js, Doku): Eine Dashboard-Übersicht soll einen angebundenen Dienst, dessen gespeicherte Zugangsdaten sich nicht mehr entschlüsseln lassen, als "unlesbar" markieren, statt als Ganzes zu scheitern oder "Nicht konfiguriert" anzuzeigen. Der Brief verlangte neue Tests, Doku-Pflege und eine Mutationsprobe für jeden neuen Zweig (Zweig brechen, der neue Test muss fehlschlagen).

Im ursprünglichen Produktivlauf hatte der Review eine Lücke mittleren Schweregrads gefunden: Das Überspringen der Downstream-Aufrufe war nur für einen Teil der Dienste getestet, in den Zeilen für den Deployment-Dienst überlebten Mutanten.

3. Verhalten: was opencode 2 ändert

Die Rechte-Konfiguration, die wir für v2 auf dem echten Ticket verwendet haben, übergeben als OPENCODE_CONFIG_CONTENT zusammen mit --standalone (spätere Regeln gewinnen, pfadgenaue allow-Regeln können also auf das ask folgen). Der Mikro-Benchmark lief nur mit der ersten Regel; die question-Regel kam dazu, nachdem der Mikro-Benchmark den question-Aufruf gezeigt hatte:

{"permissions": [
  {"action": "external_directory", "resource": "*", "effect": "ask"},
  {"action": "question", "resource": "*", "effect": "deny"}
]}

Die Quellcode-Belege (Standardregeln, Dateizugriff, AGENTS.md-Suche in packages/core/src/config/plugin/instruction.ts, Verzeichnis-Erkennung der Shell in packages/core/src/shell/parse.ts) stammen vom Upstream-Entwicklungszweig, nicht exakt von 2.0.25. Jede Zeile oben außer der Quellcode-Lesung wurde auch in Läufen beobachtet.

Diese Konfiguration stellt die Grenze von 1.19 nicht vollständig wieder her: Ein Shell-Befehl, der über seine Argumente einen Pfad außerhalb des Projekts liest, läuft in v2 ohne Rückfrage (getestet mit cat; laut Quellcode werden auch Schreibzugriffe über Argumente nicht geprüft). Der Mikro-Benchmark hat das nicht erfasst, weil sein Shell-Szenario zuerst das Verzeichnis wechselte (cd ../..), was v2 prüft. Die Sicherheitsrichtlinie von opencode sagt, dass das Rechtesystem eine UX-Funktion ist und keine Sandbox, und empfiehlt für echte Isolation einen Container oder eine VM.

4. Tempo

Mikro-Benchmark (Median aus 3)

• Der Harness-Overhead (Wandzeit minus Modellzeit) ist in beiden klein: 0,7 s (v1) und 0,5 s (v2).
• Die Lücke ist fast vollständig der erste Prompt einer Session: v1 schickt jedes Mal etwa 11,9k Tokens, die den Prompt-Cache des Servers verfehlen. v2 schickt einen kleineren System-Prompt (7,8k beim allerersten Lauf). Danach kommen in einem ok-Lauf (zwei Schritte) etwa 15,2k seiner 15,7k Prompt-Tokens aus dem Cache, obwohl das Arbeitsverzeichnis pro Lauf wechselt. Warum v1 den Cache verfehlt, ist nicht verifiziert.
• edit: Tests in beiden Versionen in 3 von 3 Läufen grün, nur die zwei vorgesehenen Dateien geändert. v2 brauchte 5 statt 6 bis 8 Schritte und etwa die Hälfte der Prompt-Tokens.

Echtes Ticket (je ein Lauf)

Die Wiederholung auf 1.19 lag innerhalb von 2 % des ursprünglichen Produktivlaufs (596 s gegen 605 s); auf 1.19 reproduziert sich die Zeit für dieses Ticket also, die 1.040 s von v2 liegen deutlich außerhalb. Verglichen wird hier nur die Wandzeit des Produktivlaufs; er lief in einem regulären Worktree, in dem auch 1.19 keine zusätzliche AGENTS.md lädt.

Pro Schritt sind beide Versionen gleich schnell, und innerhalb einer langen Session nutzen beide den Prompt-Cache gut. v2 war langsamer, weil das Modell unter v2 mehr getan hat, nicht weil der Harness langsamer ist. Die Mehrzeit verteilt sich breit, ohne einzelnen Brennpunkt. Jeder Schritt zählt nach seinem ersten Tool-Aufruf; Shell-Befehle, die Tests, Lint, Typprüfung, Build oder Codegenerierung ausführen, zählen als "Tests, Lint, Build":

Was v2 zusätzlich tat: mehr Tests, zwei fehlgeschlagene Edits (der Suchtext passte nicht), wiederholtes npm ci, nachdem parallele Installationen einen unvollständigen Baum hinterlassen hatten, zweimal die --help-Ausgabe eines Tools gelesen, ein Produktions-Build und ein Wegwerf-End-to-End-Check gegen das echte Downstream-Modul. Die Ersparnis aus dem Mikro-Benchmark von etwa 15 s pro Session macht bei einem 600-s-Ticket etwa 2,5 % aus und geht in dieser Mehrarbeit unter.

5. Ergebnisqualität auf dem echten Ticket

• Beide Versionen änderten dieselben 9 Dateien. Backend 270 von 270 Tests grün; Frontend 30 von 30 (v1) und 33 von 33 (v2).
• Beide meldeten die drei geforderten Mutationsproben als gekillt. Unsere eigenen Proben auf das Überspringen in den Zeilen des Deployment-Dienstes fanden in beiden Versionen 2 überlebende Mutanten, genau die Lücke des ursprünglichen Produktivlaufs. Keine Version hat die Tests von sich aus auf diesen symmetrischen Fall erweitert; beide testeten, was der Brief wörtlich nannte.
• v1 entfernte eine Bedingung, die die Lesbarkeit nur für konfigurierte Dienste prüft. Nicht konfigurierte Dienste lösen jetzt einen zusätzlichen Zugangsdaten-Abruf und einen Downstream-Aufruf aus, und die Übersicht meldet für sie einen Fehler statt null. Die Oberfläche ist nicht betroffen, die Änderung ist ungetestet und nicht rein additiv. Der ursprüngliche Produktivlauf auf derselben Version tat das nicht: Streuung zwischen Läufen, kein Merkmal der Version.
• v2 hielt den Antwortvertrag ein, ergänzte einen Test für einen weiteren Dienst und eine zusätzliche Mutationsprobe und führte Build und einen End-to-End-Check aus.

Lesart: v2 war hier gründlicher und bezahlte dafür mit der 1,75-fachen Zeit, den 2,4-fachen Prompt-Tokens und damit der 1,75-fachen Belegung eines Server-Slots. Bei einem Lauf pro Version und sichtbarer Streuung schon innerhalb von 1.19 lässt sich "v2 ist gründlicher" nicht von Zufall trennen.

6. Grenzen

• Ein Lauf pro Version auf dem echten Ticket, und nicht im Wechsel: v2 lief zuerst, dann v1 (ein Schleifenfehler im Benchmark-Skript ließ beim ersten Aufruf nur v2 laufen; die Daten wurden umbenannt, nichts ging verloren). Mit dem Produktivlauf hat 1.19 zwei Zeitmessungen für dieses Ticket, v2 nur eine.
• Die Mikro-Szenarien wiederholen identische Prompts, das begünstigt den Prompt-Cache. Ein ausgelasteter Server oder wechselnde Briefs wurden nicht gemessen.
• Die Ursache der Cache-Fehlgriffe von v1 beim ersten Prompt ist eine Hypothese (ein pro Lauf variabler Wert früh im System-Prompt), nicht per Request-Mitschnitt belegt.
• Reasoning-Tokens melden beide Versionen als 0, obwohl das Modell denkt (wie im Pilot). Output-Tokens trennen Reasoning daher nicht.
• Ein Build von 2.x (2.0.25). Der Entwicklungszweig bewegt sich schnell; 1.19 hat seither Patch-Releases bekommen, die nicht neu gemessen wurden.
• Beide Arme liefen in Klonen außerhalb des Home-Verzeichnisses. In der produktiven Anordnung (Checkouts unterhalb des Workspace-Ordners) hätte v2 zusätzlich die Workspace-AGENTS.md geladen.

7. Fazit

1. opencode 2 ist kein direkter Ersatz für eine unbeaufsichtigte Lane. Die Standardrechte erlauben alles, run ohne --standalone ignoriert Rechte-Overrides, die Suche nach AGENTS.md reicht über das Repository hinaus, das Tool question steht in unbeaufsichtigten Läufen zur Verfügung, und Shell-Befehle erreichen über ihre Argumente Pfade außerhalb des Projekts, auch mit expliziter ask-Regel. Jede dieser Änderungen verändert die Lane ohne sichtbaren Fehler.
2. Der stille Abbruch ist behoben, aber der Exit-Code bleibt 0. Ein Wrapper, der einen Lauf ohne abschließenden Bericht als fehlgeschlagen wertet, ist in beiden Versionen nötig.
3. Schneller auf Spielaufgaben, langsamer bei echter Arbeit. Der Vorteil auf Spielaufgaben ist eine feste Prompt-Cache-Ersparnis pro Session. Auf einem echten Ticket dominiert die Zahl der Schritte, und davon brauchte das Modell unter v2 mehr.
4. Der wahrscheinlichere Qualitätshebel ist der Brief, nicht der Harness. Beide Versionen ließen denselben symmetrischen Testfall aus. Symmetrische Zweige im Brief ausdrücklich zu nennen ist der nächste Test; dieser Vergleich hat es nicht ausprobiert.

Wir bleiben bei 1.19 und wiederholen den Vergleich auf echten Tickets mit mehreren Läufen pro Version, sobald 2.x das reguläre npm-Release ist: mit --standalone, den Rechte-Regeln oben, Checkouts außerhalb des Home-Verzeichnisses und der Berichtsprüfung des Lauf-Wrappers. Da die Rechte-Regeln in v2 keine Shell-Argumente abdecken, bräuchte eine Lane auf v2 einen Container oder eine VM als eigentliche Grenze.

Nach der Veröffentlichung ergänzt (Oktober 2026): die Zeile zu Pfad-Argumenten in der Shell samt Folge sowie der Dokumentationsstand zu den Standardrechten und zur AGENTS.md-Suche. Ein Feature-Request für eine einstellbare Suchgrenze liegt upstream als anomalyco/opencode#55999.