PCBRouteAgent: How Close Are LLM Agents to Becoming PCB Routing Engineers?

What does it mean to route a PCB?

A printed circuit board connects electronic components through copper traces. After the components have been placed, routing turns their intended electrical connections into physical paths across the board's copper layers. The router must connect the required pads while respecting constraints such as clearance, trace width, and allowed layer transitions.

The input to our task is a KiCad board with fixed component placement, a netlist, and design rules, with the target routes removed. The output is a routed board in the same native format. We judge success using the official PCBWorld evaluator: all required connections must be complete, and KiCad must report zero error-level design-rule violations. A plausible-looking trace is not enough.

Why separate planning from execution?

Each routing decision changes what remains possible. A short connection can block a corridor needed by another net; a locally successful path can make a later connection much harder. Choosing the next tool action without maintaining a broader routing plan can therefore lead to repeated failures and expensive interaction.

Our starting point is the way engineers coordinate board-level strategy with local routing decisions. Decide which regions and connections need to be linked, work out the detailed geometry with a routing engine, and reconsider the strategy when execution reveals an obstacle. This motivates an agent that reasons over routing guides rather than issuing every geometric routing action through the language model.

Plan globally, route locally, revise with feedback

PCBRouteAgent has three functional components. An execution controller manages routing tasks, checkpoints, and bounded recovery.

1. Global Routing Planner. Given structured board information and board images, the planner specifies connections between disconnected clusters, routing order, soft corridors, and layer transitions. The initial guide is constructed by scripts; multimodal model planning is used to revise it when execution gets stuck.
2. Detailed Routing Executor. The executor realizes the guide using KiCad's native push-and-shove router. It handles geometric routing and bounded local recovery while preserving accepted connections.
3. Feedback-Driven Replanning. When local recovery cannot resolve a connection, the framework collects execution evidence and unresolved targets. The same global planner then revises the relevant guide, and execution resumes from a consistent board state.

The distinction matters: the language model does not need to micromanage every routing step. The native engine handles geometry, while the model revisits decisions that require a broader view of the board.

Does the framework complete more boards?

We evaluate on 247 boards from PCBWorld-Bench: 128 synthetic D2 boards, 99 small real-world D3-A boards, 10 medium D3-B boards, and 10 large D3-C boards. The main outcome below is clean pass: the fraction of boards with complete required connectivity and no error-level design-rule violations.

On the three real-world splits, the Opus variant improves clean pass over the best evaluated baseline by 13.9, 36, and 10 percentage points. On D2, it matches the full completion achieved by the strongest baselines.

What changes beyond clean pass?

Clean pass measures complete success at the board level. To see how routes differ, we also compare routability (the fraction of required connections completed), mean DRV count, wirelength, and via count. The interactive comparison below uses Claude Opus 5.5 for PCBRouteAgent and includes three rule-based routers: Freerouting, OrthoRoute, and KiCadRoutingTools. Select a test split and metric to inspect the results. Freerouting is the strongest evaluated rule-based baseline in clean pass on the real-world splits.

Source: rule-based results for D2, D3-A, and D3-B are from PCBWorld Table 22 (@1). D3-C and PCBRouteAgent results are local evaluations.

On D3-A, routability increases from 0.900 to 0.994 and mean DRV decreases from 1.08 to 0.09. On D3-B, PCBRouteAgent reaches full connectivity and zero DRV across all ten boards. These results show that the higher clean-pass rate is accompanied by better completion and fewer reported violations.

On D3-C, mean routability rises from 0.918 to 0.949 and DRV falls from 32.00 to 6.30, an 80.3% reduction. Yet only four of ten boards pass. This highlights the strictness of board-level success: even a small number of remaining connections can prevent a nearly routed board from passing.

Physical routing cost presents a tradeoff. The Opus variant uses 10.9% more wirelength on D3-B and 8.2% more on D3-C than Freerouting while completing more boards. A lower wirelength alone does not establish better routing, since incomplete solutions can leave less copper on the board. Completion, rule compliance, and physical cost need to be assessed together.

Is the gain just a stronger model?

We also compare PCBRouteAgent and PCBWorld's interactive agent using the same Claude Haiku 5.5 backbone. This tests whether the overall agent framework helps when model choice is held fixed.

The improvement holds across all four splits. It supports the effectiveness of the overall planning–execution framework beyond the choice of model backbone, although this comparison does not isolate the contribution of each component or equalize interaction budgets.

We do not conduct a full PCBWorld–Opus evaluation because we verified that its per-step model invocation incurs substantially higher API costs than PCBRouteAgent. The shared-Haiku comparison provides evidence without relying on an unmeasured Opus baseline.

How much computation does routing require?

The following comparison uses Claude Haiku 5.5 for both frameworks under the same local evaluation conditions and timing scope. Values are per-board means, including boards that do not pass. Input and output tokens are in thousands (k), and costs are recorded API charges.

