Which Model Did My Claude Code Subagent Use? How to Check

To see which model a Claude Code subagent actually ran on, open the subagent’s transcript and read the model field on its assistant messages, then compare it with what you asked for. The docs name one other way: run /tasks (v2.1.242 or later), and Claude Code shows the model on the subagent’s row (checked 2026-10-23). Do not rely on asking the agent, because a self-report is weak evidence.

In a snapshot of our own logs (one account, 30 days to 2026-10-23, Claude Code 2.1.280 to 2.1.309, almost all background-type spawns), 3,039 of 3,039 spawns where the requested model’s tier differed from the parent session’s ran on the requested tier. This is a count from one setup, not a general rule. All counts are from a snapshot taken 2026-10-23; live sessions add a few dozen spawns a day. The details, the method and the limits are below.

Which model does a subagent use?

The docs list a resolution order. This is a paraphrase of the page as read on 2026-10-23 (sub-agents docs):

1. The model parameter passed on that one call to the Agent tool.
2. The model field in the agent’s own file (its frontmatter, the settings block at the top). The value inherit selects the main model.
3. The CLAUDE_CODE_SUBAGENT_MODEL environment variable.
4. The main conversation’s model.

Three details matter. Before v2.1.251 the environment variable came first and overrode both the call parameter and the frontmatter, so older advice may describe a different order. To force one model for every subagent, you set that variable together with CLAUDE_CODE_SUBAGENT_MODEL_FORCE set to 1, which needs v2.1.257 or later; with force on, the model field in agent files is ignored. And a family alias such as opus can resolve to the main model when the main model is already in that family, so an opus request under an Opus parent can never show a difference.

Forks are separate. Per the docs, a fork runs on the same model as the main session, and fork mode is on by default from v2.1.302 (in interactive terminal sessions from v2.1.232).

How do I check what actually ran?

The docs say /tasks. For checking after the fact, or in bulk, use the transcripts. These are the steps we followed. The transcript layout is an internal detail of the current release and can change, so note your Claude Code version.

1. Find the subagent transcripts. In our install they sit in a subagents/ folder under each session, in ~/.claude/projects/.
2. Next to each transcript is a small meta.json file with a toolUseId. Use it to find the matching Agent tool call in the parent session file.
3. Read the model the parent used for that call, and the model field of the assistant messages in the subagent transcript.
4. Work out what you asked for: the call parameter if there was one, otherwise the agent file’s model.
5. Compare tiers (opus, sonnet, haiku), not exact ids.

