Fünf-Sekunden-Fazit: Dasselbe Modell kann sehr unterschiedlich viel Kontingent verbrauchen, je nachdem, welcher Kontext bei jedem Schritt übertragen wird, wie oft das Modell aufgerufen wird, wie viel Tool-Ausgabe erhalten bleibt, wann komprimiert wird und wie Retries laufen. Ist das Modell der Motor, dann ist das Harness Getriebe, Einspritzung, Navigation und Boxencrew zugleich.
1. „Dasselbe Fünf-Stunden-Fenster, aber doppelt so viel Arbeit“ ist eine Beobachtung, kein offizieller Benchmark
Ein Entwickler berichtete in sozialen Medien, dass er nach dem Wechsel von Codex zu OpenCode weiterhin GPT-5.6 Sol über ChatGPT-Authentifizierung nutzte, innerhalb derselben Fünf-Stunden- und Wochenlimits aber gefühlt mehr als doppelt so viel erledigen konnte.
In den Antworten wurden ein anderes Harness namens pi, mögliche Unterschiede bei Kontextlimits sowie Routing und Telemetrie zur Messung des realen Verbrauchs erwähnt.
Die wichtige Grenze lautet: Es gibt keine offizielle Garantie, dass OpenCode das verfügbare Kontingent verdoppelt.
OpenAI dokumentiert dagegen, dass Codex-Nutzung keine feste Nachrichtenanzahl ist. Der Verbrauch hängt unter anderem von Modell, Ausführungsort, Aufgabenkomplexität, Kontext, Reasoning, Geschwindigkeit und Tools ab. Bei manchen Tarifen existieren sowohl Fünf-Stunden- als auch Wochenfenster.
Dass ein Harness-Wechsel die Effizienz verändert, ist also technisch plausibel. Der genaue Faktor zwei ist nicht bewiesen.
2. Was ist ein Harness? Alles rund um das Gehirn
Das Modell allein ist einfach:
Sol = Gehirn.
Ein Coding-Agent muss jedoch zusätzlich entscheiden:
- wie Systemanweisungen aufgebaut werden
- welche Dateien gelesen werden
- wie viel Verlauf erhalten bleibt
- welche Tool-Schemas sichtbar sind
- wie viel Shell-/GitHub-Ausgabe in den nächsten Schritt gelangt
- wie viele Retries stattfinden
- wie viele Plan-, Implementierungs- und Review-Schleifen laufen
- wann Context-Compaction erfolgt
- ob Subagents eingesetzt werden
- wie „fertig“ definiert wird
Diese gesamte Betriebsumgebung ist im weiten Sinn das Harness.
OpenAI selbst verwendet den Ausdruck „Codex harness“ und beschreibt einen App Server, der Modellgespräche, Clients und Tools verbindet.
Daher gilt:
Dasselbe Modell bedeutet nicht dasselbe System.
Derselbe Motor in Fahrzeugen mit unterschiedlichem Gewicht und Getriebe hat nicht denselben Verbrauch.
3. Der Verbrauch entsteht häufig durch das Gepäck, das bei jeder Fahrt mitkommt
Eine lange Session kann bei jedem Modellaufruf erneut mitschleppen:
- langen Gesprächsverlauf
- großen System-Prompt
- Projektregeln
- MCP-Tool-Schemas
- Repository-Dateien
- Terminal-Logs
- Testergebnisse
- frühere Fehler
- Retry-State
Ein großes Log einmal zu lesen ist nicht zwangsläufig das größte Problem.
Teuer wird es, wenn ein großer aktiver Kontext 10, 20 oder 30 Modellaufrufe begleitet.
Auch die Orchestrierung zählt. Wenn Harness A in 15 Calls fertig wird, Harness B aber wegen Planung, erneuter Suche, Review und Re-Review 30 Calls benötigt, kann dasselbe Modell insgesamt sehr unterschiedlich verbrauchen.
Als Denkmodell:
Verbrauch ≈ Gepäck × Fahrten × Retries
Keine Abrechnungsformel, aber eine nützliche technische Intuition.
4. Warum OpenCode interessant ist: ChatGPT-Authentifizierung, MCP und Compaction
Laut OpenCode-Dokumentation kann OpenAI über die Option ChatGPT Plus/Pro verbunden und im Browser authentifiziert werden. Das ist ein separater Weg neben der manuellen API-Key-Eingabe.
OpenCode fungiert außerdem als MCP-Client für lokale und entfernte MCP-Server.
Zum Beispiel:
OpenCode → GitHub MCP → Datenbank-MCP → eigene API → weitere Tools
OpenCode bietet auch automatische Compaction. Die aktuelle Dokumentation zeigt sie standardmäßig aktiviert und ein Beispiel, bei dem ein generierter Checkpoint plus ungefähr 15.000 aktuelle Tokens erhalten bleiben.
Die Idee:
Das Archiv bleibt im Lager, aber das gesamte Lager fährt nicht bei jeder Anfrage mit.
OpenCode warnt allerdings selbst, dass MCP-Server Kontext hinzufügen. Große Tool-Sammlungen wie GitHub MCP können viele Tokens verbrauchen.
Zwanzig MCPs anzuschließen macht einen Agenten nicht automatisch stärker.
Manchmal trägt der Held einfach das Lager auf dem Rücken.
5. Alles von ChatGPT über MCP zu steuern ist im Kern dieselbe Architektur
Wenn ChatGPT die zentrale Steuerung ist und MCP/Connectors GitHub, Server, Cloud und Storage bedienen, lautet das Grundmuster weiterhin:
Modell + Harness + Tools.
ChatGPT → MCP / Connector → GitHub, Server, Cloud, Storage
ChatGPT trifft mehrdeutige Entscheidungen, MCP liefert die Hände und externe Systeme halten den realen State.
OpenCode folgt demselben Muster:
OpenCode → MCP / Shell / API → Repository, Server, Cloud
Der Unterschied liegt darin, wo Conversation State liegt, wo der Tool-Loop läuft, wann Kontext komprimiert wird und wie Completion geprüft wird.
Auf die Frage „Ist das nicht im Grunde dasselbe wie alles aus ChatGPT über MCP zu steuern?“ lautet die architektonische Antwort:
Ja, sehr ähnlich.
Dasselbe Gebäude, anderer Kontrollraum.
6. Kann ChatGPT Arbeit an OpenCode delegieren?
OpenCode dokumentiert klar die Nutzung als MCP-Client. Zusätzlich gibt es opencode serve als headless HTTP/OpenAPI-Server sowie SDK und ACP.
Eine saubere Architektur wäre:
ChatGPT → dünne MCP-Bridge → OpenCode Server → Sol → MCP / Shell / API → GitHub und Cloud
Die Bridge muss nur wenige Werkzeuge auf hoher Ebene anbieten:
- OpenCode-Task starten
- Status abfragen
- Endergebnis holen
Dann muss ChatGPT nicht bei jedem Schritt Dutzende GitHub-Schemas und riesige Logs mitführen. Der lange Ausführungsloop bleibt bei OpenCode, nur das Ergebnis kommt zurück.
Der Punkt ist nicht bloß, eine weitere App einzusetzen.
Man verschiebt die Grenze des Agent-Loops.
7. Wer Verbrauch reduzieren will, sollte weniger oft zur KI zurückkehren
Ein effizientes Design:
- deterministische Schritte in Scripts verlagern
- State und Receipts außerhalb des Chats speichern
- nur notwendige Tools aktivieren
- große Logs vorab extrahieren und verdichten
- unveränderte Dateien nicht neu lesen
- Fehlerursache und Next Action speichern
- leistungsstarke Modelle nur bei Mehrdeutigkeit aufrufen
- am Ende den Production-Readback zurückgeben
Die Rollen werden klar:
KI = Mehrdeutigkeit
Scripts/Workflows = deterministische Ausführung
GitHub/DB/State = Gedächtnis
Wenn die KI in jeder Runde neu herausfinden muss, „was kommt als Nächstes?“, bezahlt man immer wieder für eine vollständige Lagerinventur.
8. Was noch nicht bewiesen ist
OpenAI dokumentiert, dass Work und Codex ein gemeinsames Nutzungskontingent haben und der Verbrauch unter anderem mit Kontext und Tools variiert. Für passende Pläne existieren Fünf-Stunden- und Wochenfenster.
OpenCode dokumentiert die ChatGPT-Plus/Pro-Authentifizierung.
Die zitierten offiziellen Quellen enthalten jedoch keine universelle Regel, nach der OpenCode über ChatGPT OAuth intern exakt gleich wie Codex gemessen wird, und keine Garantie für einen festen Effizienzmultiplikator.
Daher:
„Bei mir war es doppelt so effizient“ ist eine interessante Messung.
„Es ist immer doppelt so effizient“ ist nicht belegt.
Ein sinnvoller Benchmark hält Repository, Modell, Aufgabe und Abschlusskriterien konstant und misst Modellaufrufe, Tokens, Compactions, Tool Calls, Retries, Laufzeit und finale Tests.
Die bessere Einheit ist Verbrauch pro erfolgreich abgeschlossener Aufgabe.
9. Fazit: Im Agenten-Zeitalter ist die Verdrahtung fast so wichtig wie der Motor
Die Modellwahl bleibt wichtig.
Doch bei langen Aufgaben mit Tools bestimmen auch Kontextverwaltung, State, Tool-Anzahl, Retries, Compaction und Completion-Logik die tatsächliche Produktivität.
Das Modell ist der Motor.
Das Harness ist der Rest des Fahrzeugs.
Sobald mehrere Systeme über MCP verbunden werden, nutzt man nicht mehr nur KI.
Man entwirft den Arbeitsplatz der KI.
Und eine der besten Optimierungen besteht manchmal darin, einen Arbeitsschritt so mechanisch zu machen, dass dafür überhaupt kein weiterer KI-Aufruf nötig ist.
Quellen
[1] https://openai.com/index/unlocking-the-codex-harness/ [2] https://help.openai.com/ja-jp/articles/11369540 [3] https://help.openai.com/ja-jp/articles/20001516-managing-usage-with-gpt-6-astra-in-work-and-codex [4] https://opencode.ai/docs/providers [5] https://opencode.ai/v2/docs/mcp-servers [6] https://opencode.ai/v2/docs/compaction [7] https://dev.opencode.ai/docs/server/ https://dev.opencode.ai/docs/ja/sdk/ [8] https://opencode.ai/v2/docs/cli/acp/
Quellen
- OpenAI, Unlocking the Codex harness: how we built the App Server openai.com
- OpenAI Help Center, ChatGPTプランでCodexを使う help.openai.com
- OpenAI Help Center, WorkとCodexでのGPT-6 Astraの利用量管理 help.openai.com
- OpenCode Docs, Providers opencode.ai
- OpenCode Docs, MCP servers opencode.ai
- OpenCode Docs, Compaction opencode.ai
- https://dev.opencode.ai/docs/ja/sdk/ dev.opencode.ai
- OpenCode Docs, ACP opencode.ai
