Three PCB autorouters on six KiCad boards…

At fabPlane, we want PCB autorouting to become fast enough to feel interactive: change a board, get routing feedback, and try again while the design is still fresh in mind. An autorouter finds paths for copper tracks and vias to connect the components on a board. To understand what could support that workflow, we compared how three engines balance completion, route quality, and CPU time.

TraceMaker looked like a promising alternative or companion to Freerouting. We ran a small comparison of the two alongside fab_router, the PCB-bridge router that is the fallback from Freerouting on unpinned projects — not TraceMaker, and not the unpinned default.

We expected TraceMaker to be fast. We didn’t expect it to produce good results too.

On the simple repair task, TraceMaker used 0.42 seconds of median CPU time versus Freerouting’s 44.37 seconds, about a 100× difference. Both passed all three runs. Their routes were not identical: Freerouting used slightly less copper and won the benchmark’s quality ranking. TraceMaker also passed every whole-board and dense breakout run in the selected configurations.

This was a small experiment on six boards. The galleries below use the original KiCad renders. Setup, methodology, and provenance are on a separate page, with a short summary at the end.

Results at a glance

Each cell shows passing runs out of total runs, followed by median CPU time for passing outputs. A pass means the required connections were completed without new KiCad design-rule errors, changes to parts of the board that must stay unchanged, or dangling copper. Fail means none of the runs passed. CPU time includes startup and file conversion, so it is not a measure of interactive response time.

Test	TraceMaker	Freerouting	fab_router
1. Whole-board, two boards	Pass 6/6 · 1.64 s	Pass 3/6 · 12.86 s	Pass 6/6 · 1.53 s
2. Simple repair	Pass 3/3 · 0.42 s	Pass 3/3 · 44.37 s	Pass 3/3 · 2.16 s
3. USB-A swap repair	Fail 0/3 · N/A	Fail 0/3 · N/A	Fail 0/3 · N/A
4. Dense SMD breakout	Pass 3/3 · 8.78 s	Fail 0/3 · N/A	Fail 0/3 · N/A
5. FFC pair repair	Fail 0/3 · N/A	Fail 0/3 · N/A	Fail 0/3 · N/A

N/A means there were no passing outputs from which to calculate a median. Test 1 pools three runs on each of two boards. Every row uses the settings selected in a small search on a separate board, referred to as tuned settings below.

An open connection, shortened to “open” in the images, is a required electrical connection that has not been completed. Errors are violations reported by KiCad’s design-rule check (DRC), such as clearance or trace-width violations. “+ errors” counts additions to the input board’s existing errors.

The galleries use the original KiCad renders from the benchmark. “Starting board” is the saved input given to each engine. In repair tests, tracks and copper areas outside the repair area must stay unchanged. Click any board to expand it. Each gallery shows one run, including failed outputs. Timeout images show the unchanged starting board.

Test 1: Whole-board routing. CH340G and Lantern

What we tested: Could each engine route an entire board from its placed components? We removed the original tracks, vias, and copper zones, then asked the autorouters to rebuild the connections. CH340G started with 43 open connections. Lantern started with 42. Each board ran three times with the selected configuration, giving six scored runs per engine for this test. The human-routed boards are visual references.

CH340G board

ch340g · Human trace reference · Reference only — Test 1 · CH340G. TraceMaker and fab_router pass the displayed run. Freerouting leaves one connection open.

ch340g · Starting board · 43 open connections — Test 1 · CH340G. TraceMaker and fab_router pass the displayed run. Freerouting leaves one connection open.

Lantern board

lantern · Human trace reference · Reference only — Test 1 · Lantern. All three engines pass the displayed run. The Test 1 summary pools this board and CH340G, with three tuned runs per board.

lantern · Starting board · 42 open connections — Test 1 · Lantern. All three engines pass the displayed run. The Test 1 summary pools this board and CH340G, with three tuned runs per board.

Results: TraceMaker and fab_router produced valid outputs in all six tuned runs. Freerouting passed three of six. In the displayed CH340G run, Freerouting left one connection open. All three engines passed the displayed Lantern run.

Across the two boards, TraceMaker had a median of 18 vias and 365.49 mm of copper, compared with fab_router’s 36 vias and 384.16 mm. Their reported median CPU times were close: 1.64 seconds for TraceMaker and 1.53 seconds for fab_router. These quality medians include only valid outputs.

