zeroshot

The agent that writes the code should not be the one that decides it works.

We built zeroshot because we were tired of being gaslit by agents telling us broken code was ready.

zeroshot runs a QA process your coding agent can't skip. You define it as a graph: which agents review, what must pass, where a rejection loops back. In the built-in software-change workflow, one agent implements, independent agents review, and failures go back to a bounded repair loop. Git delivery waits for both reviewers to accept. zeroshot doesn't replace Claude Code, Codex or Copilot. It runs one of them as the worker and as the reviewers.

Use the built-in graph or draw your own: code review, your own reviewers and test agents, any model per node. Save the setup as a profile for the next task.

Skills and review graphs

A skill is advice: the agent still decides whether to follow its reviewer's feedback and when to stop. A zeroshot graph defines the required reviews and repair loop before execution; the engine follows it mechanically until the reviews accept or the retry limit is reached.

Add custom agent nodes: a security reviewer, a bugfinder that writes tests, or an agent that checks the app in a browser. Choose each node's model and instructions, which nodes run in parallel, and where rejected work goes for repair.

The product site, zeroshot.sh, has the FAQ.

▶ Video: a single agent vs. zeroshot (scripted)

Questions, ideas, or a run worth showing? Join the zeroshot community on Discord.

Get started

Prefer Cloud? Cloud setup →

Run locally

npm install -g @the-open-engine-company/zeroshot

The installer requires Node.js 18 or newer and installs a verified native binary for Linux x64/arm64, macOS x64/arm64, or Windows x64. It also installs one zeroshot skill for Codex, GitHub Copilot, and Claude Code at user scope.

For local execution, install and sign in to Codex, Claude Code, or GitHub Copilot. Local runs can reuse the harness's existing login, including subscription-backed sessions. See the installation guide for harness prerequisites.

Run your first task

This example uses Codex and keeps delivery local. The worker edits the current Git worktree, so start in a clean worktree intended for the task.

Create input.json, replacing the example task with a change appropriate for your repository:

{
  "task": "Add JSON output to the status command and cover it with focused tests."
}

Create runtime.json. Replace YOUR_MODEL_ID with a model identifier supported by your installed Codex CLI:

{
  "harness": "codex",
  "provider": "openai",
  "model": "YOUR_MODEL_ID",
  "effort": "high"
}

Start the run. Add --validate-only to check the graph, runtime configuration, and input first:

zeroshot run \
  --title "Add JSON status output" \
  --template software-change \
  --input input.json \
  --uniform-runtime-config runtime.json

Open another terminal to inspect the run:

zeroshot ui

Visit http://127.0.0.1:4173/ui/ and open Runs. Stopping the UI server leaves active runs running. The CLI also provides zeroshot list, zeroshot status RUN_ID, and zeroshot logs RUN_ID.

For other harnesses and providers, see Runtimes and connections.

Run in the cloud

Connect GitHub and bring your own model API keys. Cloud setup guide →

What the built-in workflow does

1. A worker implements the task.
2. Acceptance and code reviewers check the result independently, in parallel.
3. Rejected work goes to one repair worker with both reviews' feedback, then through both reviews again.
4. With delivery enabled, accepted work proceeds through the configured Git and CI steps.
5. Delivery conflicts return through repair and review.

The graph defines the sequence, parallel steps, retry paths, and exit conditions before execution starts. Runs are bounded, and events are recorded in a durable SQLite ledger. A passing run means its configured checks accepted the work; coverage depends on the requirements, reviewers, tests, and environment you provide.

Auto-research

The built-in auto-research template runs ten iterations by default; set a positive options.iterations value in the run input to choose another count. Three scouts propose directions, then a planner chooses an experiment and either the current candidate or a restorable archived candidate as its starting point. Independent judges check the evidence and method, while the progress judge decides whether the result should replace the current candidate under the task charter. A valid result can go into the archive without replacing it. An auditor checks the ledger, archive, and workspace before the next iteration.

Inspect the graph with zeroshot template show auto-research.

Bring your own graph topology

Choose each agent's model and instructions, which steps run in parallel, and when to retry. Example topology, adding stages after the review loop:

Implementation
      ↓
Code review + acceptance review
      ↓
Bugfinder: adversarial tests
      ↓
E2E tests
      ↓
Delivery

The software-change review loop, auto-research graph, and delivery are built in. You define other stages, their tools, services and credentials, and where failures go for repair.

Inspect the built-in graph as a starting point:

zeroshot template show software-change

See the graph contract for custom graph authoring and Prepare a runtime environment for dependency and service setup.

Save and reuse a profile

Each step can use its own model. Pass --runtime-config with one binding per node in place of `--uniform-