When to Use CodeDAG

How CodeDAG differs from the way you work today, what kinds of work it suits, and what it can't do yet.

Claude Code and Codex can already handle several things at once and dispatch subagents, and Claude Code also has Dynamic Workflow. Each of these approaches has its own strengths, and CodeDAG doesn't replace them. It targets one kind of work: several related tasks that form a complete workflow and need to run to the end in dependency order, with no one watching along the way and with results you can review and roll back. For a small change that takes a few lines, or exploration where you're still setting the direction as you go, using Claude Code or Codex directly is a better fit.

Approaches you may already use

Approach	Works well for	Where it falls short	How CodeDAG differs
Put every task into one big prompt for a single agent	Tightly connected work that takes only a few steps. It needs no setup, and the agent has the full picture the whole time.	As the steps pile up, the session keeps growing. Files it read earlier and intermediate conclusions that no longer hold accumulate in the context, and its later judgments become less and less reliable. And everything has to be done one thing at a time.	Each task starts in a fresh session whose context holds only what that task needs. Tasks that don't depend on each other can run at the same time.
Queue up prompts one after another	A series of small steps in a clear order. You queue the follow-up instructions while the agent is still working, so you don't have to stay and give them one by one.	All the instructions still run in sequence in the same session. They can't run in parallel, and you can't hand some of the steps to another agent or model.	Dependencies determine the order, and tasks with no dependency between them run at the same time. Each task can specify its own agent and model.
Have a main agent orchestrate subagents or agent teams	Smaller work that needs judgment calls along the way. The main agent can adjust who does what at any time as the work progresses.	The main agent decides what to do next, turn by turn. As tasks and dependencies multiply, it has to keep the plan and everyone's progress in mind at once, so it can easily miss a dependency or misjudge when to move on, and it can't repeat the run exactly as before. Members of an agent team also have no worktree isolation between them, so avoiding conflicts depends on dividing up the files.	Tasks and dependencies are written into a workflow file ahead of time, and CodeDAG runs them as defined. Execution doesn't drift as the scale grows, and you can run the same workflow again and again. By default, each task works on its own branch.
A Ralph loop, or a scripted loop around `claude -p` or `codex exec`	Repeating the same job until it meets the bar, or chaining a fixed set of steps. You control exactly how it works, and it's easy to plug into your existing scripts and toolchain.	Pausing, resuming from where it stopped, retrying on failure, and isolating parallel runs are all things you have to implement in the script yourself. An agent running non-interactively is also hard to interrupt and correct partway through.	A workflow and each of its tasks can be paused, killed, and recovered, and a recovered task continues in its original session. Every task is an interactive session, so you can open it while it runs and talk to the agent directly.
Use an agent kanban tool with parallel workspaces	Working on several unrelated things at once. Each one runs in its own worktree or session. You assign the work, then check progress and changes one by one.	These tools work in units of standalone tasks or issues. When tasks depend on each other, it's up to you to arrange when the next one starts, how it gets the previous one's result, and how everything is merged at the end.	The unit of work is a complete workflow of related tasks. By default, after an upstream task is accepted, CodeDAG merges its result into the downstream task's branch, then starts the downstream task, and finally merges all the results into one integration branch.
Claude Code Dynamic Workflow	Large batch migrations and refactors, scripted by Claude, when there's a clear test or way to verify the result.	It can only drive Claude's subagents, execution details are hard to see, and it doesn't accept intervention or correction from a person mid-run.	This is the approach closest to CodeDAG. For a detailed comparison, see the next section.

Compared with Claude Code Dynamic Workflow

Dynamic Workflow is the orchestration approach built into Claude Code, and the one closest to CodeDAG. Both take the question of what to do next out of the model's turn-by-turn judgment and hand it to a definition written in advance.

The difference is in how much each one covers. Dynamic Workflow is a feature inside a single Claude Code session. It drives that session's subagents, takes no input from you once it starts, and shows very little detail about the run along the way. CodeDAG covers a piece of development work from end to end: queueing, execution, review, and merging. Tasks can go to Claude Code or Codex individually. Each task is a session you can open and talk to, its changes land on its own branch, and it stops for your review wherever you tell it to. After a pause, it continues in the same session instead of starting over.

	CodeDAG	Claude Code Dynamic Workflow
Agents and models	Each task can go to Claude Code or Codex (more agents will be supported later) and can specify its own model. For example, one model can implement while another reviews.	It can only drive Claude Code's own subagents, and models are limited to the Claude family.
Stepping in mid-run	Every task is a native session. You can open it at any time while it runs and give the agent new instructions directly.	Its official documentation states explicitly that it takes no user input while it runs.
Manual review	You can have any task, or the whole workflow, stop when it finishes and wait for your review. If you're not satisfied, you can have the agent keep revising, have it redo the work from scratch, or make the changes yourself, then let the result through once you're satisfied.	There's no manual review step during a run.
Branches, merging, and rollback	Each task changes code on its own branch, and results are merged automatically while the main branch stays untouched. Unwanted changes can be discarded individually.	By default, subagents edit the same copy of the code directly. Even changes that you isolate with extra configuration aren't merged automatically.
Progress and status	Status tells you more than progress. It also tells you whether you need to act: a task that runs into a problem stops and states the reason, then continues once you've dealt with it.	Status reflects only execution progress, and an agent that runs into a problem simply ends as failed.
Execution trace	You can view each task's complete trace from start to finish, both while it runs and after it ends.	For each agent, you can see only its 3 most recent tool calls and its final result.
Pausing and resuming	Both workflows and individual tasks can be paused, killed, and recovered, and a half-finished session picks up where it left off when it's recovered.	You can pause only at the workflow level, not a specific task. On resume, a half-finished session has to be rerun.
How it's defined	A YAML file that declares tasks and dependencies. You can see at a glance which tasks exist and what depends on what.	A JavaScript script written by Claude. It's less intuitive, and it isn't friendly to users who aren't familiar with JavaScript.

