I don't really get this. At this point, my limiting factor is not how quickly Claude can self-trudge through code. It's whether Claude is going to do the task correctly or not.
I need more mechanisms for controlling long-running sessions and dynamically injecting my thoughts, correction, and nudges rather than faster ways to burn through my tokens without knowing if the results are going to be correct.
"Agents address the problem from independent angles, other agents try to refute what they found, and the run keeps iterating until the answers converge."
So you will be supplying the "ground truth" (test suite, detailed spec, whatever) and empower an agent to use it to guide the other agents. Currently a lot of people do this sequentially in the form of multiple code-review passes by fresh agent sessions looking at the work of previous sessions.
Adversarial models are a longstanding technique in ML so it makes sense they would try to go this way.
Ground truth is not consensus, it has to be graded against what actually works for the original goal. Plenty of scenarios with AI and Humans can result in consensus around incorrectness.
While pedantically correct, I think the comment above assumed that you've correctly specified the work. If you can't correctly specify your work, AI agents are just going to help you get a non-solution faster.
Isn't coding the act of specificying the work to a processor? And AI agents are supposed to bridge the gap with intelligence from less specificed to more specified or possibly even more intelligent and alternate implementations?
Dynamic workflows, in my experience, make Claude more effective at complex long-running tasks. They help precisely with getting Claude to do the task correctly.
It feels more like a bespoke build system for the specific task/project than prompting a freeform chat.
As long as agents are fuzzy (which they will continue to be with the Transformers architecture), the need to validate will continue to exist. I cannot imagine merging code without at least 1 human review.
When this is all finished and done, these coding models will allow you to rewrite the linux kernel in rust, recode Kubernetes in assembly, and create your own web framework in 10 min.
But each prompt will cost your company, 10 to 15 million dollars. An extra 20 million if you ask them to review the code and improve the comments.
yes I agree with this, more granular going back, letting me interrupt where it went off the rails, or even editing file reads myself etc would be lovely. Ingesting parts of other conversations would also be cool!
Interesting to note, not sure if this was known publicly before today's blog post:
Rewriting Bun with dynamic workflows
An example of what dynamic workflows can unlock at scale is the recent rewrite of Bun. Jarred Sumner used dynamic workflows to port Bun from Zig to Rust with 99.8% of the existing test suite passing, roughly 750,000 lines of Rust, and eleven days from first commit to merge. One workflow mapped the right Rust lifetime for every struct field in the Zig codebase. The next wrote every .rs file as a behavior-identical port of its .zig counterpart, hundreds of agents working in parallel with two reviewers on each file. A fix loop then drove the build and test suite until both ran clean. After the port landed, an overnight workflow addressed unnecessary data copies and opened a PR for each for final review. While not yet in production, all of this was handled by dynamic workflows. Jarred will be writing about this more in the future.
I'm extremely skeptical that dynamic workflows had anything to do with this. I've been able to refactor one of the most complicated parts of our code base with similar results.
Mechanical refactors are relatively straight forward for agents.
> I've been able to refactor one of the most complicated parts of our code base with similar results. Mechanical refactors are relatively straight forward for agents.
A rewrite of bun in Rust is unlikely to be a trivial mechanical refactor. And if you are not sharing what the complicated parts were, or how big it is, how do we assess that the task was similar?
Unless you are intimately familiar with the bun codebase and you've already made that assessment.
A few of us from the Claude Code team will be hanging around if anyone has questions! Very excited for this launch -- dynamic workflows have been a game changer for engineering here at Anthropic. Can't wait to hear what you think.
Thanks to you and the anthropic team for developing such exciting tools! The blog post seems to position workflows for “breadth”: generating fixes / refactors against large code bases. What about for “depth”: developing specific new features and functionality end-to-end? I’ve struggled to make this work reliably using the current experimental agent teams. Does this replace or augment that functionality?
Yes, it also helps! That's a place where raw model capability is the most helpful, but we do find that some dynamic workflow configurations can be helpful too.
Is there an example of how y'all use Dynamic Workflows internally that you could share with the rest of us here so that we can mimic something similar?
Hey, yep. A few things I personally used dynamic workflows for over the last few weeks:
1. Autonomously landed 20+ optimizations to reduce Claude Code's token usage by ~15%
2. Ported tree-sitter, color-diff, yoga-layout, and a number of other WASM and Rust native modules to TypeScript, improving CPU and memory use by 2-10x in the process
3. Made our CI faster, and repeatedly found and fixed flaky tests (with /loop)
4. Migrated from regex-based bash static analysis to tree-sitter, reducing false positive permission prompts by 45%
5. Reduced Claude Agent SDK startup time by 61%, by repeatedly profiling and optimizing the startup path, putting up a number of PRs in the process
Very cool. What % of the CC team's engineering would you say goes into QoL (as opposed to new feature development)? Obviously some live in a grey area, while others are more clear like making CI faster.
I tried creating a workflow in Claude 1.9255.2 (1dc8f7) 2026-05-27T01:57:20.000Z
and got
API Error: 400 messages.3.content.11: `thinking` or `redacted_thinking` blocks in the latest assistant message cannot be modified. These blocks must remain as they were in the original response.
Tried again in
Claude 1.9659.1 (193bcb) 2026-05-28T16:22:15.000Z also but may need a new chat
This is really dissapointing release for such a promising technique. Long walks with fanned vectors can actually be token optimizing vs token burning when combined with self grading each agent along the walk and compared to manual long coding walks to solve first pass problems. But instead this frames it (assumptively) as a tokenmaxxing strategy. There are also many other strartegies that can prove effeciency and wider solution consideration with consensus, but none of this is explained why its an improvement or better than other technqiues.
Its like you guys aren't even aware of the primary problem you are all facing: your token burns aren't paying off anyore against standard coding -- and looking net negative. I have to ask, are you this unaware of your core problem set here?
There are no any examples, proofs, or scenarios that show why there is improvement either in complexity or reliability of the solution or effeciency to the path of the solution. I'm baffled.
Hi Boris! Amazing work on CC. I'm curious what the team thinks of the current capabilities of Claude being able to vibe code games. When I say games, I mean full 3D games.
Something most models do, Claude Code included, is use three.js, which comes with many limitations compared to the what the rendering engines in native game engines can do and the accompanying plugins/toolsets they offer. However, the fast iteration to go from ideation to concept, to prototype, is invaluable.
My team is building a way to vibe code full featured Unreal Engine games, directly in the browser with publishing workflow straight to a browser. The games are then rendered in WebGPU and use WebAssembly for near-native performance. We think this pipeline and workflow will be transformational for the gaming industry.
Would love to show off what we have. You can DM me on X:
It feels like we're far past the point of where having AI do more faster is helpful.
It's telling that they used "rewrite Bun in Rust" as the proof point here. It's cool! But the vast majority of software engineering doesn't start with tens of thousands of tests, where making them pass is the whole job.
In my experience, AI still drifts from what I meant it to do on anything bigger than building a widget. My time is spent suspiciously reviewing output for changes the agent snuck in, or invariants it broke. I talked with a friend recently where the agent broke the test harness badly enough that none of the tests mattered for 3 weeks. They did pass, though, so CI never complained.
There's something at the intersection of context engineering, managing that sloppy pile of markdown plans, and good old fashioning system understanding that's the real bottleneck.
Quite a thing to use Bun rewrite to Rust as example of dynamic workflows, while now it is considered as anti pattern which leads team to stop supporting the tool due to inability to properly understand and navigate 1m vibe coded Rust lines
Are these “features” just hooks to get people to burn more tokens faster?
I’m at the point where deciding what we should and should not do takes a lot more time than actually doing it. More agents just means running faster in potentially the wrong direction
I made my own knockoff of that for myself https://github.com/vblanco20-1/AgentLoom (not really usable, just a vibecoded prototype), based on the workflow files found in the Bun repo. Ive been using it but pointed at deepseek flash to do some really large scale stuff. Its a fun way of using agents, and highly useful for tasks like code review to apply some rules, or to find vulnerability candidates. Funny enough, i used it in the same way claude does, vibecoding the workflow scripts and prompts themselves.
I did find it uses tokens like crazy, i migrated Pixel Dungeon (java) to C# as a experiment, and it used almost 2 billion tokens. It was just 20 bucks due to deepseek flash, but i shudder thinking of how much money this uses when run on the real claude API pricing.
just to test the tech. No real usage other than for the fun of it.
I did port stb_image from C to Jai which i was able to fully verify and harden and that one ill give more use. Im also using the same workflow system to perform agentic translation of a game i work with from english to various other languages, the results are far better than the commercial "human" translation services we tested. And i also use it to fix OCR issues on PDF books im ocr-ing for a data pipeline. This kind of workflow/wide agent swarm system is rather useful for many things where you want to "apply" the same prompts across a whole codebase or just in parallel.
I'm going to be honest, this very much reads like an exciting new way to burn up as many tokens as possible. Large amounts of parallel agents that all have all their work double-checked by multiple other agents, and that keeps running for a longer period of time?
I feel like there are more efficient ways to tackle the issues given.
Anthropic is going to price themselves out of code, but still find a nice market providing service to senior management. Their long term play is virtual employees rather than tools for humans.
“We realized the tech is not as addictive as we’ve hoped so we won’t be able to raise token prices enough to be profitable, so here’s a way to make you consume a lot more tokens without even realizing”
I don't really get this. At this point, my limiting factor is not how quickly Claude can self-trudge through code. It's whether Claude is going to do the task correctly or not.
I need more mechanisms for controlling long-running sessions and dynamically injecting my thoughts, correction, and nudges rather than faster ways to burn through my tokens without knowing if the results are going to be correct.
I think the theoretical answer here is this:
"Agents address the problem from independent angles, other agents try to refute what they found, and the run keeps iterating until the answers converge."
So you will be supplying the "ground truth" (test suite, detailed spec, whatever) and empower an agent to use it to guide the other agents. Currently a lot of people do this sequentially in the form of multiple code-review passes by fresh agent sessions looking at the work of previous sessions.
Adversarial models are a longstanding technique in ML so it makes sense they would try to go this way.
Ground truth is not consensus, it has to be graded against what actually works for the original goal. Plenty of scenarios with AI and Humans can result in consensus around incorrectness.
While pedantically correct, I think the comment above assumed that you've correctly specified the work. If you can't correctly specify your work, AI agents are just going to help you get a non-solution faster.
Isn't coding the act of specificying the work to a processor? And AI agents are supposed to bridge the gap with intelligence from less specificed to more specified or possibly even more intelligent and alternate implementations?
Dynamic workflows, in my experience, make Claude more effective at complex long-running tasks. They help precisely with getting Claude to do the task correctly.
It feels more like a bespoke build system for the specific task/project than prompting a freeform chat.
As long as agents are fuzzy (which they will continue to be with the Transformers architecture), the need to validate will continue to exist. I cannot imagine merging code without at least 1 human review.
When this is all finished and done, these coding models will allow you to rewrite the linux kernel in rust, recode Kubernetes in assembly, and create your own web framework in 10 min.
But each prompt will cost your company, 10 to 15 million dollars. An extra 20 million if you ask them to review the code and improve the comments.
yes I agree with this, more granular going back, letting me interrupt where it went off the rails, or even editing file reads myself etc would be lovely. Ingesting parts of other conversations would also be cool!
I have heard of "token-maxxing" but I have not heard of "correctness-maxxing" or "quality-maxxing".
Interesting to note, not sure if this was known publicly before today's blog post:
Rewriting Bun with dynamic workflows
An example of what dynamic workflows can unlock at scale is the recent rewrite of Bun. Jarred Sumner used dynamic workflows to port Bun from Zig to Rust with 99.8% of the existing test suite passing, roughly 750,000 lines of Rust, and eleven days from first commit to merge. One workflow mapped the right Rust lifetime for every struct field in the Zig codebase. The next wrote every .rs file as a behavior-identical port of its .zig counterpart, hundreds of agents working in parallel with two reviewers on each file. A fix loop then drove the build and test suite until both ran clean. After the port landed, an overnight workflow addressed unnecessary data copies and opened a PR for each for final review. While not yet in production, all of this was handled by dynamic workflows. Jarred will be writing about this more in the future.
I'm extremely skeptical that dynamic workflows had anything to do with this. I've been able to refactor one of the most complicated parts of our code base with similar results.
Mechanical refactors are relatively straight forward for agents.
> I've been able to refactor one of the most complicated parts of our code base with similar results. Mechanical refactors are relatively straight forward for agents.
A rewrite of bun in Rust is unlikely to be a trivial mechanical refactor. And if you are not sharing what the complicated parts were, or how big it is, how do we assess that the task was similar?
Unless you are intimately familiar with the bun codebase and you've already made that assessment.
[delayed]
A few of us from the Claude Code team will be hanging around if anyone has questions! Very excited for this launch -- dynamic workflows have been a game changer for engineering here at Anthropic. Can't wait to hear what you think.
Thanks to you and the anthropic team for developing such exciting tools! The blog post seems to position workflows for “breadth”: generating fixes / refactors against large code bases. What about for “depth”: developing specific new features and functionality end-to-end? I’ve struggled to make this work reliably using the current experimental agent teams. Does this replace or augment that functionality?
Yes, it also helps! That's a place where raw model capability is the most helpful, but we do find that some dynamic workflow configurations can be helpful too.
Are you planning on adding a secrets manager?
Will workflows be reusable? I have a big use case of sharable and repeatable workflows for projects. Especially if this comes to Cowork.
Yes!
Any idea how soon dynamic workflows might be available in Cowork?
Will you document how to (AI-)author and share reusable workflows between team members, to ensure some consistency of quality?
Maybe blasphemy, but will workflows be able to use non-Anthropic LLMs (e.g., delegating some steps to local models, but design and review by Claude)?
Yes, more docs + technical details coming soon.
Hi Boris! Thanks for Claude Code.
Is there an example of how y'all use Dynamic Workflows internally that you could share with the rest of us here so that we can mimic something similar?
Hey, yep. A few things I personally used dynamic workflows for over the last few weeks:
1. Autonomously landed 20+ optimizations to reduce Claude Code's token usage by ~15%
2. Ported tree-sitter, color-diff, yoga-layout, and a number of other WASM and Rust native modules to TypeScript, improving CPU and memory use by 2-10x in the process
3. Made our CI faster, and repeatedly found and fixed flaky tests (with /loop)
4. Migrated from regex-based bash static analysis to tree-sitter, reducing false positive permission prompts by 45%
5. Reduced Claude Agent SDK startup time by 61%, by repeatedly profiling and optimizing the startup path, putting up a number of PRs in the process
6. Shipped 69 code simplification PRs, deleting >10k lines of code
Very cool. What % of the CC team's engineering would you say goes into QoL (as opposed to new feature development)? Obviously some live in a grey area, while others are more clear like making CI faster.
You _reduced_ its _efficiency_? Why do you make CC more inefficient?
Typo! Edited
What language are the workflows in? Curious what you settled on. And are they running in the cloud or locally?
JavaScript, running locally or in the cloud.
I tried creating a workflow in Claude 1.9255.2 (1dc8f7) 2026-05-27T01:57:20.000Z
and got
API Error: 400 messages.3.content.11: `thinking` or `redacted_thinking` blocks in the latest assistant message cannot be modified. These blocks must remain as they were in the original response.
Tried again in
Claude 1.9659.1 (193bcb) 2026-05-28T16:22:15.000Z also but may need a new chat
Looking
Still seeing it in new threads with Claude 1.9659.1 (193bcb) 2026-05-28T16:22:15.000Z
How do you guys plan feature support between the CLI and Claude Desktop?
We generally build features into the Claude Agent SDK, which is shared by CLI, Desktop, VSCode, and cloud.
This is really dissapointing release for such a promising technique. Long walks with fanned vectors can actually be token optimizing vs token burning when combined with self grading each agent along the walk and compared to manual long coding walks to solve first pass problems. But instead this frames it (assumptively) as a tokenmaxxing strategy. There are also many other strartegies that can prove effeciency and wider solution consideration with consensus, but none of this is explained why its an improvement or better than other technqiues.
Its like you guys aren't even aware of the primary problem you are all facing: your token burns aren't paying off anyore against standard coding -- and looking net negative. I have to ask, are you this unaware of your core problem set here?
There are no any examples, proofs, or scenarios that show why there is improvement either in complexity or reliability of the solution or effeciency to the path of the solution. I'm baffled.
Hi Boris! Amazing work on CC. I'm curious what the team thinks of the current capabilities of Claude being able to vibe code games. When I say games, I mean full 3D games.
Something most models do, Claude Code included, is use three.js, which comes with many limitations compared to the what the rendering engines in native game engines can do and the accompanying plugins/toolsets they offer. However, the fast iteration to go from ideation to concept, to prototype, is invaluable.
My team is building a way to vibe code full featured Unreal Engine games, directly in the browser with publishing workflow straight to a browser. The games are then rendered in WebGPU and use WebAssembly for near-native performance. We think this pipeline and workflow will be transformational for the gaming industry.
Would love to show off what we have. You can DM me on X:
https://x.com/AlexStLouis10
It feels like we're far past the point of where having AI do more faster is helpful.
It's telling that they used "rewrite Bun in Rust" as the proof point here. It's cool! But the vast majority of software engineering doesn't start with tens of thousands of tests, where making them pass is the whole job.
In my experience, AI still drifts from what I meant it to do on anything bigger than building a widget. My time is spent suspiciously reviewing output for changes the agent snuck in, or invariants it broke. I talked with a friend recently where the agent broke the test harness badly enough that none of the tests mattered for 3 weeks. They did pass, though, so CI never complained.
There's something at the intersection of context engineering, managing that sloppy pile of markdown plans, and good old fashioning system understanding that's the real bottleneck.
Quite a thing to use Bun rewrite to Rust as example of dynamic workflows, while now it is considered as anti pattern which leads team to stop supporting the tool due to inability to properly understand and navigate 1m vibe coded Rust lines
Are these “features” just hooks to get people to burn more tokens faster?
I’m at the point where deciding what we should and should not do takes a lot more time than actually doing it. More agents just means running faster in potentially the wrong direction
I made my own knockoff of that for myself https://github.com/vblanco20-1/AgentLoom (not really usable, just a vibecoded prototype), based on the workflow files found in the Bun repo. Ive been using it but pointed at deepseek flash to do some really large scale stuff. Its a fun way of using agents, and highly useful for tasks like code review to apply some rules, or to find vulnerability candidates. Funny enough, i used it in the same way claude does, vibecoding the workflow scripts and prompts themselves.
I did find it uses tokens like crazy, i migrated Pixel Dungeon (java) to C# as a experiment, and it used almost 2 billion tokens. It was just 20 bucks due to deepseek flash, but i shudder thinking of how much money this uses when run on the real claude API pricing.
curios minds... why to do that port?
just to test the tech. No real usage other than for the fun of it.
I did port stb_image from C to Jai which i was able to fully verify and harden and that one ill give more use. Im also using the same workflow system to perform agentic translation of a game i work with from english to various other languages, the results are far better than the commercial "human" translation services we tested. And i also use it to fix OCR issues on PDF books im ocr-ing for a data pipeline. This kind of workflow/wide agent swarm system is rather useful for many things where you want to "apply" the same prompts across a whole codebase or just in parallel.
I say this as someone who's found LLMs incredibly beneficial.
Is this a way to increase token burn?
I thought we covered this with Claude's C compiler. What changed?
My initial reaction was that this is tokenmaxxing disguised as a product.
I'm going to be honest, this very much reads like an exciting new way to burn up as many tokens as possible. Large amounts of parallel agents that all have all their work double-checked by multiple other agents, and that keeps running for a longer period of time?
I feel like there are more efficient ways to tackle the issues given.
We really need a way to scope and implement these multi-agent orchestration features that isn't locked in to one provider.
Anthropic is going to price themselves out of code, but still find a nice market providing service to senior management. Their long term play is virtual employees rather than tools for humans.
Not sure I understand how it's different from a team of sub-agents, what's the difference I'm curious?
There's two main differences:
1. Support for 1-2 OOMs more agents, to do more work in parallel
2. A phased, semi-structured approach where work happens in steps
“We realized the tech is not as addictive as we’ve hoped so we won’t be able to raise token prices enough to be profitable, so here’s a way to make you consume a lot more tokens without even realizing”
Wow, almost like the good old days of /ultrathink are back. Feels simultaneously like just yesterday and a lifetime ago.
Cloudflare just launched a feature with this same name, just this month. Why would Anthropic choose the same exact name?
https://blog.cloudflare.com/dynamic-workflows/
Also isn’t all of this already easy to do on any of the platforms (include Claude before this and OpenAI too).
[dead]