SwarmCoder
IN DEVELOPMENT · APACHE 2.0 · CODE COMING SOON

Agentic software development that your organization can actually account for.

SwarmCoder is a multi-agent coding system that follows one fixed software development lifecycle every time it runs. It uses expensive frontier models only where a task genuinely needs that level of judgment, does the bulk of the work with swarms of cheap local models on your own hardware, and writes down every decision it makes along the way so that you can go back and check it later.

You make two decisions per story and the system does the rest.

How it works Project status

You make two decisions per story. The system does everything in between.

Everything happens on one board. A story appears when the planner suggests it, you decide whether it is real work, the swarm builds it, and then you judge whether the delivery is what you asked for. Nothing disappears off the board and nothing gets parked somewhere you have to remember to go and look.

YOU · DECISION 1
Accept the work
Is this suggestion real work that you want done, or is it not needed?
THE MACHINE · RECORDED END TO END
design plan into slices tests first swarm ×8 verify select on evidence integrate
If the system has a genuine question it asks you on the story card itself, with the buttons to answer it right there.
YOU · DECISION 2
Judge the delivery
Accept the commit, or send it back with a note explaining what is wrong.
Every line of code can be traced back

For any line of code you can see which worker wrote it, which candidate it was part of, which test proved it and which requirement asked for it, right back to the sentence in the document it came from. And you can still query this months later, in either direction.

Your code stays on your network

The token heavy part of the work, i.e. the loops that read through your whole repository, runs on your own hardware. The cloud based roles only ever see typed summaries and diffs, never a raw worker session, and whatever cloud spend remains is capped per run.

A specification that stays true

Every requirement is bound to an executable check, so it is only marked as implemented when there is evidence (a commit and a passing test) and not because somebody said so. If you edit the wording of a requirement, the evidence is marked as stale and you can see that on the board.

Many cheap attempts generally beat one expensive attempt.

On hardware you own, running eight workers on the same task costs roughly the same as running one, because the model weights are read out of memory once per step regardless of how many sequences are in flight. So if seven of the eight attempts get thrown away, that is fine, that is basically how the method is supposed to work. You can only afford to think this way when the marginal cost of a token is your electricity bill.

8+
parallel attempts per task, at the cost of one
2
decisions asked of you per story, and no more
100%
of implementation tokens generated locally
0
rate limits, per-seat meters, or queues
Why run it locally? →
Frontier — judgment onlySCALES WITH TASKS
The analyst, architect, reviewer, test author and judge. Each of these gets one attempt at an artifact that nothing downstream can check mechanically, so the work is kept small and structured, and the spend is capped per run.
Local — everything elseSCALES WITH TOKENS
The worker swarms, retrieval, chat and the learning that happens after a run. This is over 95% of the token volume and it all runs on your hardware, which is possible because every worker output has to pass a verification gate anyway.

Fifteen agents, each on the model its task actually needs.

SwarmCoder is a multi-agent system, and which model an agent runs on is essentially a cost decision made per task. Every agent runs on the cheapest model that can do its particular job well, whether that is a frontier model, a mid-tier one or a local one. The rule of thumb is simple enough: you need a frontier model where there is no test sitting in front of the output to catch a mistake.

Workers get eight attempts and a verification gate, so they can run as swarms of local models. The judgment roles, on the other hand, get one shot at an artifact that nothing downstream can check mechanically, and that is where the frontier spend goes. Keep in mind that this spend is small, structured and capped per run.

Meet all fifteen agents →

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

The price you pay for frontier tokens today is a market share price and not a cost price, and most agentic coding platforms are built to consume more and more of them with every release. SwarmCoder is designed the other way around, and it was designed that way before the repricing rather than after it.

THE SUBSIDY
Frontier inference is heavily subsidized to win market share. Whether or not the AI bubble actually bursts, prices that sit below cost eventually have to correct, and at that point the cost of your development capability is a number that somebody else sets.
THE INDUSTRY'S BET
Agentic platforms are generally heading in the opposite direction, with longer sessions, more tool calls and more frontier tokens per unit of delivered software. Rising consumption and artificially low prices cannot both continue indefinitely.
THE PRE-EMPTIVE ANSWER
SwarmCoder treats token cost as an architectural constraint from the start. Judgment is a few capped frontier calls per story, and over 95% of the token volume runs locally at the cost of electricity, so even a 10× repricing of frontier tokens would not change your bill very much.
Read the full argument →

Generating code is cheap. Choosing the right candidate is the hard part.

Most tools that run agents in parallel simply hand you a row of tabs and twenty diffs to read through yourself. SwarmCoder picks the winner mechanically: the tests are written first in a place the workers cannot touch, the cheap filters (does it parse, does it compile) run before the expensive ones, the survivors are grouped by how they actually behave, and only then does a judge rank a handful of genuinely different diffs against the real test results.

Exactly one candidate wins, and alternatives are never merged together. The losing candidates are archived along with their evidence rather than deleted, so you can always go back and see what else was tried.

See how selection works →
8 candidates
parse filter
build + tests
cluster by behavior
judge on evidenceranked vs. real test results
1 winner → commit

Who this is for (and who it is not for)

SwarmCoder is for organizations that need proper traceability on their software development, i.e. one process that is followed every time and leaves a record behind, rather than an agent that reinvents its way of working on every run. It runs on your own hardware, on your own network and against your own repository. If you are a solo developer who is happy with a chat based coding assistant, this is probably not for you, and you should not change what already works.

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.