In the end, the most fundamental difference is whether you want to keep control in your own hands. Dynamic Workflow is like a one-off outsourcing job: you hand the work to Claude Code, wait for it to finish, and get a result back. You can't step in along the way, and only Claude can do the work. CodeDAG is like running a project with your own team. You can check in, take over, and sign off at any point. You also decide whether each step goes to Claude Code or Codex and which model it uses, because CodeDAG is a tool independent of these agents and doesn't lock you into one vendor. So if you want agents to get the work done for you while you keep control of the process and your choice of agents, use CodeDAG.

Using CodeDAG doesn't mean giving up Dynamic Workflow. A task agent is an ordinary Claude Code or Codex session, so inside its own task it can still dispatch subagents or start a Dynamic Workflow, and CodeDAG waits for all of them to finish before it considers the task complete. That suits work that does the same thing to a large number of similar items, doesn't depend on order, and doesn't need branch isolation, such as checking every route or migrating a few hundred files. Write the batch part as a single task and let the main agent in that task drive the subagents. That task consumes just 1 CodeDAG credit. The planning before it and the testing and code review after it are still CodeDAG tasks, with manual review, pausing, and resuming all available as usual.

Products in a different category

Workflow platforms such as n8n, Dify, and Zapier also organize a process as nodes and connections. But there, a node is usually a single model call or API request, the process runs on a server or in the cloud, and it handles data and messages rather than changing code in your local repository. Data pipeline orchestrators such as Airflow also organize tasks as a DAG, but what they produce is data, not code. In CodeDAG, every node is a complete coding agent session that works in a Git repository on your own machine, and what it produces is code changes on a branch.

How to decide whether to use CodeDAG

To decide whether a piece of work should go to CodeDAG, answer three questions in order: Can this work be delegated? Is orchestrating it worth the effort? Does it fit within CodeDAG's limits? Whether the code changes can run in parallel and whether you need manual review aren't prerequisites. A workflow that is purely sequential and auto-accepted from start to finish is a perfectly normal use of CodeDAG.

Can you state the goal and deliverables of the next stretch of work? You don't have to prescribe how each step is implemented. That's the task agent's own call. But you do need to say what counts as done for each task and where its result goes, so the agent can keep going without waiting for you to confirm each turn. If the goals and tradeoffs still need rounds of discussion, settle them in an interactive session first, then decide which parts are worth orchestrating.
Does orchestration take real work off your hands this time? That work usually takes one of these forms: steps depend on each other, so a later step has to wait for an earlier result; a batch of tasks can run at the same time; you want another agent to review independently; the run takes a long time and you don't want to babysit it; or you need to be able to check progress, pause, and resume at any time, or sign off at key points. If any one of these applies, and the effort you save is worth preparing a workflow and spending credits per task, orchestration is worth it. You don't have to write the workflow yourself, either. An agent with the CodeDAG Guide plugin installed can write and submit it for you. See Let Your Agent Orchestrate. For a one-off question, or a small change that takes no time at all, handing it straight to Claude Code or Codex is less trouble.
Is everything the goal requires within CodeDAG's current limits? CodeDAG works within a single local Git project, and the relationships between tasks have to be fixed before you submit. If the goal can't do without adding or removing tasks during execution, automatically connecting multiple repositories, or automatically pushing results, split out the part CodeDAG can take on and hand that part to it. Handle the rest yourself, or use another tool. For a workaround for adding and removing tasks during execution, see Current limitations.

If the answer to all three is yes, the work is a good fit for CodeDAG. That means there's a stretch of work you can delegate continuously, the payoff from orchestration is worth the investment, and no product limit stands in the way of the goal.

Current limitations

The items below are CodeDAG's current limitations. Each one is slated to be lifted in a later release. Until then, you can use the workarounds in the table.

Limitation	Explanation	Workaround
No conditional branches or loops	Tasks and dependencies are fixed at submission. CodeDAG doesn't decide which tasks to run based on results, and it doesn't go back and rerun earlier tasks.	Lay out every task you might need ahead of time, and state the conditions in the prompts. Put work that needs repeated attempts inside a single task. See the FAQ.
Can't add or remove tasks during execution	A workflow runs to the end with the content it had at submission.	Split the work into two workflows, one after the other. The first writes its conclusions to a file, and then you or an orchestrating agent writes and submits the next one based on them.
No graphical interface	You view status and logs in the terminal.	Use `cdg status` to see the whole project's queue and `cdg dag status` to see every task in a workflow. Add `--watch` to keep the output refreshing. See Check what's happening: three levels of status.

Next steps

Installation and Sign-In: Install cdg and sign in to your CodeDAG account.
Quickstart: Your First Workflow: Run a workflow in your own repository that only adds new files and doesn't change existing code.
Design Philosophy: Why CodeDAG is designed the way it is, and what each tradeoff costs.