Warum: DFlash2 fuer den Coder lag vom 19.08. bis 04.09. ungenutzt auf der Platte, weil der KISS-Radar nur nach innen sah. stack-upstream.py fragt die Watchlist als Fakten ab (GitHub-Issues/PRs/Releases/Branches, PyPI, neue Repos eines HF-Autors, Zeilen einer URL), vergleicht mit dem letzten Lauf und meldet nur Aenderungen als ACHTUNG NEU. stack-radar.sh haengt das an den IST-Zustand; faellt es aus, bleibt der Innen-Bericht vollstaendig. Erster Lauf fand sofort: MMQ-Issue 21284 ist geschlossen, pocket-tts 3.1.0, Electron 44 — alles Dinge, die der Radar seit Juli haette melden sollen. heavy: gpt-oss-120b (AA-Index 24, 60 GB) gibt die Rolle an Qwen3.8-27B ab (Index 52, 17 GB, 31 t/s mit DFlash2) — ein Modell, zwei Rollen. gpt-oss bleibt ohne Alias als Rollback. Live gemessen ueber :9010 mit Reasoning. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
OpenCode-Konfiguration des PCs
Hier liegt die Quelle. %USERPROFILE%\.config\opencode\ ist die Kopie.
Am 21.08.2026 habe ich die dortige opencode.json ueberschrieben, ohne sie
vorher zu lesen — sie existierte nur an dieser einen Stelle, ohne Sicherung und
ohne Historie. Rekonstruiert aus einer Juli-Sicherung. Damit das nicht nochmal
passiert, liegt sie jetzt hier.
Copy-Item "deploy\opencode-config\*" "$env:USERPROFILE\.config\opencode\" -Force
Modellwahl (Stand 22.08.2026)
| Rolle | Modell | warum |
|---|---|---|
| build | aibox/coder — Qwen3.8-27B (dicht) |
macht die eigentliche Arbeit |
| plan | aibox/heavy — gpt-oss-120b |
denkt vor, aendert nichts |
| explore | aibox/hermes — Qwen3.6-35B-A3B |
liest und sucht, immer warm |
small_model |
aibox/hermes |
Titel, Zusammenfassungen |
★★ Korrektur einer falschen Empfehlung. Bis zum 22.08. stand hier fast
(Qwen3.6-35B-A3B, MoE) als Standard, mit der Begruendung, es schlage den coder
„in Tempo und Qualitaet". Das Tempo war gemessen, die Qualitaet nie — in der
Notiz vom 20.08. steht fuer den Coder woertlich „keine agentische Messung".
Die veroeffentlichten Zahlen sagen etwas anderes:
fast (3.6-35B-A3B) |
coder (3.8-27B) |
|
|---|---|---|
| SWE-bench Verified | ~73,4 | 73,4 |
| Terminal-Bench 2.1 | — | 73,0 |
| DeepSWE 1.1 | — | 42,2 (Vorgaenger 3.6-27B: 13,3) |
| OSWorld-Verified | — | 84,3 |
Einzelschuss gleichauf, agentisch ueber viele Schritte zieht der Coder davon — und genau das ist der Betrieb hier. Alle Zahlen stammen von Qwen selbst, teils aus eigenen Benchmark-Fassungen; sie sind ein Indiz, kein Beweis.
Der Preis, gemessen: dieselbe Leseaufgabe brauchte mit fast 24,3 s,
mit coder 89,3 s — 3,7× laenger in der Wanduhr. Der Coder ist dicht und
bandbreitenlimitiert (17 GB / 215 GB/s ≈ 12,6 t/s, Hardware-Grenze, kein
Konfigfehler). Er hat ausserdem ttl=5400, faellt also nach 90 Minuten aus dem
Speicher und muss neu laden.
Was noch aussteht: der echte Vergleich an einer echten Aufgabe.
F:\Coding Stuff\mc2-referenz liegt genau dafuer bereit — 17 Dateien, davon 5
erledigt, mit objektivem Pruefbefehl docs/aufgaben/referenz-check.sh.
Erst dieser Lauf entscheidet die Frage; bis dahin ist die Modellwahl begruendet,
aber nicht bewiesen.