The Oracle and the Operator

How people pair GPT-5.6 Pro with Codex—and why the split works

Prepared for Marc

July 2026

Private edition prepared for personal reading

A note before we begin

This little book grew out of an X thread, not a controlled benchmark. Ethan Mollick amplified Will Depue’s report that GPT-5.6 Pro was unusually good at finding and repairing the bad ideas produced by the coding model in Codex. People replied with the contraptions they had built around that difference: browser skills, an API “oracle,” ZIP files passed like diplomatic pouches, and loops in which one model gives orders while the other edits and tests.

The reports are interesting because they converge on the same design even when the plumbing differs. People are separating judgment from execution.

That distinction is the subject here. Model names and product menus will change. The useful pattern probably will not.

Reading time: about 30 minutes. Skim the chapter openings, linger over the field notes, and steal the prompt cards at the end.

The complaint that became a workflow

A good product story sometimes begins with a user doing unpaid systems integration.

Will Depue described a clumsy loop. He would ask Codex to write research reports, paste them into GPT-5.6 Pro, then copy Pro’s corrective instructions back into Codex. The irritation was not that either model was useless. It was that each seemed to occupy a different part of the competence map.

Codex had the workshop. It could inspect files, edit code, run commands, test changes, and keep moving through a repository. Pro had the sharper editorial eye. It was, in Depue’s words, “inordinately good” at criticizing and fixing the other model’s ideas and implementations.

Mollick amplified the observation and ranked Pro above the strongest coding variants for hard problems. The ranking drew attention, but the replies were more useful than the leaderboard. They showed what practitioners do when the model with better judgment is not the model holding the tools.

They build a hallway between the two rooms.

The middleman tax

The first hallway was a human clipboard:

Codex produces a plan, report, patch, or explanation.

The person carries it to Pro.

Pro identifies weak assumptions, omissions, or bad implementation choices.

The person carries the review back.

Codex revises and tests.

This works. It is also clerical, easy to mangle, and surprisingly expensive in attention. The human has to decide what context to move, notice when a response has been truncated, and keep two conversations synchronized. After a few rounds, the operator becomes a lossy message bus with coffee.

The thread’s replies were attempts to remove that tax without losing the useful separation of roles.

A correction worth keeping

The original framing said Pro was available only through the chatbot. Mollick later corrected that: an API route exists. That correction matters because it splits the available plumbing into two families.

The browser family uses an existing ChatGPT subscription and lets Codex operate the web interface. It can be economical, but it inherits browser state, UI changes, login friction, and automation fragility.

The API family makes the handoff explicit and programmable. It is easier to structure, log, retry, and test. Each call has a visible cost, which encourages users to reserve Pro for decisions that justify it.

Neither route answers the more important question: what deserves to cross the hallway?

Two rooms, two kinds of work

The most useful way to understand the thread is as a small organization chart.

Pro sits in a quiet room with a whiteboard. Codex is downstairs in the workshop with the repository open, tests running, and half the machine covered in build output. Trouble begins when the whiteboard consultant pretends to have tightened the bolts, or when the workshop crew quietly redesigns the building while replacing a hinge.

[picture]

The basic two-model loop.

The oracle’s work

Across the examples, people gave Pro five recurring jobs.

Critic

Pro receives a Codex plan or implementation and looks for defects: hidden assumptions, missing cases, mismatched requirements, unsafe changes, or a solution that is elegant in prose and wrong in the repository.

This is the role that started the thread. It also has the cleanest boundary. The critic does not need to touch every file. It needs a truthful packet describing the decision and enough evidence to challenge it.

Planner

Before Codex edits anything, Pro turns an ambiguous objective into constraints, stages, interfaces, acceptance tests, and likely failure points. One user described using Pro for planning and brainstorming, then leaving implementation to Codex’s strongest coding mode.

Planning is a good use of expensive reasoning when a wrong first move would create a large amount of polished waste.

Decision adviser

A custom browser skill in the replies was aimed at architecture, business decisions, and skill design reviews. The author gave it a sensible constitution: Pro supplies a second opinion; the local agent decides whether to accept, reject, or modify it and remains responsible for the final result.

That last clause is doing real work. “The oracle said so” is not an engineering argument.

Research synthesist

