Skip to content

Rhumbatron

Rhumbatron lets a team of people and AI agents change one codebase at the same time.

Rhumbatron lets a team of people and AI agents change one codebase at the same time. You describe an outcome in plain language. Agents do the work in parallel. Before their work merges, Rhumbatron finds conflicts between their plans. It then builds each version, tests it, and uses it in a real browser. It deploys only a version that passes all of its required checks. When a check fails, a repair Task starts automatically.

Rhumbatron runs on your computer as one Docker Compose stack, at https://rhumbatron.localhost. Every component is open source. Only the model calls to Anthropic cost money.

Made by Sudhanva Narayana and Maanasa Narayan.

flowchart LR
  goal[Request in plain language] --> intake[Intake check<br/>clear? duplicate?]
  intake --> plan[Work Graph<br/>Tasks + dependencies]
  plan --> wake[Causal wake-up<br/>only ready Tasks]
  wake --> agents[Agents in parallel<br/>one Git fork each]
  agents --> intents[Typed Intents and Claims<br/>on semantic resources]
  intents --> conflict{Semantic<br/>conflict?}
  conflict -->|no| compose[Compose one Candidate]
  conflict -->|yes| fork[Fork Candidates<br/>A and B]
  compose --> verify[Verify with evidence<br/>build, tests, contract, browser, p95]
  fork --> verify
  verify --> select[Select by evidence]
  select --> promote[Compare-and-swap promotion<br/>S41 → S42]
  promote --> live[Live app on<br/>workerd]
  • Parallel agents. Each agent has an isolated Git workspace and a Sandbox. Agents without ready work stay asleep.
  • Semantic conflict detection. Rhumbatron finds conflicts between designs, for example two data models for one feature, even when the text merges cleanly.
  • Evidence-based merge. Build, test, contract, browser, and acceptance checks decide which version ships. A skipped check never counts as a pass.
  • Browser check. Each version that changes pages opens in a real browser, at every risk tier. The check submits each form with sample data, then opens every linked page by a click and by a direct load. A not-found page, a script error, or a failed page or asset stops the version, and a repair Task starts.
  • Safe promotion. One compare-and-swap per version, so two merges cannot overwrite each other.
  • Teams. Owner, admin, member, and viewer roles. A Board shows each request by person and by stage.
  • Cost control. Budgets for each request, Project, and person. Small Tasks use less expensive models.

The stack runs behind Caddy at https://rhumbatron.localhost (ADR 0034).

Function Component What Rhumbatron uses it for
Edge, TLS, routing Caddy 2.11 (edge) Signs the certificate of every *.rhumbatron.localhost host with its own local CA. Routes rhumbatron.localhost, api., docs., and each app subdomain. Serves the docs site.
Web app TanStack Start on Bun 1.3.14 (web) The UI. Server functions call the API.
API and back end One Bun 1.4.4 process (core) Runs the API, the coordinator, the agents, integration, the event router, and the indexer. Calls between them are in-process calls.
Actors The actor host in packages/platform ProjectRootDO keeps the Canonical Generation and does the compare-and-swap promotion. ResourceShardDO keeps Claims and Intents. ProjectViewDO sends live updates over WebSockets. AgentDO keeps agent state. Each actor has its own SQLite file.
Workflows The workflow engine in packages/platform Runs ChangeWorkflow (plans a Change), CandidateVerificationWorkflow (runs the checks), and ReleaseWorkflow (deploys the live app).
Commands and Events NATS JetStream 2.15 (nats) One work-queue stream carries the commands: agent wake-ups, integration, verification, indexing, release, and failed commands. Eight streams keep all Events in order. Actors write each Event to an outbox first.
Product data SQLite in core Projects, Changes, Tasks, Candidates, check summaries, members, usage meters, the policy copies, the vectors, and the metrics.
Large files versitygw 1.10 (objects) An S3 bucket for check reports and logs, context packets, patches, app bundles, and the event archive.
Source The git service (git) One bare Git repository per Project. Each agent Task, Candidate, and code edit session works in its own fork.
Sandboxes sandboxd with sibling containers Runs agent shell commands, bun install, builds, and Candidate tests in an isolated Linux container with an egress allowlist.
Live apps workerd with the Worker Loader (apps) Loads and runs the bundle of each live app at <slug>.rhumbatron.localhost and each Candidate preview. Loaded apps have no network access. AppDataDO keeps the data of each app. Each app cookie gets the rba_ prefix on the app host.
Browser checks Playwright 1.64.1 server (browser) Opens each Candidate preview that changes pages in a headless browser. Visits up to 8 linked pages, submits forms, and saves screenshots as Evidence.
Embeddings and rerank llama.cpp (embed, rerank) bge-small-en-v1.5 makes embeddings. bge-reranker-base ranks related requests at intake.
Small decisions (Clef-flash) Claude Haiku with a forced tool call Picks the model tier for a step, decides whether an Event wakes an agent, and checks whether a request is clear and new. Rhumbatron uses a decision only when its confidence is high enough. It also writes the goal suggestions for a new Project.
Model calls The Anthropic API All Claude calls. An in-app meter reserves and settles each call and stops calls at the monthly budget.
Sign-in Clerk development instance Accepts rhumbatron.localhost.

The agents use Claude Sonnet 5.5 and Claude Haiku 5.5.

flowchart LR
  user[Browser] --> edge[Caddy]
  edge --> web[web]
  edge --> core
  subgraph core[core]
    api[API] --> cw[ChangeWorkflow<br/>planner]
    cw --> router[event router<br/>causal wake-ups]
    router -->|ready Tasks| agent[AgentDO<br/>agent loop]
    agent -->|ChangeSet| integ[integration<br/>compose + verify]
    integ -->|compare-and-swap| root[ProjectRootDO]
    router --> view[ProjectViewDO]
  end
  web --> api
  agent -->|fork, commit| git[(git)]
  agent -->|shell| sbx[sandboxd]
  integ --> ev[(Evidence<br/>SQLite + objects)]
  root -->|outbox| js[(JetStream events)]
  js --> router
  integ -->|release| apps[apps<br/>workerd]
  edge --> apps

The architecture guide gives the details.

  • Architecture: how a goal becomes one verified canonical future.
  • Operations: the local stack, release, costs, cleanup, naming.
  • Demo: the prediction market runbook and the shared requests demo.
  • Decisions: the architecture decision records.
  • Protocols: the protocol schemas and the API routes.
  • Build status: current phase and progress.