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.
Hi Boris. Love the velocity of features. Are you planning on adding a secrets manager? Enterprise workflows almost always require an encrypted parameter or calling a secret.
Personally, I am happy paying 1password for my personal secret management. Their security credibility and bona fides are well-established. I'd strongly consider them for a business contract too.
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.
Cool! If you can point to any examples of those types of workflow configurations I’d be super interested. For example, to have a team of agents review a PR and iterate on it until all requirements are met including UX, security and product functionality goals. If they could “converge” to a solution like workflows seems to be designed for that would be amazing.
Using the keyword “Workflow”like “Ultrathink” is problematic?
Ultrathink is uncommon enough that it is unlikely to be used in code or prompt outside its intended purpose.
Workflow is generic keyword and used in so many contexts both inside the codebase and orchestration tooling like say temporal.io or others that name their constructs “workflows”.
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.
Personally I would just like to be able to read more than 2 lines of an AskUserQuestion on the iOS app. Ever since the feature launched it's truncated the question, so you cannot actually read it.
How granular is the control over the internal process?
In my experiments I've had some success modeling the work to be done as a DAG of typed artifacts with a combination of code + LLM doing decomposition, transforms, synthesis, and fitness checking to generate the output. It took me a lot of tries to arrive at that formula and it would be cool to have something more general. I also run part of it against local compute because it would be far beyond my budget to do it all on Opus, so something for that would be nice too.
Can you please fix the issue where like 99.99999% of the time Claude tries to launch a subagent on its own accord it gets "Prompt is too long" and tries several more times, then gives up and does it without the subagent. Big waste of time and tokens and not getting almost any subagent advantages. Not kidding that this happens about 100 times a day.
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
VSCode has an official client? Given IDE usage is being restricted from Claude Code via the CC SDK tokens going to the Claude API rather than your CC Subscription, i'm unclear which IDEs can actually use claude code now.
Eg is Zed capable of using a Claude Code Subscription?
Oh, yea here's all the proof you need. Even Zed themselves admit you won't be able to use Claude Code via ACP via Subscription: https://zed.dev/blog/terminal-threads
So yea, bcherny didn't reply to me but as far as i can tell - No, Zed nor VSCode will have Claude Code natively in it. The best we can do is embed a Terminal into the editor and run CC in that.
With that said, because bcherny advertised VSCode, i'm going to guess VSCode is going to get special treatment. Really annoying.
to be clear, i'm referring to the recent fact where it appears that they're disabling all Claude Code (Subscription) usage from the SDK. Which ACP would be included on.
As usual though it's not super clear exactly what is allowed or not.
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
> 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
Curious to learn more on this (unless there’s a write-up in the works). I’m naive on this matter but:
1. is this because it’s higher cost when passing objects back and forth across the JS/native boundary?
2. Does this have anything more specific to do with use of Bun?
3. is the stance for claude code then to keep all the deps in raw TypeScript?
4. How do you folks keep these ported deps up-to-date?
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.
Is there not a reason to instead port claude code to rust? Do you have internal benchmarks that show that claude code is better at typescript than rust?
just wanted to say thank you, just did a 2 days "ai computer use" workshop - think a virtual desktop on hetzner with claude code in yolo mode, a github account, vercel and logged in into a google account and claude had all the credentials and then let a mix of marketing / product manager / sales / customer support let loose. 2k token budget ... and just let them see do magic again and again.
