Codeswarm is a provider-agnostic execution system for orchestrating multi-node Codex workers on:
- Local processes (single machine)
- Slurm clusters (HPC)
- AWS EC2 + shared EBS
It provides a router control plane, a backend API/WebSocket bridge, and a Next.js frontend.
Current implementation includes two complementary operating modes:
- ad hoc swarm operation with direct prompt routing
- opt-in orchestrated projects with planner-generated task graphs, deterministic worker dispatch, live project/task UI, and project resume
curl -fsSL https://raw.githubusercontent.com/kalowery/codeswarm/main/install-codeswarm.sh | bashThat installer downloads the latest published release bundle from GitHub Releases, installs the bundled Python wheel into a private virtualenv, installs CLI/backend runtime dependencies, and writes a codeswarm launcher into ~/.codeswarm/bin.
To pin installation to a specific published release, fetch the installer from that tag:
curl -fsSL https://raw.githubusercontent.com/kalowery/codeswarm/v0.1.2/install-codeswarm.sh | bashOptional installer overrides:
CODESWARM_INSTALL_DIR(default:~/.codeswarm)CODESWARM_RELEASE_URLCODESWARM_RELEASE_ARCHIVECODESWARM_INSTALL_MODE=release|sourceCODESWARM_REPO_URLandCODESWARM_BRANCHfor source-mode installs only
- Install a published release
curl -fsSL https://raw.githubusercontent.com/kalowery/codeswarm/main/install-codeswarm.sh | bash- Start the full web stack
codeswarm web --config ~/.codeswarm/configs/local.jsonThis starts:
- Router on
127.0.0.1:8765 - Backend on
http://localhost:4000 - Frontend on
http://localhost:3000
Use this path for development, branch testing, or when you want the working tree directly on disk.
- Clone
git clone https://github.com/kalowery/codeswarm.git
cd codeswarm- Bootstrap dependencies
./bootstrap.shbootstrap.sh installs Node 24.13.0, workspace dependencies, builds the frontend/backend/CLI artifacts, links the codeswarm CLI, and checks for optional Beads CLI (bd) with an optional install prompt.
It also installs the Python package in editable mode so router, agent, slurm, and related modules resolve directly from the git checkout.
If runtime packages are missing after branch switches or large git updates, run:
npm install --workspacesThen rebuild the JS artifacts if needed:
npm run build:allFor a package-style Python install without the full bootstrap flow:
python3 -m pip install --user --break-system-packages -e .If you are using a virtual environment, drop --user --break-system-packages.
- Use local config
configs/local.json already exists and uses local backend:
{
"cluster": {
"backend": "local",
"workspace_root": "runs",
"archive_root": "/tmp/archives"
}
}Note: configs/combined.json is intentionally treated as a local operator file and is not tracked by git.
- Start the full web stack
codeswarm web --config configs/local.jsonYou can also run components manually from the checkout:
python3 -u -m router.router --config configs/local.json --daemon
npm --prefix web/backend run dev
npm --prefix web/frontend run devIf you only want terminal-based swarm launch, you do not need the web stack:
codeswarm providers --config configs/local.json
codeswarm launch --nodes 2 --prompt "You are a focused autonomous agent." --provider local --config configs/local.json
codeswarm stop-all --config configs/local.jsonOptional web-launch parity flags:
--agents <path>accepts either a singleAGENTS.mdfile or a persona directory containingAGENTS.mdand optionalskills/--provider-param key=valuecan be repeated for provider-specific launch fields--provider-params-json '{"key":"value"}'passes provider overrides as JSON--detachexits after launch; otherwise the CLI follows INFO activity logs by default
Codeswarm now supports a deterministic project mode alongside normal swarm usage.
High-level flow:
- Launch or select a planner swarm.
- Launch one or more worker swarms.
- In the web UI, create a project in one of two modes:
- plan from a spec plus planner swarm
- create directly from an explicit task list
- Router schedules one task at a time to idle worker nodes, with each task executed on its own branch in an isolated per-worker repo checkout.
- A final integration task is appended automatically and runs after implementation tasks complete.
Repository inputs supported by the project UI and backend:
- existing local git repo path
- existing GitHub repo reference
- GitHub owner/repo with create-if-missing behavior for project planning/execution flows
Project resume is also implemented:
- resume reconciles router project state against durable task branches in the canonical repo
- assigned tasks can be recovered or reset
- failed tasks can optionally be retried
- worker swarms can be replaced at resume time
CLI support:
codeswarm project resume-preview <project-id> --config configs/local.json
codeswarm project resume <project-id> --config configs/local.jsonRecommended local launch presets for project work:
local-orchestrated-plannerlocal-orchestrated-worker
These presets default to real Codex workers, approval_policy=never, sandbox_mode=danger-full-access, native auto-approval, and orchestrated-worker-safe thread behavior. The same launch path now also supports worker_mode=claude.
Codeswarm handles execution approval in its own UI/router flow (exec_approval_required -> /approval -> router approve_execution).
To avoid conflicting prompts and write failures, configure Codex for workspace writes and no internal approval gate:
sandbox = "workspace-write"
approvalPolicy = "never"Equivalent CLI flags:
codex --sandbox workspace-write --ask-for-approval neverIf Codex is left in read-only or on-request modes, commands may execute inconsistently or fail to write files.
Claude is supported as a local, AWS, and Slurm worker runtime through the Anthropic Claude Code SDK/CLI path.
- current support scope is local, AWS, and Slurm swarms, plus orchestrated project flows where the provider supports repository preparation
- select
worker_mode=claudein the launch modal or provider defaults approval_policy=nevermaps to Claude bypass mode- non-
neverapproval policies route tool permissions through the normal Codeswarm approval UI - if no
claude_env_profileis selected, Claude inherits the router process environment as-is
The sample local configs include an AMD gateway profile named amd-llm-gateway. It expands ${LLM_GATEWAY_KEY} from the host environment and injects:
ANTHROPIC_API_KEY=dummyANTHROPIC_BASE_URL=https://llm-api.amd.com/AnthropicANTHROPIC_CUSTOM_HEADERS=Ocp-Apim-Subscription-Key: ${LLM_GATEWAY_KEY}- model defaults such as
ANTHROPIC_DEFAULT_SONNET_MODEL CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1
Claude launch/runtime precedence is:
worker_mode=claudeselects the Claude worker implementation.claude_env_profileinjects a named Anthropic environment bundle from the active provider backend config'sclaude_env_profiles.- If no profile is selected, the worker uses inherited host env such as
ANTHROPIC_API_KEY,ANTHROPIC_BASE_URL, andANTHROPIC_MODEL. claude_modeloverrides the model passed to the Claude SDK for that swarm.pricing_modelcan override billing lookup independently from the runtime-selected model.
Auth selection is therefore deterministic:
- profile selected: use the resolved profile values, with
${VAR}placeholders expanded from the router host environment at launch time - no profile selected: use whatever Anthropic env vars already exist in the router process environment
- placeholder missing: swarm launch fails rather than silently running with incomplete auth
This means Codeswarm will use plain ANTHROPIC_API_KEY-style environment configuration by default, and can also route Claude through the AMD LLM gateway when a profile injects gateway-specific values.
For containerized local workers, the default image is now the published GHCR image ghcr.io/kalowery/codeswarm-local-worker:latest.
If that image is not locally present, Codeswarm will try to pull it first and fall back to building from local-worker.Dockerfile when a checkout is available.
Router-side usage accounting is model-aware and no longer assumes a single model for the entire project.
- pricing tables live in the top-level
model_pricingobject in the router config, for example configs/local.json - router also ships with a built-in default catalog in router/router.py
- configured
model_pricingentries override built-in defaults on a per-model basis - launch-time
pricing_modeloverrides the label used for spend lookup - if
pricing_modelis omitted, router falls back to the resolved agent model; Codex defaults togpt-5.4 - mixed-model task/project aggregates are labeled
mixedwhen usage from different pricing models is combined
Each pricing entry currently supports:
input_tokens_usd_per_mcached_input_tokens_usd_per_moutput_tokens_usd_per_mreasoning_output_tokens_usd_per_m
The UI now surfaces router-computed spend totals at the swarm, task, and project levels, so the config file is the source of truth for token billing rates.
For protocol debugging, you can enable continuous raw session capture from each worker:
export CODESWARM_CAPTURE_ALL_SESSION=1With that set before launch, workers emit every raw Codex session entry to mailbox outbox as session_trace records in addition to the normal codex_rpc stream. This applies to local, Slurm, and AWS worker launches.
flowchart TD
UI[Frontend Next.js] -->|WebSocket| BE[Backend Express]
BE -->|TCP codeswarm.router.v1| RT[Router]
RT --> PR[Provider Interface]
PR -->|local| LP[LocalProvider]
PR -->|slurm| SP[SlurmProvider]
PR -->|aws| AP[AwsProvider]
LP --> WK[Workers]
SP --> WK
AP --> WK
WK --> MB[Mailbox JSONL]
MB --> RT
Core principles:
- Provider abstraction: router is backend-neutral.
- Event-sourced UI: frontend state derives from streamed events.
- Mailbox contract: worker inbox/outbox JSONL files.
- Durable control state:
router_state.jsonand backendstate.json.
For local swarms on macOS and other non-Linux hosts, active-worker recovery now requires a fresh per-worker heartbeat rather than weak PID-only evidence. This prevents dead local swarms from being resurfaced as running after restart.
- Spawns worker subprocesses.
- Uses mailbox under
<workspace_root>/mailbox(defaultruns/mailbox). - Optional archive move on terminate via
cluster.archive_root. - When archive is enabled, per-job workspace plus mailbox artifacts are archived together under one job directory.
- Submits jobs through
slurm/allocate_and_prepare.py. - Uses SSH (
cluster.slurm.login_host, or profile-specificcluster.slurm.profiles.<name>.login_host) forsqueue,scancel, inbox writes, and outbox follower. - Mailbox under
<workspace_root>/<cluster_subdir>/mailbox.
Router command set (protocol codeswarm.router.v1):
swarm_launchinjectenqueue_injectqueue_listswarm_listswarm_statusapprove_executionswarm_terminateproject_createproject_planproject_startproject_resumeproject_resume_previewproject_list
UI prompt syntax supports both intra-swarm and cross-swarm targeting:
/all .../node[0,2-4] .../swarm[alias]/idle .../swarm[alias]/idle/reply .../swarm[alias]/first-idle .../swarm[alias]/all .../swarm[alias]/node[0,2-4] ...
Cross-swarm idle routes use the router queue and dispatch to the first target node with no outstanding work.
The frontend sidebar also shows queued cross-swarm items (source/target/selector/age/content).
Codeswarm supports launching workers with an optional Agent Persona.
Agent Persona definition:
- a directory with:
AGENTS.mdat directory root (required)skills/subdirectory (optional)
Launch UI behavior:
- if a single file is selected, its content is copied into each worker workspace root as
AGENTS.md(filename does not matter) - if a directory is selected, only root
AGENTS.mdand files underskills/are copied - persona skills are copied into each worker workspace root under
.agents/skills/... - repo root
AGENTS.mdis always prepended as a default baseline - if no user file/directory AGENTS content is provided, the repo root
AGENTS.mdis used by itself
Sample personas are provided under:
personas/amd-gpu-developerpersonas/full-stack-web-developerpersonas/flutter-mobile-app-developerpersonas/swarm-tool-orchestratorpersonas/cuda-swarm-tool-clientpersonas/cuda-swarm-responderpersonas/beads-task-graph-orchestrator
Backend inspects task_complete final assistant output and auto-submits any line that matches cross-swarm syntax:
/swarm[alias]/idle .../swarm[alias]/idle/reply .../swarm[alias]/first-idle .../swarm[alias]/all .../swarm[alias]/node[...] ...
This enables self-sustaining multi-swarm workflows where one swarm emits follow-on work for another.
Current repository-level automation includes:
- CLI build:
npm --workspace=cli run build - headless browser UI tests:
npm run test:web-ui - local orchestrated project runtime smoke:
npm run test:project-runtime-smoke - orchestrated project resume smoke:
python3 tools/orchestrated_project_resume_smoke.py - AWS runtime smoke:
python3 tools/aws_claude_runtime_smoke.py --provider aws-claude-default - AWS project smoke:
python3 tools/aws_claude_project_smoke.py --provider aws-claude-default --worker-mode claude --execution-mode container --container-engine docker - Slurm runtime smoke:
python3 tools/slurm_claude_runtime_smoke.py --provider slurm-claude-default - Slurm project smoke:
python3 tools/slurm_claude_project_smoke.py --provider slurm-claude-default
The browser suite uses Puppeteer and covers launch flows, project creation, worker interaction, and project resume behavior through the live frontend.
The project runtime smoke harness is runtime-aware and can be pointed at mock, codex, or claude for planner and worker swarms independently. Example:
python3 tools/orchestrated_project_runtime_smoke.py --planner-runtime codex --worker-runtime claude --mode both
python3 tools/orchestrated_project_runtime_smoke.py --planner-runtime claude --worker-runtime claude --mode plannedRemote smoke notes:
- AWS and Slurm smokes provision real remote workers
- GitHub-backed project smokes create temporary repos unless
--keep-repois set - GitHub repo cleanup requires
ghauth withdelete_reposcope
Full smoke-test documentation is in docs/SMOKE_TESTS.md.
npm install -g @openai/codexcodex loginEnsure router daemon is running on port 8765:
python3 -u -m router.router --config configs/local.json --daemonnpm --workspace=web/frontend run builddocs/CONFIG_SCHEMA.mddocs/PROTOCOL.mddocs/PROTOCOL_SPEC.mddocs/PROVIDER_INTERFACE.mddocs/SMOKE_TESTS.mddocs/USER_GUIDE.mddocs/QA_TEST_PLAN.md