Skip to content

Agent definition ai.model is not consulted when spawning sub-agent tasks #3038

@unthought

Description

@unthought

Agent definition ai.model is not consulted when spawning sub-agent tasks

Summary

The ai.model field in agent .md definition files is documented and parsed but not used when the task service creates sub-agent workspaces. Sub-agents always inherit the parent session's model, regardless of what ai.model is set to in the agent definition.

This makes it impossible for custom agent definitions to pin themselves to a specific model — e.g., running review agents on openai:gpt-5.4 while the parent session uses anthropic:claude-opus-4-6.

Reproduction

  1. Create a custom agent definition with a pinned model:

    ---
    name: GPT Review
    base: exec
    subagent:
      runnable: true
    ai:
      model: openai:gpt-5.4
      thinkingLevel: high
    ---
    A review agent pinned to GPT-5.4.
  2. In a session running on anthropic:claude-opus-4-6, spawn the agent:

    task({ agentId: "gpt-review", prompt: "Review this file...", title: "test" })
    
  3. Expected: Sub-agent runs on openai:gpt-5.4 as specified in its definition.

  4. Actual: Sub-agent runs on anthropic:claude-opus-4-6 (inherited from parent).

Root cause

There are two independent model resolution paths, and the one that matters for sub-agents doesn't read the agent definition:

Task Service path (taskService.ts ~line 1053-1068)

This runs when task tool creates the workspace. Resolution order:

  1. cfg.agentAiDefaults[agentId].modelString — from app config (Settings UI)
  2. args.modelString — parent's MUX_MODEL_STRING env var
  3. parentAiSettings.model — workspace-level settings
  4. defaultModel — hardcoded fallback

The agent descriptor's aiDefaults.model (from the .md file) is not in this chain.

ACP Session Loader path (resolveAgentAiSettings.ts ~line 77-119)

This runs when the client connects to a workspace. It does consult descriptor.aiDefaults as a fallback — but by then, aiSettings have already been persisted by the task service with the parent's model, so the .md value is shadowed.

thinkingLevel has the same gap

The task service's thinking level resolution also skips the agent descriptor's ai.thinkingLevel. The same fix should cover both fields.

Suggested fix

In the task service model resolution, insert the agent descriptor's aiDefaults between the app config check and the parent model fallback. The descriptor is already parsed and available — it just needs to be wired in.

Proposed resolution order:

  1. args.modelString — explicit call-site request from parent
  2. cfg.agentAiDefaults[agentId] — app config / Settings UI
  3. agentDescriptor.aiDefaults — from agent .md definition ← add this
  4. parentAiSettings.model — inherited ambient model
  5. defaultModel

This preserves the app config as the highest-priority override (Settings UI wins), makes agent definitions work as documented, and falls back to parent model inheritance when no model is specified.

Workaround

Per-agent model overrides can be configured via the agentAiDefaults key in ~/.mux/config.json. This path is consulted by the task service. However, this is a global setting that applies to all sessions, and it's not portable — agent definitions should be the authoritative source for agent-specific defaults.

Environment

  • Mux version: v0.21.0
  • Agent definitions with ai.model set in frontmatter
  • Sub-agents spawned via task tool

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions