[Bug]: “One child per named model” instruction blocks explicitly requested same-model subagents #24967

What happened

After the recent orchestration-instruction rewrite, asking T3 to launch two subagents using the same model causes the parent agent to stop at one. It cites this injected instruction:

One child per named model.

This prevents an explicit request such as “try to launch 2 Sol subagents” from being carried out. The observed failure is an instruction-level refusal before the second tool call; a backend concurrency rejection has not been demonstrated.

Steps to reproduce

1. Open a Codex thread in T3 Code Nightly with the T3 orchestration tools enabled.
2. Ask: “Launch two Sol xhigh subagents. Give each a trivial task that only replies OK.”
3. The parent reports that T3's injected “One child per named model” instruction prevents it from starting the second child, even after the user explicitly requests two.

Live verification

A minimal launch through delegate_task completed successfully with:

{
  "target": {
    "providerInstanceId": "codex",
    "model": "gpt-6.1-sol",
    "options": { "reasoningEffort": "xhigh" }
  },
  "role": "test",
  "isolation": "shared",
  "mode": "wait",
  "task": "Do not use tools, inspect files, modify anything, or launch subagents. Reply exactly: SOL_LAUNCH_OK"
}

Returned: status: completed, model gpt-6.1-sol, reasoningEffort: xhigh, and SOL_LAUNCH_OK. The child's transcript confirms that response.

The second launch was not attempted because the parent treats the injected rule as binding. This is not evidence of a one-agent limit in the scheduler or provider.

Source of the regression

PR #24850 added the unconditional sentence to packages/provider-core/src/server/orchestrationInstructions.ts.

The preceding file at a6aca345 has no such sentence. Current upstream main still contains it, and the active desktop session receives it.

Expected behavior / suggested fix

Honor the number of subagents the user explicitly requests, including multiple children with the same provider and model.

Remove the unconditional cap or qualify it, for example: “Honor explicitly requested counts per model. When multiple models are named without counts, create one child for each named model.”

Add an orchestration eval for a request to launch two children with the same model. It should require two distinct successful launches and should not accept one child plus work done by the parent, or substitution of a different model.

Environment

• Windows desktop, T3 Code Nightly 0.1.3-nightly.20261025.3682.
• Parent: Codex harness, gpt-6-astra, xhigh.
• Child: codex / gpt-6.1-sol, xhigh.
• No local application patches.

Impact

Explicitly requested parallel work using one chosen model is blocked by T3's own instructions. The single-child launch succeeds, but the parent refuses to attempt the requested second child.

Investigated and filed with Codex (GPT-6 Astra) at the user's request.