TORCH

TORCH 0.1.0-alpha.3 · Experimental pilot

An AI team shaped by your project.

TORCH is a local-first, project-aware foundation for a provider-flexible AI fleet. The active TORCH-on-TORCH self-host pilot is Codex-run. Built-in Codex, Claude, and Pi adapters exist; live mixed-provider swaps and production use remain unqualified.

See how to start Source and install guide

From project brief to checked work

  1. P
    Project + specificationTORCH maps code, tests, constraints, and stated goals.
  2. T
    Proposed teamYou review domains, responsibilities, and reporting lines.
  3. AI
    Your runtime for each sessionCodex, Claude, Pi, or a trusted local adapter.
    Direct peer links
  4. ↔
    Shared coordinationSessions exchange messages, status, tasks, and evidence.
  5. ✓
    Checked integrationWork converges through an authorized, serialized path.

Start with the repository. The proposed fleet stays yours to shape.

Built around your repo

Codex · Claude · Pi

Choose per session

Local-first control

Owner-shaped fleet

The project shapes the organization.

TORCH does not start from a fixed roster. It studies the repository and specifications you choose, then proposes a team you can split, merge, rename, or reject before anything is installed.

Understand

Read the real project

Architecture, tests, working practices, shared files, and your selected specifications become evidence for a proposed fleet.

Coordinate

Give each session a lane

Roles get explicit scope, exclusions, neighbors, checks, and worktree boundaries. Each session can use the runtime and model that fit its job.

Grow

Change shape when needed

As coordination grows, TORCH can recommend a lead or new specialist when there is real integration work to own. You review the evidence and approve every organization change.

Keep the right context close to the work.

Each long-lived session can focus on a coherent part of the project, while durable messages and shared records connect it to the rest of the fleet. The aim is less context thrash—not a set of agents trapped in silos.

Lower cache and context costs are a hypothesis TORCH still needs to measure.

Trust comes from evidence.

The active pilot uses the accepted immutable 0.1.0-alpha.3 artifact from source 28c. Later canonical source at 0c2 is not installed automatically. The user-system schedule timer is installed and running; automatic AI wakes remain paused. Pipeline execution, isolated candidate-executor assurance, and production acceptance remain open.

CapabilityCurrent evidenceState
Project analysis and fleet designRepository/spec scenariosProven locally
Shared messages, status, and tasksDurable local control planeProven locally
Exact-commit checks and serialized integrationImplemented coordination foundationCandidate executor and fence assurance open
Codex, Claude, Pi, and local adaptersBuilt-in adapters; live mixed-provider swap unqualifiedLive provider gate open
TORCH-on-TORCH self-host pilotCodex-run; accepted alpha.3 artifact is source 28c; canonical source 0c2 is not auto-installedPilot active; full qualification open
COMBATRIG importRead-only inventory; ownership review neededMigration gated

Start with the project you already have.

Point TORCH at a Git repository and, if useful, a product specification. It prepares an evidence brief for a fleet proposal; installing or starting the team waits for your review and approval.

torch bootstrap \
  --repo /path/to/project \
  --spec /path/to/product-spec.md \
  --output fleet-design-brief.json \
  --json