Hitonabi
c28aa4a6a2
Ampel / ampel (push) Successful in 22s
README war auf dem Stand "Final-Version eingefroren" und kannte weder Governor,
Coding-Bahn, CI-Ampel noch den Weg einer Idee. Neu geschrieben mit den echten
Ports/Diensten, den gemessenen Modell-Rollen und den vier Qualitaets-Toren.
Alle Verweise gegen den Baum geprueft.
Dabei aufgefallen: das eigene VERDIKT vom 24.07. ("Devstral bricht beim 32K-Prefill
auf 63 t/s ein") widerlegt meine Begruendung "ein Kritiker liest viel und schreibt
wenig, also stoert die Langsamkeit nicht" — es ist genau das LESEN, das einbricht.
Nachgemessen: Prefill 265-318 t/s (Coder 754). Der Kritiker ist deshalb in
llama-swap UND in beiden opencode.json auf 16384 gedeckelt; schlimmster Fall je
Review jetzt unter einer Minute statt 8+ Minuten.
VERDIKTE um zwei Eintraege ergaenzt: die enge Kritiker-Rolle mit Deckel, und die
llama-swap-Gruppenregel (eine Gruppe resident, persistent:false, OOM-Grenze).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
OpenCode-Seite: ein Regelwerk, zwei Auslöser
Tagsüber tippst du in Zed (PC), nachts ruft ein Hermes-Cron dasselbe (Box). Beide Wege benutzen dieselbe OpenCode-Version, dieselbe Mannschaft, dasselbe Plugin und denselben Token-Wächter. Der einzige Unterschied ist die Adresse des Governors.
Was wohin gehört
| Datei hier | Ziel auf dem PC | Ziel auf der Box |
|---|---|---|
opencode.pc.json |
~/.config/opencode/opencode.json |
— |
opencode.box.json |
— | ~/.config/opencode/opencode.json |
plugin/mc2-governor.ts |
~/.config/opencode/plugin/ |
~/.config/opencode/plugin/ |
VERIFY.template |
— | wird von gitea-repo-create.sh in jedes neue Repo als VERIFY gesät |
Der Governor selbst liegt in ../governor/ (Proxy + systemd-Unit), der unbeaufsichtigte
Läufer in ../opencode-lauf.sh.
Die Mannschaft
| Rolle | Modell | Gemessen (25.07.2026) | Warum |
|---|---|---|---|
plan + build |
coder — Qwen3-Coder-Next |
51,5 t/s | Hält den Faden, verteilt Zuarbeit. MoE mit 3B aktiv → schnell auf Strix Halo. |
explore |
hermes — Qwen3.6-35B |
69,6 t/s | Ohnehin dauerwarm → kostet null zusätzlichen Speicher. Sucht, liest, meldet kurz zurück. |
review |
kritiker — Devstral-Small-2 |
15,0 t/s | Bewusst eine fremde Modellfamilie (Mistral statt Qwen) → andere blinde Flecken. Dicht = langsam beim Schreiben, aber ein Kritiker liest viel und schreibt wenig. |
heavy (gpt-oss-120b, 63 GB) ist nicht mehr in der Tagesrolle: es würde beim Laden
das ganze warme Set verdrängen. Es bleibt der Nacht-Gutachter (4:30-Cron).
Nach einer Änderung
Die Dateien hier sind Vorlagen, keine Live-Konfiguration. Nach einer Änderung verteilen:
# Box
scp deploy/opencode/opencode.box.json hitonabi@192.168.178.151:~/.config/opencode/opencode.json
scp deploy/opencode/plugin/*.ts hitonabi@192.168.178.151:~/.config/opencode/plugin/
# PC (aus dem Repo heraus)
cp deploy/opencode/opencode.pc.json ~/.config/opencode/opencode.json
cp deploy/opencode/plugin/*.ts ~/.config/opencode/plugin/
Zed muss danach neu gestartet werden — OpenCode liest seine Konfiguration nur beim Start.
Fallen, die Zeit gekostet haben
- Kein
_comment-Schlüssel inopencode.json. OpenCode validiert streng und verweigert den Start mit „Unrecognized key". Kommentare gehören in dieses README. - Das Plugin läuft auf Windows UND Linux. Deshalb
node:fsstattcatund Buns${{ raw: cmd }}stattbash -lc— beides fehlt auf Windows bzw. verschluckt den Befehl. - Bei
opencode runbeendet sich der Prozess, bevorsession.idlefertig ist (gemessen 25.07.). Für unbeaufsichtigte Läufe liegt die Prüf-Schleife deshalb zusätzlich inopencode-lauf.sh, wo sie den Prozess überlebt. In Zed greift das Plugin. - Plugin-Verzeichnis:
plugin/undplugins/werden beide erkannt; wir nutzenplugin/.