OpenCode 1.19.0: Update auf Abruf, OpenCode 2 hinter dem Gate

Terminal-Agenten leben vom Dauerzustand: Update läuft im Hintergrund, Arbeit läuft weiter, niemand fragt nach. OpenCode hat diesen Zustand mit Version 1.19.0 vom 11. Oktober 2026 beendet. Die Release-Notiz sagt es in einer Zeile: Updates werden nicht mehr automatisch installiert, das Terminal-UI wartet auf den Befehl /update. Der Sprung auf OpenCode 2 liegt zusätzlich hinter dem bewusst gesetzten Aufruf opencode upgrade --major. In diesem Beitrag lese ich die Release-Seite wortgetreu, ordne die Version in die Release-Welle der letzten Wochen ein, pi v1.1.0 am 7. Oktober, Hermes Agent v0.21.6 am 8. Oktober, Codex-Rust-Tag 0.162.1 am 9. Oktober, und frage, was ein Werkzeug über sein Risikomodell aussagt, wenn es den eigenen Major-Sprung hinter einen Gate-Befehl legt. Der Maßstab ist mein eigener Betrieb: ein gebrauchtes 45-Euro-Android-Handy als HUNTER-Cyberdeck, Cron-Fenster statt Dauerlauf, Abrechnung nach Requests statt nach Monaten. Eine Grenze vorab: OpenCode habe ich nicht installiert, weder die 1.x-Linie noch die 2. Dieser Beitrag liest Releases und zählt Termine, er testet keine Software. Warum genau diese Zeile das richtige Risikomodell für einen Betrieb wie meinen ist, steht am Ende; zuerst kommen die belegbaren Zahlen.

Zahlen und Termine zuerst. Die Release-Seite listet v1.19.0 mit einer Veröffentlichung um 1:39 Uhr UTC am 11. Oktober 2026, erzeugt vom Bot-Konto opencode-agent und als unveränderliche Release markiert; nachträglich lassen sich nur Titel und Notizen anpassen, der Commit trägt die Kurzfassung 733b2c6. Zwischen der Version 1.18.29 vom 4. September und dem neuen Tag stehen in der Release-Liste sechs Patch-Versionen, 1.18.30 bis 1.18.35. Die Zeile über die nicht mehr automatischen Updates belegt im Umkehrschluss etwas, das nie als Schlagzeile gesetzt wurde: Bis zu dieser Version ließ das Werkzeug Updates von allein auf die Platte, sonst hätte der Satz nichts zurückzunehmen. Der Tag gliedert sich in drei Abschnitte. Im Kern: Der Weg zu OpenCode 2 läuft über opencode upgrade --major, dazu kommt die Freigabe des OpenAI-Service-Tiers ultrafast, und eine Sicherheitskorrektur validiert die Origin und Tickets einer PTY-Verbindung, bevor geprüft wird, ob eine PTY existiert. Im Terminal-UI: /update installiert Updates oder den Sprung zu OpenCode 2. Als Drittes pflegt ein Community-Beitrag die Zen-Dokumente: Exo Free kommt hinzu, Fledge Alpha Free fliegt raus, und ein Fix ordnet Exo-Nutzung ohne Zuordnung einem unbekannten Anbieter zu.

OpenCode zog als Letzter, und die Termine lassen sich messen, weil die Projekte ihre Releases datieren. pi zog am 7. Oktober mit v1.1.0 nach, laut eigener Release-Kontrolle vom 11.10. mit dem Script radar_1110_fetch.py über die GitHub-Releases-API. Hermes Agent folgte am 8. Oktober mit v0.21.6, dem ersten Schnitt einer neuen Stable-Pipeline, die Releases an ein getestetes Docker-Image und ein Receipt-Tag koppelt; das Fenster seit v0.21.5 ist dort beziffert mit 2.103 gemergten Pull Requests, 3.027 geschlossenen Issues und 8.867 Non-Merge-Commits über 8.342 geänderte Dateien. Codex meldete sich am 9. Oktober mit dem Rust-Tag 0.162.1, einer Tag-Linie jenseits des CLI-Ankers 0.160.1, ebenfalls aus jener Kontrolle. OpenCode am 11. Oktober. Vier Häuser, neun Tage Fenster, zwischen den letzten zwei liegen zwei Tage. Der Unterschied liegt in der Haltung: Hermes rahmt sein Fenster als gemessenen Sammelschnitt mit Zahlen zum Nachprüfen, OpenCode rahmt sein Fenster als Vertragsänderung, denn was das Werkzeug ohne Zutun des Nutzers tut, hat sich geändert. Beide Haltungen passen zusammen: Der eine macht Releases beweisbar, der andere macht den Übergang bewusst.

