Sidecrew MCP server

sidecrew

You ask for a change to your source code, and you get it — made on your Mac, by models that cost you no Claude tokens, and only after a machine has checked it.

Claude Opus plans the work and reviews what came back. Small models running locally (MLX, no network) do the narrow parts. Between them sits a gate a machine can run — for a code change: the diff stayed where it was asked to, tsc is clean, and every test that passed before still passes. Claude never sees anything that did not survive it.

$ sidecrew fix change_plan.json
fix 2026-09-20T09-14-02Z-rename: 1 step, 12 tasks, 13.0 GB free ÷ 6.5 GB per slot = 2; 1 worker up
step 1/1 "rename the helper": capturing the baseline
rename-01: survived (src/util/asset.util.ts)
rename-02: survived (src/util/asset.util.ts, src/util/asset.util.spec.ts)
…
multi-06: failed at compile · escalating — renamed the symbol 7 times over, 5 compile errors
11/12 survived · 0 → 0 tsc errors · .sidecrew/runs/2026-09-20T09-14-02Z-rename/result.json

Illustrative shape, not a captured transcript — it is the real output format with the counts from the React measurement below, and no client's file names. 11 of 12 with a 95 % interval of [0.615, 0.998] is the number; the line above is what it looks like while it runs.

Unit tests are workload #1 — the same shape with a mutation-kill gate instead — and the numbers for both are below, each with its interval.

sidecrew needs 24 GB of installed RAM. Below that a 7B cannot sit beside a normal working set (measured), so sidecrew refuses to run and tells you why rather than quietly becoming a different tool (ADR-0073). sidecrew doctor answers this before you plan anything.

And the other half of the ledger, measured 19–20 Sep 2026: the workers are free, the coordination is not. Opus planning costs 8,400–22,100 tokens per task, depending almost entirely on how many tasks are in the plan — see What this costs to run below. A page that says "the work is free" without saying that is telling you half of it.

Before any number below: how tightly to read it

Every rate on this page is an interval, never a point, and the reason is measured. Replaying a frontier model's own diffs — which the gate finds no defect in — through the gate a second time, it disagreed with itself on 2 of 19 candidates: D = 0.105, 95 % interval [0.013, 0.331] (experiments/gate-error-rate/, against a rule frozen before the first replay). That rule's own verdict at D > 0.10 is UNACCEPTABLE, and its consequence is this paragraph: no survival rate here is published as a bare fraction, D travels beside each of them, and no two of our rates are compared without asking whether their difference survives it.

What that does and does not damage. D counts the gate refusing changes that were fine. Nothing in it is evidence of the gate admitting something bad. So:

The gate admits nothing that fails — stands.

The gate refuses only things that fail — **measured false, at roughly one evaluation in ten, and

unproven at any tighter bound.**

Two of the three known causes are now recorded on every verdict — memory pressure (ADR-0066) and a baseline captured on a different calendar day (ADR-0069). The third is undiagnosed, and both measured disagreements happened on a quiet machine, so it is neither of the first two. D was measured on workload #2a's gate; it says nothing about workload #1's mutation gate, which is a different oracle (§4.4 of the rule).

Workload #2a — behaviour-preserving changes, measured

Against a decision rule frozen before the tool had produced a single verdict (experiments/go-no-go-2a/results/REPORT.md). S is survival, A is a blind reviewer's approval of the diff. Every cell is k/n with its exact 95 % interval; D = 0.105 [0.013, 0.331] applies to every S.

Shortened. The full README is on GitHub.