It isn't sub agents. The gap with existing tooling is that the abstraction is over a task rather than a conversation (due to the issue with third-party apps, Claude Code has been inherently limited to conversations which is why they have been lacking in this area, Claude Code Web was the first move in this direction), and the AI is actually coordinating the work (as opposed to being constantly prompted by the user).
One of the issues that people had which necessitated this feature is that you have a task, you tell Claude to work on it, and Claude has to keep checking back in for various (usually trivial) things. This workflow allows for more effective independent work without context management issues (if you have subagents, there is also an issue with how the progress of the task is communicated by introducing things like task board, it is possible to manage this state outside of context). The flow is quite complex and requires a lot of additional context that isn't required with chat-based flow, but is a much better way to do things.
The way to think about this pattern - one which many people began concurrently building in the past few months - is an AI which manages other AIs.
It isn't "just" sub agents, but you can achieve most of this just with a few agents that take on generic roles, and a skill or command that just tells claude to orchestrate those agents, and a CLAUDE.md that tells it how to maintain plans and task lists, and how to allow the agents to communicate their progress.
It isn't all that hard to bootstrap. It is, however, something most people don't think about and shouldn't need to have to learn how to cobble together themselves, and I'm sure there will be advantages to getting more sophisticated implementations.
Right, but the model is still: you tell the AI what to do, this is the AI tells other AIs what to do. The context makes a huge difference because it has to be able to run autonomously. It is possible to do this with SDK and the workflow is completely different.
It is very difficult to manage task lists in context. Have you actually tried to do this? i.e. not within a Claude Code chat instance but by one-shot prompting. It is possible that they have worked out some way to do this, but when you have tens of tasks, merge conflicts, you are running that prompt over months, etc. At best, it doesn't work. At worst, you are burning a lot of tokens for nothing.
It is hard to bootstrap because this isn't how Claude Code works. If you are just using OpenRouter, it is also not easy because, after setting up tools/rebuilding Claude Code, it is very challenging to setup an environment so the AI can work effectively, errors can be returned, questions returned, etc. Afaik, this is basically what Aider does...it is not easy, it is especially not easy in Claude Code which has a lot of binding choices from the business strategy that Anthropic picked.
> Have you actually tried to do this? i.e. not within a Claude Code chat instance but by one-shot prompting.
You ask if I've tried to do this, and then set constraints that are completely different to what I described.
I have done what I described. Several times for different projects. I have a setup like that running right now in a different window.
> It is hard to bootstrap because this isn't how Claude Code works.
It is how Claude Code works when you give it a number of sub-agents with rules for how to manage files that effectively works like task queues, or skills/mcp servers to interact with communications tools.
> it is not easy
It is not easy to do in a generic way that works without tweaks for every project and every user. It is reasonably easy to do for specific teams where you can adjust it to the desired workflows.
I can tell you based on your description that you did not do this. Subagents are completely different and cannot be used in this way.
No, it isn't how Claude Code works because Claude Code is designed to work with limited task queues, this is not what this feature is. Again, I would suggest you trying to actually build something like this. Why do you think Anthropic are doing this? They just don't understand anything about their product?
No, it doesn't work within that context. Again: sharing context between subagents, single instance running for months...I am not even sure why someone would think this could work. The constraints that I set are the ones that you require to build this...because I have done this. You are talking about having some CLAUDE.md files like you have invented the wheel, lol. HN is great.
> I can tell you based on your description that you did not do this. Subagents are completely different and cannot be used in this way.
And yet I have used them exactly in the way I described. That you assume they can't just demonstrate that you haven't tried very hard.
> No, it isn't how Claude Code works because Claude Code is designed to work with limited task queues, this is not what this feature is.
Claude allows your setup to execute arbitrary code that gets injected into context. The entire point is that you don't need to rely on built in capabilities of Claude Code to do any of this.
> No, it doesn't work within that context. Again: sharing context between subagents, single instance running for months...I am not even sure why someone would think this could work.
I know what I described works because I am doing it. You can achieve what I described in a variety of ways: Using skills to tell the agents how to access a shared communications channel. Using MCP servers. Just using CLAUDE.md and describe how to use files as a shared communications channel.
This is only difficult if you lack imagination.
> You are talking about having some CLAUDE.md files like you have invented the wheel, lol. HN is great.
No, the exact opposite: I'm saying that this isn't hard, that it isn't anything revolutionary or even special. It's pretty basic usage of the existing facilities. There's no invention there.
You're the one trying to imply this is more revolutionary than it is.
> Claude Code has been inherently limited to conversations
How so? I’ve been using “claude -p” for a while now.
But even within an interactive session, an agent call out is non-interactive. It operates entirely autonomously, and then reports back the end result to the top level agent.
Because of OAuth. If they gave people API keys then no-one buys their ludicrously priced API product (I assume their strategy is to subsidise their consumer product with the business product).
You can use Claude Code SDK but it requires a token from Claude Code. If you use this token anywhere else, your account gets shut down.
Claude -p still hits Claude Code with all the tools, all the Claude Code wrapping.
Okay...and continue to work up the levels? Why do you think OAuth might be limiting? Why do you think they started building subagents first? What is the difference between subagents and products like Aider?
If they were able to wrap the API directly, this is relatively easy to implement but they have to do this within Claude Code which is based on giving a prompt/hiding API access. This is obvious if you think carefully about what Claude Code is, what requests it is sending to the API, etc.
That’s not what this subthread is about. They’re talking about the subagent within Claude Code itself.
Btw, you can use the Claude Agent SDK (the renamed Claude Code SDK) with a subscription. I can tell you it works out of the box, and AFAIK it is not a ToS violation.
Yes, you can build feature in OP with SDK have done this. Works well...but this is something completely different to agents.
Subagents and the auth implementation are linked because Anthropic's initial strategy was to have a prompt-based interaction which, because of the progress in model performance, has ended up being limiting as users want to run things without prompting. This is why they developed Claude Code Web (this product is more similiar to what this feature will do than subagents, subagents are similar if you have a very shallow understanding...the purpose of this change is to abstract away human interaction, i assume that will use subagents but the context/prompt management is quite different).
Oh really? I was looking at the Agent SDK for an idea and the docs seemed to imply that wasn't the case.
Unless previously approved, we do not allow third party developers to offer Claude.ai login or rate limits for their products, including agents built on the Claude Agent SDK. Please use the API key authentication methods described in this document instead.
I didn't dig deeper, but I'd pick it back up for a little personal project if I could just use my current subscription. Does it just use your local CC session out of the box?
You can’t resell - that’s the third party language. You can build and use for your own purposes. And yes it just picks up your local sessions out of the box.
> If they gave people API keys then no-one buys their ludicrously priced API product
The main driver for those subscriptions is that their monthly cost with Opus 3.7 and up pays itself back in couple hours of basic CC use, relative to API prices.
You can. This is how Opencode worked, but they are clamping down on that approach.
As someone else has mentioned, you can actually use SDK for programmatic access. But that happens within the CC wrapper so it isn't a true API experience i.e. it has CC tools.
One of the issues that people had which necessitated this feature is that you have a task, you tell Claude to work on it, and Claude has to keep checking back in for various (usually trivial) things. This workflow allows for more effective independent work without context management issues (if you have subagents, there is also an issue with how the progress of the task is communicated by introducing things like task board, it is possible to manage this state outside of context). The flow is quite complex and requires a lot of additional context that isn't required with chat-based flow, but is a much better way to do things.
The way to think about this pattern - one which many people began concurrently building in the past few months - is an AI which manages other AIs.