Plan in ChatGPT Pro, voer uit in Codex: Het draaiboek voor de overdracht van ontwerpdocumenten

De workflow die het deze maand waard is om te stelen is geen model, maar een arbeidsverdeling. Je geeft GPT-6 Pro in ChatGPT een repository-URL, vraagt om een ontwerpdocument in plaats van een patch, en geeft dat document aan Codex of Claude Code om het te implementeren. De planner draait op GPT-6 Astra — GPT-6 Pro is de naam die de gebruikslimieten van ChatGPT ervoor gebruiken — en Astra is een model van 2026-09-03, dus niets hier is lanceringsdekking of een releaseclaim. Wat er in de afgelopen zeven dagen is veranderd, is beperkter, en de moeite waard om precies te benoemen: op 2026-09-17 meldden mensen uit de praktijk dat de officiële GitHub-plugin in gewone ChatGPT Chat, niet ChatGPT Work en niet Codex, repositorybestanden kan bewerken, kan committen en pull requests kan openen zonder een beroep te doen op de Codex/Work-limiet. Dat is een claim uit de community, geen leveranciersdocumentatie — de officiële help-pagina's beschrijven de GitHub-app nog steeds als alleen-lezen en leiden al het schrijven via Codex — en de kanttekeningen erbij zijn net zo belangrijk als de claim. Alles hieronder is gelabeld als door de leverancier gemeld, door de community gemeld, of overgenomen uit de officiële pagina's op 2026-09-19.

De workflow, in één keer

Praktijkmensen beschrijven dezelfde lus met kleine variaties. Degene die steeds terugkomt: plak een GitHub-adres in ChatGPT, vraag het om de code te lezen en een ontwerpdocument te maken, download dat document vervolgens en voer het aan een uitvoerende agent. Sommigen vragen ook om een pull request; anderen stoppen bij het document en laten de uitvoerder het schrijfwerk doen. Hoe dan ook is de vorm identiek — plannen in het chatproduct, bouwen in het agentproduct — en de reden dat het de moeite waard is om te kopiëren, is dat de twee helften afzonderlijk worden gemeten.

• Planningsartefact — een ontwerpdocument: de toe te voegen interfaces, de aan te passen bestanden met hun pad erbij, de migratievolgorde, de acceptatietests, en wat te doen als het misgaat.

• Uitvoeringsartefact — een branch en een pull request, geproduceerd door een agent die de zojuist geschreven tests kan uitvoeren.

• Reviewartefact — de diff, het enige dat een reviewer ooit zou mogen bereiken.

Het ontwerpdocument is het dragende onderdeel, en het verdient zijn plaats om twee redenen. Ten eerste is een document overdraagbaar: dezelfde tekst werkt of de uitvoerder nu Codex, Claude Code of een door jouzelf geschreven gescripte agent is, zodat de planning waarvoor je hebt betaald niet aan de tool van één leverancier gebonden is. Ten tweede is het het beoordelingsoppervlak dat bestaat voordat er iets naar je repository wordt geschreven — wat van groot belang is, aangezien het schrijfpad in het chatproduct het minst gedocumenteerde onderdeel van de hele opzet is.

Waarom de structuur met twee buckets de hele truc is

ChatGPT factureert deze workflow niet uit één pot. Chat, ChatGPT Work en Codex hebben afzonderlijke tegoeden, waarbij Work en Codex samen één enkele pool delen; een OpenAI API-sleutel valt weer onder een aparte facturering. Die structuur maakt de overdracht juist voordelig: het denkwerk gebeurt in de Chat-bucket, het uitvoeren gebeurt in de agent-bucket, en een ontwerpdocument kost één Chat-bericht terwijl de implementatie agent-gebruik kost.

De cijfers, zoals OpenAI ze voor de Chat-kant publiceert — door de leverancier gerapporteerde cijfers in de eigen plandocumentatie van de leverancier, geen metingen:

• ChatGPT Pro voor $200 per maand — 200 GPT-6 Pro-berichten per week; GPT-5.6 Sol Pro biedt daarnaast 170 berichten per dag, waarbij beide modellen samen een maximum van 200 per dag hebben.

• ChatGPT Pro voor $100 per maand — 50 GPT-6 Pro-berichten per week, afkomstig uit een tegoed dat wordt gedeeld met GPT-5.6 Sol Pro.

• Business Standard — 15 GPT-6 Pro-berichten per maand, gedeeld met Sol Pro; Business Premium — 50 per week op dezelfde gedeelde basis.

• ChatGPT Plus — helemaal geen GPT-6 Pro in Chat. Astra bereikt Plus alleen via ChatGPT Work en Codex, precies de categorie die dit draaiboek probeert te beschermen.

