DUEX coordinates Claude and Codex as independent builder and reviewer runs, enforces configured workflow policies and spending limits, requires human approval, and preserves an append-only evidence record. The same execution run can never approve its own work.
Ten things that are true of DUEX and not of a coding agent on its own.
Codex builds, Claude reviews — or the reverse. A prompt injection tuned for one model rarely steers the other, and neither can wave through its own mistakes.
Structurally impossible, not discouraged. The reviewer must be a different execution identity, checked by the database on every insert.
Approvals require a real user record. There is no field an agent could fill in, so "the AI approved it" cannot happen by accident or by bug.
Agents run on your machines. DUEX receives a diff hash, test results and a usage claim. Your security review gets a much shorter answer.
Bring your own Anthropic and OpenAI keys. No markup, no resale, no exposure when vendor pricing moves. We have nowhere to store your keys and no reason to.
Hard limits per task, session, project and organisation. When a cap is reached, DUEX stops handing out work and records that it did.
Append-only audit history and hash-chained evidence bundles. Diffs, test output, findings and approvals, in a form you can hand to a reviewer months later.
Rules inherit organisation → project → repository → task, and a child can only narrow a parent. Widening needs a named approver and an expiry.
Work will not run on a machine that cannot attest the isolation your policy requires. The refusal names the exact gap. Today every registered runner attests process isolation, so the verified and regulated profiles are not yet available — they are refused rather than approximated.
Illegal state transitions fail closed. A blocked write reports failure rather than a successful build that changed nothing. Bad news arrives early.
A playbook is a sequence of roles, not a prompt. Each role runs independently, and the gates are enforced in the database — not merely requested in an instruction.
/build /review /security /debate
/roast /ship and more. Each defines which role acts, in what order,
and where a human must decide.
Every task gets its own git worktree on your own infrastructure. Codex builds, Claude reviews — or the reverse. Different vendors, by configuration.
Work stops at REVIEW_PENDING and cannot advance without a human approval
record. No agent can write one.
Every claim below is enforced by a database constraint or a policy check. These are lines of code, not marketing.
A model cannot review its own output. Enforced in the schema, so an application bug cannot bypass it.
Only a human can approve. There is no column an agent could populate.
Work cannot skip budget approval or review. Invalid transitions fail closed at the database level.
Audit history, usage records and approvals reject UPDATE and DELETE. Evidence bundles are SHA-256 hash-chained.
A real refusal, not an illustration. Work will not dispatch to a runner that cannot prove the isolation your policy demands — which is why the verified and regulated profiles are unavailable until a runner can attest them.
DUEX stores no API keys. Runners call Anthropic and OpenAI directly from your infrastructure. We cannot leak what we never receive.
You pay for the control plane — orchestration, policy, evidence and approvals. Model usage is billed directly to your own Anthropic and OpenAI accounts, at cost, with no markup.
What is enforced today: worktree isolation, independent cross-model review, human approval gates, hash-chained evidence, spend caps and projections. The verified and regulated execution profiles require a runner attesting container or VM isolation and are not yet available on any tier — DUEX refuses them at dispatch rather than running work it cannot isolate. Tier names do not grant a profile the runtime cannot prove.
Loading plans…
No. Runners execute on infrastructure you control. Your repositories are cloned there, agents run there, and prompts go directly from your machine to Anthropic and OpenAI. DUEX receives a diff hash, test results and a usage claim — never your source.
On your runner, in your environment. DUEX has no table to store them in. That is a deliberate design decision, not an oversight.
No — it drives them. When you're iterating alone on your own machine, use Claude Code directly; it's faster. DUEX earns its place when two models must check each other, a human must approve, spend must be capped, or you need to prove afterwards what happened.
GitHub charges for access to agents. DUEX charges for trusting the result.
Your runner reports its own token usage, because the calls happen on your infrastructure and we never see them. We record the claim and label it as one. We'd rather say that plainly than imply a measurement we don't make.
Yes, on Enterprise. Self-hosted or private cloud, with customer-managed secrets and data residency.
Start free against one repository. Upgrade when you need the guarantees.