Skip to content

feat: per-task model/provider overrides in delegate_task #15789

@djmcnay

Description

@djmcnay

Feature Request: Per-task model/provider overrides in delegate_task

Problem

delegate_task currently assigns all subagents the same model/provider pair, configured via delegation.model / delegation.provider in config.yaml. There is no way to route different sub-tasks to different models within a single delegation call.

This forces a trade-off: you either configure the delegation model for expensive high-quality work (and waste tokens on trivial summaries), or for cheap/fast work (and get poor results on complex analysis). There's no middle ground without making multiple delegation calls and manually switching config between them.

Use Cases

  1. Mixed-cost batch processing — One subagent does a cheap text summarisation (deepseek-v4-flash), a second does code review (gpt-5.5), a third does a web research task (gemma4). All in one delegate_task call.

  2. Smart routing with cheap fallbacks — The main delegation config defaults to the expensive model, but individual task items can override down to a cheaper one when the task is trivial.

  3. Provider diversity — Some tasks need OpenRouter-specific models, others need Anthropic or Ollama Cloud. Per-task provider override enables this.

Proposed API

Add two optional fields to each task item in the tasks array:

{
    "goal": "Summarise this text",        # required (existing)
    "context": "...",                      # optional (existing)
    "toolsets": ["terminal", "file"],      # optional (existing)
    "model": "deepseek-v4-flash",         # NEW: per-task model override
    "provider": "ollama-cloud",           # NEW: per-task provider override
}

And corresponding optional top-level parameters for the single-task mode.

Implementation Sketch

The change is localised to tools/delegate_tool.py:

1. Schema (DELEGATE_TASK_SCHEMA)

Add "model" and "provider" to the task item properties (lines ~2090-2114):

"model": {
    "type": "string",
    "description": "Per-task model override. Overrides delegation.model for this task only.",
},
"provider": {
    "type": "string",
    "description": "Per-task provider override (e.g. 'openrouter', 'ollama-cloud'). Overrides delegation.provider for this task only.",
},

Also add top-level model and provider to the main properties block for parity in single-task mode.

2. Credential resolution in delegate_task() (lines ~1625-1655)

Currently each child is built with:

model=creds["model"],           # single global delegation model
override_provider=creds["provider"],
override_base_url=creds["base_url"],
override_api_key=creds["api_key"],
override_api_mode=creds["api_mode"],

When a per-task model or provider is present, it should resolve fresh credentials for that specific child instead of using the global delegation config. This could work as:

  • If per-task provider is set → resolve full credentials for that provider (using resolve_runtime_provider or the provider system)
  • If only per-task model is set → use same provider as delegation config, but with the overridden model name
  • If neither is set → existing behaviour (use delegation config)

3. _resolve_delegation_credentials() (line ~1885)

This function could be extended or a new helper created that resolves credentials for a given (model, provider) pair, reusing the same resolve_runtime_provider mechanism already in use.

Backward Compatibility

Fully backward compatible. Both new fields are optional. The "required": ["goal"] constraint on task items stays unchanged. When neither model nor provider is specified on a task, behaviour is identical to current releases.

Why Not Just Use Multiple delegate_task Calls?

You can already do this manually, but it's cumbersome:

  • You'd need to track results across calls
  • You lose the unified spinner/progress display
  • The parallelism is capped by what you can manually schedule
  • It requires the calling agent to know about model routing strategy explicitly

Per-task model routing lets the agent itself decide which model suits each subtask, keeping the parent context clean.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3Low — cosmetic, nice to havetool/delegateSubagent delegationtype/featureNew feature or request

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions