[FEATURE] Agent Teams: Support per-teammate effort tier at spawn

Resolved 💬 3 comments Opened Apr 18, 2026 by tlmader Closed May 26, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet. Closest match is #32110 (per-teammate model config) but it does not cover effort tier. No dedicated issue for per-teammate effort.
  • [x] This is a single feature request (not multiple features).

Problem Statement

When orchestrating multi-teammate workflows with Agent Teams, the Agent tool accepts a model parameter but has no structured parameter for reasoning effort (low | medium | high | xhigh | max). This means every spawned teammate inherits a default effort tier — the lead cannot assign xhigh to analytical/architectural stages (planning, adversarial review) while keeping medium or low for mechanical stages (CI watchdog, baseline check, PR thread reply loop).

Workarounds attempted:

  1. Natural-language phrasing in the prompt body (e.g. "Use opus with xhigh effort"). Not reliably honored — teammate's actual effort appears tied to the lead's session-level tier at spawn, not parsed from the prompt.
  2. Sending a mid-session SendMessage asking the teammate to "apply xhigh behavior." Not effective — effort is bound at spawn, a runtime message cannot change it.
  3. Shutting the teammate down and respawning. Works only for model selection (which has a structured param); effort still falls back to the lead's tier.

The result is either over-spending (run the whole lead+team at max) or under-spending (run at default and accept shallower reasoning on the stages that actually need depth).

Proposed Solution

Add a structured effort parameter to the Agent tool schema, alongside the existing model parameter:

Agent({
  subagent_type: "general-purpose",
  team_name: "issue-871-example",
  name: "planner",
  model: "opus",
  effort: "xhigh",    // <-- new
  prompt: "..."
})

Semantics:

  • Accepts the same tier values as CLAUDE_CODE_EFFORT_LEVEL: low | medium | high | xhigh | max.
  • If omitted: inherit lead's effort tier (current behavior).
  • Applies only to this teammate's spawn — does not affect the lead or other teammates.
  • Visible in ~/.claude/teams/{team}/config.json under the member entry for debugging.

Alternative Solutions

  • Status quo (workaround): document natural-language effort in skill prompts. Observed unreliable in practice — see "Problem Statement" above.
  • Per-teammate env var override: export CLAUDE_CODE_EFFORT_LEVEL before the Agent spawn. Does not work because the env var is read at session start, not at Agent subprocess spawn.
  • Separate sessions per tier: run each teammate in its own Claude Code session invoked with claude --effort xhigh. Defeats the purpose of Agent Teams (shared task list, inbox delivery, coordinated shutdown).

Priority

Medium - Would be very helpful

Feature Category

Developer tools/SDK

Use Case Example

Building a skill (super-team) that orchestrates a 5-teammate pipeline to take a GitHub issue from plan to PR:

  1. planner (opus, xhigh) — novel AC decomposition, E2E mapping architecture.
  2. executor (sonnet, high) — pattern-driven TDD implementation.
  3. reviewer (opus, xhigh) — adversarial code review.
  4. finisher (sonnet, medium) — mechanical push + PR open + CI watch.
  5. comment-handler (sonnet, medium) — reply/resolve review threads.

Plus a throwaway baseline-check teammate at sonnet+low for a single pnpm test run.

Today I can specify the model column but the effort column can only be expressed in prose. That makes cost forecasting and quality gating imprecise — the architectural stages degrade to default effort, and the mechanical stages overspend when the lead runs at xhigh.

With a structured effort param, the skill authoring cost/quality matrix becomes enforceable by the harness rather than hope-based.

Additional Context

Observed on Claude Code CLI, Agent Teams experimental harness (CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1).

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