Planen in ChatGPT Pro, Ausführen in Codex: Das Design-Dokument-Handoff-Playbook

Der Workflow, den man diesen Monat stehlen sollte, ist kein Modell, sondern eine Arbeitsteilung. Sie geben GPT-6 Pro in ChatGPT eine Repository-URL, bitten es um ein Designdokument statt um einen Patch und geben dieses Dokument an Codex oder Claude Code zur Implementierung. Der Planer läuft auf GPT-6 Astra — GPT-6 Pro ist der Name, den die Nutzungsobergrenzen von ChatGPT dafür verwenden — und Astra ist ein Modell vom 2026-09-03, also ist nichts hiervon Launch-Berichterstattung oder eine Release-Behauptung. Was sich in den letzten sieben Tagen geändert hat, ist enger gefasst und verdient eine genaue Formulierung: Am 2026-09-17 berichteten Anwender, dass das offizielle GitHub-Plugin im normalen ChatGPT Chat, nicht ChatGPT Work und nicht Codex, Repository-Dateien bearbeiten, committen und Pull Requests öffnen kann, ohne das Codex/Work-Kontingent zu belasten. Das ist eine Community-Behauptung, keine Herstellerdokumentation — die offiziellen Hilfeseiten beschreiben die GitHub-App weiterhin als schreibgeschützt und leiten alles Schreiben über Codex — und die damit verbundenen Vorbehalte sind ebenso wichtig wie die Behauptung. Alles Folgende ist gekennzeichnet als vom Hersteller berichtet, von der Community berichtet oder am 2026-09-19 aus den offiziellen Seiten abgelesen.

Der Workflow, in einem Durchlauf

Praktiker beschreiben dieselbe Schleife mit kleinen Abweichungen. Die immer wiederkehrende: eine GitHub-Adresse in ChatGPT einfügen, es bitten, den Code zu lesen und ein Design-Dokument zu erstellen, dann dieses Dokument herunterzuladen und einem ausführenden Agenten zuzuführen. Manche bitten zusätzlich um einen Pull Request; andere bleiben beim Dokument stehen und lassen den Executor schreiben. So oder so ist die Form identisch – planen im Chat-Produkt, bauen im Agent-Produkt – und der Grund, warum es sich lohnt, das zu kopieren, ist, dass die beiden Hälften getrennt abgerechnet werden.

• Planungsartefakt — ein Designdokument: die Schnittstellen, die hinzuzufügen sind, die zu berührenden Dateien mit Angabe des Pfads, die Migrationsreihenfolge, die Abnahmetests und was zu tun ist, wenn es schiefgeht.

• Ausführungsartefakt — ein Branch und ein Pull Request, erzeugt von einem Agenten, der die Tests ausführen kann, die er gerade geschrieben hat.

• Review-Artefakt — der Diff, das Einzige, was jemals einen Reviewer erreichen sollte.

Das Designdokument ist das tragende Element, und es verdient seinen Platz aus zwei Gründen. Erstens ist ein Dokument portabel: Derselbe Text funktioniert, egal ob der Ausführende Codex, Claude Code oder ein von Ihnen selbst geschriebener Skript-Agent ist, sodass die Planung, für die Sie bezahlt haben, nicht an das Tool eines einzelnen Anbieters gebunden ist. Zweitens ist es die Prüfoberfläche, die bevor irgendetwas in Ihr Repository geschrieben wird, existiert – was sehr viel ausmacht, wenn man bedenkt, dass der Schreibpfad im Chat-Produkt der am wenigsten dokumentierte Teil der gesamten Anordnung ist.

Warum die Zwei-Bucket-Struktur der ganze Trick ist

ChatGPT rechnet diesen Workflow nicht aus einem einzigen Topf ab. Chat, ChatGPT Work und Codex haben getrennte Kontingente, wobei sich Work und Codex einen gemeinsamen Pool teilen; ein OpenAI-API-Schlüssel wird wieder separat abgerechnet. Diese Struktur macht die Übergabe wirtschaftlich: Das Denken findet im Chat-Topf statt, das Tun im Agenten-Topf, und ein Designdokument kostet eine Chat-Nachricht, während die Implementierung Agenten-Nutzung kostet.