Conclusion: TraceMaker led this whole-board test under the benchmark’s ranking. It matched fab_router’s completion rate while using fewer vias and less copper. The different outcomes on CH340G and Lantern also show why a single board is insufficient to judge a router.

Test 2: Simple repair on Decoder-v2

What we tested: Could each engine fix a small set of missing connections while preserving the rest of an already routed board? Decoder-v2 started with three open connections. Unlike whole-board routing, this repair task kept the existing copper outside the repair scope and retained/refilled the original zones. Success required completing the connections without disturbing parts of the board outside the repair area or adding errors.

decoder-v2 · Human trace reference · Reference only — Test 2 · Decoder-v2. All three engines pass. Freerouting wins the declared quality ranking, while TraceMaker has the shortest reported CPU time.

decoder-v2 · Starting board · 3 open connections — Test 2 · Decoder-v2. All three engines pass. Freerouting wins the declared quality ranking, while TraceMaker has the shortest reported CPU time.

Results: All three engines passed all three tuned runs. Freerouting and TraceMaker both had a median of one via, but Freerouting used slightly less copper: 501.73 mm versus 511.38 mm. TraceMaker had the shortest reported median CPU time: 0.42 seconds versus Freerouting’s 44.37 seconds.

fab_router used 499.03 mm of copper, but its median of two vias placed it behind the other two. The benchmark ranks validity first, then vias, copper-length ratio, and finally CPU time.

Conclusion: Freerouting won the quality ranking with slightly less copper at the same median via count. TraceMaker used far less CPU time while also passing every run. For a workflow built around repeated attempts, we would try TraceMaker first, then check whether that CPU advantage translates into shorter waits. Under the benchmark’s preference for fewer vias, then less copper, Freerouting won this comparison.

Test 3: Repair after a USB-A swap

What we tested: Could each engine repair the connections in the USB-A swap scenario while respecting the remaining board geometry and repair scope? The starting board had 16 open connections. This tested repair within an existing layout rather than routing an empty board. The leftmost image is a placement checkpoint, not a completed human route.

swap · Placement checkpoint · Reference only — Test 3 · USB-A swap. No engine passes. TraceMaker’s timeout view is the unchanged input. The leftmost view is a placement checkpoint, not finished human routing.

swap · Starting board · 16 open connections — Test 3 · USB-A swap. No engine passes. TraceMaker’s timeout view is the unchanged input. The leftmost view is a placement checkpoint, not finished human routing.

Results: No engine produced a valid result in any of the three tuned runs. In the displayed run, TraceMaker reached the time limit, so its image shows the unchanged input. Freerouting reduced the open connections to four but added one KiCad DRC error. fab_router left 15 connections open, with no new KiCad DRC errors.

Conclusion: None of the tested configurations completed this repair. Making partial progress or avoiding new errors was insufficient: the output still had to connect every required net and satisfy the other validity checks.

Test 4: Dense SMD breakout routing

What we tested: Could each engine complete the dense SMD breakout routing from its placed components? After the original routing was removed, this input had 64 open connections. Success required completing them, preserving board geometry, and leaving no dangling copper or added KiCad DRC errors.

The input already had 46 DRC errors before autorouting. Their causes are not documented in the setup and provenance notes. We treated them as the baseline and checked for added errors, so a passing result here does not mean a DRC-clean board. The human-routed image is a visual reference.

smd-breakout · Human trace reference · Reference only — Test 4 · SMD breakout. Only TraceMaker passes. This input already has 46 DRC errors. The displayed error counts are additions to that baseline.

smd-breakout · Starting board · 64 open connections — Test 4 · SMD breakout. Only TraceMaker passes. This input already has 46 DRC errors. The displayed error counts are additions to that baseline.

Results: TraceMaker passed all three tuned runs, with medians of 38 vias, 283.67 mm of copper, and 8.78 seconds of CPU time. Neither Freerouting nor fab_router produced a valid output.

In the displayed run, Freerouting connected all nets but added three errors. fab_router left 25 connections open and added 19 errors. The displayed error counts are additions to the baseline, rather than the board’s total error count.

Conclusion: TraceMaker was the only engine to pass this dense-routing test. This reinforced the surprise in the comparison: its speed came with a valid routing result. Freerouting’s output also shows why zero open connections alone cannot establish success.