One workflow asked Pro to research and plan, then return a ZIP that could be handed to Codex. Another sent Codex-generated research reports to Pro for criticism. The direction changes, but the division does not: Pro shapes or checks the intellectual frame; Codex turns it into working artifacts.

Supervisor

The most ambitious setup makes Pro the continuing orchestrator. It gives one assignment, waits for Codex to implement and test it, reviews the evidence, and issues the next instruction. The models repeat the loop until a defined gate is met.

This can be powerful. It can also become two language models writing management memos to each other while no one notices that the same test has failed four times. A supervisor needs evidence and stopping rules, not merely senior-sounding prose.

The operator’s work

Codex earns its place by touching reality:

inspect the repository before proposing changes;

edit the actual files;

run builds, tests, linters, migrations, or smoke checks;

report exact observations rather than narrating intended behavior;

surface contradictions between the plan and the code;

package the useful delta for another review.

The cleanest handoff is therefore asymmetric. Pro returns decisions and tests. Codex returns artifacts and evidence.

Field note: the status report is part of the product

“Done” is not evidence. A useful return packet names the files inspected, files changed, commands run, observed results, unresolved uncertainty, and any departure from the plan.

Six ways people built the hallway

The thread looked like a pile of hacks until the examples were normalized. Most of the apparent variety came from mixing up three things: Pro’s role, the transport used to reach it, and the artifact being exchanged.

The transports reduce to six patterns.

1. The human clipboard

This is the original copy-and-paste loop. It needs no setup and exposes every handoff to human judgment.

Best for: occasional hard decisions, short reviews, and experiments where you are still learning what context Pro needs.

Hidden advantage: the friction can be healthy. Copying a packet by hand forces you to notice whether it contains a question, evidence, and a requested output.

Hidden cost: after several rounds, the human starts summarizing aggressively. Important caveats disappear. Threads drift. The same stale context is copied back and forth like a fax of a fax.

Use this first. Automate only after the packet shape stabilizes.

2. The native side door

One reply described a pleasantly strange feature path inside Codex:

Highlight a question or decision.

Choose More details.

Codex forks the context into a ChatGPT conversation.

The fork initially uses Instant, so switch it to Pro.

Discuss the issue with Pro.

Click Add to chat to return the answer to Codex.

For larger work, the user applied this to each question produced by a brainstorming skill. Pro handled the discussion; the answer was inserted back into the implementation conversation.

The rough edges are revealing. The user could not choose Pro as the initial model, and repeated requests appeared to reuse the same fork. Even so, this is close to an ideal lightweight consultation: context leaves through a product-supported door and the answer returns through another.

Best for: a few bounded planning questions inside an active Codex session.

Watch for: old assumptions accumulating in a reused fork.

3. The browser passage

Several people independently told Codex to log into ChatGPT Web through its in-app browser and ask Pro the hard question. Others wrapped the same move in a custom skill.

This is the minimum viable automation. The agent already has the context and the browser. The human supplies a logged-in session and an instruction such as: “Consult Pro about this architecture, include these files, and bring back a decision table.”

One user created a browser-based consultation skill specifically to stop acting as the middleman. Another open-sourced a skill that organizes context and real files, invokes a Codex Chrome plugin, and asks for confirmation that the intended Pro model is selected before sending.

That confirmation step is easy to dismiss as ceremony. It is actually a practical response to a messy truth: web interfaces route, rename, default, and remember state. The label in the menu is part of the execution environment.

Best for: subscription-backed access, file-aware consultations, and teams comfortable with browser automation.

Watch for: model-selection mistakes, stale sessions, accidental context leakage, UI changes, and an automation tab colliding with ordinary browsing.

A charmingly specific fix

One respondent installed Surf CLI, downloaded Chrome Dev, and pinned the automation there so it would not clash with day-to-day browsing. This is the sort of detail that makes a workflow feel real: the grand architecture of machine intelligence eventually becomes “please stop stealing my browser tab.”

4. The custom browser tool

A respondent had the coding model build a Chrome extension that performed the handoff. The reason was blunt: copy-and-paste was tiresome, and browser access avoided paying the API cost for every Pro consultation.

Mechanically, this belongs to the browser family. Operationally, it is a step up. A purpose-built extension can define what gets sent, preserve a transcript, insert the reply into the right task, and expose a single “ask the reviewer” action.

The danger is that a small integration can become an unexamined conveyor belt. If every Codex thought is sent to Pro, the system gains latency without gaining judgment. Good routing is selective.

