Skip to main content
← All articles
ai

Claude Code shipped the per-subagent effort control my own config had been pretending existed

Claude Code shipped the per-subagent effort control my own config had been pretending existed

My own global Claude Code configuration has a section telling subagents to run at a specific reasoning-effort level depending on the task — low for mechanical lookups, up to a required high tier for anything touching production or unclear debugging. I wrote those rules as instructions for a model to interpret, because for a while that's all they were: guidance the model could follow or not, with no actual lever behind it. Checking the release history against my own config, that stopped being true over the course of four releases in October.

The actual feature

v2.1.292 (6 October) is the one that matters: "Added an effort parameter to the Agent tool, so Claude runs a sub-agent at the effort level you ask for." That's the difference between a written instruction and an actual mechanism — before this, asking a subagent to run at a given effort level was asking the model to self-regulate something it had no real control surface for; after it, it's an explicit parameter the dispatching call sets.

What shipped around it

  • v2.1.302 (16 October): fork subagents — ones that inherit the parent conversation's full context — turned on by default across claude -p, the Agent SDK, the desktop app, and VS Code, not just the terminal. An opt-out env var (CLAUDE_CODE_FORK_SUBAGENT=0) exists if you specifically don't want that.
  • v2.1.304 (19 October): /effort status stopped showing a guessed effort level when the setting is unset or on auto — a small fix, but the kind that matters if you were ever trying to debug why a task ran at a level you didn't expect.
  • v2.1.311 (26 October): ultrathink in the interactive terminal now runs at the xhigh effort tier on several Claude 5.x models; the /code-review workflow changed to set its effort level explicitly first, reserving max only for when it's actually asked for rather than defaulting to the most expensive tier.
  • v2.1.312 (27 October): the spinner, OpenTelemetry traces, and session transcripts now show the effort level actually in force, rather than a pick that hasn't been applied yet — closing a gap where you could set an effort level and not be able to confirm, from the UI, that it had actually taken.

Why I'm writing about this instead of another AI-agent trend piece

Most "AI agent tooling" writing is necessarily abstract, because most people describing a feature haven't used it as part of a real daily workflow yet. This one I can check against my own config directly: the low/medium/high/xhigh/max scheme in my global CLAUDE.md subagent rules — the same five names, in the same order — is exactly what showed up as the accepted effort values once the parameter landed. I'd been writing instructions in that shape for a model to interpret as best it could; the October release cycle is where those instructions started addressing an actual typed parameter rather than a convention I was hoping got followed.

What changed for me, concretely

Nothing about how I write the rules — the subagent-selection section of my config reads the same as it did before 6 October. What changed is confidence: when I dispatch a subagent for, say, debugging a production issue and mark it as requiring high effort, that's now an explicit parameter on the call rather than a hope expressed in a markdown file. For anyone else maintaining a CLAUDE.md with similar model-selection guidance, it's worth checking whether your own rules are still written as guidance for a model to interpret, or whether there's now an actual parameter in the tool you're using that should be setting it directly instead.

BM
Blue Moose
The moose behind Blue Moose. Full-stack PHP developer — Drupal by day, Symfony by night, tests always.