[Feature Request]: Configurable model routing rules for Orchestrator subagent delegation #15181

Summary

Add configurable model-routing rules to T3 Code settings so users can define which provider and model the orchestrator invokes for specific subtasks and roles when delegating work via delegate_task.

Motivation & Context

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:

• 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.

Right now, we have to specifically mention these routing instructions manually in every thread or prompt to steer the orchestrator. Having this handled automatically in the chat with the agent based on configured preferences would be a relief and a significant quality-of-life improvement. This is not urgent, but something to consider as Orchestrator V2 matures.

Current Behavior

• Subagents delegated via delegate_task inherit the parent thread's provider and model by default unless the orchestrator model decides to override target.providerInstanceId and target.model.
• There is no central configuration in Settings or settings.json that informs the orchestrator of user-defined model preferences or task-to-model routing policies.
• Users must repeatedly specify routing guidelines via ad-hoc chat prompts or manual repository instructions.

Proposed Solution

1. Settings Schema (packages/contracts/src/settings.ts)

Introduce an optional orchestratorRoutingRules collection in ServerSettings:

export interface OrchestratorModelRoutingRule {
  readonly id: string;
  readonly description: string; // e.g., "Literature review, web search, reading research papers"
  readonly role?: "implementation" | "research" | "review" | "design" | "test" | "general";
  readonly target: {
    readonly providerInstanceId: string;
    readonly model: string;
    readonly options?: Array<{ id: string; value: string | boolean }>;
  };
}

export interface ServerSettings {
  // ...
  readonly orchestratorRoutingRules?: ReadonlyArray<OrchestratorModelRoutingRule>;
}

2. Instruction Injection (apps/server/src/provider/T3OrchestrationInstructions.ts)

When compiling the orchestration prompt for the root agent, append the user-configured routing matrix to the system prompt:

### Orchestrator Delegation Rules
When selecting target models for subtasks in `delegate_task`, follow these user-defined routing rules:
- [Research / Literature]: Use `antigravity` (`gemini-3.8-flash-high`)
- [Experiment Monitoring]: Use `codex` (`gpt-6-luna` with high reasoning)
- [Architecture & Planning]: Use `claudeAgent` (`claude-opus-5-5`)
- [Implementation / Grunt work]: Use `codex` (`gpt-6.1-sol`)

3. Server-side MCP Fallback Resolution (apps/server/src/mcp/OrchestratorMcpService.ts)

If a delegated task call supplies a matching role (e.g., role: "research") without an explicit target.model, or if target is omitted, OrchestratorMcpService resolves the model from the configured routing rules before falling back to parent thread inheritance.

4. Settings UI (apps/web/src/components/settings/)

Add a dedicated "Orchestrator Routing" section in T3 Code Settings allowing users to add, edit, enable/disable, and reorder routing rules with dropdown selectors for available providers and models.

Alternatives Considered

• Instruction-only files (.t3/instructions.md): Works as a prompt-level workaround today, but requires manual setup per project and lacks UI visibility, validation against installed providers, or server-level fallback for tools delegating by role.