Plan in ChatGPT Pro, Execute in Codex: The Design-Document Handoff Playbook

The workflow worth stealing this month is not a model, it is a division of labour. You hand GPT-6 Pro in ChatGPT a repository URL, ask it for a design document rather than a patch, and give that document to Codex or Claude Code to implement. The planner runs on GPT-6 Astra — GPT-6 Pro is the name ChatGPT's usage caps use for it — and Astra is a 2026-09-03 model, so nothing here is launch coverage or a release claim. What changed inside the last seven days is narrower, and worth stating exactly: on 2026-09-17 practitioners reported that the official GitHub plugin in ordinary ChatGPT Chat, not ChatGPT Work and not Codex, can edit repository files, commit and open pull requests without drawing on the Codex/Work allowance. That is a community claim, not vendor documentation — the official help pages still describe the GitHub app as read-only and route all writing through Codex — and the caveats attached to it matter as much as the claim. Everything below is labelled as vendor-reported, community-reported, or read off the official pages on 2026-09-19.

The workflow, in one pass

Practitioners describe the same loop with small variations. The one that recurs: paste a GitHub address into ChatGPT, ask it to read the code and produce a design document, then download that document and feed it to an executing agent. Some ask for a pull request as well; others stop at the document and let the executor do the writing. Either way the shape is identical — plan in the chat product, build in the agent product — and the reason it is worth copying is that the two halves are metered separately.

• Planning artefact — a design document: the interfaces to add, the files to touch named by path, the migration order, the acceptance tests, and what to do if it goes wrong.

• Execution artefact — a branch and a pull request, produced by an agent that can run the tests it just wrote.

• Review artefact — the diff, which is the only thing that should ever reach a reviewer.

The design document is the load-bearing piece, and it earns its place for two reasons. First, a document is portable: the same text works whether the executor is Codex, Claude Code, or a scripted agent you wrote yourself, so the planning you paid for is not tied to one vendor's tool. Second, it is the review surface that exists before anything is written to your repository — which matters a great deal given that the write path in the chat product is the least-documented part of the whole arrangement.

Why the two-bucket structure is the whole trick

ChatGPT does not bill this workflow out of one pot. Chat, ChatGPT Work and Codex hold separate allowances, with Work and Codex sharing a single pool between them; an OpenAI API key is separate billing again. That structure is what makes the handoff economical: the thinking happens in the Chat bucket, the doing happens in the agent bucket, and a design document costs one Chat message while the implementation costs agent usage.

The numbers, as OpenAI publishes them for the Chat side — vendor-reported figures on the vendor's own plan documentation, not measurements:

• ChatGPT Pro at $200 a month — 200 GPT-6 Pro messages a week; GPT-5.6 Sol Pro additionally carries 170 a day, with both models together capped at 200 a day.

• ChatGPT Pro at $100 a month — 50 GPT-6 Pro messages a week, drawn from an allowance shared with GPT-5.6 Sol Pro.

• Business Standard — 15 GPT-6 Pro messages a month, shared with Sol Pro; Business Premium — 50 a week on the same shared basis.

• ChatGPT Plus — no GPT-6 Pro in Chat at all. Astra reaches Plus only through ChatGPT Work and Codex, which is precisely the bucket this playbook is trying to protect.

On the Work/Codex side OpenAI publishes estimates rather than limits, and says so: roughly 5 to 45 Astra messages per five-hour window on Plus, 25 to 225 on Pro 5x, and 100 to 900 on Pro 20x, with the same page noting that actual consumption varies with task complexity, context, output and tool use, and that weekly limits may apply on top. Those ranges sit at roughly half the equivalent Sol numbers, which is the arithmetic reason a frontier model is affordable to run as an agent at all.

The practical consequence is a budgeting rule you can write on a card. Spend Chat messages on decisions and agent usage on code. A planning session that argues about an interface for twenty minutes costs a handful of Chat messages and produces a document that saves an agent an hour of exploratory edits — which is the trade the practitioners in the thread are actually making.

The write path: what the connector does, and what people claim it does

Here the sources disagree, and the disagreement is the interesting part.

OpenAI's own help documentation is unambiguous: the GitHub app in ChatGPT reads your repositories for analysis and search, and generating code, editing it and pushing it to GitHub is what Codex is for. That is the read-only position, and it is the one to plan against if you are putting this in a team process, because it is the one with a vendor behind it.

The community position, dated 2026-09-17, is that the web version's GitHub plugin in Chat mode will edit code, commit and open pull requests, and that because it is an official plugin rather than a third-party MCP server, it does not consume Codex or Work quota. The same thread is careful about scope: small tools, minor edits, small bugs — large refactors and hard debugging still belong in Codex. Its own commenters add the caveats worth repeating, because they are the ones that bite:

