Which open-source autorouter to use for each KiCad routing job

Last week, TraceMaker surprised us on six boards. This week we raced five open-source autorouters on 26 routing cases across 11 public KiCad boards.

fastroute routed every whole board in under two seconds, but it passed only 3 of 9 edits. drandyhaas/KiCadRoutingTools handled edits best and passed the most cases overall. No router reliably kept a ground pour. TraceMaker is still good, but it is no longer our first choice.

The five routers: drandyhaas/KiCadRoutingTools and TraceMaker read KiCad files directly; fastroute, Freerouting and fab_router, our own router, work from a Specctra export. We also ran the hosted, closed-source Zap!; its results are still provisional, so it is listed but not ranked.

Whole board

Try fastroute first. It routed all six boards in 0.7–1.6 s. TraceMaker and drandyhaas/KiCadRoutingTools also passed all six, but took up to 57 s and 6 s respectively. The price of fastroute’s speed is slightly longer tracks, 4–16% above the shortest. On easy boards almost every router passed; the differences only showed on medium and hard ones.

We removed every track, via and copper zone from a board with its parts placed, and asked each router to route it from scratch.

Reroute after an edit

Start with drandyhaas/KiCadRoutingTools. It fixed 7 of 9 edits, each in under 4 s. This task split the routers most: fastroute, the whole-board winner, fixed only 3. Two edits defeated every open-source router.

File format is probably part of the reason. drandyhaas/KiCadRoutingTools reads the KiCad file directly, so it sees the board’s existing pours and how they connect. fastroute and Freerouting work from a Specctra export, which cannot carry the pours’ connection rules. It is not the whole story: our own fab_router uses the same export and fixed 6.

We removed the copper of one net, one part or a connector-sized group from a fully routed board, as if it had just been moved, and asked each router to reconnect it without touching anything else.

Power widths

fastroute again. Four routers passed the same four boards, so speed and copper decided it: fastroute was the fastest on each and used the fewest vias. The fifth board, a compact power supply, defeated every open-source router. drandyhaas/KiCadRoutingTools came closest: one power track at half the required width. Widening it by hand gave a valid board, so the board is routable; the routers just did not find the route.

Each router routed the whole board while giving power nets their required track widths.

Keep a ground pour

No router does this reliably. The best passed 3 of 6 boards, and the passes did not line up: one board passed only with drandyhaas/KiCadRoutingTools, another only with fab_router, and Aquarius with none. This is where open-source autorouting is weakest today. If your board has a ground pour, try more than one router and check the result.

Each router routed the whole board around its existing ground pours, which had to stay unchanged and connected.

When a router fails, switch routers

Failures were consistent. No router ever passed a case on one run and failed it on the next, and fastroute, drandyhaas/KiCadRoutingTools and fab_router produced the same copper every time. Running the same router again rarely helps; trying another one does. fastroute first, then drandyhaas/KiCadRoutingTools when it fails, covers 21 of the 26 cases, and a failed fastroute attempt usually costs about a second.

What changed since last week

TraceMaker still does well, with 18 of 26 cases valid. But on more and denser boards, fastroute matched its whole-board pass rate in a fraction of the time. Our own fab_router passed every whole board last week; here it passed three of six.

We also timed differently. Last week we compared CPU time with one thread per router. This week we used wall-clock time, which is what a person waits for, with each router’s default threading. That favors routers that use more cores: Freerouting averaged 3.5 busy cores and TraceMaker 3.1, against 1.5 or less for the others. Measured by CPU time instead, fastroute and fab_router still lead on speed.

What’s next

Our goal hasn’t changed since last week: routing fast enough to feel interactive. A whole board routed in about a second, on these boards, is a good sign.

Next we want to see what an AI harness and a router look like together. The harness prepares the board, runs a router, checks the result and hands that feedback to the model, which decides what to change or retry. This study tells us which router to put in that loop for each task. The next one measures how the whole loop feels.