SwarmCoder
IN DEVELOPMENT · APACHE 2.0 · CODE COMING SOON

Agentic coding your organization can actually account for.

SwarmCoder runs a team of specialized agents through one fixed development lifecycle — frontier models only where judgment demands them, swarms of cheap local ones for the bulk of the work, and every decision written down.

You decide twice per slice. The machine does the rest.

How it works Project status

You decide twice. Everything between is the machine's job.

One board. A story appears when the planner suggests it — you accept it as real work, the swarm builds it, you judge the delivery. Nothing vanishes, nothing parks off-screen.

YOU · DECISION 1
Accept the work
"This suggestion is real." Or: not needed.
THE MACHINE · RECORDED END TO END
design plan into slices tests first swarm ×8 verify select on evidence integrate
If it has a genuine question, it asks on the story card — with the buttons that answer it.
YOU · DECISION 2
Judge the delivery
Accept the commit, or send it back with a note.
Every line has a receipt

Which worker wrote it, which candidate won, which test proved it, which requirement demanded it — down to the sentence of the document it came from. Queryable months later, in both directions.

Your code never leaves

The token-heavy loops that read your whole repository run on your own hardware. Cloud roles see typed summaries and diffs — never a raw worker trajectory. Remaining cloud spend is capped per run.

A spec that cannot rot

Every requirement is bound to an executable check. It flips to implemented on evidence — a commit and a passing test — not on anyone's say-so. Edit the wording and the evidence goes stale, visibly.

Many cheap attempts beat one expensive one.

On hardware you own, eight workers on one task cost roughly what one costs. If seven of eight attempts are wasted, that is not a failure of the method — it is the method. You can only afford to think that way when the marginal cost of a token is electricity.

8+
parallel attempts per task, at the cost of one
2
decisions asked of you per story — no more
100%
of implementation tokens generated locally
0
rate limits, per-seat meters, or queues
Why local, specifically →
Frontier — judgment onlySCALES WITH TASKS
Analyst, architect, reviewer, test author, judge. One shot each at artifacts nothing downstream can mechanically check — small, structured, capped per run.
Local — everything elseSCALES WITH TOKENS
The worker swarms, retrieval, chat, post-run learning. 95%+ of token volume, on your hardware, priced in electricity — because every worker output faces a verification gate.

Fifteen agents. Each on the model its task actually needs.

SwarmCoder is multi-agent by design, and model selection is a per-task cost decision: every agent runs on the cheapest model that can do its job well — frontier, mid-tier, or local. The rule that sorts them: frontier is needed where there is no test in front of the output.

Workers get eight attempts and a verification gate, so they run as local swarms. The judgment roles get one shot at artifacts nothing downstream can mechanically check — that is where the frontier spend goes, and it is small, structured, and capped per run.

Meet all fifteen agents →

Frontier tokens are sold below cost. Plan for the day that stops.

Today's frontier pricing is a market-share price, not a cost price — and most agentic coding platforms are architected to consume more of it with every release. SwarmCoder is built the other way, before the repricing, not after it.

THE SUBSIDY
Frontier inference is heavily subsidized to win market share. Whether or not the bubble bursts, prices that sit below cost eventually correct — and your development capability becomes a line item someone else reprices.
THE INDUSTRY'S BET
Agentic platforms are moving the other way: longer trajectories, more tool calls, more frontier tokens per unit of delivered software. Two curves — rising consumption, artificially low prices — cannot both continue.
THE PRE-EMPTIVE ANSWER
SwarmCoder treats token cost as an architectural constraint now: judgment is a few capped frontier calls per story; 95%+ of token volume runs locally, priced in electricity. A 10× repricing barely moves the bill.
Read the full argument →

Generation is cheap. Selection is the product.

Other parallel-agent tools hand you a row of tabs and twenty diffs. SwarmCoder picks the winner mechanically: tests are written first where workers can't touch them, cheap filters run before expensive ones, survivors are clustered by behaviour, and only then does a judge rank a handful of genuinely different diffs against real test results.

One candidate wins. Alternatives are never merged. Losers are archived with their evidence — never deleted.

See the whole selection machinery →
8 candidates
parse filter
build + tests
cluster by behaviour
judge on evidenceranked vs. real test results
1 winner → commit

Built for teams that can't throw code over the wall.

SwarmCoder is for organizations that need proper traceability on their software development — one process, followed every time, with the receipts — instead of an agent that reinvents its way of working on every run. It runs on your hardware, on your network, on your repository.

The principles Where this is today
SwarmCoder

Agentic software development with full traceability — built on ZeroZ4j by Franz Schöning, Principal Enterprise Architect.

swarmcoder.dev GitHub ↗ soon zeroz4j.com ↗ franzschoning.com ↗ ● In development · Apache 2.0
© 2026 Franz Schöning. Released under the Apache License 2.0.