Feature request: per-worker model and reasoning-effort controls for Codex subagents

Codex
1

I’m using Codex with several parallel subagents for search, implementation, validation, and review. Workspace agents can be configured with a model and reasoning effort, but the disposable worker path does not currently expose equivalent per-worker controls.

When workers inherit a high reasoning setting, even bounded tasks such as documentation lookup or repetitive validation can consume much more of the shared usage window than expected. The critical path may need deep reasoning; every side task usually does not.

Requested behavior

  • Optional model or model-tier and reasoning_effort settings per worker (auto, low, medium, high, xhigh).
  • Inheritance by default, plus a parent-defined ceiling so a child cannot silently exceed the intended effort.
  • Telemetry showing the actual model, effort, runtime, and usage for each worker or task class.
  • Policy defaults by task type—for example, low/medium for search and repetitive checks, high for implementation or security review, and xhigh only for an explicitly escalated final arbiter.
  • Backward-compatible automatic routing when no override is supplied.

This would make parallel Codex workflows more predictable and token-efficient without lowering quality on the critical path. It would also make task-distribution telemetry much more useful, because users could compare the requested policy with the model and effort that actually ran.

2

This request points to the right control surface. I would add an automatic orchestration layer above the per-worker settings.

The parent agent could decompose the task and choose the model tier, reasoning effort, tools, and parallelism for each subtask.

For example:

- architecture and ambiguous requirements may use stronger reasoning;

- routine inspection or high-volume transformation may use smaller models;

- file enumeration or checksums may use deterministic tools;

- validation and final integration may move back to a stronger model.

Routing could adapt during execution: escalate when a worker is underpowered, reduce effort when the work is simpler than expected, and replan failures instead of retrying the same profile.

Most users would only need to choose a broad policy:

- Fast

- Balanced

- Quality-first

- Usage-capped

- Manual

Expert users could retain per-worker pins, ceilings, and reproducible routing controls.

After completion, a compact summary could show the profiles actually used, approximate usage, and validation results.

The goal is not only to reduce usage. It is to spend inference where it changes the result.