Die Zahlen, wie OpenAI sie für die Chat-Seite veröffentlicht – vom Anbieter gemeldete Angaben aus der eigenen Plan-Dokumentation des Anbieters, keine Messungen:

• ChatGPT Pro für 200 $ pro Monat — 200 GPT-6 Pro-Nachrichten pro Woche; GPT-5.6 Sol Pro bietet zusätzlich 170 pro Tag, wobei beide Modelle zusammen auf 200 pro Tag begrenzt sind.

• ChatGPT Pro für 100 $ im Monat — 50 GPT-6 Pro-Nachrichten pro Woche, aus einem Kontingent, das mit GPT-5.6 Sol Pro geteilt wird.

• Business Standard — 15 GPT-6 Pro-Nachrichten pro Monat, gemeinsam mit Sol Pro; Business Premium — 50 pro Woche auf derselben gemeinsamen Basis.

• ChatGPT Plus — überhaupt kein GPT-6 Pro in Chat. Astra erreicht Plus nur über ChatGPT Work und Codex, und genau das ist der Bereich, den dieses Playbook zu schützen versucht.

Auf der Work/Codex-Seite veröffentlicht OpenAI Schätzungen statt Limits und sagt das auch: ungefähr 5 bis 45 Astra-Nachrichten pro Fünf-Stunden-Fenster bei Plus, 25 bis 225 bei Pro 5x und 100 bis 900 bei Pro 20x, wobei auf derselben Seite angemerkt wird, dass der tatsächliche Verbrauch je nach Aufgabenkomplexität, Kontext, Ausgabe und Tool-Nutzung variiert und dass zusätzlich wöchentliche Limits gelten können. Diese Spannen liegen bei etwa der Hälfte der entsprechenden Sol-Werte, was der arithmetische Grund dafür ist, dass sich ein Frontier-Modell überhaupt als Agent wirtschaftlich betreiben lässt.

Die praktische Konsequenz ist eine Budgetregel, die man auf eine Karte schreiben kann. Verwende Chat-Nachrichten für Entscheidungen und Agent-Nutzung für Code. Eine Planungssitzung, die zwanzig Minuten über eine Schnittstelle diskutiert, kostet eine Handvoll Chat-Nachrichten und erzeugt ein Dokument, das einem Agenten eine Stunde explorativer Bearbeitungen erspart – genau der Tausch, den die Praktiker im Thread tatsächlich eingehen.

Der Schreibpfad: Was der Connector tut – und was ihm nachgesagt wird

Hier widersprechen sich die Quellen, und der Widerspruch ist der interessante Teil.

OpenAIs eigene Hilfedokumentation ist eindeutig: Die GitHub-App in ChatGPT liest Ihre Repositories zur Analyse und Suche, und Codex ist dafür da, Code zu generieren, ihn zu bearbeiten und zu GitHub zu pushen. Das ist die Nur-Lese-Position, und mit ihr sollte man planen, wenn man dies in einen Teamprozess einbindet, denn sie ist diejenige, hinter der ein Anbieter steht.

Die Haltung der Community, mit Datum 2026-09-17, ist, dass das GitHub-Plugin der Webversion im Chat-Modus Code bearbeiten, committen und Pull Requests öffnen wird, und dass es, da es ein offizielles Plugin statt eines MCP-Servers von Drittanbietern ist, kein Codex- oder Work-Kontingent verbraucht. Im selben Thread wird der Umfang sorgfältig abgegrenzt: kleine Tools, kleinere Änderungen, kleine Bugs — große Refactorings und schwieriges Debugging gehören weiterhin in Codex. Die eigenen Kommentierenden ergänzen die Vorbehalte, die es wert sind, wiederholt zu werden, denn sie sind die, die zubeißen:

• Normale ChatGPT-Rate-Limits gelten weiterhin. „Kein Codex-Kontingent“ bedeutet nicht „kostenlos“.

• Die Qualität kann nach mehreren Runden unbemerkt nachlassen, wobei die Sitzung mitten in der Aufgabe auf ein kleineres Modell zurückfällt.

• Die Autoren des Threads raten davon ab, zu Work zu wechseln, wenn die Oberfläche es anbietet, und warnen, dass das übermäßige Beanspruchen anonymer Chatseiten das Web-Erlebnis für alle verschlechtert.

