Anthropic Opus 4.8 is out, and the headline feature is a tool called Dynamic Workflows for coordinating swarms of subagents. That's per TechCrunch's report, published today. My first reaction wasn't excitement about the capability. It was a question every solo builder in Sri Lanka should ask before touching it: do I actually need a swarm, or am I about to multiply my bill for no reason?
That question is the whole point of this post. The feature is real and useful. Whether you need it is a separate decision.
🤖 What "swarms of subagents" actually means
A subagent is just another model instance you spin up to handle one slice of a bigger job. Instead of one model doing everything in a single long conversation, an orchestrator hands out tasks: one subagent reads files, another writes tests, a third reviews the output. Dynamic Workflows is the coordination layer that decides who does what and when.
Key takeaway: A subagent swarm trades a single predictable conversation for many parallel ones. You gain speed and separation of concerns. You pay for it in tokens, complexity, and harder debugging.
The "dynamic" part matters. A static workflow is a fixed pipeline you wrote by hand. A dynamic one lets the model decide the shape of the work at runtime, branching based on what it finds. That's powerful for open-ended tasks where you can't script every step in advance.
💰 The cost math nobody puts in the press release
Here's the part that gets skipped when a feature like this lands. Every subagent is a separate set of input and output tokens. If your orchestrator spawns five subagents and each one re-reads the same context, you are paying for that context five times over.
| Setup | Token cost | Latency | Debuggability |
|---|---|---|---|
| Single agent, one conversation | Lowest | Sequential, slower | Easy — one transcript |
| 2–3 subagents, focused tasks | Moderate | Some parallelism | Manageable |
| Large dynamic swarm | Highest | Fast in parallel | Hard — many transcripts |
None of those are Anthropic's published numbers. They're the structural trade-offs that hold regardless of the exact per-token price. The lesson is simple: a swarm is not free parallelism. It's parallelism you rent.
If you want to sanity-check what a workload will cost before you run it, our AI Token Counter shows how much of a model's context window a given chunk of text eats. Multiply that by the number of subagents re-reading the same context and the bill stops being abstract.
🛠️ When a swarm earns its keep
I'm not anti-subagent. There are jobs where splitting the work genuinely beats one long conversation. A few patterns where it pays off:
- Independent parallel tasks — translating one document into eight languages, or running the same analysis across many files. No subagent needs to wait on another.
- Separation of roles — one agent drafts, a fresh one reviews with no memory of the drafting. The clean context often catches mistakes the author would defend.
- Long jobs that blow past one context window — research across dozens of sources, where a single conversation would run out of room.
And the cases where it's the wrong call:
- A short, linear task. Spawning agents adds overhead you'll never recover.
- Anything you can't yet debug. If you can't read one transcript and explain what happened, ten transcripts will not help.
- A learning project on a tight budget. Master the single-agent loop first.
If you're a student or freelancer learning this for the first time, build the one-agent version, get it working, then ask what splitting it would actually buy you. Most of the time the honest answer is "not enough to justify the cost."
🌐 What this means for builders here
For a small team or solo developer in Colombo working in USD-priced API credits against LKR income, the constraint isn't capability. It's spend per useful output. A swarm that finishes faster but costs four times as much is not automatically a win when you're the one paying the invoice.
My practical take:
- Treat Dynamic Workflows as an optimisation, not a default. Reach for it when a single agent is genuinely the bottleneck, not because the release notes are exciting.
- Cap your subagent count early. Start with two or three. Add more only when you can point at a specific task that runs in parallel.
- Measure before you scale. Compare model pricing and context windows on our AI Model Comparison tool so you're choosing the right model per subagent, not running the most expensive one for jobs a cheaper model handles fine.
There's also a quieter point. Every model release pushes "more agents, more autonomy" as the direction of travel. That suits vendors, because more agents means more tokens. It doesn't automatically suit you. The skill that compounds isn't spinning up swarms. It's knowing when one well-prompted agent is enough.
💡 What this means for you
Opus 4.8 and its Dynamic Workflows tool make subagent coordination a first-class feature instead of something you bolt on yourself. That's a real step. But the feature being available is not a reason to use it.
Before you build a swarm, ask three things: Can the tasks genuinely run in parallel? Can I afford the multiplied token cost? Can I still debug it when it breaks? If you can't say yes to all three, a single agent is the better engineering decision, and it's the cheaper one. Start small, measure with a token counter, and let the workload tell you when it's time to scale up.
