FAQ

FAQ

Which models should I configure?

Two tiers in dag.jsonc: advanced for judgment nodes (reviews, arbitration, anything required), standard for volume. If you only configure one, it serves everything. Resolution per node is tier → worker agent model → parent session model; if nothing resolves, the workflow is not created and you are asked to configure — it never silently picks a default you did not choose.

What does a graph cost?

Each node is a child session spending tokens like a normal conversation. Cost control is structural: the standard tier fans out on cheaper models, max_total_nodes caps the graph size, per-node timeout_ms bounds runaway work, and the review budget (max_node_replan_attempts) bounds retry loops. For expensive graphs, deep mode's admission pass exists precisely so you do not build the wrong thing at scale.

A model ran out of quota mid-workflow. Now what?

The node fails with a visible error on the graph; the workflow stays inspectable. Switch the tier in dag.jsonc to a fallback model, then replan the failed node (a replacement under a new id, or restart: true while it is still running). Nodes already completed keep their outputs — you pay only for what reruns.

How is this different from upstream opencode?

Upstream capabilities are all preserved (multi-provider, LSP, client/server, TUI/desktop/web). The fork adds the DAG engine (AGPL-licensed, see the README's license table), the hooks compatibility layer, CJK/IME terminal fixes, worktree isolation per workflow, and the goal loop. The fork is not published to npm; install from the releases page or source.

Can I use it without the graph features?

Yes — as a plain opencode. Everything graph-related lives behind the workflow tool, the /dag-flow and /goal commands, and .opencode/ config files. Ignore them and you have upstream behavior.

Do workflows survive a restart?

Yes. State is event-sourced into SQLite; on restart, running nodes reconcile against their child sessions' durable state, finished sessions back-fill their outputs, and anything ambiguous pauses the workflow for you to decide. No provider work is ever replayed on recovery — a half-finished model call is not re-sent behind your back.

Why did my workflow show completed after a node failed?

Because the failed segment was rewritten. Superseded nodes disappear from the view and do not count toward the terminal state; the status you see reflects the current graph revision. If a failure is live — quota exhausted, API error, timeout cap — it stays visible until it is fixed. To audit the rewrite history, an agent can query superseded nodes by id through the result store; the TUI deliberately exposes no entry to it.

Can nodes run shell commands / read files / use MCP?

A node is a full child session with the same tools as the main agent, scoped by its worker_type's agent config. Permissions behave the same as anywhere else in opencode, including hooks and ask-gating.

How do I share workflows with my team?

Commit specs to .opencode/workflows/ in the repo — everyone who clones gets them by name. Cross-project personal libraries go in the config dir's global scope. The curated global scope is maintained in the opencode-dag-config repository; /dag-template-update syncs it with preview and backup.