Subagents ignore requested medium reasoning effort and run at high

Version

• ChatGPT/Codex desktop: 26.715.52143 (5591)
• macOS arm64
• Observed: 2026-07-20

Problem

Subagents launched with an explicit gpt-5.6-sol model override and
reasoning_effort: medium ran with high reasoning effort instead. This makes
the requested cost/latency policy unreliable and is visible to the user as an
unexpected high-effort task.

Reproduction

1. From a Codex desktop task, call the collaboration subagent creation tool

with fork_turns: "none", model: "gpt-5.6-sol", and
reasoning_effort: "medium".

1. Wait for the child task to start.
2. Inspect the child rollout's latest turn_context.

Repeated three times in one gate. All three creation requests explicitly used
medium. All three child rollouts recorded:

{
  "model": "gpt-5.6-sol",
  "effort": "high",
  "collaboration_mode": {
    "settings": {
      "model": "gpt-5.6-sol",
      "reasoning_effort": "high"
    }
  }
}

The child results' prompt-level provenance repeated the requested value
medium, so request construction was not the source of the discrepancy.

Expected behavior

The child runs at the explicitly requested medium effort, or creation fails
closed with a clear unsupported-override error. The desktop UI, task API, and
rollout metadata should agree on requested and effective effort.

Impact

• Unexpected token use and latency.
• A user cannot enforce a default medium policy for autonomous subtask work.
• Prompt/receipt provenance can incorrectly claim medium while the effective

runtime is high.

• Autonomous workflows need an extra post-dispatch audit and cannot safely rely

on the creation response.

Workaround

After each child starts, inspect its observed rollout metadata and stop/retry or
route differently on mismatch. This is incomplete because the unexpected
high-effort turn may already have begun.

Duplicate search

Searched open and closed issues in openai/codex for subagent reasoning
effort, reasoning effort medium high, and reasoning_effort spawn agent; no
matching issue was found.