---
title: "Claude Code: low effort for subagents only, measured"
description: "Since v2.1.292, Claude Code can set effort each time it launches a subagent. I measured time and estimated cost with search subagents at low and with the docs' \"time matters\" line."
url: https://udon-dev.com/en/notes/claude-code-subagent-effort/
lang: en
published: 2026-10-19
topic: [ai]
tags: ["claude", "claude-code", "opus-5-5", "subagents", "effort", "cost-management"]
---

# Claude Code: low effort for subagents only, measured

- Since v2.1.292, the Agent tool takes an effort argument. Ask in your prompt for "subagents at low" and those launches run at low
- With three lookups delegated in parallel, low-effort subagents cut wall time from 54 to 36 seconds and estimated cost from $0.58 to $0.38, with the same answers
- Adding only the "time matters" line did not shorten a single-subagent task. The documented method pairs it with an elapsed-time display to speed up parallel multi-agent work

In my [post on choosing effort levels](/en/notes/claude-code-usage-effort/), 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](https://code.claude.com/docs/en/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](https://code.claude.com/docs/en/sub-agents), 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):

```text
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.

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

## Time and cost with three lookups in parallel

According to the [headless documentation](https://code.claude.com/docs/en/headless), 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](https://code.claude.com/docs/en/costs) 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](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5-5) 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:

```text
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.