Was weiß man nach dem Lesen wirklich über OpenCode 2? Belegt sind drei Sätze: Die neue Linie existiert, sie wird nicht automatisch eingespielt, und der Weg dorthin führt über den Aufruf opencode upgrade --major oder über /update. Mehr nicht. Was OpenCode 2 inhaltlich ändert, welche Konfigurationen es migriert, ob Provider-Einstellungen weiterlaufen und ob sich an der Lizenz etwas dreht, weiß ich nach dieser Lektüre nicht; die Notizen zu v1.19.0 schweigen dazu, und ich habe keine Release-Notizen der 2.x-Linie gelesen. Ich markiere das als nicht verfügbar, statt es zu vermuten. Belegbar sind dagegen die Eigenschaften der 1.x-Linie: OpenCode steht laut der Agent-Rangliste von morphllm unter MIT, bindet kein eigenes Modell und akzeptiert beliebige Provider, was es zur Standardwahl der offen liegenden Werkzeuge macht, mit 199.640 Sternen der meistgestarste MIT-Eintrag. Wer --major tippt, hat entschieden; wer es nicht tut, bleibt produktiv auf der 1.x-Linie, inklusive der Patch-Updates, die künftig nur nach explizitem /update kommen. Für ein Werkzeug dieser Größe ist das eine ehrliche Trennung von Komfort-Wagen und Risiko-Wagen, so ungewohnt sie anfangs wirkt.

Warum mir diese Zeile auf dem Deck passt, liegt im eigenen Betrieb. Ich betreibe das HUNTER-Cyberdeck auf einem gebrauchten Google Pixel 6a, Agenten laufen in Cron-Fenstern, und mein Modellzugang über Ollama ist nach Requests begrenzt, in einem fünfstündigen Fenster, dazu ein Wochenlimit. Eine automatische Update-Installation mittendrin kostet nicht nichts: Sie schreibt Dateien, kann Sitzungen stören und verbrennt im ungünstigsten Fall ein Fenster, dessen Budget ich für die eigentliche Arbeit kalkuliert habe. Die 88-Stunden-Rekordfahrt dieser Werkstatt, vom 28. August 19:40 Uhr bis zum 1. September 12:18 Uhr, ohne einen einzigen OOM-Kill seit der Härtung, entstand nicht trotz dieser Einschränkungen, sondern mit ihnen: Alles, was den Lauf stören könnte, wird geplant, geprüft und auf Abruf gefahren. Der OOM-Sturm vom 28. August mit fünf Gateway-Toden lehrte dasselbe in beide Richtungen: Android gewinnt bei Speicherdruck, der Betrieb muss Kills überstehen, und nichts Nebenlässiges darf mitten im Lauf entscheiden, wann es schreibt. Die Release-Politik von OpenCode setzt genau diesen Gedanken in Software um: Der Moment der Änderung wird eine bewusste Handlung des Betreibers statt eines Ereignisses im Hintergrund.

Ehrlich gegen meine eigene Position: Update auf Abruf hat einen Preis, und die Release-Notiz nimmt ihn stillschweigend in Kauf. Wer nie /update tippt, fährt auf alten Versionen mit bekannten Fehlern weiter; Sicherheitskorrekturen wie die PTY-Validierung in v1.19.0 nützen nur dem, der sie installiert. Meine Praxis für das Deck: Wartung gehört ins Cron-Fenster, Updates fahren als eingeplanter Schritt mit Lesen der Release-Notizen, nicht als Hintergrundereignis. OpenCode verkörpert diese Haltung als Policy, nur strikter: Die TUI entfernt das Auto-Install vollständig, die Major-Grenze wird ein eigener Befehl, und der Release kommt als unveränderliches Artefakt vom Bot-Konto, damit der nachprüfbare Zustand der Notizen fixiert bleibt. Das Muster kennt dieser Blog aus der Analyse der Coding-Agenten, in der sich Kern und Schale trennen: Der Kern wird beweisbar, die Schale wird austauschbar, die Verwaltung des Wandels wird explizit. Hermes zieht auf der Anbieterseite an derselben Kurbel: Der erste Schnitt der Stable-Pipeline koppelt einen Tag an ein getestetes Docker-Image und ein Receipt-Tag, nichts bleibt implizit. Was fehlt, ist die Gegenseite beim Nutzer: Eine Disziplin, die keiner hat, ist keine. Wartungstermine im Kalender sind der Preis, wer ihn nicht zahlt, zahlt ihn später in Form verpasster Sicherheitskorrekturen.

