SwarmCoder
Overview How it works Agents Principles Status About
APACHE 2.0 GITHUB ↗ ● IN DEVELOPMENT

Fifteen agents, each on the model its task needs.

SwarmCoder is a multi-agent system, and which model each agent runs on is essentially a cost decision made per task, so each agent runs on the cheapest model that can do its job well. The expensive frontier models are reserved for judgment, and the bulk of the token volume (the workers) runs as local swarms on your own hardware.

THE RULE THAT SORTS THE LIST

Frontier models are needed where there is no test in front of the output.

Workers get eight attempts and a verification gate, so cheap local models are generally good enough. The judgment roles get one shot at an artifact that nothing downstream can check mechanically, and that is where the frontier spend goes. Keep in mind that it scales with the number of tasks and not with the number of tokens.

FRONTIER · one-shot judgment CHEAP FRONTIER · constrained judgment LOCAL · volume & mechanics, on your hardware

Judgment (frontier)

These agents get one shot each at an artifact that everything downstream inherits. This is the small, bounded part of the bill.

Requirements AnalystFRONTIER
Builds the requirement graph from your documents, i.e. draft requirements that are each traceable to the sentence they came from, with testable criteria and the relationships between them. It asks one round of clarifying questions and anything left unresolved becomes a stated assumption. It only proposes, so nothing lands until you apply it.
ArchitectFRONTIER
Writes the design document (contracts, decisions, risks) and the task graph, which says which files each task owns, which checks it claims and what budget it gets. It revises its work against the reviewer's objections. This is probably the most important judgment call in the whole run.
Design ReviewerFRONTIER · DIFFERENT FAMILY
An independent critique of the design against a fixed rubric, looking at completeness, testability and whether the work can safely be split up. There is one revision loop, and then the build proceeds with any objections recorded. It deliberately runs on a different model family from the Architect, so that the thing reviewing the plan is not the same thing that wrote it.
Test AuthorFRONTIER
Writes the acceptance tests into a directory the workers cannot touch, and a red check proves they fail before any change is made. Every selection decision in the system is grounded in these tests, which is exactly why this role is never done on a cheap model.

Constrained judgment (cheap frontier)

Real judgment, but structured and narrow enough that a capable mid-tier model is usually enough.

VisionCHEAP FRONTIER
Reads text out of uploaded images so that they can enter intake. Its output is stamped as a model's reading and not as the document itself. There is deliberately no silent fallback, so if no vision model is configured, image upload is refused with a named error.
Story PlannerCHEAP FRONTIER
Proposes stories, i.e. the thinnest vertical slices that deliver whole checks (never half a check and never just a layer). It refuses to invent requirement content, and it reports coverage back to you, i.e. which requirements have no story yet and which checks are unclaimed.
JudgeCHEAP FRONTIER → LOCAL
Ranks the surviving candidates after verification and behavioral grouping, and writes its reasoning down. It only ever sees candidates that have already compiled and passed, collapsed to a handful of genuinely different diffs, which makes it the obvious next role to move onto a local model.

Volume & mechanics (local)

This is where the tokens actually go, and all of it runs on your hardware at the cost of electricity.

WorkersLOCAL · THE SWARM
Several per task, run under an engineered diversity matrix (temperature sweeps, seeds, strategy personas) inside a sandbox with write-set enforcement and early kill. This is the whole thesis of the project, and over 95% of the token volume.
LibrarianLOCAL
Retrieval and compression rather than judgment. It produces a knowledge brief per task and answers API lookups for workers from a pre-warmed local index of your codebase and frameworks.
UtilityLOCAL · SMALL
The small workhorse behind several of the other agents, doing classification, failure grouping, summarization and distillation.
Guideline ExtractorLOCAL
After a run, it goes through the completed sessions (failures first) looking for durable lessons, removes the ones that are already known, and writes the genuinely new ones up as proposals. Nothing touches a prompt until a human promotes it.
Knowledge ExtractorLOCAL
The same post-run pass, but producing proposed knowledge documents about your system and its frameworks for future builds to draw on.
ResearcherLOCAL
The only role in the system that touches the web, since the workers stay offline by design. It synthesizes external sources into proposed knowledge documents.
ChatLOCAL
The companion dock, used for conversation and for confined, read-only research. It is deliberately kept separate from the judgment roles, since a chat model is perfectly fine for chat.
ApproverRESERVED
A reserved slot for a semantic review before hand back. Today the approver is you, on the story card, which is where the decision belongs anyway.

Built for the day the subsidy ends

Frontier token prices are heavily subsidized today and there is no guarantee that this lasts. Most agentic coding platforms are built in the other direction, consuming more frontier tokens with every release, and if that pricing ever becomes a real cost price those platforms become prohibitively expensive more or less overnight.

SwarmCoder's split is a pre-emptive answer to this. Cloud cost scales with the number of tasks, i.e. a handful of small, structured judgment calls per story, enforced by a hard per-run cap. Local cost scales with implementation tokens, and those are priced in electricity on hardware you own.

If frontier prices rise 10×, the judgment slice of a SwarmCoder run rises with them, and the 95% of token volume that is local does not move at all.

Read the full argument on the principles page →
See the lifecycle these agents run →
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.