You ask Claude Code to fix a bug. It reads six files, traces the logic, makes the change, runs the tests, and reports back. The whole thing feels like one continuous conversation with one assistant.
It usually was not. Somewhere in there, Claude handed the real work to its general-purpose agent, and you never saw the handoff.
This is the thing to understand, stated plainly. The general-purpose agent is not the main Claude you are talking to. It is a built-in subagent that Claude delegates to, on its own, when a task is complex enough to warrant it. You do not summon it. You do not configure it. Most people using Claude Code every day have never typed its name, and it has still done a large share of their work. So it is worth knowing what it is, when it fires, and what it quietly costs, because the agent doing your hardest tasks should not be the one you understand least.
It is just a subagent
The general-purpose agent is a built-in subagent. That is the whole definition, and it dissolves most of the confusion. It is not a separate product, not a smarter mode, not the “real” Claude behind a curtain. It is the same subagent machinery I described in what a subagent is and set against parallel agents and skills, with one specific built-in configuration that ships with Claude Code.
The official documentation describes it as “a capable agent for complex, multi-step tasks that require both exploration and action.” Three properties define it. Its model inherits from your main conversation, so it is exactly as capable, and exactly as expensive per token, as the Claude you started with. Its tools are all tools, the full set, because a general-purpose worker cannot know in advance which ones it will need. Its purpose is the broad middle of real work: complex research, multi-step operations, code modifications. Where the Explore subagent only reads and the Plan subagent only researches in plan mode, the general-purpose agent is the one allowed to explore and then change things. That breadth is the entire reason it exists, and also the reason Claude reaches for it so often. Most hard requests are some mix of looking and doing.
So when someone asks how the general-purpose agent works, the plain first answer is: like any other subagent. The interesting parts are the three that follow.
The five built-in subagents
The general-purpose agent makes more sense once you see the company it keeps. Claude Code ships with a small set of built-in subagents, each one a worker with a fixed job, and the official docs are clear that “Claude Code includes built-in subagents that Claude automatically uses when appropriate.”
Explore is the read-only researcher. It searches and understands a codebase without changing anything, and it deliberately skips your CLAUDE.md and git status to stay fast and cheap. Plan does research while you are in plan mode, gathering context for a plan without touching files. General-purpose is the one that both explores and acts. Then there are two narrow helpers you will almost never think about: statusline-setup, which runs on Sonnet when you configure your status line, and claude-code-guide, which runs on the cheaper Haiku model to answer questions about Claude Code itself.
Notice the pattern. Each built-in subagent is a specialist with a deliberately narrow remit, except one. General-purpose is the generalist by design, the worker with no specialty and therefore no gaps. It is the catch-all, and a catch-all is exactly what you want as the default for the unpredictable shape of real tasks. Explore and Plan are scalpels. General-purpose is the hand that holds whichever tool the moment needs.
When Claude routes to it
You rarely invoke the general-purpose agent by name. Claude routes to it, and the routing rule is specific. The documentation says Claude delegates to general-purpose “when the task requires both exploration and modification, complex reasoning to interpret results, or multiple dependent steps.”
Read those three triggers as a single test: is this task too big and too branching to keep tidy in the main conversation? A one-line edit fails that test, so Claude just does it directly. “Find every call site of this function, work out which ones are unsafe, and fix them” passes it on all three counts, so Claude delegates. The decision is about shape, not difficulty. A task can be hard and still stay in the main session if it is linear and self-contained. A task can be moderate and still get delegated if it sprawls.
This is why the handoff is invisible and why that is mostly fine. Claude is making a context-management decision on your behalf: keep the noisy, file-heavy, multi-step work out of the conversation you are actually reading, and bring back the result. When it routes well, you get a clean main session and a finished task. When it routes badly, usually by delegating something small enough that the overhead was not worth it, you pay for a subagent you did not need. If you are trying to get a team consistent about when this delegation helps and when it just adds cost, reach out and I am happy to talk it through.
Why it spawns a fork
Here is the part that surprises even experienced Claude Code users, and it is current behavior worth knowing. When Claude would use the general-purpose agent, it does not always spawn a clean, empty subagent. The documentation states it directly: Claude “spawns a fork whenever it would otherwise use the general-purpose subagent. Named subagents such as Explore still spawn as before.”
A fork is a subagent that inherits the entire conversation so far, rather than starting fresh. This is a real departure from the textbook picture of a subagent. A named subagent like Explore begins empty and has to be told the task from scratch in a delegation message. A fork already knows everything your main session knows, because it is a copy of it. The isolation it keeps is one-directional: the fork’s own tool calls and file reads stay out of your conversation, so your main context still does not fill with debris, but the fork itself is not working blind.
That design makes sense for the general-purpose case. The tasks Claude routes here are exactly the ones where re-explaining the situation in a delegation message would be expensive and lossy. Inheriting the conversation means the fork starts with full context and wastes nothing re-establishing it. It is the right trade for complex, deeply-contextual work. It also means the general-purpose agent is less “isolated worker” and more “a second instance of this exact session, sent to do the messy part.”
What it costs you
The most common wrong idea about the general-purpose agent is that it is a cheap escape hatch, a way to offload work to something lighter. It is not. Its model inherits from your main conversation. If you are running Opus, the general-purpose agent is running Opus. There is no quiet downgrade to a cheaper model, and no token discount.
So the cost is real and it has two parts. First, the work itself: the fork reads files and runs tools, and every one of those tokens is billed, just in the fork’s window instead of yours. Second, because it spawns as a fork, it carries a copy of your conversation as its starting context, and a long conversation is a large thing to copy. The general-purpose agent is the most expensive of the built-in subagents to invoke, precisely because it is the most capable and the least stripped-down.
What you buy for that cost is real, though. You buy a main context window that stays clean while a hard, sprawling task gets done somewhere else. That is worth paying for in a long session. It is worth less in a short one. The practical takeaway is not to avoid the general-purpose agent, since you mostly cannot, Claude routes to it for you. It is to recognize when it has fired, by watching for the Agent tool call in your terminal, and to notice whether the task that triggered it was actually big enough to deserve it. The agent doing your hardest work should not be the one you never think about. Now you will.