Aan de Work/Codex-kant publiceert OpenAI schattingen in plaats van limieten, en zegt dat ook: ruwweg 5 tot 45 Astra-berichten per venster van vijf uur op Plus, 25 tot 225 op Pro 5x, en 100 tot 900 op Pro 20x, waarbij dezelfde pagina opmerkt dat het werkelijke verbruik varieert met taakcomplexiteit, context, output en toolgebruik, en dat er daarnaast wekelijkse limieten kunnen gelden. Die bandbreedtes liggen op ongeveer de helft van de overeenkomstige Sol-getallen, wat de rekenkundige reden is dat een frontiermodel überhaupt betaalbaar is om als agent te draaien.

De praktische consequentie is een budgetregel die je op een kaartje kunt schrijven. Besteed Chat-berichten aan beslissingen en agentgebruik aan code. Een planningssessie waarin twintig minuten wordt gediscussieerd over een interface kost een handvol Chat-berichten en levert een document op dat een agent een uur aan verkennende bewerkingen bespaart — wat de afweging is die de professionals in de thread daadwerkelijk maken.

Het schrijfpad: wat de connector doet, en wat mensen beweren dat hij doet

Hier zijn de bronnen het oneens, en juist dat meningsverschil is het interessante deel.

OpenAI's eigen helpdocumentatie is ondubbelzinnig: de GitHub-app in ChatGPT leest je repositories voor analyse en zoeken, en code genereren, bewerken en naar GitHub pushen is waar Codex voor bedoeld is. Dat is de alleen-lezenpositie, en dat is degene waarop je moet plannen als je dit in een teamp proces onderbrengt, want het is degene met een leverancier erachter.

Het standpunt van de community, gedateerd op 2026-09-17, is dat de GitHub-plugin van de webversie in Chat-modus code bewerkt, commits maakt en pull requests opent, en dat deze, omdat het een officiële plugin is en geen MCP-server van een derde partij, geen Codex- of Work-quota verbruikt. Dezelfde thread is voorzichtig met de scope: kleine tools, kleine aanpassingen, kleine bugs — grote refactors en lastige debugging horen nog steeds thuis in Codex. De eigen commentatoren voegen de kanttekeningen toe die het herhalen waard zijn, want dat zijn de punten die bijten:

Normale ChatGPT-snelheidslimieten blijven van toepassing. "Geen Codex-quotum" is niet "gratis".

• De kwaliteit kan na meerdere rondes zonder waarschuwing afnemen, waarbij de sessie midden in een taak overschakelt naar een kleiner model.

• De auteurs van de thread adviseren om niet over te schakelen naar Work wanneer de interface dat aanbiedt, en waarschuwen dat het hameren op anonieme chatpagina’s de webervaring voor iedereen verslechtert.

Een onafhankelijke Japanse uiteenzetting van hetzelfde patroon komt tot een compatibele conclusie zonder de quotumclaim: als een GitHub-integratie schrijfacties ondersteunt, kan gewone chat een repository lezen, bestanden wijzigen, een branch aanmaken en een pull request openen; de gebruikelijke chat-rate-limieten gelden; en Codex en Work putten uit de gedeelde agentpool, dus gewone chat is voor het bewerken van een paar bestanden en Codex is voor langdurige softwaretaken. Waar de twee verslagen overeenkomen, is de overeenstemming het bruikbare deel: chat is een kanaal voor kleine wijzigingen, Codex is het kanaal voor lange sessies, en de pools zijn gescheiden.

Er bestaan MCP-servers van derden die een echte git-workflow beschikbaar stellen — branch, diff, commit, push, een pull request openen — met machtigingen die je kunt indelen van alleen-lezen tot push. Als je wilt dat het schrijfpad deterministisch en auditeerbaar is in plaats van een gedrag waarop je hoopt, dan is dat de route; als je wilt blijven binnen wat OpenAI documenteert, plan dan in Chat en schrijf in Codex.

Hoe dan ook, de overdracht van het ontwerpdocument is wat het schrijfpad van de chat verdedigbaar maakt. Een chatsessie met schrijfrechten op een repository is een grotere machtiging dan een chatsessie met leesrechten, en het document is het artefact dat je beoordeelt voordat die machtiging wordt uitgeoefend.

De overdracht, stap voor stap

• Richt de planner op de repository — een openbare URL die in de prompt wordt geplakt, of de GitHub-connector als je die hebt geautoriseerd — en vraag hem de code te lezen voordat hij iets voorstelt.

• Vraag om een ontwerpdocument, niet om een patch. Eis bestandspaden, de interfaces die worden toegevoegd of gewijzigd, de volgorde waarin de wijzigingen moeten landen, en de tests die elke stap bewijzen.

• Vraag het de bestanden te citeren die het daadwerkelijk heeft gelezen. Een ontwerpdocument dat een interface beschrijft die de repository niet heeft, is de meest voorkomende manier waarop deze workflow mislukt, en de citaten zijn hoe je het binnen een minuut betrapt in plaats van een sprint.

