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 statusstopped 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):
ultrathinkin the interactive terminal now runs at thexhigheffort tier on several Claude 5.x models; the/code-reviewworkflow changed to set its effort level explicitly first, reservingmaxonly 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.