[opensourcedex]

zeroshot is a free, open source version control & collaboration project written in Rust and released under MIT. It has 1,919 GitHub stars, 180 forks and 3 open issues, and was last pushed 11 hours ago. On this registry it ranks #23 of 41 tracked projects in Version Control & Collaboration, with 5 head-to-head comparisons available.

What is zeroshot?

Zeroshot is an open-source, MIT-licensed Rust CLI that orchestrates coding agents as an explicit review graph for developers who want AI-written changes verified by agents other than the one that wrote them.

What it is

Zeroshot turns a software goal into an explicit multi-agent graph: one agent implements, independent agents review the whole change, failures go back into a bounded repair loop, and nothing is delivered until the graph's checks pass. It lives in the coding-agent and developer-tooling ecosystem, working alongside harnesses such as Codex, Claude Code, and GitHub Copilot rather than replacing them; you can use the built-in graph or bring your own topology, adding reviewers, tests, and repair loops and then saving the setup as a profile for later tasks.

The concrete problem it addresses is that the implementing agent never approves its own work — a single agent session writing and judging its own code has no separation of duties. Zeroshot supplies that separation by routing independent reviewers against the task's acceptance criteria and code quality before delivery, and by pairing with Opcore, which checks each edit while an agent writes code, so the whole change is reviewed before it lands. Zeroshot v8 is a hard interface cutover that replaces the former Node.js runtime with a native zeroshot binary.

Key capabilities

  • Orchestrates a graph in which one agent implements and independent agents review, with the implementing agent barred from approving its own work.
  • Routes failures into a bounded repair loop and delivers nothing until the graph's checks pass.
  • Lets you build on the built-in graph or bring your own topology: add reviewers, tests, and repair loops, then save the setup as a profile for reuse across tasks.
  • Delivers results as a branch, a pull request with review feedback handled, or a merge after CI.
  • Runs the same review and repair setup locally, on your own Docker target, or in Zeroshot Cloud.
  • v8 replaces the Node.js runtime with a native zeroshot binary; the npm installer delivers verified binaries for Linux x64/arm64, macOS x64/arm64, and Windows x64.
  • Installs one Zeroshot skill at user scope for Codex, GitHub Copilot, and Claude Code, and local runs can reuse the harness's existing login, including subscription-backed sessions.

Who uses it and how

  • Developers who want a change checked by agents other than the writer, against the task's acceptance criteria and for code quality, before it is merged.
  • Teams that want the same review and repair configuration reused across many tasks by saving it as a profile, executed locally, on their own Docker target, or in Zeroshot Cloud.
  • Contributors who want delivery handled as a branch, a pull request whose review feedback is worked through, or a merge gated on CI.
  • Individuals running against Codex, Claude Code, or GitHub Copilot with a signed-in local session; local runs can reuse the harness's existing login.
  • Users who start each task in a clean Git worktree, because the worker agent edits the current worktree directly.

Getting started

Install with npm install -g @the-open-engine-company/zeroshot, which requires Node.js 18 or newer, then create an input.json describing the task and a runtime.json naming your model, and run against a clean Git worktree with Codex, Claude Code, or Copilot signed in.

How it compares

Among the tools named in the project's own facts, the closest relation is Opcore, which checks each edit while an agent is writing code, whereas Zeroshot has independent agents review the entire change before it lands — they are described as working alongside each other rather than competing. Zeroshot itself is not positioned against a specific paid product here, and as a graph-based multi-agent review orchestrator it stands alone in this registry.

When to use it — and when not

Do not pick it for a small edit you will review yourself in the editor, where a single agent session is quicker, and note that it does not replace your tests: a passing run only means the configured checks accepted the work, so coverage depends entirely on the requirements, reviewers, and tests you provide. A self-hoster must operate the surrounding environment — a clean Git worktree per task, a harness login for Codex, Claude Code, or Copilot, and a Docker target if not using Zeroshot Cloud — and the npm path still requires Node.js 18 or newer even though the runtime itself is a native binary.

project readme (upstream, from github) — read inline

 

Release npm Build Opcore Coverage Docs License: MIT Discord

Zeroshot

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

Zeroshot turns a software goal into an explicit multi-agent graph: one agent implements, independent agents review, failures go back to a bounded repair loop, and nothing is delivered until the graph's checks pass. The implementing agent never approves its own work.

Use the built-in graph or bring your own topology. Add reviewers, tests, and repair loops, then save the setup as a profile for the next task.

Opcore works alongside it: Opcore checks each edit while an agent writes code, and Zeroshot has independent agents review the whole change before it lands.

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

When to use it

Zeroshot fits when:

  • a change should be checked by agents other than the one that wrote it, against the task's acceptance criteria and for code quality;
  • you want the result delivered as a branch, a pull request with review feedback handled, or a merge after CI;
  • you want the same review and repair setup reused across tasks, locally, on your own Docker target, or in Zeroshot Cloud.