• Sla het document op in de repository in plaats van het in de volgende tool te plakken. Een uitvoerder die een bestand leest, kan het opnieuw lezen; een uitvoerder die een geplakte tekst heeft ontvangen, heeft er maar één kans op.

• Start de executor met het document als instructie, en beperk één pull request tot één sectie ervan. Het is in lange sessies dat de kwaliteit van de agent stilletjes afneemt.

• Houd de planner daarna uitsluitend in een controlerende rol. Wanneer het document onjuist is, herplan en werk het document bij — laat de uitvoerder niet buiten het document om improviseren, want geïmproviseerd werk is precies wat het document bestond om te voorkomen.

Waar het breekt

• Verouderde repositorystatus — de planner heeft de standaardbranch gelezen terwijl je aan een featurebranch werkt, dus de bestandspaden in het document lopen een versie achter. Geef aan welke branch gelezen moet worden, of plak de branchstructuur.

• Ontwerpdocument-afwijking — het document en de code lopen uiteen, en de uitvoerder volgt het document. De stap met de geciteerde bestanden hierboven is de goedkope verzekering.

• Quota-verrassing in de verkeerde richting — een planningsgesprek van twintig minuten is goedkoop in Chat-berichten en duur in aandacht; een lange agent-run is het omgekeerde. Budgetteer de bucket waarin je daadwerkelijk uitgeeft.

• Stille downgrade — een chatsessie die na meerdere rondes terugvalt naar een kleiner model, zal nog steeds een zelfverzekerd ontwerpdocument opleveren. Beoordeel het document op zijn eigen merites, niet op de aanname dat het topmodel het heeft geschreven.

• Geleidelijke rechtenuitbreiding — het schrijfpad, of dat nu via een plug-in of een MCP-server verloopt, geeft een chatsessie de mogelijkheid om je code te wijzigen. Verdeel de machtigingen in lagen en trek ze in zodra de wijziging is doorgevoerd.

De executor-helft via één endpoint uitvoeren

De planningshelft van deze workflow zit in een abonnementsproduct, en dat deel is wat het is. De uitvoerende helft is een API-aanroep, en dat is de helft die het waard is om te bezitten. Als je de uitvoerder script — een kleine agent-loop, een CI-job die een goedgekeurd ontwerpdocument omzet in een branch — is de modelaanroep het enige onderdeel dat verwisselbaar moet zijn, want het model dat je volgend kwartaal wilt, is niet het model waarop je je vandaag baseert.

Daar is een routeringslaag voor bedoeld. openai/gpt-6-astrastaat achter hetzelfde OpenAI-compatibele endpoint als 200+ andere modellen, met de catalogusprijs van de provider doorgegeven tegen 0% opslag — dus wanneer een leverancier een prijs wijzigt, wijzigt de prijs aan onze kant dezelfde dag in plaats van bij de volgende contractverlenging. Automatische failover laat je een onbewezen model op een deel van het verkeer inzetten met een bewezen model eronder, wat de eerlijke manier is om erachter te komen of een goedkope executor goed genoeg is voor je tests. En de routerings-DSL stelt meerdere modellen samen tot één aanroep, zodat een reviewermodel de diff van de executor kan controleren met dezelfde sleutel, in hetzelfde requestpad, zonder een tweede integratie.

Niets daarvan verandert de structuur van de overdracht. Het verandert de kosten van het experimenteren met de helft die jij beheert: één sleutel, één endpoint, en een modelstring die je kunt wijzigen zonder de pipeline aan te raken.

Wie moet dit nu uitvoeren, en wie moet wachten?

Als je al betaalt voor een ChatGPT-abonnement op Pro-niveau en je al Codex of Claude Code draait, is het de moeite waard om deze overdracht deze week te adopteren, want de twee potjes staan al apart op je factuur en het ontwerpdocument is het goedkoopste onderdeel in de cyclus. Begin met een wijziging die je goed genoeg begrijpt om een slecht plan te herkennen: vraag om het document, lees de geciteerde bestanden en draag het dan over.

Als je op Plus zit, matig dan de verwachting. Astra bereikt je via Work en Codex, maar niet via Chat, dus de planningshelft van dit draaiboek is niet in de beschreven vorm voor jou beschikbaar — je zou plannen en uitvoeren uit dezelfde pool, waardoor het economische argument vervalt en alleen de discipline overblijft om het document eerst te schrijven. Die discipline is nog steeds de moeite waard. De korting niet.

En als je reden om dit te willen het schrijfpad in Chat is in plaats van de overdracht, wacht dan tot de documentatie van OpenAI de forumthread heeft ingehaald. Een functionaliteit die door de eigen helppagina's van de leverancier wordt tegengesproken, kun je het beste op een scratchrepository houden totdat de pagina's veranderen.

Dezelfde sleutel geeft toegang tot de rest van de catalogus, en je kunt de volledige modellencatalogus bekijken om te zien wat er nog meer achter één OpenAI-compatibel endpoint schuilt.