Claude Code: low effort for subagents only, measured

In my post on choosing effort levels, I covered switching the whole session’s effort with /effort. But when you hand lookups to subagents, the one hunting for files probably doesn’t need to think as deeply as the main agent that pulls everything together.

Since Claude Code v2.1.292, you can set effort each time a subagent is launched. I measured how much faster and cheaper things get when only the search subagents run at low, and whether the answers change.

What changed#

The v2.1.292 changelog says the Agent tool gained an effort argument, so a subagent can run at the requested effort. The Agent tool is what Claude uses to launch a subagent.

Before that, the only way to set effort per subagent was the effort field in its definition file. According to the subagent documentation, the settings now apply in this order:

1. The CLAUDE_CODE_EFFORT_LEVEL environment variable (if set, it overrides everything else)
2. The per-launch effort argument (Claude adds it when you ask in your prompt)
3. The effort field in the subagent’s definition file

A per-launch setting carries over when that subagent is resumed. It doesn’t apply to “fork” subagents, which inherit the conversation. The available levels depend on the model.

Does one line in the prompt really get you low?#

In a local repository (the source of this blog), I set up a task where three subagents each investigate one of the following in parallel, and the main agent summarizes:

1. How many check-*.mjs files are in scripts/, and which ones the build never calls
2. The trigger conditions of each file in .github/workflows/
3. The required fields in an article’s frontmatter

I counted the right answers in advance. There are 38 check-*.mjs files (23 excluding tests), and 9 are not called from the build. There are 10 workflows and 5 required fields.

I started the main agent with --effort high and compared runs with and without this line at the end of the prompt (written in Japanese in my test):

Run all three subagents at effort low.

Running claude -p with --output-format stream-json logs the arguments of every tool Claude calls. In the runs with the line, all three Agent tool calls had "effort": "low". Without it, there was no effort, and the subagents ran at high like the main agent.

{"subagent_type": "general-purpose", "effort": "low", "run_in_background": false}

Time and cost with three lookups in parallel#

According to the headless documentation, JSON output from claude -p includes the estimated cost as total_cost_usd. With stream-json, the final result line had the same field. To keep project hooks out of the timing, I ran with --setting-sources local, which skips user and project settings. Time is wall-clock time from start to finish of the command, one run per condition.

Condition	Time	Estimated cost	Output tokens
No setting (subagents also at high)	54.3 s	$0.58	11,474
Subagents at low	36.0 s	$0.38	6,158
Add the “time matters” line	37.4 s	$0.36	5,493
Both low and “time matters”	41.3 s	$0.41	5,786

All four conditions correctly returned the list of 9, the 10 workflows, and the 5 required fields. Output tokens and estimated cost are Opus 5.5 totals, subagents included. The estimated cost is computed from token counts at list price and, as the cost documentation notes, is not your bill. On Pro and Max plans, this usage comes out of the plan’s allowance.

Two runs each, one subagent at a time#

The table above has one run per condition, so it says nothing about variance. So I took just the first lookup (the check-*.mjs files the build doesn’t call), gave it to a single subagent, and ran each condition twice. Time and tool-call counts are the values Claude Code reports when the subagent finishes.

Condition	Time (run 1, run 2)	Tool calls
high	19.2 s, 18.0 s	4, 3
low	12.3 s, 10.9 s	3, 2
high + “time matters”	18.3 s, 23.6 s	3, 4
low + “time matters”	11.6 s, 14.3 s	2, 3

All eight runs got the list of 9 right. Low was roughly 40% faster than high and made about one fewer tool call. The high runs often added a note that they had grepped the scripts the build calls to check for indirect calls, and that extra work appears to account for the time difference.

What the “time matters” line is for#

The Opus 5.5 prompting documentation includes guidance for setups where a main agent hands work to subagents. If you can’t predict a sensible time budget, it suggests showing the elapsed time alone and adding this line to the system prompt:

Time matters here: do not spend time that can be avoided, and the earlier a correct result is obtained, the better.

The same documentation says that in Anthropic’s evaluations, both signals (elapsed time against a budget, and elapsed time with this line) made small agent teams finish sooner than a single agent working without them. It also explains the difference: lowering effort reduces the work itself, while showing a time budget mainly increases the number of agents running in parallel. It adds that time pressure may slightly reduce how much the agents research and verify, so you should check answer quality on your own tasks.

My test didn’t show elapsed time in messages. It only added this one line to the prompt, so it isn’t the documented method itself. Under that condition, the line did not shorten the single-subagent task. That task already finishes in 2 to 4 tool calls, so there’s likely no room to parallelize. In the three-way parallel task, the main agent in the run with the line launched the subagents in the background, and the time was about the same as the run with low specified. With one run each, I can’t say whether that difference came from the line.

Low for lookups with a fixed answer, high for deep checks#

For lookups with a fixed right answer, like finding files and listing them, it seems fine to set only the subagents to low. The main agent stays at high, so the effort of the agent doing the synthesis doesn’t change.

If you use a subagent with the same role every time, writing effort: low in its definition file means you can’t forget to ask. On the other hand, for lookups where you want indirect calls checked too, high looked deeper. The “time matters” line seems better suited to long tasks that run many agents in parallel.