PCBRouteAgent requires fewer model calls, fewer tokens, less time, and lower API cost on every split. On D2, mean model calls decrease from 43.20 to 0.05; on D3-C, they decrease from 676.60 to 5.10. Fewer than one call per board is possible because many boards finish with scripted guide initialization and native execution, without requiring a model-driven guide revision.

Across all 247 boards

Across the full benchmark, this is approximately 131× fewer model calls, 8.8× lower combined token usage, 4.3× lower API cost, and 14× lower cumulative runtime. Cumulative time sums the elapsed time of individual boards; it is not the duration of a parallel batch. These resource reductions accompany higher clean-pass rates on all four splits.

Cost relative to completed work

The token savings also hold when measured per connected target edge: 11,374 → 202 tokens on D2, 22,079 → 1,972 on D3-A, 65,545 → 4,355 on D3-B, and 269,324 → 6,744 on D3-C. This metric divides all input and output tokens by the total number of connected target edges in each split.

Low per-board cost does not guarantee low cost per successful board. On D3-C, PCBRouteAgent costs $0.393 per board, but only one of ten Haiku boards passes; dividing the total cost by the number of passes gives $3.93 per clean-pass board. PCBWorld–Haiku has no clean-pass boards on D3-B or D3-C, so its cost per clean-pass board is undefined there. Improving reliable completion on large boards therefore remains important for both routing quality and efficiency.

What do individual boards reveal?

The updated manuscript (PDF) includes three case studies. They show how the framework uses model decisions and why board completion still falls short of the broader requirements of PCB engineering.

More routing from fewer model calls

On the same D3-C board with Claude Haiku 5.5, PCBRouteAgent connects 84 of 86 targets, while the PCBWorld interactive baseline connects 10 of 86. This is an 86.0 percentage-point increase in connection completion, not in clean-pass rate: the PCBRouteAgent board still has two unresolved connections.

The baseline reaches its 403-step action limit, making one model call per action. PCBRouteAgent uses five calls while the native router handles detailed execution. Recorded input tokens decrease from 2,024,617 to 398,021 and output tokens from 682,784 to 86,963, reductions of 80.3% and 87.3%, respectively. This case illustrates more effective use of the same model through the planning–execution framework.

Earlier routes can trap later connections

A second D3-C example shows a limitation of local recovery: the Opus variant connects 70 of 83 targets, while the reference connects all 83. Sensor power is routed first without reserving pad access or space for layer-changing vias. Clock and data signals initially stall near crowded controller pads; later attempts change layers but encounter the retained power route near the sensor. Repair preserves that route, leaving the restriction in place.

View the controller and sensor routing comparison

The lesson is that more local retries cannot always compensate for an earlier allocation of routing space. Better look-ahead should reserve critical access, prioritize connections with few alternatives, and reconsider earlier routes when needed.

All connections complete, but electrical validation remains

On a D3-B board, the Opus variant connects all 55 targets, yet routes USB D+ and D− independently. The reference keeps the pair together, with each trace measuring 30.25 mm; PCBRouteAgent produces separate 34.03 mm and 36.49 mm paths. Its planning input specifies individual net widths and clearances but does not encode the differential-pair relationship.

USB design guidelines recommend treating D+ and D− as a differential pair and controlling their geometry and skew. This example exposes a missing signal-specific representation; it does not by itself establish that the USB link fails electrically. That requires further electrical validation. Connection completion and basic design-rule checks alone do not establish that a design meets its electrical requirements.

How close are we to a routing engineer?

There is still a substantial gap. On the largest split, the Opus variant passes four of ten boards. Its mean routability reaches 0.949, but high average connectivity does not guarantee that every connection on a board is complete and clean. Routing compactness also remains a challenge: on D3-C, wirelength is 8.2% higher than Freerouting, while clean pass improves from 30% to 40%.

The case studies make this gap more concrete. Approaching the responsibilities of a PCB routing engineer requires stronger coordination across early and late routing decisions, recovery that can revisit accepted routes, explicit signal-specific constraints, and validation beyond connectivity and basic design rules. Better completion on large boards, more compact routes, and controlled component ablations remain important next steps.

Citation

The paper is available on arXiv. Please use the following BibTeX to cite it.

@misc{zhang2026pcbrouteagentclosellmagents,
      title={PCBRouteAgent: How Close Are LLM Agents to Becoming PCB Routing Engineers?},
      author={Yue Zhang and Jilei Sun and Liqiang Jing and Yijie Wei and Ruohan Yang},
      year={2026},
      eprint={2611.08175},
      archivePrefix={arXiv},
      primaryClass={cs.AI},
      url={https://arxiv.org/abs/2611.08175},
}

Download BibTeX

Resources

• Latest manuscript PDF, including case studies
• PCBRouteAgent paper · arXiv:2611.08175
• PCBRouteAgent code
• PCBWorld: A Benchmark Environment for Engine-Grounded PCB Design Automation
• KiCad documentation