Eine unabhängige japanische Darstellung desselben Musters kommt ohne die Quotenbehauptung zu einem kompatiblen Schluss: Wenn eine GitHub-Integration Schreibaktionen unterstützt, kann einfacher Chat ein Repository lesen, Dateien ändern, einen Branch erstellen und einen Pull Request öffnen; es gelten die üblichen Chat-Rate-Limits; und Codex und Work greifen auf den gemeinsamen Agent-Pool zu, sodass regulärer Chat für das Bearbeiten einiger weniger Dateien und Codex für lange Softwareaufgaben gedacht ist. Wo die beiden Darstellungen übereinstimmen, ist die Übereinstimmung der nutzbare Teil: Chat ist ein Kanal für kleine Änderungen, Codex ist der Kanal für lange Sitzungen, und die Pools sind getrennt.

Es gibt MCP-Server von Drittanbietern, die einen echten Git-Workflow bereitstellen – Branch, Diff, Commit, Push, Pull Request öffnen – mit Berechtigungen, die du von Nur-Lesen bis hin zu Push staffeln kannst. Wenn du möchtest, dass der Schreibpfad deterministisch und auditierbar ist statt ein Verhalten, auf das du hoffst, dann ist das der Weg; wenn du innerhalb dessen bleiben möchtest, was OpenAI dokumentiert, plane in Chat und schreibe in Codex.

So oder so ist es die Übergabe des Design-Dokuments, die den Schreibpfad des Chats verteidigbar macht. Eine Chat-Sitzung mit Schreibberechtigung für ein Repository ist eine umfangreichere Berechtigungserteilung als eine Chat-Sitzung mit Leseberechtigung, und das Dokument ist das Artefakt, das Sie prüfen, bevor diese Berechtigung ausgeübt wird.

Die Übergabe, Schritt für Schritt

Richten Sie den Planer auf das Repository aus – eine öffentliche URL, die in den Prompt eingefügt wird, oder den GitHub-Connector, wenn Sie ihn autorisiert haben – und bitten Sie ihn, den Code zu lesen, bevor er etwas vorschlägt.

• Bitten Sie um ein Designdokument, nicht um einen Patch. Verlangen Sie Dateipfade, die hinzugefügten oder geänderten Schnittstellen, die Reihenfolge, in der die Änderungen landen müssen, und die Tests, die jeden Schritt belegen.

• Bitten Sie es, die Dateien zu zitieren, die es tatsächlich gelesen hat. Ein Designdokument, das eine Schnittstelle beschreibt, die das Repository nicht hat, ist die häufigste Art, wie dieser Workflow fehlschlägt, und die Zitate sind der Weg, wie Sie es in einer Minute statt in einem Sprint erkennen.

• Speichern Sie das Dokument im Repository, anstatt es in das nächste Tool einzufügen. Ein Executor, der eine Datei liest, kann sie erneut lesen; ein Executor, der ein Einfügen erhalten hat, hat nur einen Versuch.

• Starte den Executor mit dem Dokument als seiner Anweisung und begrenze einen Pull Request auf einen Abschnitt davon. Lange Sitzungen sind der Ort, an dem die Qualität des Agenten leise verfällt.

• Behalte den Planer danach in einer reinen Prüfrolle. Wenn das Dokument falsch ist, plane erneut und aktualisiere das Dokument – lass den Ausführenden nicht daran vorbei improvisieren, denn improvisierte Arbeit ist genau das, was das Dokument verhindern sollte.

Wo es bricht

• Veralteter Repository-Status — der Planner hat den Standard-Branch gelesen, während du an einem Feature-Branch arbeitest, daher hinken die Dateipfade im Dokument eine Version hinterher. Sag, welcher Branch gelesen werden soll, oder füge den Branch-Baum ein.

• Design-Dokument-Drift — das Dokument und der Code stimmen nicht überein, und der Executor folgt dem Dokument. Der obige Schritt mit den zitierten Dateien ist die kostengünstige Absicherung.

• Kontingent-Überraschung in die falsche Richtung – ein zwanzigminütiges Planungsgespräch ist bei Chat-Nachrichten günstig und bei Aufmerksamkeit teuer; ein langer Agentenlauf ist das Gegenteil. Budgetiere den Topf, den du tatsächlich verbrauchst.

