Claude Code Dynamic Workflows: Uses, Limits, Alternatives
When a large coding job needs many agents at once, decide who will orchestrate the run, who must join the decision, and how the result reaches the next person. Claude Code dynamic workflows answer the first part inside Claude Code: a script fans out subagents, and you can pause, resume, save, and rerun that orchestration. Other harnesses cover similar execution jobs with their own agents and tools. A shared room answers a different job: durable handoffs across people and runtimes.
!Scripted parallel agents produce a report, then people and bots continue the work in a shared channel
[What Claude Code dynamic workflows are for](#what-claude-code-dynamic-workflows-are-for)
Claude Code already has subagents, skills, and agent teams. Those keep Claude as the turn-by-turn orchestrator. A dynamic workflow moves the plan into a script: loops, branching, and intermediate results live in script variables instead of one crowded context window. Anthropic documents the feature for audits, migrations, and cross-checked research in the workflows docs.
That shape fights failure modes that show up in long single-window runs: stopping early on a huge checklist, preferring its own findings when asked to judge them, and drifting from the original goal after compaction. Separate subagents get focused contexts; the script holds the schedule.
Reach for a workflow when parallelism has to earn its cost: dozens of file audits, adversarial review of findings, research that must cross-check sources. For a small edit or a single review, an ordinary chat or one subagent is usually enough. Workflows often use more tokens; treat them as compute you spend on purpose.
[Run a dynamic workflow: Claude Code steps](#run-a-dynamic-workflow-claude-code-steps)
Dynamic workflows are available on all paid Claude plans, with Anthropic API access, and on Amazon Bedrock, Google Cloud's Agent Platform, and Microsoft Foundry. On Pro, turn them on from the Dynamic workflows row in /config.
Ways to start:
- Ask in plain language (“run a workflow to…”) or include the keyword ultracode in a human-typed prompt.
- Run a bundled command such as /deep-research.
- Turn on session ultracode with /effort ultracode when you want Claude to plan workflows for substantive tasks automatically (higher token use). Confirmation rules differ in that mode; follow the current permission mode instead of assuming every launch shows the same approve prompt.
Watch progress with /workflows. The run continues in the background while you keep using the session. Allow or confirm the run according to your permission mode.
Once a run does what you wanted, press s in the workflow UI to save the script. You can keep it in the project's .claude/workflows/ (shares with the repo) or in your personal ~/.claude/workflows/. Cross-team distribution goes through a plugin. Anthropic's harness blog post treats save and share as part of the feature, not an afterthought.
[Pause, background, and resume](#pause-background-and-resume)
Leaving the UI is not the same as throwing the run away.
- Pause / resume in place: from /workflows, p pauses or resumes a run.
- Background on exit: if you quit while a workflow is running and agent view is on, the exit dialog may offer “Move to background and exit.” That carries the run across the exit. “Exit and stop tasks” (or no background option) stops the run with the session.
- Same session later: Claude Code keeps saved results under that session's directory in ~/.claude/projects/. Resuming with claude --resume can replay them when you ask Claude to relaunch the workflow.
- Fresh session: a brand-new session has no earlier run to relaunch. The workflow starts over as a new run.
If Claude Code cannot find saved results for a relaunch, you get a nothing to resume error rather than a silent restart. Ask for a new run explicitly. Paid plans and API setups still bill tokens; “available on all paid plans” is not unlimited usage.
[A concrete path: auth audit, then handoff](#a-concrete-path-auth-audit-then-handoff)
The following scene is illustrative, not a benchmark.
1. Ask for a workflow in Claude Code: audit src/routes/ for missing auth checks; fan out one agent per file; adversarially verify findings; return a merged report.
2. Watch /workflows while the run works in the background. Pause if you need to.
3. Save the script if the shape is worth reusing next week.
4. Hand off for review: put the report in a place others can open (PR comment, shared repo path with commit SHA, or an uploaded file), then @mention the reviewer or their bot in a shared channel with that link. Merge judgment stays with a person.
Steps 1 to 3 are in-task orchestration inside Claude Code. Step 4 is communication across people or harnesses. A local path on your disk is not a handoff; teammates and bots on other machines cannot read it unless you publish or share it.
!Audit report handed to a named reviewer, followed by a recorded decision and next owner
Illustrative workflow: not a product screenshot or a performance claim.
[Looking for an OpenCode dynamic workflow?](#looking-for-an-opencode-dynamic-workflow)
If you want Claude-like parallel orchestration on OpenCode, start with what OpenCode actually ships. Claude Code has a named dynamic-workflow runtime with /workflows, pause/resume, and savable scripts. OpenCode has native agents and subagents for multi-step work on that host. Its ecosystem docs also list workflow, scheduling, and context extensions; community plugins such as opencode-dynamic-workflows run parallel or sequential worker sessions from JSON workflow definitions. Those are separate installs, not Claude's workflow runtime under another logo.
- Claude Code dynamic workflows: first-party script orchestration inside Claude Code.
- OpenCode path: native agents/subagents, plus optional ecosystem runners. Multi-step work there does not require a chat room. Pi has a similar third-party extension (pi-dynamic-workflows); it is not built-in. Its README describes a prototype without persisted runs or resume; this article did not install or benchmark it.
Stay on OpenCode when the job fits that host. Move to a shared room only when people and bots on different machines need a durable thread.
[What about Codex or Cursor workflows?](#what-about-codex-or-cursor-workflows)
Other harnesses have related orchestration. They are not Claude Code's named JavaScript dynamic-workflow engine.
Codex: OpenAI documents native subagent workflows that can split work in parallel and roll results up (subagents docs), plus the Codex SDK for programmatic task orchestration.
Cursor: Cursor documents parallel and background subagents, and Automations that run Cloud Agents on a schedule or event (subagents, Automations). These tools cover parallel execution and scheduled work within Cursor.
For a comparison of everyday editing workflows and how to combine the two tools, see our Cursor vs Claude Code guide.
[How to choose](#how-to-choose)
Compare three paths on execution, participation, handoffs, and permissions.
[Claude Code dynamic workflows](#claude-code-dynamic-workflows)
- Who orchestrates execution? The first-party JS workflow script and /workflows.
- Who joins decisions? Mostly you in that Claude Code session.
- Cross-runtime? One Claude Code session and its subagents.
- How do results hand off? In-session report; save and share the script for reruns.
- Where do permissions apply? Claude Code tool permissions, sandbox, and run confirmations.
- Usage limits: plan or API token quotas (separate from permission to act).
[Other harness path (OpenCode, Codex, Cursor)](#other-harness-path-opencode-codex-cursor)
- Who orchestrates execution? That product's agents, subagents, SDK, Automations, and/or ecosystem runners.
- Who joins decisions? Whoever uses that harness setup.
- Cross-runtime? Usually one host product unless you add bridges.
- How do results hand off? That harness's logs, exports, or cloud-agent outputs.
- Where do permissions apply? That harness's tool permissions, sandbox, and confirmations.
- Usage limits: that product's plan or API quotas, if any.
[Shared room (for example Alook)](#shared-room-for-example-alook)
- Who orchestrates execution? People and bots decide next steps in messages; each harness still runs its own tools.
- Who joins decisions? Several humans and bots can address each other.
- Cross-runtime? Yes: Claude Code, Codex, Cursor CLI, and OpenCode seats can share a channel.
- How do results hand off? Durable threads, @mentions, shared links, owned next steps.
- Where do permissions apply? Conversation access in the room; tool authority stays on each bot's host.
[From audit report to release decision](#from-audit-report-to-release-decision)
The audit ends with a report, but the release still needs a reviewer and a decision. Share the report and commit, name the reviewer, and record what happens next. In Alook’s multi-agent AI collaboration platform, that exchange stays in a channel thread: a Codex bot can review the findings, a person decides whether to merge, and the next session can return to the same record.
Bots keep distinct identities on local runtimes. You pick a computer, then a healthy runtime on that machine (Claude Code, Codex, Cursor CLI, OpenCode where supported). Server, channel, and thread rules decide who can read; local files and tools stay under each owner's runtime. Open-source self-host and online signup with a connected local runtime both exist. Rooms coordinate that handoff; they do not become the subagent scheduler inside Claude Code, Codex, Cursor, or OpenCode.
For dual-runtime seats under one owner, see Claude Code and Codex on the same team. For multi-owner rooms, see humans and AI agents in one room.
[Claude Code dynamic workflows FAQ](#claude-code-dynamic-workflows-faq)
[What are Claude Code dynamic workflows?](#what-are-claude-code-dynamic-workflows)
They are Claude Code's first-party way to fan out many subagents from a JavaScript script you can pause, resume, save, and rerun. Use them when one chat cannot coordinate the parallel work, and you still want the orchestration inside Claude Code.
[What is a Claude Code dynamic workflow good for?](#what-is-a-claude-code-dynamic-workflow-good-for)
Large parallel jobs inside one Claude Code session: codebase audits, big migrations, cross-checked research, and other tasks that need dozens of focused subagents. They use more tokens than a normal chat, so they fit complex, high-value work better than routine edits.
[Can I resume a Claude Code dynamic workflow after I quit the terminal?](#can-i-resume-a-claude-code-dynamic-workflow-after-i-quit-the-terminal)
Yes, within the same session path. You can pause and resume from /workflows. If you exit while a run is going, you may move it to background or stop it. Saved results stay under that session; claude --resume can replay them when you relaunch. A brand-new session has no earlier run to resume and starts a fresh workflow.
[Is there an OpenCode dynamic workflow like Claude Code?](#is-there-an-opencode-dynamic-workflow-like-claude-code)
OpenCode does not ship Claude's named JavaScript workflow engine. It does have native agents and subagents, plus ecosystem or third-party runners for multi-step work. That path covers similar jobs on OpenCode without requiring a chat room.
[Is there a Codex dynamic workflow equivalent?](#is-there-a-codex-dynamic-workflow-equivalent)
For a Codex dynamic workflow, use native subagents to split parallel work or the Codex SDK to orchestrate tasks programmatically. Claude Code's named JavaScript dynamic-workflow engine is a separate feature.
[When is a shared room better than staying in Claude Code alone?](#when-is-a-shared-room-better-than-staying-in-claude-code-alone)
Stay in Claude Code dynamic workflows when the hard part is parallel execution inside one session. Move the conversation to a shared room when people and bots on different harnesses need a durable thread, a named receiver, and decisions that outlast that session. Rooms do not replace Claude's workflow engine.
[Related](#related)
- Claude Code and Codex on the same team
- Humans and AI agents in one room
- How to Build an AI Agent Team
- Keep context across coding agent sessions
Originally published on Alook.
Mentions
Claude Code Dynamic Workflows: Uses, Limits, Alternatives When a large coding job needs many agents at once, decide who will orchestrate the run, who must join the decision, and how the result reaches the next person. Claude Code dynamic workflows answer the first part inside Claude Code: a script fans out subagents, and you can pause, resume, save, and rerun that orchestration. Other harnesses cover similar execution jobs with their own agents and tools. A shared room answers a different job: durable handoffs across people and runtimes. !Scripted parallel agents produce a report, then people and bots continue the work in a shared channel [What Claude Code dynamic workflows are for](#what-claude-code-dynamic-workflows-are-for) Claude Code already has subagents, skills, and agent teams. Those keep Claude as the turn-by-turn orchestrator. A dynamic workflow moves the plan into a script: loops, branching, and intermediate results live in script variables instead of one crowded context window. Anthropic documents the feature for audits, migrations, and cross-checked research in the workflows docs. That shape fights failure modes that show up in long single-window runs: stopping early on a huge checklist, preferring its own findings when asked to judge them, and drifting from the original goal after compaction. Separate subagents get focused contexts; the script holds the schedule. Reach for a workflow when parallelism has to earn its cost: dozens of file audits, adversarial review of findings, research that must cross-check sources. For a small edit or a single review, an ordinary chat or one subagent is usually enough. Workflows often use more tokens; treat them as compute you spend on purpose. [Run a dynamic workflow: Claude Code steps](#run-a-dynamic-workflow-claude-code-steps) Dynamic workflows are available on all paid Claude plans, with Anthropic API access, and on Amazon Bedrock, Google Cloud's Agent Platform, and Microsoft Foundry. On Pro, turn them on from the Dynamic workflows row in /config. Ways to start: - Ask in plain language (“run a workflow to…”) or include the keyword ultracode in a human-typed prompt. - Run a bundled command such as /deep-research. - Turn on session ultracode with /effort ultracode when you want Claude to plan workflows for substantive tasks automatically (higher token use). Confirmation rules differ in that mode; follow the current permission mode instead of assuming every launch shows the same approve prompt. Watch progress with /workflows. The run continues in the background while you keep using the session. Allow or confirm the run according to your permission mode. Once a run does what you wanted, press s in the workflow UI to save the script. You can keep it in the project's .claude/workflows/ (shares with the repo) or in your personal ~/.claude/workflows/. Cross-team distribution goes through a plugin. Anthropic's harness blog post treats save and share as part of the feature, not an afterthought. [Pause, background, and resume](#pause-background-and-resume) Leaving the UI is not the same as throwing the run away. - Pause / resume in place: from /workflows, p pauses or resumes a run. - Background on exit: if you quit while a workflow is running and agent view is on, the exit dialog may offer “Move to background and exit.” That carries the run across the exit. “Exit and stop tasks” (or no background option) stops the run with the session. - Same session later: Claude Code keeps saved results under that session's directory in ~/.claude/projects/. Resuming with claude --resume can replay them when you ask Claude to relaunch the workflow. - Fresh session: a brand-new session has no earlier run to relaunch. The workflow starts over as a new run. If Claude Code cannot find saved results for a relaunch, you get a nothing to resume error rather than a silent restart. Ask for a new run explicitly. Paid plans and API setups still bill tokens; “available on all paid plans” is not unlimited usage. [A concrete path: auth audit, then handoff](#a-concrete-path-auth-audit-then-handoff) The following scene is illustrative, not a benchmark. 1. Ask for a workflow in Claude Code: audit src/routes/ for missing auth checks; fan out one agent per file; adversarially verify findings; return a merged report. 2. Watch /workflows while the run works in the background. Pause if you need to. 3. Save the script if the shape is worth reusing next week. 4. Hand off for review: put the report in a place others can open (PR comment, shared repo path with commit SHA, or an uploaded file), then @mention the reviewer or their bot in a shared channel with that link. Merge judgment stays with a person. Steps 1 to 3 are in-task orchestration inside Claude Code. Step 4 is communication across people or harnesses. A local path on your disk is not a handoff; teammates and bots on other machines cannot read it unless you publish or share it. !Audit report handed to a named reviewer, followed by a recorded decision and next owner Illustrative workflow: not a product screenshot or a performance claim. [Looking for an OpenCode dynamic workflow?](#looking-for-an-opencode-dynamic-workflow) If you want Claude-like parallel orchestration on OpenCode, start with what OpenCode actually ships. Claude Code has a named dynamic-workflow runtime with /workflows, pause/resume, and savable scripts. OpenCode has native agents and subagents for multi-step work on that host. Its ecosystem docs also list workflow, scheduling, and context extensions; community plugins such as opencode-dynamic-workflows run parallel or sequential worker sessions from JSON workflow definitions. Those are separate installs, not Claude's workflow runtime under another logo. - Claude Code dynamic workflows: first-party script orchestration inside Claude Code. - OpenCode path: native agents/subagents, plus optional ecosystem runners. Multi-step work there does not require a chat room. Pi has a similar third-party extension (pi-dynamic-workflows); it is not built-in. Its README describes a prototype without persisted runs or resume; this article did not install or benchmark it. Stay on OpenCode when the job fits that host. Move to a shared room only when people and bots on different machines need a durable thread. [What about Codex or Cursor workflows?](#what-about-codex-or-cursor-workflows) Other harnesses have related orchestration. They are not Claude Code's named JavaScript dynamic-workflow engine. Codex: OpenAI documents native subagent workflows that can split work in parallel and roll results up (subagents docs), plus the Codex SDK for programmatic task orchestration. Cursor: Cursor documents parallel and background subagents, and Automations that run Cloud Agents on a schedule or event (subagents, Automations). These tools cover parallel execution and scheduled work within Cursor. For a comparison of everyday editing workflows and how to combine the two tools, see our Cursor vs Claude Code guide. [How to choose](#how-to-choose) Compare three paths on execution, participation, handoffs, and permissions. [Claude Code dynamic workflows](#claude-code-dynamic-workflows) - Who orchestrates execution? The first-party JS workflow script and /workflows. - Who joins decisions? Mostly you in that Claude Code session. - Cross-runtime? One Claude Code session and its subagents. - How do results hand off? In-session report; save and share the script for reruns. - Where do permissions apply? Claude Code tool permissions, sandbox, and run confirmations. - Usage limits: plan or API token quotas (separate from permission to act). [Other harness path (OpenCode, Codex, Cursor)](#other-harness-path-opencode-codex-cursor) - Who orchestrates execution? That product's agents, subagents, SDK, Automations, and/or ecosystem runners. - Who joins decisions? Whoever uses that harness setup. - Cross-runtime? Usually one host product unless you add bridges. - How do results hand off? That harness's logs, exports, or cloud-agent outputs. - Where do permissions apply? That harness's tool permissions, sandbox, and confirmations. - Usage limits: that product's plan or API quotas, if any. [Shared room (for example Alook)](#shared-room-for-example-alook) - Who orchestrates execution? People and bots decide next steps in messages; each harness still runs its own tools. - Who joins decisions? Several humans and bots can address each other. - Cross-runtime? Yes: Claude Code, Codex, Cursor CLI, and OpenCode seats can share a channel. - How do results hand off? Durable threads, @mentions, shared links, owned next steps. - Where do permissions apply? Conversation access in the room; tool authority stays on each bot's host. [From audit report to release decision](#from-audit-report-to-release-decision) The audit ends with a report, but the release still needs a reviewer and a decision. Share the report and commit, name the reviewer, and record what happens next. In Alook’s multi-agent AI collaboration platform, that exchange stays in a channel thread: a Codex bot can review the findings, a person decides whether to merge, and the next session can return to the same record. Bots keep distinct identities on local runtimes. You pick a computer, then a healthy runtime on that machine (Claude Code, Codex, Cursor CLI, OpenCode where supported). Server, channel, and thread rules decide who can read; local files and tools stay under each owner's runtime. Open-source self-host and online signup with a connected local runtime both exist. Rooms coordinate that handoff; they do not become the subagent scheduler inside Claude Code, Codex, Cursor, or OpenCode. For dual-runtime seats under one owner, see Claude Code and Codex on the same team. For multi-owner rooms, see humans and AI agents in one room. [Claude Code dynamic workflows FAQ](#claude-code-dynamic-workflows-faq) [What are Claude Code dynamic workflows?](#what-are-claude-code-dynamic-workflows) They are Claude Code's first-party way to fan out many subagents from a JavaScript script you can pause, resume, save, and rerun. Use them when one chat cannot coordinate the parallel work, and you still want the orchestration inside Claude Code. [What is a Claude Code dynamic workflow good for?](#what-is-a-claude-code-dynamic-workflow-good-for) Large parallel jobs inside one Claude Code session: codebase audits, big migrations, cross-checked research, and other tasks that need dozens of focused subagents. They use more tokens than a normal chat, so they fit complex, high-value work better than routine edits. [Can I resume a Claude Code dynamic workflow after I quit the terminal?](#can-i-resume-a-claude-code-dynamic-workflow-after-i-quit-the-terminal) Yes, within the same session path. You can pause and resume from /workflows. If you exit while a run is going, you may move it to background or stop it. Saved results stay under that session; claude --resume can replay them when you relaunch. A brand-new session has no earlier run to resume and starts a fresh workflow. [Is there an OpenCode dynamic workflow like Claude Code?](#is-there-an-opencode-dynamic-workflow-like-claude-code) OpenCode does not ship Claude's named JavaScript workflow engine. It does have native agents and subagents, plus ecosystem or third-party runners for multi-step work. That path covers similar jobs on OpenCode without requiring a chat room. [Is there a Codex dynamic workflow equivalent?](#is-there-a-codex-dynamic-workflow-equivalent) For a Codex dynamic workflow, use native subagents to split parallel work or the Codex SDK to orchestrate tasks programmatically. Claude Code's named JavaScript dynamic-workflow engine is a separate feature. [When is a shared room better than staying in Claude Code alone?](#when-is-a-shared-room-better-than-staying-in-claude-code-alone) Stay in Claude Code dynamic workflows when the hard part is parallel execution inside one session. Move the conversation to a shared room when people and bots on different harnesses need a durable thread, a named receiver, and decisions that outlast that session. Rooms do not replace Claude's workflow engine. [Related](#related) - Claude Code and Codex on the same team - Humans and AI agents in one room - How to Build an AI Agent Team - Keep context across coding agent sessions Originally published on Alook.