bcherny

Boris from the team here — we’re looking into it.

For those using Claude Code, I recommend Learning mode to instruct Claude to walk you through implementing the solution yourself rather than doing it for you. It’s very helpful when diving into a new domain, and helps build lower level intuition.

To enable it, run /config > output styles > Learning

Yep! Set disableWorkflows:true in your settings.json

Looking

Typo! Edited

Yes!

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.

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

JavaScript, running locally or in the cloud.

Yes, more docs + technical details coming soon.

We generally build features into the Claude Agent SDK, which is shared by CLI, Desktop, VSCode, and cloud.

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

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.

Totally. You can do that now, and Claude will know to use /code-review.

Yep, you can add free-form input. Will update /simplify to only check for code quality and not bugs (the way it used to work), that's a good suggestion.

/code-review has a specific prompt that we've found is a good balance of precision, recall, and cost. You could totally roll your own prompt also.

Hey, Boris from the CC team here. I agree, we're working on consolidating these. Going forward it will just be the built-in /code-review skill.

Here's how to use the skill on the latest version:

/code-review # do a balanced code review. checks for bugs and inconsistencies, poor code quality, duplication, band aids, etc.

/code-review --fix # same as above, but also fix the issues

# choose an explicit effort level (defaults to your current effort level). all of these also accept --fix:

/code-review low

/code-review medium

/code-review high

/code-review xhigh

/code-review max

# do an expensive and extremely thorough review (reliably catches >99% of bugs, costs $3-20 per review depending on complexity):

/code-review ultra

Open to feedback if anyone has feedback or ideas for how to make these even nicer to use.

Yes! This is what we’re trying next.

We anticipated the default would be the best option for most people. We were wrong, so we reverted the default.

Yep, agree. We added a little "/clear to save XXX tokens" notice in the bottom right, and will keep iterating on this. Thanks for being an early user!

Hey, Boris from the team here.

We did both -- we did a number of UI iterations (eg. improving thinking loading states, making it more clear how many tokens are being downloaded, etc.). But we also reduced the default effort level after evals and dogfooding. The latter was not the right decision, so we rolled it back after finding that UX iterations were insufficient (people didn't understand to use /effort to increase intelligence, and often stuck with the default -- we should have anticipated this).

Hey, Boris from the Claude Code team here.

Normally, when you have a conversation with Claude Code, if your convo has N messages, then (N-1) messages hit prompt cache -- everything but the latest message.

The challenge is: when you let a session idle for >1 hour, when you come back to it and send a prompt, it will be a full cache miss, all N messages. We noticed that this corner case led to outsized token costs for users. In an extreme case, if you had 900k tokens in your context window, then idled for an hour, then sent a message, that would be >900k tokens written to cache all at once, which would eat up a significant % of your rate limits, especially for Pro users.

We tried a few different approaches to improve this UX:

1. Educating users on X/social

2. Adding an in-product tip to recommend running /clear when re-visiting old conversations (we shipped a few iterations of this)

3. Eliding parts of the context after idle: old tool results, old messages, thinking. Of these, thinking performed the best, and when we shipped it, that's when we unintentionally introduced the bug in the blog post.

Hope this is helpful. Happy to answer any questions if you have.

Boris from the Claude Code team here. We agree, and will be spending the next few weeks increasing our investment in polish, quality, and reliability. Please keep the feedback coming.

Hey, Boris from the Claude Code team here. People were getting extra cyber warnings when using old versions of Claude Code with Opus 4.7. To fix it, just run claude update to make sure you're on the latest.

Under the hood, what was happening is that older models needed reminders, while 4.7 no longer needs it. When we showed these reminders to 4.7 it tended to over-fixate on them. The fix was to stop adding cyber reminders.

More here: https://x.com/ClaudeDevs/status/2045238786339299431

Thanks for the report! This was fixed in v2.1.92.

Please:

1. Upgrade to the latest: claude update (seems like you did this already)

2. Start a new conversations (resuming an old convo may trigger this bug again in that convo)

Thank you! Looking

The docs are a good place to start: https://platform.claude.com/docs/en/build-with-claude/prompt...

There were two issues with some other 3p harnesses:

1. Poor cache utilization. I put up a few PRs to fix these in OpenClaw, but the problem is their users update to new versions very slowly, so the vast majority of requests continued to use cache inefficiently.

2. Spiky traffic. A number of these harnesses use un-jittered cron, straining services due to weird traffic shape. Same problem -- it's patched, but users upgrade slowly.

We tried to fix these, but in the end, it's not something we can directly influence on users' behalf, and there will likely be more similar issues in the future. If people want to use these they are welcome to, but subscriptions clients need to be more efficient than that.

This warning is not enabled for modern models. No action needed. I'm digging into the report above as soon as they're able to /feedback.

We are taking it seriously, and are continuing to investigate. We are not trusting the metrics.