• Normal ChatGPT rate limits still apply. "Not Codex quota" is not "free".

• Quality can degrade after several rounds without notice, with the session dropping to a smaller model mid-task.

• The thread's authors advise not switching to Work when the interface offers it, and warn that hammering anonymous chat pages degrades the web experience for everyone.

An independent Japanese write-up of the same pattern reaches a compatible conclusion without the quota claim: if a GitHub integration supports write actions, plain chat can read a repository, modify files, create a branch and open a pull request; ordinary chat rate limits apply; and Codex and Work draw on the shared agent pool, so regular chat is for a few-file edit and Codex is for long software tasks. Where the two accounts agree, the agreement is the usable part: chat is a small-change channel, Codex is the long-session channel, and the pools are separate.

Third-party MCP servers exist that expose a real git workflow — branch, diff, commit, push, open a pull request — with permissions you can tier from read-only up to push. If you want the write path to be deterministic and auditable rather than a behaviour you are hoping for, that is the route; if you want to stay inside what OpenAI documents, plan in Chat and write in Codex.

Either way, the design-document handoff is what makes the chat write path defensible. A chat session with write scope on a repository is a larger permission grant than a chat session with read scope, and the document is the artefact you review before that grant is exercised.

The handoff, step by step

• Point the planner at the repository — a public URL pasted into the prompt, or the GitHub connector if you have authorised it — and ask it to read the code before proposing anything.

• Ask for a design document, not a patch. Require file paths, the interfaces being added or changed, the order the changes have to land in, and the tests that prove each step.

• Ask it to quote the files it actually read. A design document that describes an interface the repository does not have is the most common way this workflow fails, and the quotes are how you catch it in a minute instead of a sprint.

• Save the document into the repository rather than pasting it into the next tool. An executor that reads a file can re-read it; an executor that received a paste has one shot at it.

• Start the executor with the document as its instruction, and scope one pull request to one section of it. Long sessions are where agent quality quietly decays.

• Keep the planner in a review-only role afterwards. When the document is wrong, re-plan and update the document — do not let the executor improvise past it, because improvised work is what the document existed to prevent.

Where it breaks

• Stale repository state — the planner read the default branch while you are working on a feature branch, so the file paths in the document are a version behind. Say which branch to read, or paste the branch tree.

• Design-document drift — the document and the code disagree, and the executor follows the document. The quoted-files step above is the cheap insurance.

• Quota surprise in the wrong direction — a twenty-minute planning conversation is cheap in Chat messages and expensive in attention; a long agent run is the reverse. Budget the bucket you are actually spending.

• Silent downgrade — a chat session that degrades to a smaller model after several rounds will still produce a confident design document. Review the document on its merits, not on the assumption that the flagship wrote it.

• Permission creep — the write path, whether through a plugin or an MCP server, hands a chat session the ability to change your code. Tier the permissions and revoke them when the change lands.

Running the executor half through one endpoint

The planning half of this workflow lives inside a subscription product, and that part is what it is. The executing half is an API call, and that is the half worth owning. If you script the executor — a small agent loop, a CI job that turns an approved design document into a branch — the model call is the only piece that has to be swappable, because the model you want next quarter is not the model you are planning around today.

That is what a routing layer is for. openai/gpt-6-astra sits behind the same OpenAI-compatible endpoint as 200+ other models, with provider list price passed through at 0% markup — so when a vendor moves a price, the price on our side moves the same day rather than at the next contract renewal. Automatic failover lets you put an unproven model on a slice of traffic with a proven one underneath, which is the honest way to find out whether a cheap executor is good enough for your tests. And the routing DSL composes several models into one call, so a reviewer model can check the executor's diff on the same key, in the same request path, without a second integration.

None of that changes the structure of the handoff. It changes the cost of experimenting with the half of it you control: one key, one endpoint, and a model string you can change without touching the pipeline.

Who should run this now, and who should wait

If you already pay for a ChatGPT plan at the Pro tier and you already run Codex or Claude Code, the handoff is worth adopting this week, because the two buckets are already separate on your bill and the design document is the cheapest thing in the loop. Start with a change you understand well enough to spot a bad plan: ask for the document, read the quoted files, then hand it over.

If you are on Plus, temper the expectation. Astra reaches you through Work and Codex but not through Chat, so the planning half of this playbook is not available to you in the form described — you would be planning and executing out of the same pool, which removes the economic argument and leaves only the discipline of writing the document first. That discipline is still worth having. The discount is not.

And if your reason for wanting this is the write path in Chat rather than the handoff, wait for OpenAI's documentation to catch up with the forum thread. A capability that the vendor's own help pages contradict is a capability to keep on a scratch repository until the pages change.

The same key reaches the rest of the catalogue, and you can browse the full model catalogue to see what else sits behind one OpenAI-compatible endpoint.