Two traps. First, the meta.json records the model that was requested, not the one that ran (GitHub issue #85592, confirmed by a maintainer on 2.1.233), so it cannot settle the question. Second, an alias is not a pin. In our window, the alias sonnet resolved to two different model ids, and opus to two as well. That is why we compare tiers.

We wrapped these steps in a read-only script that prints only totals. We are not publishing it with this guide, so the steps above are the method.

What did we find?

Our method: the steps above, run over a 30-day window ending 2026-10-23. Spawn timestamps ran from 2026-09-24 to 2026-10-23, and the spawn lines show Claude Code versions 2.1.280 to 2.1.309. We found 4,604 Agent calls and joined 4,590 of them to a subagent transcript.

The test only means something when inheritance and obedience would give different answers. We call a spawn discriminating when the tier we asked for differs from the parent session’s tier. If you asked for Sonnet under an Opus parent and got Sonnet, the subagent did not just inherit.

• 3,039 spawns were discriminating, and all 3,039 ran on the tier we asked for.
• 2,839 of those carried an explicit model parameter.
• 200 had no parameter, so only the agent file’s model field decided: 126 Sonnet-frontmatter agents under an Opus parent and 74 Opus-frontmatter agents under a Sonnet parent. All 200 ran on the frontmatter tier.
• 1,529 spawns asked for the parent’s own tier. They all matched, but they prove nothing, because inheritance gives the same answer.

Most of our own spawns carry an explicit parameter, so the strongest statement we can make about the frontmatter field is about those 200, not the 3,039. A 7-day run agreed: 55 of 55 frontmatter-only discriminating spawns.

Then there is the small group of 22 spawns where we could see no model setting: 19 built-in or untyped, plus 3 of a custom type whose agent file we could not find, so its setting is unknown. This is where inheritance shows up. 15 ran on the parent’s tier: 10 Explore, 4 general-purpose and 1 spawn with no agent type. 7 ran on Haiku: 4 claude-code-guide and 3 of a custom type. The Haiku result for claude-code-guide matches the docs, which list it as a Haiku agent.

Limits, plainly:

• Our setup only, and almost all spawns (4,582 of 4,590) were background-type per the meta files.
• The frontmatter column is read from today’s agent files, not as they were on each spawn date.
• The environment variable was not set in our shell or user settings. Organisation-managed settings could not be inspected.
• We did not test whether the open issues below still reproduce on 2.1.309.
• The set of spawns is not a sample of Claude Code users: it is every Agent call on one machine’s logs, with agent files read as they are today.

Why did our old rule go stale?

On 2026-05-25 we wrote a global rule: always pass model explicitly, because our notes said the Agent tool ignored the frontmatter model and workers ran on the parent. On 2026-10-11, on Claude Code 2.1.296, a test with one Sonnet-frontmatter agent behaved the other way, and that single self-report was challenged the same day.

We never recorded a Claude Code version in the May notes. We never tested the May behaviour again on a recorded version, so we cannot say whether it was ever true on the version we ran. The rule had no Claude Code version attached, so nobody could check whether it still applied. If you keep rules about tool behaviour, write down the version and the test, and re-run the test after updates.

Where does the bill go?

First, what “cost” means here. It is the list-price-equivalent cost that our usage tool computes from local transcripts. It is not a bill. Each share below is a share of that computed total, over the 7 days ending 2026-10-23:

• Opus-priced share: the part of cost from work billed at the Opus rate, about 66 percent.
• Main versus subagent: main sessions about 71 percent, subagent sessions about 29 percent.
• Cache-read share: the part of cost from reading already-cached context again, about 67 percent.

This is our setup, an Opus orchestrator on purpose, not a general fact. The Opus share was 78 percent in a similar read on 2026-10-05, with main sessions at 83 percent (82.5 rounded) and cache reads at 71 percent. It fell from 78 to 66 percent between two 7-day reads, and we did not investigate why.

The lesson is about order of work. Cost sat mostly in the main session and in cache reads, so forcing subagents onto a cheaper model could not have fixed most of it. Our usage tool also cannot tie cost to a single spawn, so we cannot say how much the routed spawns saved. The docs, as read, say nothing about splitting cost this way. They only suggest routing tasks to lower-cost models.

What should I do?

1. Check one real spawn today: /tasks, or the model field in the subagent transcript. Do not ask the agent.
2. Pass model explicitly where it matters, and give every agent file a model too, since the case with neither is where inheritance shows up.
3. If you set CLAUDE_CODE_SUBAGENT_MODEL, set the FORCE variant only on purpose: with FORCE on, it overrides the call parameter and the agent files’ model field (v2.1.257 or later).
4. Write the Claude Code version next to any routing rule, and re-test after updates.
5. Split spend by main versus subagent, by model tier and by cache reads before deciding what to fix. Do not move judgment work to a cheaper model just to cut the number; saving money is a bonus of delegation, not its point.

Related reports, as of 2026-10-23, all open:

• #83920: an explicit model parameter ignored on 2.1.220, based on what the reporter saw in the UI; 9 thumbs-up.
• #85592: on 2.1.233 a maintainer confirmed the environment pin overrode an explicit per-call model with no warning. The docs now order the per-call parameter first (since v2.1.251) unless FORCE is set; we did not retest.
• #87815: a parallel fleet inherited the session’s premium tier without warning.
• #92660: subagents inherit the session’s effort level. The docs now describe a per-call effort parameter (v2.1.292 or later); the issue is still open.

We did not re-test any of them on 2.1.309.

Next step

If you want the delegation setup we use, with worker agents and the checks around them, see what the AccrueDev course covers. If a rule in your CLAUDE.md is being ignored too, read why Claude Code ignores your CLAUDE.md.