Best for: a repeated, well-understood review packet.

Watch for: invisible prompt drift, fragile page selectors, and sending far more context than the reviewer needs.

5. The API oracle

Dan Robinson described giving Codex an oracle skill that calls Pro through the API.

The name is good because it implies a bounded ritual. The agent does not abdicate the task. It prepares a question, asks for judgment, receives an answer, and continues working.

An API skill can require structure on both sides:

Send:
- decision to be made
- constraints
- relevant artifacts
- evidence already collected
- current recommendation
- uncertainty

Receive:
- blocking findings
- recommended decision
- rejected alternatives and reasons
- acceptance tests
- confidence and missing evidence

This route is the easiest to observe and govern. Calls can be logged. Costs can be measured. Retries can be explicit. The skill can refuse to invoke Pro unless the request contains a genuine decision or review target.

Best for: reliable automation, recurring gates, and workflows where auditability matters.

Watch for: expensive loops and agents consulting the oracle to avoid making ordinary decisions.

6. The diplomatic pouch

Some context is too large or too concrete for a neat prompt. Two users solved that with ZIP files, in opposite directions.

In one version, a skill packages the codebase and plans and gives the archive to Pro for review. In the other, Pro researches and plans, then produces a ZIP that Codex can ingest.

The ZIP is not merely a large clipboard. It changes the unit of collaboration. Instead of passing an opinion, the sender passes a small world: source files, plans, notes, data, perhaps a runnable scaffold.

Best for: large tasks with several connected artifacts or a review that must inspect the real materials.

Watch for: irrelevant bulk, secrets, generated directories, ambiguous entry points, and archives that cannot be reproduced.

A good pouch includes a manifest:

README_FOR_REVIEWER.md
- objective
- directory map
- files that matter
- commands used to verify
- known failures
- questions requiring judgment
- material intentionally excluded

The loop that earns its keep

The most interesting proposal in the thread assigns Pro the role of orchestrator and Codex the role of executor.

Pro creates the plan and gives the next instruction. Codex implements it, tests the result, and returns to Pro for review and criticism. Pro adjusts the plan and sends the next assignment. The cycle continues.

The idea is attractive because it resembles a good technical lead working with a capable engineer. The resemblance can be dangerous. Neither model has the durable situational awareness of a human who has watched the project evolve for months. The loop has to manufacture that awareness from artifacts.

One bounded assignment at a time

Pro should not issue a ten-step epic and disappear. It should give Codex one bounded assignment with:

the decision already made;

scope and files likely involved;

constraints that must survive;

acceptance criteria;

checks to run;

conditions that require escalation instead of improvisation.

Codex should return an evidence packet:

Assignment received:
Files inspected:
Files changed:
Commands and checks run:
Observed results:
Acceptance criteria met:
Acceptance criteria not met:
Departure from the plan:
Remaining risks:
Question requiring judgment:

The packet may feel bureaucratic until something goes wrong. Then it becomes the only reliable memory the loop has.

Review the delta

On the second pass, Pro rarely needs the entire project retold. It needs the original constraints, its previous blocking findings, the changed artifact, and test evidence. Reviewing the delta reduces noise and makes it harder for the conversation to wander into a fresh redesign.

If the implementation contradicts the plan because the repository revealed new facts, Codex should say so plainly. A plan written without the repository is a hypothesis, not a commandment.

Stop before the agents invent more work

A two-model loop needs an exit condition chosen before it begins. Useful stopping rules include:

all explicit acceptance criteria pass;

the relevant tests pass and no blocking review finding remains;

the remaining concerns are preferences rather than correctness issues;

another review would examine unchanged evidence;

the cost or latency exceeds the value of the decision;

the same failure repeats twice without new evidence, which triggers human review.

Without a stopping rule, the agents can keep “improving” a solved problem. One produces a refinement; the other finds a reason to refine the refinement. The result is churn wearing a lab coat.

What deserves Pro

The expensive model should not become a ceremonial approver for every trivial action. Routing is the skill.

[picture]

A practical routing map.

Send it to Pro when

a wrong architecture will contaminate many later changes;

requirements conflict or hide a consequential trade-off;

Codex has produced a plausible plan but you distrust its assumptions;

repeated implementation attempts fail for different reasons;

