The built-in agent types in Claude Code

Ask most Claude Code users to name its agent types and you get two answers: Explore and Plan. Those are the two you see named in the terminal, so those are the two people know.

There are five. The other three run just as often, and one of them does a large share of the actual work in every session. You have been using all five for months. You have only been able to name two of them.

The reason the gap exists is not that the other three are hidden. It is that two of them are quiet by design and one of them does its job under a label that does not announce what kind of agent it is. So the average user builds a mental model with two slots in it, and every step Claude takes gets sorted into one of those two slots or into a vague third bucket called “Claude is doing something.” That third bucket is where the cost hides. It is where a step that should have been a cheap read gets mistaken for expensive work, and where an expensive fork gets mistaken for a cheap read. Both errors come from the same root: you cannot reason about a thing you cannot name.

This is the full catalog. It matters for a concrete reason, not as trivia: each agent type has a different model, a different set of tools, and a different cost, so the moment you can name the type Claude just spawned, you can predict what that step will cost you and whether it was the right call. Think of it the way you would think about hiring. You would not staff a job without knowing whether the person on it is a junior researcher, a senior engineer, or someone wired up to do one specific small task. The agent type is exactly that distinction. An unnamed agent is an unaccountable one. Five names fixes that.

The five agent types

Claude Code ships with five built-in agent types. The subagents documentation is the source of record, and it states the operating principle plainly: “Claude Code includes built-in subagents that Claude automatically uses when appropriate. Each inherits the parent conversation’s permissions with additional tool restrictions.”

The five are Explore, Plan, general-purpose, statusline-setup, and claude-code-guide. They split cleanly into three groups. Explore and Plan are the research pair: read-focused, deliberately stripped down for speed. General-purpose is the worker: the one with full tools that does complex, multi-step jobs. And statusline-setup and claude-code-guide are the helpers: narrow utilities wired to specific moments, which you will almost never think about and never need to invoke yourself. Every one of them is a subagent in the sense covered in what a subagent is, which means each runs in its own context window and reports a summary back. The agent type is just the preset: which model it runs on and which tools it gets. You can also define your own types as custom subagents, but the five built-ins cover the work most sessions actually do.

The three-group split is worth holding onto, because it maps directly onto the two things you actually care about: what an agent is allowed to touch, and what it costs to run. The research pair is read-only and cheap. The worker can write and is expensive. The helpers are tiny and pinned to a fixed model. If you remember nothing else from this catalog, remember that shape, because it tells you the rough cost of a step before you know anything else about it. See an agent from the research pair, and you know it is reading and the bill is small. See the worker, and you know it can change files and the bill is the same rate as your main conversation. The names are not decoration. Each one is a label for a budget.

It also helps to be clear about what these presets are not. They are not separate AI products, and they are not models you pick from a menu. They are configurations of the same underlying system, each tuned for a job. The phrase “Claude automatically uses when appropriate” in the documentation carries the whole design: you do not choose the agent type, Claude does, on the fly, every time it decides a piece of work is better done in a fresh context. That makes the routing invisible by default. It is good that it is invisible, because picking the type by hand on every step would be exhausting. But invisible is not the same as unknowable, and the point of learning the five names is to make a fast automatic decision into one you can still inspect after the fact.

Explore, the read-only one

Explore is the agent type you see most and understand least. Claude delegates to it when, in the documentation’s words, “it needs to search or understand a codebase without making changes.” It reads. It does not write. That restriction is the point: a read-only researcher cannot break anything, and its findings stay out of your main conversation.

Both halves of that last sentence earn their keep. The cannot-break-anything half is the obvious safety win. If an agent has no write tools, there is no path by which a bad search or a confused step turns into an edited file, a deleted line, or a broken build. You can let it loose on a large codebase and the worst case is that it reads the wrong files and reports something unhelpful. The stays-out-of-your-main-conversation half is the quieter win, and over a long session it is the bigger one. When Explore reads forty files to answer one question, those forty files do not land in your main context window. Only the answer does. Your main conversation stays short, which keeps it fast and keeps it cheap, because every later turn is billed against whatever context has piled up. Explore is, in effect, a way to ask an expensive question and only pay to keep the cheap answer.

Two details make Explore worth knowing by name. First, it has a thoroughness dial. When Claude invokes Explore it picks a level: quick for a targeted lookup, medium for balanced exploration, very thorough for a wide sweep. More thorough means more files read, which means more tokens, so the level Claude chooses is a cost decision being made on your behalf. Picture a session where you ask a small, pointed question, “where is this one constant defined,” and Claude reaches for a very thorough sweep. That is overspending on a job that needed a quick lookup. Picture the reverse: you ask Claude to understand how a whole feature hangs together and it does a quick pass, then proposes a change built on a half-read picture. That is underspending, and it costs you later in rework. Knowing the dial exists lets you read those moments. If a result feels thin, you can ask Claude to look harder. If a simple question burned a lot of tokens, you know which dial got turned too far.

Second, Explore is deliberately lightweight. It skips your CLAUDE.md and the session’s git status to stay fast and cheap. That is a small thing with a real consequence: an Explore agent does not know your project conventions, because it was never told them. It is a researcher, not a contributor, and it is built that way on purpose. So when an Explore result comes back and says “here is how this works,” treat it as a report on what the code does, not a verdict on what your project wants done. The agent that reads your conventions and acts on them is a different one. Explore tells you the lay of the land. It does not tell you the house rules, because it never read them.

Plan, the plan-mode one

Plan is Explore’s close relative, scoped to one situation. When you are in plan mode and Claude needs to understand your codebase before proposing a plan, it delegates that research to the Plan agent. Like Explore, Plan skips CLAUDE.md and git status to keep the research fast and inexpensive.