It is not the right tool when:

  • you'll review a small edit yourself in the editor; a single agent session is quicker;
  • you need it to replace your tests. A passing run means the configured checks accepted the work, so coverage depends on the requirements, reviewers, and tests you provide.

Zeroshot v8 is a hard interface cutover. v8 replaces the Node.js runtime with a native zeroshot binary.

Install

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. Native archives and checksums are attached to each canonical vX.Y.Z GitHub Release.

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"
}

Check the graph, runtime configuration, and input without starting a run:

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

Then start it:

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.

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 a repair worker, 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.


Both reviews run again after a repair. Git delivery is optional.
Static diagram

Bring your own graph topology

Choose each agent's model and instructions, which steps run in parallel, and when to retry. For example, add a bugfinder and E2E tests after the code and acceptance review loop:

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

The bugfinder and E2E stages are custom additions. Provide their test tools, services, and credentials, and configure where failures route back 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

A profile stores a graph and its runtime settings. Use Profiles in the browser UI to edit and save your configuration. Keep different profiles for different kinds of work, or reuse one for the next task.

Once you've saved a local profile named my-profile, run another task with it:

zeroshot run \
  --title "My next task" \
  --profile local:my-profile \
  --input input.json

The CLI and UI share the same local profiles. Pass --target NAME to zeroshot ui to inspect a configured direct or hosted target's run history while keeping profiles local. See UI setup.

Experimental: expose a local graph as an ACP agent. First create the separate acp-worker profile from the ACP guide. ACP requires a response output and node-scoped sessions; the software-change profile above is not compatible. Each prompt runs the graph while the ACP session keeps the workspace and node sessions alive:

zeroshot acp --profile local:acp-worker

Choose delivery and execution

Keep the first result local, then enable the delivery mode that fits your process:

Delivery Behavior
No delivery flag Keep the work local
--push Push the managed branch
--pr Prepare a mergeable pull request without merging
--ship Proceed through PR, CI, and merge

PR and ship runs address visible pull request review feedback by default; pass --no-pr-feedback to ignore it.

Graphs can execute locally, on a self-hosted target, or in Zeroshot Cloud. Each environment needs its own tools and authentication setup. Hosted merge plans, which coordinate several dependent jobs, are a Zeroshot Cloud feature.

Self-hosted: run the Docker target

Keep execution and durable state on infrastructure you control. The target image includes the native engine plus pinned Codex, Claude, and GitHub Copilot harness CLIs.

docker run --detach --restart unless-stopped --name zeroshot-target \
  -p 127.0.0.1:8080:8080 \
  -v zeroshot-data:/var/lib/zeroshot \
  ghcr.io/the-open-engine/zeroshot-target:latest

zeroshot target add local --url http://127.0.0.1:8080 --direct

The target also serves its profile editor and run viewer at http://127.0.0.1:8080/ui/.

See the target image guide for persistent storage, network isolation, builds, and HTTPS.

Zeroshot Cloud: close the laptop

Use the built-in cloud target at https://api.cloud.zeroshot.sh for a shared team queue and durable run history:

zeroshot target login cloud

Open the printed link to sign in with the device code already filled in. Use --target cloud when submitting runs.

When a failed run has a recoverable workspace, restart its graph on the latest saved files or choose an earlier node boundary:

zeroshot resume RUN_ID
zeroshot checkpoints RUN_ID
zeroshot resume RUN_ID --from-checkpoint CHECKPOINT_ID

Add --target NAME for Docker or Cloud. See Restart or resume a failed run for restore rules and retention.

Research graph

Zeroshot also includes an auto-research graph for ten bounded iterations of experiments with independent review of evidence, method, and progress. It keeps adopted, record-only, and aborted results under .zeroshot/research; add --push when each finalized iteration should be published.

zeroshot template list
zeroshot template show auto-research

See Execution for the research workflow's decision and evidence rules.

Community

Reference

Development

npm ci
npm run check
cargo test --workspace # Unix; Windows: powershell -NoProfile -File scripts/test-windows.ps1

Node.js builds the static UI and supports repository tooling and npm delivery; Rust serves the UI. See UI development, CONTRIBUTING.md, PUBLISHING.md, and SECURITY.md.

License

MIT. See LICENSE.

Frequently asked questions

Is zeroshot free to use?

zeroshot is open source under the MIT licence. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does zeroshot do?

Runs coding agents as a graph: one agent implements, independent agents review, failures go to repair, and nothing ships until the checks pass. Works with Codex

What is zeroshot written in?

zeroshot is primarily written in Rust. Its source is publicly available at https://github.com/the-open-engine/zeroshot, and it has 1,919 GitHub stars.