Programmieragenten können zunehmend ein Ziel verfolgen, ohne nach jedem Schritt auf eine neue Anweisung zu warten. Mit /goal in OpenCode 2.2.1 bieten OpenCode, Codex CLI und Claude Code nun vergleichbare Ansätze.
Hinter dem gemeinsamen Befehl stehen unterschiedliche Mechanismen. Wer entscheidet, wann eine Aufgabe abgeschlossen ist? Welche Grenzen verhindern Endlosschleifen? Und wie lassen sich die Kosten autonomer Arbeit kontrollieren?
Von einer einzelnen Anweisung zu einem dauerhaften Ziel
Ein Agent kann ein Repository untersuchen, Dateien ändern, Befehle ausführen und Fehler beheben. Das Ende eines Gesprächsschritts bedeutet aber nicht unbedingt, dass die Arbeit erledigt ist. Bei einer API-Migration können beispielsweise noch Tests fehlschlagen, Lint-Fehler bestehen und Aufrufe der alten API vorhanden sein.
Ein Goal legt eine Erfolgsbedingung fest, die über mehrere Schritte aktiv bleibt. Der Agent kann arbeiten, Ergebnisse prüfen, Probleme korrigieren und fortfahren, solange der Kontrollmechanismus weiteren Bedarf erkennt. Das ist eine an einem messbaren Ziel ausgerichtete Arbeitsschleife, keine Garantie für fehlerfreie autonome Arbeit.
So funktioniert /goal in OpenCode 2.2.1
Die am 29. Oktober 2026 veröffentlichte Version 2.2.1 führt /goal in der Terminaloberfläche (TUI) und in Desktop ein:
/goal TypeScript-Fehler beheben, alle Tests bestehen
und einen erfolgreichen Build erreichen.
OpenCode speichert das Ziel in der Sitzung. Wenn ein Schritt regulär endet und die Sitzung inaktiv werden würde, prüft ein Mechanismus den Fortschritt und kann eine Fortsetzung auslösen.
| Befehl | Funktion |
|---|---|
/goal <Ziel> | Ziel setzen |
/goal | Status anzeigen |
/goal pause | Ausführung pausieren |
/goal resume | Ziel fortsetzen |
/goal clear | Ziel entfernen |
Das eingebaute Plugin verwendet einen experimentellen Hook vor dem Inaktivwerden der Sitzung. In der ersten Implementierung nutzt die Prüfung das Modell und den Verlauf der Sitzung und verbraucht zusätzliche Modellressourcen. Die Implementierung pausiert unter anderem nach drei Runden ohne Fortschritt oder nach 50 Runden. Diese Schutzmechanismen sind keine Token- oder Ausgabengrenze.
Einschränkung: Die erste Version unterstützt TUI und Desktop. In opencode run steht /goal nicht als Slash-Befehl zur Verfügung.
Codex: ein überprüfbarer Auftrag
Goals sind in Codex ab Version 0.128.0 verfügbar. Ein dauerhaftes Ziel ist mit dem Arbeits-Thread verbunden und kann Ergebnis, Erfolgsnachweise, Einschränkungen, erlaubte Ressourcen sowie Bedingungen für einen Stopp oder menschliches Eingreifen beschreiben.
Codex kann verfügbare Nachweise wie geänderte Dateien, Testergebnisse, Protokolle oder Benchmarks prüfen. Es unterscheidet zwischen einem erreichten Ziel, einer Blockade und einem ausgeschöpften Budget: Das Erreichen einer Ressourcengrenze bedeutet nicht, dass die Aufgabe abgeschlossen ist.
Claude Code: ein separates Bewertungsmodell
In Claude Code basiert /goal auf einem sitzungsbezogenen Stop Hook. Nach jedem Schritt bewertet ein separates kleines, schnelles Modell die Bedingung anhand des Gesprächsverlaufs. Es kann das Ziel als erreicht, noch nicht erreicht oder unmöglich beurteilen; bei verbleibender Arbeit kann die Sitzung fortgesetzt werden.
Ein kleineres Bewertungsmodell kann günstiger sein als wiederholte Aufrufe des Hauptmodells. Die tatsächlichen Kosten hängen vom Anbieter und der Aufgabe ab. Das Bewertungsmodell führt selbst keine Befehle aus und liest keine Dateien: Es beurteilt nur, was der Hauptagent im Gespräch gezeigt hat. Eine separate Bewertung ersetzt daher keine unabhängige technische Prüfung.
Die wichtigsten Unterschiede
| Kriterium | OpenCode | Codex | Claude Code |
|---|---|---|---|
| Automatische Fortsetzung | Ja | Ja | Ja |
| Mechanismus | Eingebautes Plugin und Idle Hook | Persistenter Thread-Zustand und kontrollierte Fortsetzung | Sitzungsbezogener Stop Hook mit Bewertungsmodell |
| Bewertung | In der ersten Version durch das Modell der Sitzung | Evidenzbasierte Prüfung im Thread | Separates schnelles Modell |
| Budgetkontrolle | In der ersten Version kein eigenes Token-Limit; Schutz vor zu vielen oder stagnierenden Runden | Token-Erfassung und optionales Budget | Token-Anzeige und definierbare Stoppbedingungen |
| Nichtinteraktive Ausführung | In der ersten Version nicht über opencode run | Je nach unterstützter Oberfläche und Workflow | Mit claude -p unterstützt |
Keiner dieser Ansätze garantiert für sich allein die Qualität des erzeugten Codes.
Wer entscheidet, dass die Arbeit abgeschlossen ist?
Bei /goal Alle fehlschlagenden Tests korrigieren könnte ein Agent die Implementierung reparieren. Er könnte aber auch einen schwierigen Test entfernen, eine Assertion abschwächen oder eine Prüfung umgehen. In beiden Fällen könnte die Testsuite grün erscheinen.
Ein besseres Ziel beschreibt sowohl das Ergebnis als auch die Bedingungen für seine Akzeptanz:
/goal Das Authentifizierungsmodul auf die neue Client-API migrieren.
Erfolgskriterien:
- Alle Authentifizierungstests bestehen.
- Lint und Build bestehen.
- Keine Aufrufe der alten API bleiben übrig.
- Kein Test wird entfernt oder abgeschwächt.
- Öffentliche Schnittstellen bleiben kompatibel.
Den endgültigen Diff prüfen. Falls ein Kriterium nicht
erfüllt werden kann, die Blockade erklären und stoppen.
Das schafft eine bessere Grundlage für die Bewertung, beseitigt aber nicht jedes Risiko.
Autonomie vervielfacht auch die Modellaufrufe
Jede Runde kann Gesprächskontext, Befehlsausgaben und zusätzliche Tokens enthalten. Die Gesamtkosten hängen nicht nur vom Modellpreis ab, sondern auch von der Anzahl der Iterationen, der Kontextgröße und der Bewertungsmethode.
OpenCode verwendet in der ersten Version das Sitzungsmodell für die Prüfung, Claude Code ein konfiguriertes kleineres Modell, und Codex unterstützt Token-Erfassung und Budgets für Goals. Schlecht definierte Ziele können dennoch bei allen zu unproduktiven Versuchen führen. Ein länger arbeitender Agent ist nicht automatisch effizienter.
Ein aussagekräftiger Vergleich müsste Erfolgsquoten, Regressionen, Iterationen und Tokenverbrauch bei denselben Aufgaben messen. Allein das Vorhandensein von /goal zeigt nicht, welches Werkzeug besser ist.
Und mit RouterLab?
RouterLab bietet eine OpenAI-kompatible API und eine zentrale Übersicht über Modellnutzung und Guthaben. Das Open-Source-Projekt wrapper-scionos dokumentiert die Verbindung von Claude Code, Codex CLI und OpenCode mit kompatiblen RouterLab-Modellen. OpenCode unterstützt außerdem benutzerdefinierte Anbieter mit OpenAI-kompatiblen APIs.
Die Verbindung eines Modells ist von der Unterstützung einer neuen Client-Funktion zu unterscheiden. /goal sollte mit der genauen OpenCode-Version, dem gewählten Modell und der verwendeten Transportkonfiguration geprüft werden. Die Guthabenübersicht macht den Verbrauch sichtbar, ersetzt aber keine für die autonome Aufgabe konfigurierte Ausführungs- oder Ausgabengrenze.
Ein Fortschritt, noch kein Autopilot
Persistente Ziele erlauben es, ein Ergebnis, Einschränkungen und Prüfkriterien vorzugeben, während der Agent die Zwischenschritte wählt. Der Entwickler bleibt für den Umfang und die Prüfung der Nachweise verantwortlich.
Der praktische Fortschritt liegt in Workflows mit einem klaren Ziel, einer Prüfmethode, einem Budget und einer Stoppbedingung. Ein Vergleich der Werkzeuge erfordert messbare Ergebnisse, Eingriffe, Regressionen und Ressourcen bei vergleichbaren Aufgaben.
Quellen und Referenzen
Testen Sie die RouterLab-API
Gehen Sie von einem Artikel zu einer tatsächlichen Abfrage über: Erstellen Sie eine Testversion, rufen Sie einen Schlüssel ab und rufen Sie Modelle über eine OpenAI-kompatible API auf.