If Plan and Explore both do read-only research, a fair question is why there are two of them at all. Why not point plan mode at Explore and be done? The answer is the structural problem Plan exists to solve, and the documentation names it: delegating research to a Plan subagent “prevents infinite nesting (subagents cannot spawn other subagents) while still gathering necessary context.” Read that carefully. Subagents cannot spawn subagents. So when you are in plan mode, which is itself running as an agent, it cannot just spin up more agents to do its research.

That no-nesting rule is not an arbitrary limit. It is what stops a session from fanning out without bound. Imagine if any subagent could spawn its own subagents. A single planning step could open a research agent, which opens three more, each of which opens three more, and now you have a tree of agents you never asked for, all billing tokens, all reporting up a chain you cannot see the bottom of. The flat rule kills that. One level of delegation, then no further. The cost stays legible because the depth is fixed. The Plan type is what lets plan mode still gather context inside that flat rule. It is the sanctioned hop: plan mode cannot recurse, so it hands the research to Plan, gets a summary, and uses that summary to build the plan. You will rarely think about Plan directly, because it only appears inside plan mode and the label you see on screen is the planning work, not the agent type. But it is the reason plan mode can explore your codebase at all. Without it, plan mode would either be blind to your code or would need a recursion rule that makes runaway cost the default.

General-purpose, the catch-all

General-purpose is the type that does the heavy work, and it is the one most worth understanding in depth. It is the agent Claude routes to for complex, multi-step tasks that need both exploration and action. Where Explore only reads and Plan only researches, general-purpose has the full tool set and can change your files.

That full tool set is the line that separates it from the research pair, and the separation cuts both ways. It is what makes general-purpose able to finish a real task end to end, the kind that needs to read some code, decide on a change, and then make the change. Explore could do the reading and stop. General-purpose reads, then acts. But the same write access that makes it useful is what makes it the one to be careful with. A read-only agent has a worst case of an unhelpful answer. A general-purpose agent has a worst case of an unhelpful change, and an unhelpful change is something you then have to find and undo. The capability and the risk are the same property looked at from two sides.

It is also the most expensive of the five, because its model inherits from your main conversation rather than dropping to something cheaper. Sit with what “inherits from your main conversation” means for the bill. The research pair and the helpers can each be run on a lighter model because their jobs are bounded. General-purpose cannot, because its job is open-ended, so it runs at the same rate as the conversation you are already paying for. A second cost multiplier can stack on top of that, but only with a setting enabled: Claude Code has an experimental fork mode that hands the agent a copy of your conversation instead of a fresh empty context, so the worker starts full rather than blank. There is enough to say about that one type that it has its own article: how the general-purpose agent works covers the fork behavior, the routing triggers, and the real cost.

For this catalog, the thing to hold onto is its place in the set. General-purpose is the generalist among four specialists. When the task does not fit Explore or Plan or a helper, it lands here, which is exactly why it does so much of your work. The practical read on that is a question of scope. If what you need is a search, the right answer is a read-only agent, and a general-purpose agent on a search job is paying worker rates for researcher work. If what you need is a multi-step change with reading and editing braided together, general-purpose is the correct tool and a cheaper agent would fail to finish. The skill is not avoiding general-purpose. The skill is noticing when a task that got routed to it was really a read in disguise, and noticing when a job is really big enough that the worker rate is money well spent.

The two helper agents

The last two agent types are the ones nobody talks about, and that is appropriate, because they are utilities rather than workers. They still count, and naming them completes the picture. Leaving them out is how you end up with a four-agent mental model that has a hole in it. The hole does not cost you much, because these two are cheap, but a model with a known hole is worse than a model that is whole, because you stop trusting your own count.

statusline-setup runs on Sonnet, and Claude uses it when you run /statusline to configure your status line. claude-code-guide runs on the cheaper Haiku model, and Claude uses it when you ask a question about Claude Code itself, its features, settings, or commands. Notice the model choice in each case. A status-line configuration is a small, bounded job, so it gets Sonnet. Answering a documentation-style question is lighter still, so it gets Haiku. That is the same logic that runs through the whole catalog: match the agent to the weight of the work. The helpers are the clearest illustration of it, because their jobs are so narrow that the model can be pinned cheaply and left alone.

That pinning is the part worth pausing on. The worker agent cannot have its model fixed in advance, because nobody knows how hard the next task will be, so it inherits the heavy model to be safe. The helpers face the opposite situation. Their jobs are known in full ahead of time. A status-line setup is always a status-line setup. A question about Claude Code’s own features is always that and nothing larger. When the shape of the work is known and small, you do not need to reserve a heavy model just in case, because there is no “in case.” So the model gets pinned to the lightest one that does the job well, and that decision never has to be revisited. This is the whole catalog’s design rule stated in its simplest form: the more predictable a job is, the cheaper you can run it, and the helpers are predictable to the point that their cost is settled before they ever start. It is also a useful reminder that not every piece of work in a session is, or should be, an expensive one. Some of it is meant to be small, and the system is built so that the small things stay small.

You will never invoke these two yourself, and you do not need to. They are in this catalog for one reason: so that the next time you see an agent type scroll past in your terminal, all five names mean something. Explore is reading. Plan is researching for a plan. General-purpose is doing the real work, on your main model, at your main cost. The helpers are tidying up. Claude makes the routing call every time, fast and out of sight, and that is fine, that is the design. But the routing is a sequence of cost decisions, and a cost decision you cannot name is one you cannot question. Now you can name all five. The terminal stops being a place where things happen to you and starts being a place you can read.