a review must compare several artifacts or research sources;

the change touches security, data loss, money, permissions, migrations, or an irreversible external action;

the final output needs an adversarial pass before delivery.

Keep it in Codex when

the task is mechanical and tests define correctness;

the next step is repository inspection rather than judgment;

an error message already names the problem;

the change is small, local, reversible, and easily verified;

Pro would receive no information beyond what Codex already has;

the agent is merely seeking reassurance.

Ask a human when

values, taste, politics, or business ownership determine the answer;

credentials, payments, publication, deletion, or external commitments require consent;

the models disagree after seeing the same evidence;

no test can distinguish the alternatives;

the task has drifted away from the reason it was started.

The last category matters. Two models do not create accountability by averaging their confidence.

Details from the field

The entertaining part of the thread was not the model ranking. It was the improvised infrastructure surrounding it.

People are building miniature consultancies

The role labels are organizational: oracle, reviewer, adviser, orchestrator, executor. Users are not simply swapping one chatbot for another. They are creating a tiny firm inside a task, complete with delegation, review, reporting, and escalation.

This explains why the model with fewer tools can still be useful. A consulting architect does not need the deployment keys to spot that the design has no rollback plan.

The same ZIP travels both ways

One person sends the repository and plan to Pro. Another asks Pro to produce the plan and archive for Codex. The same transport supports opposite authority structures.

The direction reveals who owns the initial frame:

Codex → Pro: “Here is what I intend to do. Find the holes.”

Pro → Codex: “Here is the world I designed. Make it real.”

Neither is universally better. The first grounds the review in repository facts. The second gives the planner more freedom before implementation details narrow the options.

Browser automation is an economic decision

The browser hacks are not only product workarounds. At least one user explicitly built an extension to avoid a per-call API charge. The ChatGPT subscription becomes a pool of reasoning accessed through the UI; the browser agent becomes an unofficial transport layer.

That trade exchanges metered API cost for engineering cost: login state, page changes, selectors, model menus, and a browser profile that must stay out of the way. Cheap calls are not necessarily a cheap system.

A daily reviewer changes behavior

One respondent described having Codex send material to Pro each day for guidance and review. The detail is small, but it suggests a shift from emergency escalation to routine governance.

A reviewer consulted only after disaster becomes a debugger. A reviewer consulted at planned gates can prevent the disaster. The danger is ritual approval: Pro gets asked because the calendar says so, then produces generic criticism because no actual decision was presented.

Product seams become user interfaces

“More details,” “switch to Pro,” and “Add to chat” were not necessarily designed as a formal two-model protocol. A user combined them into one. The best workflows often appear this way: not as a new feature, but as a route through existing seams.

Prompt cards

These are deliberately short. A long prompt can hide a weak contract.

The critic card

You are reviewing a proposed solution, not implementing it.

Goal:
Constraints:
Relevant artifacts:
Current proposal:
Evidence already collected:
Known uncertainty:

Identify blocking defects first. Separate correctness issues from preferences.
For each blocking finding, cite the artifact or assumption involved and
provide a replacement decision plus a verification step.

The planner card

Turn this objective into a bounded implementation plan for Codex.

Repository facts:
Non-negotiable constraints:
Open decisions:
Risks:

Return:
1. decisions and reasons;
2. ordered assignments small enough to verify independently;
3. acceptance criteria and commands/checks for each assignment;
4. conditions that require human escalation.
Do not claim repository facts that were not supplied.

The oracle-call card

Codex is asking for one high-value judgment.

Decision:
Options considered:
Codex's current recommendation:
Why the choice is difficult:
Evidence:
Missing evidence:

Choose an option or request a specific missing fact.
State what would falsify your recommendation.

The executor card

Execute only the current assignment.
Inspect before editing. Preserve the listed constraints.
Run the relevant checks and return exact observations.
If repository evidence contradicts the plan, stop and report the conflict
instead of quietly redesigning the task.

The final review card

Review the delta against the original acceptance criteria.

Previous blocking findings:
Changed artifacts or diff:
Commands run:
Observed results:
Remaining uncertainty:

Return only:
- unresolved blocking findings;
- newly introduced defects;
- acceptance criteria not proved;
- final disposition: accept, revise, or escalate.
Do not reopen settled preferences without new evidence.

A pocket protocol

For a live task, write four lines before invoking either model:

Pro decides: what judgment belongs in the quiet room?

Codex changes: what artifact belongs in the workshop?

Codex proves: what observation will count as success?

The loop stops when: what prevents another decorative review?

If one of those lines is blank, the workflow is not ready to automate.

The context receipt

Every handoff should answer:

What artifact is being transferred?

What has already been verified?

What remains uncertain?

What may the receiver change?

What form should the answer take?

This receipt is more important than the transport. A perfect API carrying a vague request will produce well-formatted ambiguity. A clumsy copy-and-paste carrying a precise packet can work very well.

A compact decision table

Situation | Recommended route
One difficult decision | Manual consultation or native fork
Several bounded planning questions | More details → Pro → Add to chat
Repeated subscription-backed reviews | Browser skill or dedicated extension
Auditable, structured gates | API oracle
Large repository or research context | Manifested ZIP handoff
Long, judgment-heavy implementation | Pro orchestrator + Codex executor
Mechanical change with decisive tests | Keep it in Codex

The operator’s appendix

The six workflows become easier to compare when three layers are kept separate:

Role: critic, planner, adviser, synthesist, supervisor, or executor.

Transport: clipboard, native fork, browser, extension, API, or archive.

Payload: question, plan, patch, evidence packet, research bundle, or repository snapshot.

A Chrome extension and an API skill may look like different systems while performing the same review loop. A ZIP may travel through either system without changing who decides or who executes. Naming the three layers prevents tooling from masquerading as methodology.

The stable task packet

Before either model starts, give both a compact brief that can survive outside the chat transcript:

Objective:
Deliverables:
In scope:
Out of scope:
Current repository or artifact state:
Constraints:
Known facts and sources:
Uncertainties:
Acceptance checks:
Budget or deadline:

Version this packet if the task changes. A long conversation is a poor substitute: it mixes settled decisions with abandoned ideas, duplicates stale facts, and makes it difficult to tell which instruction still governs the work.

The Pro response contract

For consequential reviews, require more than a verdict:

Decision or assessment:
Assumptions:
Blocking issues:
Non-blocking issues:
Recommended action:
Acceptance checks:
Evidence needed from Codex:
Unresolved uncertainty:
Confidence and reason:

Ask Pro to identify the affected file, component, claim, or requirement whenever possible. “Improve robustness” is atmosphere, not an actionable finding.

The Codex response contract

Codex should answer with contact evidence from the working environment:

Changes made:
Files or artifacts changed:
Commands or checks run:
Observed results:
Acceptance criteria passed:
Acceptance criteria not passed:
Remaining risks:
Questions requiring judgment:

A claimed repair is incomplete until the relevant check has run or Codex states exactly why verification was impossible.

Escalation rules

Stop the machine-to-machine loop and ask a human when:

Pro and Codex still disagree after one focused rebuttal round;

the decision depends on policy, product intent, credentials, payment, consent, or an irreversible action;

verification requires access neither model has;

the same blocking issue survives two repair cycles;

a new proposal would expand the agreed scope or invalidate the task packet.

Also stop when the time, token, call, or cost budget is exhausted. Return the best verified state, failed checks, and the smallest useful next action. The ability to generate another pass is not a reason to buy one.

Source trail and cautions

The examples in this book came from X search results around Ethan Mollick’s post and the Will Depue post it quoted, including replies and quote-posts available on July 24, 2026. Direct web extraction of the X page was unavailable during collection, so this is a normalized digest of surfaced posts, not a claim of exhaustive reply coverage.

The central posts and examples:

Ethan Mollick’s thread

Will Depue’s original complaint

Jaden Tripp on the native fork-and-return route

Dan Robinson’s API oracle skill

@cjine99’s Pro-orchestrator/Codex-executor loop

Joe Devon on Surf CLI and a separate Chrome Dev setup

@anticodeXBT’s browser extension

@zjp1997720’s external-judgment skill

@odemkur’s codebase-and-plan review archive

@embw_l0x’s Pro-to-Codex ZIP workflow

Browser consultation described by @editxshub

Browser consultation skill described by Jeffrey Concerto

These are user reports, not independent measurements of model capability. The model names, access routes, prices, UI labels, and routing behavior can change. The durable idea is simpler: give difficult judgment to the system best at judgment, give execution to the system that can touch reality, and make the evidence travel back.