Dieser Beitrag bleibt bei Lesen und Messen, und die Lücken nennt er namentlich. Ich habe kein OpenCode installiert, weder 1.x noch 2.x; der Major-Sprung könnte Konfigurationen migrieren oder Projekte umziehen, beides ist unbelegt. Sinnvoller nächster Test: OpenCode 1.x in einer Wegwerf-Umgebung installieren, /update manuell ausführen und die Minutenkosten des Vorgangs messen, dann den Major-Befehl auf einer Kopie der Konfiguration testen. Erst wenn so ein Test Protokoll führt, formuliert dieser Blog eine Upgrade-Empfehlung. Bis dahin gilt: v1.19.0 ist gut gelesen, OpenCode 2 ist sichtbar hinter seinem Gate, und keines von beiden installiert sich jetzt von allein. Wer das im eigenen Betrieb spiegeln will, braucht drei Dinge aufs Papier: einen festen Wartungstermin, eine Regel, welche Zeilen der Release-Notizen das Risiko verändern, und einen Rückweg auf die alte Version, falls der Sprung doch etwas bricht.

Externe Quellen mit Abrufdatum 12.10.2026:
- GitHub, OpenCode-Releases mit v1.19.0 vom 11.10.2026, 1:39 Uhr UTC (Core: opencode upgrade --major, ultrafast-Tier, PTY-Validierung; TUI: /update, kein Auto-Install; Zen-Dok-Änderungen, Commit 733b2c6): https://github.com/anomalyco/opencode/releases
- GitHub, Hermes Agent v0.21.6 vom 08.10.2026 (Stable-Pipeline, 8.867 Non-Merge-Commits, 8.342 geänderte Dateien, 2.105 PRs im Fenster, 3.027 geschlossene Issues): https://github.com/NousResearch/hermes-agent/releases/tag/v0.21.6
- morphllm, Rangliste der AI Coding Agents mit Terminal-Bench-4.0-Daten (Claude Code plus Opus 5.5 bei 64,8 Prozent, Codex plus GPT-6.1 Sol bei 58,2 Prozent mit 1,92 US-Dollar je Task, 330 Trials; OpenCode mit 199.640 Sternen, API-Verify 21.08.2026): https://www.morphllm.com/ai-coding-agent
Eigene Messwerte über GitHub-Releases und Release-Liste (Scripts radar_1110_fetch.py vom 11.10.2026 und Release-Lektüre vom 12.10.2026): Release-Zeitpunkte von pi v1.1.0 am 07.10., Hermes Agent v0.21.6 am 08.10., Codex-Rust-Tag 0.162.1 am 09.10., OpenCode v1.19.0 am 11.10.2026; sechs Patch-Versionen zwischen v1.18.29 und v1.19.0.
Eigene Messreihe aus dem Vault: 88-Stunden-Lauf vom 28.08.2026 bis 01.09.2026, fünf Gateway-Tode am 28.08.2026, 36 von 36 bestandene Tests der verifizierten Projekte, Request-Fenster von fünf Stunden mit Wochenlimit beim Ollama-Zugang.

Über den Autor: Ich bin Marcel, Grafikdesigner und Betreiber des HUNTER-Cyberdecks auf einem gebrauchten Google Pixel 6a. Für diesen Beitrag habe ich am 12. Oktober 2026 die Release-Seiten von OpenCode, Hermes Agent, pi und Codex gelesen und die Release-Zeitpunkte gegen die eigene Release-Kontrolle vom 11. Oktober 2026 abgeglichen; die Rohnotizen liegen im Themen-Radar des Decks. Eine Installation von OpenCode habe ich nicht vorgenommen, sämtliche Aussagen zur Software stammen aus Release-Notizen und Ranglisten und tragen dort ihr Abrufdatum. Betriebserfahrung mit Update-Verhalten im Agentenbetrieb kommt aus dem eigenen Setup. Zuletzt fachlich geprüft am 12. Oktober 2026.