Dualzo is a governance layer around AI-written code. A GitHub issue or an in-app prompt becomes a plan; a human approves that plan; an AI coding provider carries it out task by task; your repository's own lint and test commands validate the result in a sandbox; a pull request is opened. Every step is written to an append-only audit log.

Dualzo never merges anything. You review the pull request and merge it yourself, exactly as you would a colleague's.

Four steps, roughly ten minutes:

1. Install the Dualzo GitHub App and pick the repositories it may touch.
2. Connect a repository. Dualzo indexes it and proposes validation commands.
3. Review and confirm those commands. Tasks are blocked until you do.
4. Start a task — write a prompt, or label a GitHub issue.

Dualzo reaches your code through a GitHub App installation, not through your personal token. Go to Repositories → Install the GitHub App, choose the account and the specific repositories to grant, and you are returned to Dualzo with an installation recorded against your workspace.

Then connect a repository from the list. Connecting kicks off indexing: Dualzo shallow-clones the default branch, detects the ecosystem and primary language, parses the manifest, maps the test layout, reads CI configuration, and builds an architecture summary. Indexing never executes your code — it only reads it.

You can revoke access at any time from GitHub, or disconnect the repository from Dualzo.

From your manifest scripts, Makefile targets, and CI workflow steps, Dualzo proposes an ordered command per kind: install, lint, typecheck, test, build. Open Repository → Settings, correct anything wrong, and confirm.

If the repository has no test command, you can still confirm by acknowledging "reduced validation". That acknowledgement is recorded and printed on every pull request produced from the repository, so a reviewer always knows what was and was not checked.

Dualzo is the governance layer; the model doing the coding — Claude, Codex, or Gemini — is picked per task. Dualzo runs the model for you, so there are no API keys to set up. Models are only ever run on work that was approved.

Model usage is included in the Dualzo subscription and measured in credits. Each workspace has a usage limit that refills automatically; when it runs out, new tasks wait until it refills.

A task is called an Execution. There are five ways one begins:

A good prompt names the outcome and the constraint, not the keystrokes: "Add rate limiting to the public API and cover it with a feature test" works better than "edit RouteServiceProvider".

Tasks that run now can carry up to 4 images and up to 3 files. Which types you can attach depends on the provider and model you pick: the form lists them under Attachments and updates as you switch. Drag files onto the form, choose them, or paste a screenshot. Scheduled tasks cannot carry attachments.

Files are sent to the provider's CLI exactly as you uploaded them — nothing is converted, re-encoded or extracted — so only formats the CLI reads natively are offered. Claude: PNG, JPEG, GIF, WebP, PDF and text files (txt, md, csv, json, yaml, xml). Gemini: PNG, JPEG, WebP, PDF and text files. Codex: PNG, JPEG, WebP and text files. Word and Excel files cannot be attached; export them to PDF or CSV first.

Limits: 4 MB per image, 10 MB per file. Password-protected PDFs and text files that are not UTF-8 are refused. If you switch to a model that cannot read a file you already attached, the form says so before the task is created.

Dualzo sends the issue or prompt plus a budgeted slice of Project Memory to your model, and gets back an ordered plan: internal tasks with instructions and acceptance criteria, the files expected to change, the commands to run, and rollback notes. Nothing executes yet.

Workspace admins get an email with the plan and single-use, expiring signed links, and the same controls appear on the task page:

• Approve — the execution is queued and starts running.
• Modify — you type instructions, planning re-runs with them, and a fresh approval request goes out.
• Reject — the task ends there.

Each plan carries a risk level and a confidence score from 0 to 100. Confidence is computed by Dualzo in PHP — from how many files are expected to change, whether those paths appear in the test inventory, whether a test command is confirmed, and your workspace's historical pass rate — not by the model rating its own work.

After each internal task, your confirmed commands run in order — install, lint, typecheck, test, build — skipping kinds you left unconfigured. They run inside an ephemeral container built on your ecosystem's base image, with:

