Why does T3 v0.1.1 use delegate_task for same-model subagents?

[thomlei]

Hi! Thanks for T3 Code. I enjoy it.

Since updating to v0.1.1, T3 Code has become unusable for my long-running agent workflows. I’m unsure whether this is a bug or intended behavior.

Problem

I repeated the same workflow with the same prompt, settings, and data, using gpt-6.1-sol at xhigh:

• Earlier T3 runs (v0.1.0) used native subagent orchestration and completed successfully.
• A recent T3 run (v0.1.1) used delegate_task. It took roughly twice as long and consumed about 2.5× as much of my Codex allowance as earlier runs.
• Another switched from Codex to Claude after a “model capacity error,” without my permission. It exhausted my 5-hour Claude allowance and got stuck.
• The same workflow still completes normally in Codex CLI through PowerShell.

Delegation instructions

T3 Code’s injected orchestration instructions say:

Prefer native subagent tools for same-provider work only when they support the chosen model and no model options are requested or inherited.

They also require:

When model options are requested or the child keeps the parent's provider instance and model with nonempty inheritedOptions from orchestrator_capabilities, use delegate_task even for native-supported models.

These rules seem to always invoke delegate_task even for the same provider, model, and settings when inherited options are present.

Is this intended behavior?

Suggestion

I like cross-provider delegation. I’d prefer these rules:

1. Use native subagent tools by default.
2. Use delegate_task when the user explicitly requests a different provider, model, or reasoning effort, or a skill requires specific settings.
3. Offer an opt-in toggle for automatic provider, model, and effort selection. Let users set preferences in AGENTS.md or a dedicated Markdown file.

I may be missing a reason for requiring delegate_task here. Happy to hear it!

[leenlbma]

From what I can see in the source, this is intended behavior, and the trigger is your xhigh setting.

Why delegate_task gets picked

The injected rule lives in packages/provider-core/src/server/orchestrationInstructions.ts, and the same wording is in the delegate_task tool description in apps/server/src/mcp/toolkits/orchestrator/tools.ts. It says to use delegate_task "when model options are requested or the child keeps the parent's provider instance and model with nonempty inheritedOptions", and gives the reason: "Native subagents cannot reliably apply T3 model options."

Reasoning effort is one of those options (Codex reasoningEffort, Claude effort). Running the parent at xhigh means inheritedOptions is never empty, so every same-model child goes through delegate_task. The goal is that children really run at xhigh instead of silently dropping to a default. The cost is a full T3 child thread for each task, which matches the slowdown and the roughly 2.5× usage you saw.

Workarounds until there's a toggle

• Run the parent thread with default model options. With no inherited options, the "prefer native subagents" branch applies again. You lose xhigh on the children, which is the trade-off the rule is guarding against.
• Tell the agent explicitly, in your prompt or AGENTS.md, to use native subagents and accept default effort for them. I haven't tested whether this reliably wins over the injected instructions.
• If you keep delegate_task, the docs say explicit target.options override inherited values and that [] / {} clear them. That lets you run cheap children without changing the parent.

The Claude switch

I couldn't find anything in those instructions telling the agent to switch providers after a capacity error. That looks like a separate fallback behavior, and it's worth its own issue with logs, especially since it used up your Claude allowance without asking.

Your three suggested rules sound reasonable to me, particularly an opt-in for automatic provider and effort selection. The maintainers would need to say whether that's on the roadmap.