Policy-based routing + ChatGPT↔Codex orchestration with human approval gates

ChatGPT Feature requests
, , ,
1

Title
Policy-based routing + ChatGPT↔Codex orchestration with human approval gates (Codex Desktop)

Context

  • Plan: ChatGPT Plus + Codex Desktop (Windows), Codex runs against a Linux execution environment (e.g. linux-node-01)
  • Current workflow: ChatGPT = planning/review, Codex = execution
  • Main pain: user manually shuttles prompts/results and must guess model/reasoning/speed without enough signal

Problem 1 — Manual handoff

  • Today: ChatGPT plans → user copies to Codex → Codex executes → user copies report back → ChatGPT reviews → user copies follow-ups → repeat
  • Cost: time, repeated context, longer prompts, and more risk of copy/paste drift

Problem 2 — Model/reasoning/speed selection

  • Users cannot reliably identify the least expensive technically sufficient configuration that preserves engineering quality
  • Common failure modes:
    • Always use the strongest model “just in case” → wastes quota
    • Downgrade because quota is scarce → risks quality regressions

Request A — First-class orchestration loop (human-supervised)

  • Flow:
    1. ChatGPT designs the task + acceptance criteria
    2. ChatGPT proposes the Codex run: task + environment + tools + safety boundaries
    3. User approves
    4. Codex executes + produces a structured delivery report
    5. ChatGPT automatically reviews results vs criteria: tests, coverage, Git state, CI, PR readiness
    6. User approval gates for sensitive actions: writes, push, PR creation, deploy, external actions
    7. Merge can remain explicitly manual

Request B — Policy-based, task-aware routing

  • User defines a policy for quality / budget / approvals, e.g.:
    • “Do not compromise engineering quality to save quota.”
    • “Estimate expected weekly + short-window impact before execution.”
    • “If expected cost exceeds remaining budget, ask before proceeding.”
  • System selects model + reasoning effort + speed + execution mode based on the task ChatGPT just analyzed

Desired pre-run UI

  • Recommended model
  • Reasoning effort
  • Speed
  • Estimated weekly impact
  • Estimated short-window impact
  • Confidence
  • Rationale
  • Approval required: yes/no
  • Which actions are gated

Concrete example — repo cleanup + docs alignment

  • ChatGPT recommendation: GPT-5.6 Terra / High / Standard
  • Estimated weekly impact: ~0.4–0.9%
  • Task executed:
    • load AGENTS.md
    • cleanup merged branch
    • update 4 documentation files
    • git diff --check
    • full test suite: 546 passed
    • commit + push
    • structured delivery report
  • Actual observed outcome: weekly quota 51% → 49% remaining

Ideal flow

ChatGPT proposes config + estimate → user approves → Codex runs automatically → ChatGPT auto-reviews → proposes PR / next action → user approves sensitive actions → merge remains manual

One-line summary

The user chooses the quality, budget and approval policy; the system chooses the appropriate model and orchestrates ChatGPT↔Codex with explicit human approval gates.

A slightly ironic footnote: while trying to post this feedback about how users currently have to act as the manual bridge between different AI tools and interfaces, my brand-new community account was automatically silenced because I pasted the prepared text “too fast.”

So, in order to suggest that humans should not have to shuttle messages between AI systems, I first had to shuttle messages between AI systems… and then wait for a human moderator because the anti-spam system thought I was too efficient.

I suppose that makes this feature request unexpectedly self-demonstrating.

2

This is close to what I ended up building for myself, so here is how the pieces actually landed, in case it’s useful while you wait for a native version.

The approval gates turned out to be the load-bearing part, and I ended up with exactly two. The first one comes before anything is written: I approve a design contract with the goal, the files in scope, and acceptance criteria phrased so that each one can visibly fail. The second is just me merging the pull request at the end. Everything in between runs unattended, and it only stops early for a scope change, a destructive action, or a runtime that isn’t available.

On the routing part, I gave up on having the model choose the model. Complexity-based routing sounds right but I could never make it predictable, and an unpredictable router is worse than a dumb one when it’s spending money. What I do instead is pin the model and the reasoning effort per phase, per project, in AGENTS.md. Implementation gets the fast cheap one, review gets the careful one. It’s boring, but I can predict the bill and I always know which model rejected what.

The auto-review half only works if the reviewer is genuinely separate. Mine runs as its own process on a different harness and receives only the diff and the contract, never the implementation session’s history.
Across 23 logged runs for my other personal projects, it sent work back in 15 of them, and in 11 of those it rejected work the implementer had already called finished.

The whole loop on video, if that’s easier than reading: hxxps://youtu.be/6pRWkhlQSAc (replace “xx” with “tt”)

dely-demo

Code, MIT: hxxps://github.com/hieuphung97/dely (replace “xx” with “tt”)

I’m the author. The honest catch is that it needs Orca to open and supervise the worker sessions, so it’s two installs rather than one.

3

Thanks for laying out the workflow. Work and Codex already support reviewing work and approving actions: https://help.openai.com/en/articles/20001275. Thanks for sharing this—we’ll pass the remaining request to the product team. We don’t have a timeline to share.