Configurable model routing rules for Orchestrator subagent delegation

[dkritarth]

Context & Idea

With Orchestrator V2 and multi-provider support, users frequently want to leverage the distinct strengths, speeds, and cost profiles of different models within a single orchestrated workflow.

For example, in a complex research/engineering workflow:

• Gemini 3.8 Flash for high-throughput literature review, arXiv paper research, and web searches.
• GPT-6 Luna (High reasoning) for monitoring long-running remote cluster jobs (e.g., HPCC / SLURM) and reporting back upon completion.
• Claude Opus 5.5 for overarching project direction, architecture planning, and critical reviews.
• GPT-6.1 for focused, repetitive implementation and boilerplate grunt work.

Current Pain Point

Right now, to achieve this, we have to specifically and manually mention these routing instructions in every thread/prompt (or via repository instructions like .t3/instructions.md) to steer the orchestrator when it calls delegate_task. Having a way to configure these model-routing descriptions or rules directly in T3 Code settings—so the orchestrator naturally and automatically dispatches to the preferred model for a given type of task—would be a big relief and quality-of-life improvement.

It's not urgent, but as Orchestrator V2 matures, having configurable orchestrator delegation policies could be a great direction for multi-agent workflows.

Potential Architecture

1. Settings / Config: Add an optional orchestratorRoutingRules array in settings.json specifying:
   • User description / task intent (e.g., "literature review, search papers")
   • Optional role ("research" | "implementation" | "review" | ...)
   • Target provider instance, model ID, and options (e.g., { providerInstanceId: "antigravity", model: "gemini-3.8-flash-high" }).
2. Instruction Injection: Dynamic injection of the user's routing guidelines into the system instructions in T3OrchestrationInstructions.ts.
3. Server-side Resolution: Fallback in OrchestratorMcpService.ts to match role or task description to the configured routing rules if no explicit model target is provided in delegate_task.
4. Settings UI: A simple management panel in Settings to add, reorder, or edit rules with provider and model pickers.

Opening this discussion to gather thoughts and feedback from the community and maintainers!

[pekth]

This can be done locally with your markdown files for agents to read. There is no need to hard-coded.

[andrelima-arch]

It would be really useful to have this configurable directly through the UI.

Cursor already has something similar, where you can select which subagent to use, and it will automatically be used whenever needed.

T3 Code could implement a similar approach, allowing users to select a specific agent or model as the default for subagent tasks. Whenever the orchestrator needs to delegate a task, it would automatically use the previously selected agent without requiring manual instructions in every prompt.

[ddmirolli]

Adding a concrete use case and local prototype to this proposal. I'd like maintainer feedback on direction and scope before opening a PR.

I'm building Model Topography / Workbench, which measures model configurations on software tasks at entry, middle, and senior responsibility levels. Topo applies those measurements to a structured subtask, with Maximize speed or Minimize cost, an explicit reliability floor and an account allowlist.

Agent instructions can request this behavior. An opt-in host hook would enforce it at delegation, including abstention and availability checks.

Proposed initial scope

• Off by default, with environment settings and project overrides.
• Route new, target-less T3-owned delegate_task calls. Preserve explicit targets and accepted-command replay. Exclude provider-native spawn tools and switching running threads.
• Give a local policy the structured task, objective and live provider/model/options catalogue. Accept an exact target or abstention. Recheck availability, project account restrictions and permissions before dispatch. Incomplete or invalid inputs block the routed request.
• Keep executable paths in local operator configuration, outside RPC and project overrides.
• Record the objective, evidence snapshot, selected target and reasons. Full decision persistence remains a follow-up in our prototype.

I propose a small generic policy interface, with Topo as one adapter, rather than a built-in Topo dependency.

Local evidence and limits

The prototype uses T3 base 2131698181bd48a1d227553b9aa9e9c9fc9dd5fa. Its 238 focused tests cover the actual delegation hook, replay, exact options, fail-closed behavior, provider rechecks and host-date freshness. Authenticated web checks cover objectives and project inheritance/reset.

One real Codex smoke routed a target-less request to gpt-6-luna, medium effort, standard tier. The child completed its temporary-file task and T3 automatically resumed its parent to verify it. This proves dispatch and result delivery, not classification accuracy or savings. Task responsibility and workload mapping are currently supplied manually. Native mobile and Electron UI checks remain outstanding.

The patch and setup are available locally. No upstream PR or public fork has been opened for this prototype. Workbench's source repository remains private pending its clean public release.

Would this narrow hook fit T3's direction? Would maintainers prefer a generic local policy interface or an existing extension point? We can adapt to an agreed scope.

Prototype implementation used GPT-5.6 Terra through the Codex harness in T3 Code. CodeRabbit reviewed the implementation and correction.