Sign up
View stargazersSign up

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

opened5d agobySSantaneu

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:

json
1{
2 "target": {
3 "providerInstanceId": "codex",
4 "model": "gpt-6.1-sol",
5 "options": { "reasoningEffort": "xhigh" }
6 },
7 "role": "test",
8 "isolation": "shared",
9 "mode": "wait",
10 "task": "Do not use tools, inspect files, modify anything, or launch subagents. Reply exactly: SOL_LAUNCH_OK"
11}

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.

JJulius Marminge5d ago

On current main e3592efe7f, I ran the exact request in the real web client on Linux with Codex 0.163.0: “Launch two Sol xhigh subagents. Give each a trivial task that only replies OK.”

With an Astra xhigh parent in an empty conversation, both Sol xhigh children completed with OK. Repeating in that conversation with a Sol xhigh parent also produced two distinct completed Sol xhigh children. The protocol log confirms that the injected “One child per named model” sentence was present during both attempts; no refusal occurred.

Please attach the failing parent conversation, including the request immediately before the refusal and any preceding instructions about subagent counts. Does the refusal also occur in a fresh conversation with only the request above? That context is missing from the report and would distinguish the failing case from these successful launches.

Runtime transcript and recorded model settings

Two completed Sol xhigh children in the real web client

Hhoop-ai5d ago
Synced from GitHub

Same here on Windows 11 (T3 Code nightly 0.1.3-nightly.20261025.3682, Codex Sol parent). The parent treats the line as a hard cap of one live child per model, and an explicit user message ("you may run more than one child per model") does not override it, because the line sits in the injected instructions above user turns. That blocks independent same-model work in separate worktrees, which is the main reason to use delegate_task for us.

Suggested wording for packages/provider-core/src/server/orchestrationInstructions.ts line 10, replacing One child per named model.:

When the user names models, start at least one child per named model; independent tasks may each get their own child, including several on the same model.

Or simply drop the sentence. Happy to test a nightly with the change.

JJulius Marminge4d ago

Reproduced in the current-main web app at commit 264969317c with a Sol xhigh parent: an explicit request for two identical-model worktree children was refused citing the injected one-child rule. #25153 replaces that sentence. The matching runtime sequence accepted the requested model and count after the change, with one worktree preparation timeout requiring a retry. Runtime proof. Scoped checks passed; CI remains pending.

JJulius Marminge14h ago

Closing: current main already covers this as of 3ed0688c10. If you still see it on a build that includes that commit, reply and we'll reopen.