KiCadRoutingTools puts a Rust A* autorouter behind a KiCad plugin

What the Rust core changes about a KiCad autorouter

The headline claim is speed. The README describes a grid-based A* router with a native Rust core, roughly ten times faster than the pure Python version, which is what makes batch routing and incremental obstacle caching practical on a board with thousands of nets. The movement model is octilinear, meaning horizontal, vertical and 45 degree segments, and routing happens across layers with automatic via insertion. A Rust core is only half the story. The other half is that the work is organised around measurement: the README says every change to the router is A/B tested by replaying a corpus of real open-source boards on rented cores, grading each result for DRC violations and unconnected nets, with a test suite of roughly six hundred files fanning out the same way. That corpus approach is what separates a router that helps one board from a router that quietly regresses ten others.

Ripping up copper when a net blocks another

A* on its own produces a first route that can paint itself into a corner, so the interesting machinery is in the retry logic. Rip-up and reroute is described as progressive N+1 blocker analysis with ripped-corridor avoidance, which means a route that cannot be completed is torn out and the search continues with knowledge of what blocked it. Net ordering decides the order in which nets are attempted, and the README lists three strategies: MPS, which is crossing-aware, inside-out, and original order, with MPS able to swap layers. Around that sit smaller corrections: stub layer switching, vertical track alignment, and turn-cost straightening, which are the kind of geometry cleanups that matter when a board has to be reviewed by eye as well as by DRC.

Differential pairs handled as geometry, not as two wires

The differential pair implementation is the part that goes furthest beyond a grid router. Instead of routing two conductors independently, it uses pose-based A* with a Dubins heuristic and adaptive setback angles to produce orientation-aware centerlines. Bare-pad, multi-point with three or more terminals, and hybrid geometries are all supported, the last combining coupled middle sections with single-ended legs. Polarity is resolved through opt-in pad swaps, U-turns are prevented, and ground return vias are placed. Legs that are electrically short are automatically deferred to single-ended routing, which is a sensible degradation rather than a failure, and per-layer impedance-controlled widths are supported. The same care appears in length matching, where trombone meanders and automatic DQ and DQS grouping are via-barrel aware, and in time matching, which works through propagation delay and distinguishes microstrip from stripline.

Planes, power nets and the repair passes

Ground and power handling is a separate body of work. Power nets can be routed wider, with automatic neck-down at fine-pitch pads, and plane pours are supported, with pads welded by the route step and plane layers several nets share handled as split round spines on the layer, reported with resistance and max-current figures. Two failure modes get their own repair paths: disconnected plane regions are fixed through region joins and pad taps, and ground return vias are placed. After routing, a cleanup pass reconciles copper against the connectivity model so that no orphaned copper is left behind and ripped copper is restored, with gap-snap connectors bridging the gaps. There is also a KiCad-oracle reconnect mode that routes exactly the links KiCad's own DRC reports as unconnected, which is a useful way to close the last few nets after a human has done the hard routing.

The plugin, the CLI, and a corpus you can rerun

The tool ships in two shapes. The KiCad plugin gives a full GUI for KiCad 9 and 10, including a tab that plans a routing workflow and per-field helpers, and a scriptable command line interface for automation, with a full option list in the configuration documentation. The repository is laid out in a way that shows the split: rust_router/ holds the native core, py_router/ the Python routing layer, py_placer/ the placement side, py_tools/ utility and rendering code, and kicad_routing_plugin/ the GUI. Two details make the CLI usable in practice. A routing plan can be saved and loaded as JSON, so a whole chain of routing steps can be built from a recorded command chain and replayed. And board rendering and routing animation are supported, with make_movie.py producing an .mp4 or .gif of the router laying, ripping and restoring copper, which is the fastest way to see what a parameter change actually did.

Dependency floors that will break your install if you ignore them

The Python side has three real dependencies, and the version floors are documented with unusual candour in requirements.txt. numpy must be at least 1.22, and the file explains why in terms of a specific attribute landing in that release, with the failure being a TypeError about an object that is not subscriptable. scipy must be at least 1.7, and the README file notes that scipy 1.11 and later warn when numpy is 1.22.4 or newer but below 2.3.0. shapely must be 2.0, because the courtyard reader calls the vectorized distance and points API. The numpy floor is described as load-bearing, and the startup checks read that line directly, so the declared floor is the floor the gates enforce, with a separate fallback set for stripped installs:

numpy>=1.22.0
scipy>=1.7.0
shapely>=2.0

The failure the file documents looks like this:

#   * `numpy._DTypeMeta.__class_getitem__` landed in 1.22. Below that, any
#     package whose import evaluates `np.ndarray[Any, np.dtype[...]]` dies with
#     `TypeError: 'numpy._DTypeMeta' object is not subscriptable`.

Rendering is the optional half. The raster stack lives in py_router/route_render.py and is the only module that imports the raster dependency, so its absence disables board stills, review sheets and the routing movie without stopping routing itself.

Where the autorouter is the wrong tool

Two situations rule this out. The first is a board that is simply not routable, because an autorouter cannot create space that the placement does not have; the README offers placement optimisation for routability and a design brief, a sibling file the toolchain reads, plus graded floorplan intent, but those are aids rather than a guarantee. The second is a team that wants a finished board with no review step, since the project's own checkers exist precisely because routed output still needs verification for DRC, connectivity, orphan stubs, copper hygiene and pad geometry. Compared with routing by hand in KiCad's own editor, the difference in approach is batch versus interactive: the autorouter can chew through a board in one pass and can be replayed, but every decision it makes lands on your board without a human looking at it, so the review cost moves rather than disappears.

Version churn and what a 0.x release implies

The release history is fast. v0.22.1 landed on 2026-09-17, v0.23.0 on 2026-10-08 and v0.23.1 on 2026-10-16, and the last push was on 2026-10-22. A project that ships minor releases every couple of weeks and is still on a 0.x version number is telling you that interfaces will move, and a plugin pinned to a KiCad version will need attention when either side updates. The README also states plainly that the plugin and the command line are held to parity, with a parity check in the repository tree, which is a reasonable signal that the two interfaces do not drift, though it also means the CLI gains whatever the GUI gains. Licensing is MIT with no paid tier and nothing paywalled, and the project says donations cover roughly 500 dollars a month of cloud compute and AI-assisted development, which is also the money that pays for the rented cores used to replay the corpus.

Editorial conclusion

KiCadRoutingTools suits a board owner who wants a batch autorouter that can be scripted, replayed and graded rather than a router that has to be nudged by hand, and who is willing to install a plugin and a Python toolchain on top of KiCad. It does not suit someone who needs a guaranteed clean board from an unroutable design, a team that cannot take on a 0.x tool with a fast release cadence, or anyone who wants a single static binary with no numpy, scipy and shapely dependency floors. Verify three things before trusting it on a real board: that your KiCad version is 9 or 10, that your numpy is at least 1.22 and your scipy below 2.3, since the dependency floor is enforced at startup, and that a routed board passes the project's own checkers, check_complete.py and the copper hygiene checker check_weird.py, before you treat the result as finished copper.

Frequently asked questions

Official sources

1. drandyhaas/KiCadRoutingTools on GitHub
2. License: MIT
3. Project website
4. README
5. Releases