• Stiller Downgrade – eine Chat-Sitzung, die nach mehreren Runden auf ein kleineres Modell herabgestuft wird, erzeugt trotzdem ein selbstsicheres Designdokument. Bewerten Sie das Dokument nach seinem eigenen Wert, nicht nach der Annahme, dass das Flaggschiff es geschrieben hat.

• Berechtigungsausweitung – der Schreibpfad, ob über ein Plugin oder einen MCP-Server, gibt einer Chat-Sitzung die Möglichkeit, Ihren Code zu ändern. Staffeln Sie die Berechtigungen und entziehen Sie sie, sobald die Änderung übernommen wurde.

Ausführen der Executor-Hälfte über einen Endpunkt

Die Planungshälfte dieses Workflows steckt in einem Abonnementprodukt, und dieser Teil ist eben, wie er ist. Die ausführende Hälfte ist ein API-Aufruf, und das ist die Hälfte, die es lohnt, selbst zu besitzen. Wenn du den Executor scriptest – eine kleine Agent-Schleife, ein CI-Job, der ein freigegebenes Design-Dokument in einen Branch umwandelt –, ist der Modellaufruf der einzige Bestandteil, der austauschbar sein muss, denn das Modell, das du nächstes Quartal willst, ist nicht das Modell, mit dem du heute planst.

Dafür ist eine Routing-Schicht da. openai/gpt-6-astra liegt hinter demselben OpenAI-kompatiblen Endpunkt wie über 200 weitere Modelle, wobei der Listenpreis des Anbieters mit 0 % Aufschlag durchgereicht wird – wenn ein Anbieter also einen Preis ändert, ändert sich der Preis auf unserer Seite noch am selben Tag und nicht erst bei der nächsten Vertragsverlängerung. Automatisches Failover ermöglicht es Ihnen, ein unerprobtes Modell auf einen Teil des Traffics zu setzen und ein erprobtes darunter – das ist der ehrliche Weg herauszufinden, ob ein günstiger Executor für Ihre Tests gut genug ist. Und die Routing-DSL kombiniert mehrere Modelle zu einem einzigen Aufruf, sodass ein Reviewer-Modell den Diff des Executors mit demselben Schlüssel und im selben Request-Pfad prüfen kann, ohne eine zweite Integration.

Nichts davon ändert die Struktur der Übergabe. Es ändert die Kosten des Experimentierens mit der Hälfte, die Sie kontrollieren: ein Schlüssel, ein Endpunkt und ein Modell-String, den Sie ändern können, ohne die Pipeline anzufassen.

Wer sollte das jetzt ausführen, und wer sollte warten

Wenn Sie bereits für ein ChatGPT-Abo der Pro-Stufe bezahlen und bereits Codex oder Claude Code nutzen, lohnt es sich, die Übergabe diese Woche einzuführen, denn die beiden Posten sind auf Ihrer Rechnung bereits getrennt und das Designdokument ist das günstigste Element im Kreislauf. Beginnen Sie mit einer Änderung, die Sie gut genug verstehen, um einen schlechten Plan zu erkennen: Fordern Sie das Dokument an, lesen Sie die zitierten Dateien und übergeben Sie es dann.

Wenn du Plus hast, dämpfe die Erwartung. Astra erreicht dich über Work und Codex, aber nicht über Chat, also steht dir die Planungshälfte dieses Playbooks nicht in der beschriebenen Form zur Verfügung – du würdest aus demselben Pool planen und ausführen, was das wirtschaftliche Argument beseitigt und nur die Disziplin übrig lässt, das Dokument zuerst zu schreiben. Diese Disziplin lohnt sich trotzdem. Der Rabatt nicht.

Und wenn dein Grund dafür, das zu wollen, der Schreibpfad in Chat und nicht die Übergabe ist, dann warte, bis die Dokumentation von OpenAI mit dem Forum-Thread gleichgezogen ist. Eine Fähigkeit, der die eigenen Hilfeseiten des Anbieters widersprechen, sollte man in einem Scratch-Repository behalten, bis sich die Seiten ändern.

Derselbe Schlüssel erreicht den Rest des Katalogs, und du kannst den vollständigen Modellkatalog durchsuchen, um zu sehen, was sonst noch hinter einem OpenAI-kompatiblen Endpunkt steckt.