Test 5: FFC pair repair

What we tested: Could each engine complete the FFC pair repair while preserving the existing layout and scoped copper? The starting board had eight open connections and retained/refilled the original zones. As in the USB-A swap test, the leftmost view is a placement checkpoint rather than finished human routing. Pair adjacency was assessed as a geometric diagnostic, not a signal-integrity qualification.

ffc-v2 · Placement checkpoint · Reference only — Test 5 · FFC repair. Zero opens and zero new errors do not guarantee validity. TraceMaker’s image is unchanged after timeout. The leftmost view is a placement checkpoint.

ffc-v2 · Starting board · 8 open connections — Test 5 · FFC repair. Zero opens and zero new errors do not guarantee validity. TraceMaker’s image is unchanged after timeout. The leftmost view is a placement checkpoint.

Results: No engine passed any of the three tuned runs. In the displayed run, TraceMaker timed out and its image shows the unchanged input. Freerouting left one connection open with no new KiCad DRC errors. fab_router reported zero opens and zero new KiCad DRC errors, but the result remained invalid. The benchmark identifies dangling copper as an issue.

Conclusion: Completing connections and passing the KiCad DRC error-count check are only part of a successful repair. The output must also preserve the repair scope and avoid dangling copper. This test exposed a gap that would be missed by looking only at open connections and new DRC errors.

What these results tell us about choosing an autorouter

TraceMaker is our first tool to try for whole-board autorouting. In this test set, it passed both Test 1 boards and was the only engine to pass the dense SMD breakout. On Test 1, fab_router used slightly less median CPU time, but TraceMaker used fewer vias and less copper. Our preference comes from that balance of completion, quality, and CPU cost, rather than being fastest on every task.

Simple repair presents a useful tradeoff. Freerouting won the quality ranking with the same median via count as TraceMaker and slightly less copper. TraceMaker passed the same three runs at much lower CPU cost, making it the option we would try first when frequent attempts matter. Neither result makes one engine the best choice for every board.

Complex repair remains unresolved in these configurations. No engine passed the USB-A swap or FFC repair tasks. Those failures show why a router needs independent checks before its output is accepted. Our recommendation is where to begin trying a tool, not evidence that we can automate every repair or replace our shipped router default.

Why faster routing feedback matters

In an AI workflow, the autorouter would find paths for tracks and vias. The harness would prepare the board, run the router, and validate its output. Together, they could let a model propose a design change and use checked feedback to retry or revise it, without specifying every track itself. The repair failures show why those checks matter. This benchmark tested routers, so the benefit to models remains unmeasured.

Can PCB autorouting become fast enough to feel interactive?

Our takeaway is that fast autorouting can still produce passing results. TraceMaker’s whole-board results and simple-repair CPU advantage support trying it in a workflow built around frequent feedback. The complex repair failures also identify what needs work: completing the requested task reliably and catching unacceptable outputs.

Our view is that interactive autorouting is worth pursuing. What remains unproven is whether the complete cycle from a design change to a validated result feels responsive, including time spent on conversion, validation, and retries. The CPU measurements in this post cannot answer that on their own.

Our follow-up posts will test this view on more boards and measure that full cycle. We’ll examine where the CPU advantage holds, where routing or repair breaks down, and what changes when an AI model uses the tools. Those results may strengthen our recommendation or give us a reason to revise it.

Methodology and limitations

Six boards, five tasks, three runs per board using settings selected on a separate charger board. Runs were sequential on Linux, CPU-only, with one requested thread and a 120-second wall-time cap. CPU time includes startup and file conversion. Freerouting ignores seeds.

Rules differed across engines. KiCad checked connectivity and DRC. Acceptance also required preserving board geometry and avoiding dangling copper. Existing errors could remain, so a pass is not manufacturing approval. Ranking prioritizes validity, then vias, copper-length ratio, and CPU time. Medians include passing outputs only.

Twelve decoder runs with incorrect input preparation were excluded. No AI routing calls or signal-integrity qualification were performed. These results apply to the tested configurations. Setup, methodology, and provenance notes are available.

Tested versions

The October 8, 2026 benchmark used a pinned TraceMaker CPU build, Freerouting 2.4.1, and a pinned fab_router revision. Results may differ with newer versions.

Three PCB autorouters on six KiCad boards: TraceMaker leads