Feature request: cost-aware adaptive orchestration (single → cascade → critique) for Codex

What variant of Codex are you using?

Codex App / CLI / IDE / Web. This is primarily a runtime/orchestration proposal that could be shared across Codex surfaces.

What feature would you like to see?

I would like Codex to add an opt-in cost-aware adaptive orchestration mode whose goal is:

Use the least expensive amount of inference that can reliably complete the task, and spend stronger-model compute only when evidence justifies it.

This is broader than automatic model selection. Instead of choosing one model for an entire task, Codex could dynamically choose an execution pattern per task or phase.

A useful first version could support three bounded strategies:

1. Single — route straightforward work directly to the cheapest model/reasoning level expected to meet the quality bar.
2. Cascade — let a cheaper/faster model attempt the work first, validate the result, and escalate to a stronger model only when the candidate fails a quality gate.
3. Critique — for work where independent review is valuable, let one model produce the candidate, use an isolated read-only critic to identify concrete problems, then allow one bounded revision pass.

Conceptually:

user task
   |
   v
cost/quality router
   |
   +-- Single  ------> efficient model --------------------> result
   |
   +-- Cascade -----> efficient model -> quality gate
   |                                      | pass -> result
   |                                      | fail
   |                                      v
   |                                 stronger model -------> result
   |
   +-- Critique ----> solver -> isolated critic -> revision -> result

Codex already has many of the useful primitives: multiple model/reasoning tiers, subagents, model overrides, tests/tools, persistent task state, and increasingly capable orchestration. The missing piece is a product-level policy that optimizes the whole task for outcome quality, token/plan usage, latency, and compute rather than requiring the user to manually decide every model transition.

Important design constraints

1. Optimize cost per successful task, not token count in isolation.

A weaker model that repeatedly fails, re-reads the repository, or spawns many agents can cost more than one strong pass. The router should consider expected retries, context duplication, verification cost, and probability of success.

2. Routing itself must be cheap.

Do not require a full expensive model turn merely to decide which model should handle the task. Prefer runtime/task metadata, lightweight classifiers, cached historical signals, or a very small routing model where appropriate.

3. Escalate from evidence.

Useful escalation signals could include:

• failing tests or validation;
• repeated unsuccessful tool cycles;
• low-confidence/ambiguous changes;
• unresolved compiler/type errors;
• security or migration risk;
• critic findings;
• evidence that the current task boundary is wrong;
• explicit user quality/budget requirements.

4. Avoid multi-agent overhead when it is not worth it.

Every additional agent may duplicate system instructions, repository context, tool schemas, and discovery work. Fan-out should happen only when predicted benefit exceeds this fixed context cost. Context/cache reuse should be treated as part of the optimization objective.

5. Independent review should be isolated and bounded.

A critic should normally be read-only/tool-less and should not be able to modify the repository. One critique + one revision is a reasonable initial bound. On cancellation or failed validation, Codex should avoid leaving a partially applied patch.

6. Account for the complete workflow.

Expose total usage across routing, drafting, critique, revision, escalation, retries, and subagents. A strategy should not be considered cheaper merely because one individual call was cheaper.

7. Preserve user control.

A pinned model/reasoning level should remain authoritative unless the user explicitly enables adaptive orchestration. An experimental mode could offer policies such as:

Adaptive: Balanced
Adaptive: Minimize usage/cost
Adaptive: Maximize quality within budget
Manual

The UI should make the effective strategy observable without exposing chain-of-thought, for example:

Strategy: Cascade
Initial: lightweight model / medium
Validation: tests + runtime quality gate
Escalated: no
Estimated usage saved vs selected strong baseline: 58%

Reference: GitHub Project HydraFusion

GitHub recently published a useful reference implementation/research direction:

https://github.blog/ai-and-ml/github-copilot/project-hydrafusion-frontier-quality-via-multi-model-orchestration/

HydraFusion selects among Single, Cascade, and Critique workflows and treats workflow selection as an optimization problem across quality, cost, and latency.

GitHub reports the following controlled offline results relative to Claude Opus 5:

Benchmark	Estimated cost	Verified quality
TerminalBench 2.1	67% lower	+4.9 points
DeepSWE	36% lower	-1.5 points
CheckpointBench	65% lower	-0.1 points

Those numbers are specific to GitHub's evaluated model pool, benchmark versions, and pricing assumptions, so I am not claiming Codex would reproduce them. They do demonstrate that runtime orchestration is worth evaluating as a way to approach frontier quality at materially lower average workflow cost.

The point is not to copy GitHub's implementation. Codex has its own architecture and could potentially do better by combining adaptive model routing with its existing subagent/task infrastructure.

Why this matters to users

For many users, the practical limit on long Codex sessions is not model capability but usage/cost. If routine repository search, exploration, test triage, straightforward edits, and review can use cheaper inference while difficult reasoning escalates only when needed, users should be able to complete more useful work within the same budget or plan allowance.

This could make long-running coding workflows substantially more accessible while preserving frontier-model capability for the portions that actually need it.

Compute and environmental efficiency

There is also a broader infrastructure benefit. Systematically avoiding unnecessarily expensive inference should reduce avoidable accelerator work, electricity consumption, cooling demand, and datacenter load per completed task.

The carbon impact should not be overstated: emissions depend on hardware utilization, datacenter energy mix, caching, workload displacement/rebound effects, and other factors. But cost per successful task and compute per successful task are measurable optimization targets, and reducing unnecessary inference is directionally aligned with lower energy demand.

At Codex scale, even modest improvements in average compute per successful task could be meaningful.

Suggested evaluation / acceptance criteria

I would evaluate this mode against a fixed strong-model baseline using real agentic coding workloads.

Track at least:

• verified task completion rate;
• total input/cached/output tokens;
• normalized plan usage or estimated API cost;
• wall-clock latency;
• number of model legs and retries;
• duplicated context sent to subagents;
• escalation rate;
• tests/validation success;
• failures caused by under-routing;
• cost per successfully completed task.

A successful policy should reduce average usage/cost materially while preserving an explicit quality floor, rather than merely routing everything to smaller models.

A safe rollout could begin as an experimental opt-in with shadow evaluation before automatic routing is enabled broadly.

Related Codex requests

This seems complementary to existing requests rather than identical to them:

• #34388 — Smart Mode for automatic model and reasoning-effort selection. This focuses primarily on selecting a model/effort; this request adds compound per-task execution strategies, quality gates, critique, and conditional escalation.
• #40037 — evidence-driven semantic escalation in dynamic multi-agent graphs. This provides useful primitives/signals for deciding when execution should be retried, escalated, or replanned.
• #39808 — notes that subagent fan-out can increase usage because every worker pays fixed context/tool/skill overhead. A cost-aware orchestrator should explicitly account for this.
• #40599 — pre-turn routing hook for plugins. A native implementation could use similar task signals without requiring an extra routing turn.
• #38721 — cost/budget metrics. Better accounting would make adaptive policies auditable to users.

I would be happy to test an experimental implementation and compare it against fixed-model Codex workflows on real repository tasks.

No files, tests, or entry points are named in the proposal. Start by locating Codex's existing model, subagent, task-state, validation, and usage-accounting components, then evaluate an opt-in Single/Cascade/Critique mode against a fixed strong-model baseline using the listed completion, cost, latency, retry, and validation metrics.