• network access only during the install step;
• CPU, memory, and wall-clock limits;
• read-only mounts everywhere except the working directory;
• none of Dualzo's own secrets in the environment.

If a command fails, its output is fed back to the model for up to two fix attempts. Still failing, the execution moves to Needs review rather than pushing anything.

When everything is green, the branch is pushed and a pull request is opened against your default branch. The body contains a summary, what changed per task, a testing checklist, rollback instructions, the AI's explanation, which validation commands ran (with a reduced-validation notice where it applies), and a link back to the Dualzo audit page.

Once the PR is open, Dualzo tracks it: merging or closing it on GitHub updates the state here and is audited.

A task in Needs review shows the plan, per-task status, the cumulative diff, and the failing output. You have three options:

• Abandon — the branch is deleted and the task closes.
• Edit plan and re-run — your instructions go back into planning, and the new plan needs approval again.
• Take over — the branch is pushed as-is and a draft pull request is opened, labelled needs-human and clearly marked unvalidated.

A scheduled task is a saved prompt that runs once, automatically, on a date you pick — useful for a change you want made on a specific day. Manage them on the Scheduled page, where you can pause, resume, or delete each one.

Suggested tasks come from indexing: TODO and FIXME markers found in your source appear as dashboard cards. Start turns one into a task; Dismiss rejects it for good. Auto-fix CI opens a task when a workflow fails on the default branch. Both are per-repository opt-ins under Repository → Settings.

Invite teammates by email from the Members page; they join by following a signed link. There are two roles:

• Admin — manages billing, members, repositories, and approves plans.
• Member — starts tasks and follows their progress, but cannot approve or change billing.

Workspaces are fully isolated: nothing in one workspace is visible from another, regardless of role.

• Team plan: $119 per month, 5 seats included.
• Free credits are occasionally offered as a time-limited signup promotion. Outside of an active promotion, no free credits are granted. When a workspace has none and no active subscription, it is gated to the billing page until you subscribe — your data stays put.
• Payments run through Paddle, which is the merchant of record and handles tax. Invoices are listed on the billing page.
• Cancelling takes effect at the end of the paid period, and you can resume any time before it lapses.
• Only workspace admins can see or change billing.

Every governed action — webhook received, plan built, approval given, execution run, validation result, pull request opened, billing change — is written to an append-only log. Nothing in the application can edit or delete an entry; records are pruned automatically after 90 days.

Filter the whole workspace log by event, actor, and date on the Audit page, or read a single task's events in order on its own timeline.

• Your code is never used to train models.
• Only a budgeted slice of the repository goes to your model provider — the artifacts and files relevant to the task, never the whole repository.
• Indexing parses statically. Your code executes only inside the validation sandbox.
• Provider keys use encrypted columns and are excluded from logs and serialisation.
• GitHub webhooks are signature-verified on the raw body before anything is parsed.
• Working directories are deleted at the end of every job, including failed ones.
• Attached images and files are stored privately, are visible only to members of your workspace, and are never shared through public links. All attached files are deleted automatically one year after the task finishes.
• Attached files are never opened or converted by Dualzo; they reach your provider's CLI unchanged, and their content is marked for the AI as data, not instructions.

Which languages are supported?

Any. Language support comes from detection, manifest parsing, and your repository's own commands — not from hand-written per-language analyzers. Ecosystems with a dedicated sandbox image are PHP, Node, Python, JVM, Go, and Ruby, with a generic fallback for everything else.

Does Dualzo merge code?

No. It opens a pull request and stops. Merging is always a human decision on your side.

Can it run without approval?

No. Every plan requires a human approval before any code is executed, and the approval is recorded with the actor.

Can two tasks run on the same repository at once?

No. One execution runs per repository at a time; the rest queue behind a lock.

What happens to my data if I cancel?

Nothing is deleted when a subscription ends — the workspace is gated until you subscribe again. Deleting your account removes your data on the schedule in the Privacy Policy.

Who pays for model usage?

You do, directly to your model provider, on the key you supply. The subscription covers Dualzo itself.