What the reference solvers report on 1,000 to 10,000-stop instances, next to what iRoutify measures on the same instance classes through its production entry point. The third-party figures are quoted from peer-reviewed papers exactly as published — we did not re-run anyone's solver.
4.82%OR-Tools gap at 1,000 stops, as published
104 sOR-Tools time at 1,000 stops, as published
0.10%iRoutify regular at 1,002 stops
0.0000%iRoutify MaxQuality at 1,002 stops
The same numbers as curves
Gap and time as functions of size.
One axis per chart: the gap to the proven optimum on the left, the time to get there on the right, both against the number of stops on a logarithmic scale. Every point is a row of the table below, which is the table view of these charts. Hover, tap, or use the arrow keys to read all series at one size.
Gap to the proven optimum
percent above the optimum · lower is better
Time to the answer
seconds, logarithmic · lower is better
LKH-3 at 5,000 and 10,000 stops is drawn hollow at zero on the gap chart: the paper used its tour as the reference there, so its own gap was not measured. Concorde is drawn on the same four instances: it proves the optimum at 1,002 and 2,392 stops, and above that it is shown at the gap it had reached when its time limit stopped it. The two iRoutify MaxQuality points at 1,002 and 2,392 stops carry a whisker down to the faster of the two runs taken that day. Seconds come from different machines and are indicative, as the table’s notes say. Each gap is measured against its own instance’s proven optimum; the OR-Tools and LKH-3 points are random uniform instances, so read those against each other rather than against the TSPLIB points.
How solve time grows with the number of stops
seconds against stops, both logarithmic · markers are measured or published points · dotted lines are extrapolated
iRoutify service: one vehicle, fixed-seed uniform random stops in a 60 × 90 km box, sent to the production entry point (Azure Container Apps, 2 vCPU / 4 GiB, scale-to-zero) with the answer memory bypassed; server-reported solve time, the median of three samples at 1,000 and 2,000 stops on 2026-10-12 (the published /limits table, which also covers 50 to 500 stops) and of two from 3,000 to 20,000 on 2026-10-01. Forecast: above 20,000 stops a request does not get the full search a smaller one gets but a fixed extra effort, so the line is built from two measured parts: the service’s time at 30,000 and 50,000 stops before the release of 2026-10-12 (2.2 and 3.9 s on 2026-10-08, these stops), continued as n log n, plus the 21 s that release added to such a request (measured on the service the same evening, before and after it, on a single route of 30,000 stops and one of 50,000: from 2.4 to 23.5 s and from 6.0 to 27.2 s). Drawn to one million stops, it is a projection, not a measurement; the public API caps a request at 250,000 stops, and 20 million stops have been measured separately in 9.7 minutes on one 8-core machine (see the home page). The laptop points are the regular-tier figures of the charts above, the same engine on 12 cores; MaxQuality is not drawn here, its times are in the table below. The third-party points are the published figures of the charts above, on their authors’ hardware. Their dotted continuations are ours, not the papers’: a power law fitted through the four published points of each series and continued until it leaves the chart (OR-Tools and LKH-3 both grow close to n2.3 over the published range; these were runs under the authors’ own configuration and time budgets, so the trend describes their study as much as the solver). Concorde is not continued: its 550 s and 1,000 s at 5,915 and 11,849 stops are the time limits the study set, and the optimum had not been proved when they ran out. Hover or tap past 20,000 stops to read every continued value.
The quality behind those times.
The gap to the proven optimum, by tier: tour length divided by the instance’s published optimum, minus one, on TSPLIB and the Waterloo national tours. Up to 20,000 stops each tier runs its full search. Above 20,000 stops both get the same fixed extra effort up to 30,000 stops, so at the two sizes measured there they return the same tour; the regular tier keeps that effort fixed beyond, MaxQuality spends more in proportion to the stops. Before the release of 2026-10-12 nothing was spent above 20,000 stops and the service returned these two 13.96% and 12.98% above the optimum.
Stops
iRoutify regularthe default response
iRoutify MaxQualitythe opt-in batch mode
1,002pr1002
0.10%
0.0000%the published optimal tour
2,392pr2392
0.35%
0.0011%
5,915rl5915
0.64%
0.035%
11,849rl11849
1.34%
0.120%
15,112d15112
1.37%
0.094%
22,775vm22775
3.06%13.96% before 2026-10-12
3.06%the same tour
24,978sw24978
2.32%12.98% before 2026-10-12
2.32%the same tour
Measured through the production entry point, Release build, on the AMD Ryzen AI 9 HX 370 laptop: the regular tier on 2026-10-12 on two of its cores, the service’s size (below 20,000 stops the same tours as on 2026-09-13); MaxQuality as in the batch table below up to 15,112 stops, and on 2026-10-12 above 20,000. The times at each size are the charts’ and the tables’.
1,000 to 10,000 stops
Gap to the proven optimum, and the time to get there.
Every gap below is measured the same way: tour length divided by the proven optimum, minus one. The Concorde and iRoutify columns are the SAME four TSPLIB instances, so those read directly against each other. The OR-Tools and LKH-3 columns are a different study on random uniform instances of the same size class — the same kind of denominator, but not the same instances, and instance family matters more than size: Concorde needs 8.3 s on pr1002 and 488 s on a random uniform instance of the same size.
Stops
OR-Toolsgap / time · random uniform
LKH-3gap / time · random uniform
Concordegap / time · same instance
iRoutify regulargap / time
iRoutify MaxQualitygap / time
~1,000size class
4.82%104 s
0.17%22 s
0.00%8.3 spr1002 · proven · 488 s on random uniform
0.10%1.7 spr1002 · 1,002 stops
0.0000%25–38 spr1002 · the published optimal tour
~2,000size class
4.82%532 s
0.49%80 s
0.00%13.1 spr2392 · proven · 7,950 s on random uniform
0.35%3.1 spr2392 · 2,392 stops
0.0011%138–208 spr2392 · integer rounding, see notes
~5,000size class
3.86%5,368 s
reference562 s
0.67%550 srl5915 · time-limited, not proven
0.64%5.1 srl5915 · 5,915 stops
0.035%272 srl5915 · 5,915 stops
10,000size class
3.44%21,359 s
reference4,747 s
0.85%1,000 srl11849 · time-limited, not proven
1.34%7.5 srl11849 · 11,849 stops
0.120%651 srl11849 · 11,849 stops
OR-Tools and LKH-3: Table 1 of the H-TSP paper (Pan et al., AAAI 2023), random uniform instances in the unit square, average time per instance, run by the authors on an Intel Xeon Platinum CPU with their own configuration and time budgets. “Reference” means the paper measured the other methods against LKH-3’s tour at that size, so LKH-3’s own gap is zero by definition there. Concorde: Tables 1 and 2 of ViTSP (Yin, Ding, Khir & Cai, ICLR 2026, arXiv:2509.23465), on the same four TSPLIB instances iRoutify runs. Concorde was given a time limit matched to that study’s own runtime, so a zero gap means it found and proved the optimum inside the limit, and a non-zero gap is the incumbent it held when the limit stopped it — not a failure to be exact. Its 8.3 s on pr1002 agrees with the authors’ own 2003 benchmark, which records pr1002 at 9.9 s and pr2392 at 35 s, each closed at one search node. In the same study Concorde returned no answer at all on pla33810 and pla85900. Concorde is licensed for academic research use; other uses need a licence, so it cannot be shipped inside a product.
iRoutify: TSPLIB pr1002, pr2392, rl5915 and rl11849, gap to each instance’s published proven optimum on the TSPLIB metric, measured through the production entry point, Release build, on one AMD Ryzen AI 9 HX 370 laptop (12 cores): pr1002, pr2392 and the regular tier on 2026-09-13, MaxQuality at 5,915 and 11,849 stops on 2026-09-20. “Regular” is the default response; “MaxQuality” is the opt-in batch mode, as shipped on 2026-09-20 (the regular tier keeps interactive latency and gained an exact re-solve of the long cross-cluster hops on 2026-09-13, so it reads 0.64% and 1.34% at 5,915 and 11,849 stops against 0.65% and 1.59% the day before; the batch mode runs the same pass, re-solves the neighbourhoods it touched, and since 2026-09-17 adds a further pass over the tour’s large-scale order, which took MaxQuality at 5,915 stops from 0.060% to 0.035%; on 2026-09-18 a defect in the batch search’s later rounds was fixed, which took 11,849 stops from 0.275% to 0.120%; on 2026-09-20 the batch mode’s independent polish passes started running side by side, which took 5,915 stops from 329 s to 272 s on the same day and the same laptop and left every tour identical). Where two runs were taken the wall is given as a range: a laptop’s clock drifts with heat, the tour does not. pr2392’s 0.0011% is integer rounding: the tour is shorter than the published optimal tour in unrounded Euclidean distance.
Read it honestly: below about 2,400 stops Concorde beats iRoutify on these instances — it is faster and it returns a proof, which iRoutify never does. Above that it runs out of time before it runs out of problem. Different machines throughout, so the seconds are indicative and no column is a head-to-head; each gap is measured against its own instance’s published proven optimum, and the OR-Tools and LKH-3 columns are a different instance family from the rest of the table.
5,915 to 16,862 stops
Every instance the batch tier was measured on.
The four instances above are the ones the published studies also ran, so those can be read against each other. These eight are the whole set iRoutify itself was measured on — TSPLIB and the Waterloo national tours, each with a proven optimum. The worst of them is 0.320% above the optimum; six of the eight are under 0.15%.
rl59155,915 stops
0.035%
ja98479,847 stops
0.075%
d1511215,112 stops
0.094%
brd1405114,051 stops
0.111%
rl1184911,849 stops
0.120%
gr98829,882 stops
0.139%
usa1350913,509 stops
0.149%
it1686216,862 stops
0.320%
0%0.1%0.2%0.3%
Instance
Stops
Gap to the proven optimum
Time to the answer
rl5915
5,915
0.035%
272 s
ja9847
9,847
0.075%
691 s
d15112
15,112
0.094%
967 s
brd14051
14,051
0.111%
894 s
rl11849
11,849
0.120%
651 s
gr9882
9,882
0.139%
574 s
usa13509
13,509
0.149%
829 s
it16862
16,862
0.320%
1,019 s
MaxQuality, the opt-in batch mode, through the production entry point on one AMD Ryzen AI 9 HX 370 laptop (12 cores), one solve at a time on a quiet machine, measured 2026-09-20. Each gap is the returned tour re-costed against that instance’s published optimal tour on its own metric. Sorted by gap rather than by size, because the gap does not track the stop count over this range: the largest instance here is the loosest, and the second largest, d15112, is the third tightest. The seconds are a laptop’s and a laptop’s clock drifts with heat; the tours do not.
On the production box
What the live service answers in.
The times above are a laptop’s. These are the service’s own, published by the API itself at /limits so a call can be sized before it is made: server-reported solve time on Azure Container Apps, 2 vCPU, scale-to-zero. The table is measured and loaded, never computed — a row that fails to measure is omitted rather than filled in, and the response carries a flag that turns false the moment the table describes a build that is no longer running.
One vehicle
Stops
Veh.
p50
p95
50
1
31.4 ms
31.5 ms
100
1
79.2 ms
79.3 ms
250
1
260.2 ms
263.6 ms
300
1
312.6 ms
332.7 ms
400
1
540.0 ms
553.2 ms
450
1
573.8 ms
576.7 ms
500
1
687.0 ms
690.0 ms
1,000
1
2,206.7 ms
2,245.7 ms
2,000
1
4,349.8 ms
4,351.0 ms
Fleet
Stops
Veh.
p50
p95
100
5
51.3 ms
59.1 ms
500
5
2,380.8 ms
2,386.0 ms
1,000
10
5,899.7 ms
5,961.3 ms
2,500
10
5,313.6 ms
5,331.0 ms
Measured 2026-10-12 through the public entry point, 13 of 13 rows, with the answer memory bypassed so every sample is a fresh solve. Until 2026-09-23 this table had a bump: 400 stops took 2,765 ms and 450 took 798, because routes of 400 stops or fewer took a different, slower search. They now take the same one as longer routes - never worse on any of the 65 instances it was measured on, the routes shorter on 27 of them - and 400 stops takes 540 ms against 450’s 574. The table is still allowed to be non-monotonic and is tested to stay that way, so that nobody later “fixes” the data to match an assumption. A request is capped at 250,000 stops and a plan at 14 days; past the largest measured size no estimate is published at all, because extrapolating this curve is a claim the data does not support.
Same instance, same optimum
On TSPLIB the same picture holds.
Cheng et al. (AISTATS 2023) ran OR-Tools and LKH-3 on the large TSPLIB instances. They report OR-Tools at 5.74% ± 1.78% in 285 s averaged over eleven 1,000–2,000-node instances, and 4.89% ± 2.20% in 3,291 s over seven 2,000–6,000-node instances. One of those instances, rl5915, is one iRoutify also runs — so here the optimum is not merely the same class, it is the same number.
rl5915 · 5,915 stopspublished optimum 565,530
OR-ToolsCheng et al. 2023
LKH-3Cheng et al. 2023
iRoutify regularmeasured 2026-09-13
iRoutify MaxQualitymeasured 2026-09-17
Gap to optimum
6.10%
0.148%
0.64%
0.035%
Time
7,381 sXeon E5-2650 v4, 2.20 GHz
48 sXeon E5-2650 v4, 2.20 GHz
5.1 sRyzen AI 9 HX 370, 12 cores
272 sRyzen AI 9 HX 370, 12 cores
Cheng et al. ran the C++ solvers on an Intel Xeon E5-2650 v4 at 2.20 GHz with their own configuration; the group averages above are their Table 4 and the rl5915 row is their Table 7. Different hardware, so compare the gaps first and treat the seconds as indicative. LKH-3 is the strongest published heuristic and is included as the reference point iRoutify is measured against, not as a product comparison.
The three reference points
What each column actually is.
OR-Tools · Google
General routing toolkit
Open-source constraint-programming library. Its routing solver builds a first solution, then improves it by local search until a time limit you set. It handles rich vehicle-routing constraints; it does not attempt to prove optimality.
“OR-Tools sometimes returns solutions that are good, but not optimal.” … “While specialized solvers like Concorde excel at large TSPs, OR-Tools provides a more versatile platform for routing problems with constraints beyond the basic TSP.”developers.google.com/optimization/routing, accessed 2026-09-08
// heuristic · runs to a time limit
LKH-3 · Helsgaun
The reference heuristic
The strongest published heuristic for the travelling-salesman problem. Given enough runs it reaches the proven optimum on most benchmark instances, which is why benchmark papers use its tour as the reference where the exact solver is too slow to run.
// heuristic · usually reaches the optimum
Concorde · Applegate, Bixby, Chvátal, Cook
The exact solver
Branch-and-cut code that finds the optimum and proves it. The proof is the expensive part: its running time grows steeply with size, which is why studies stop running it around 2,000 nodes. It is available for academic research use; other uses need a licence.
// exact · proof included · hours and up
Descriptions are drawn from each project’s own documentation, linked in the sources below. Trademarks belong to their owners; comparison for evaluation only.
How the iRoutify figures were measured
Measured on the shipped path, against published optima.
The iRoutify numbers on this page follow the benchmark methodology sheet we hand to technical evaluators. The method behind the engine is proprietary and not disclosed; the measurement protocol is not.
Neutral ground truth
Canonical TSPLIB EUC_2D instances, each with a published, proven optimum. Metric: round(sqrt(dx²+dy²)), closed tour — the same metric the optima were proved in. No vendor-selected baseline.
One definition of gap
gap = (iRoutify tour ÷ published optimum − 1) × 100. The same definition the papers above use, so the columns share a denominator.
The production entry point
The harness calls the same code path a customer request takes — not a lab configuration. “Regular” is the default response; “MaxQuality” is the opt-in batch mode. Release build, hardware named, date stamped. The service answers a set of places it has planned before from the best tour already found; the harness bypasses that memory, so every figure here is a fresh solve.
Deterministic and validated
Every tour visits every stop exactly once and is checked for validity. Same input, byte-identical tour on every run — two consecutive runs are compared by hash before a figure is published.
Scope
Per-vehicle routes of about 150 stops or fewer — the common production path after fleet splitting — are proven optimal on the straight-line metric: 10 of 10 TSPLIB instances from 51 to 150 stops returned at the exact published optimum. Single routes of 51 to 400 stops, as shipped on 2026-09-23: the default response returns 31 of 38 TSPLIB instances at the published optimum (mean gap 0.017%; 14 of 38 before), the max-quality mode 33 of 38; on eil51, st70 and ch130 the one unit left is TSPLIB’s integer rounding — the tour is shorter than the published optimal tour before rounding. The large single tours above are near-optimal, measured against published optima directly. Road-distance routing is a different metric; a route proved optimal here is not thereby optimal in road distance.
What is not claimed
No head-to-head against OR-Tools, LKH-3 or Concorde has been run by us; their figures are quoted as published. The harness and instances are available on request, and every iRoutify figure on this page can be reproduced through the public API.
Sources
Every third-party figure, to its page.
Accessed 2026-09-08, and the ViTSP paper 2026-09-09. Quote from the originals, not from us.
ViTSP: A Vision Language Models Guided Framework for Solving Large-Scale Traveling Salesman Problems · Yin, Ding, Khir & Cai, ICLR 2026Tables 1 and 2: the Concorde column above, on the same TSPLIB instances. Table 7: the published cost of the VLM API calls, $0.12 to $39.40 per instance solved.https://arxiv.org/abs/2509.23465
On the empirical scaling of run-time for finding optimal solutions to the travelling salesman problem · Hoos & Stützle, EJOR 2014How Concorde’s proof time grows with instance size.https://ada.liacs.nl/papers/HooStu14.pdf
iRoutify figures: internal benchmark record, measured as described above. Methodology sheet, harness and instances available on request.
Verify it yourself
Send one anonymized day of stops.
We return the optimized routes, the per-route proof or certificate, and the harness — so you can reproduce every iRoutify figure on this page without taking our word for it.