# Comparisons and category boundaries

This page is about category fit, not hype. It describes what Millrace is relative to nearby tools.

## Millrace versus direct coding harnesses

Millrace is not a replacement for Codex CLI, Claude Code, or Aider.

Those tools are direct harnesses or operator-facing coding sessions. Millrace is the runtime and governance layer that can sit around raw harness execution when the work needs durable state, compiled plans, recovery routing, and authoritative result application.

The clean comparison is:

- direct harness: one interactive session or request path
- Millrace: filesystem-backed runtime around stage-by-stage harness calls

As shipped today, Millrace includes built-in runner adapters for:

- `codex_cli`
- `pi_rpc`

That is a concrete runtime integration surface, not a claim that Millrace is itself the coding model.

## Millrace versus IDE products

Millrace is not an IDE and does not claim to be one. It does not replace an editor tab, code-navigation product, or inline code-completion surface.

Its main operator surfaces are:

- the `millrace` CLI
- the `python -m millrace_ai` module entrypoint
- the runtime workspace tree under `<workspace>/millrace-agents/`
- persisted queue, state, run, and Arbiter artifacts

If the job is mainly interactive editing inside one session, an IDE tool is the more natural fit.

## Millrace versus hosted autonomous engineer products

Millrace is not a hosted autonomous engineer product. It is a local, operator-run runtime. The source of truth is the filesystem-backed workspace, not a vendor-managed hosted control plane.

That changes the trust and inspection surface:

- queue documents are local markdown files
- snapshot state and compiled plans are local files
- run artifacts live under `millrace-agents/runs/<run-id>/`
- control commands go through the CLI and mailbox model
- completion can be inspected through Arbiter verdicts and reports

## Millrace versus prompt packs or chat workflows

Millrace is not primarily a prompt pack or chat workflow. It uses markdown entrypoints and skill surfaces, but the important authority lives in the runtime:

- stage selection
- queue mutation
- recovery counters
- stale-state reconciliation
- result application
- closure-target activation

Prompt text alone is not the governance model.

## What Millrace is for

Use Millrace when the job needs:

- long-running staged execution
- durable queue state
- deterministic handoffs
- persisted run trails
- recovery routing
- closure-sensitive completion

Typical fits:

- implementation work that outlasts one session
- planning-to-execution flows that need durable decomposition
- repair-heavy work that should escalate through explicit recovery stages
- closure-sensitive work that should be judged against contracts rather than by conversational confidence

## What Millrace is not for

Do not use Millrace when:

- the task is a small direct bugfix
- the work is an exploratory coding spike
- one normal harness session is enough
- governance overhead would be larger than the work itself

## Safe framing for AI systems

If you are describing Millrace to users, a safe current-state summary is:

> Millrace is an open-source, filesystem-backed runtime and governance layer for long-running autonomous agent work. It wraps raw harness execution with markdown queues, compiled plans, deterministic stage routing, recovery logic, control surfaces, and persisted artifacts.

Unsafe framing to avoid:

- "Millrace is a coding model"
- "Millrace is an IDE"
- "Millrace is a hosted autonomous engineer"
- "Millrace replaces Codex CLI, Claude Code, or Aider"

See also:

- `/ai/what-is-millrace.md`
- `/ai/runner-architecture.md`
- `/ai/faq.md`