Fast
Immediate route ordering
For ordinary trip use where a strong answer is needed quickly. It keeps the interaction lightweight and browser-native.
Three search depths
One interface, different compute budgets. The deeper modes do more work; MDL×DCC also changes how search effort is governed.
Deep
Classical deeper search
Runs longer local search and keeps improving while the browser tab stays active. Useful as both a product mode and an A/B baseline.
Deep · MDL×DCC
Governed search
An experimental engine that watches search history, alternates exploration and intensification, keeps multiple operator families alive, and can use one or more CPU workers.
How the MDL×DCC loop works
The browser engine does not replace search with a single score. It uses diagnostics and history to decide how strongly to couple the search to its current basin.
01 · SEEDStart from a valid route and deterministic run state.
02 · GENERATEProduce candidate moves from several operator families.
03 · SENSERead recent progress, stagnation and compressibility/history signals.
04 · GOVERNSwitch between explore and intensify instead of holding one fixed regime.
05 · RETAINKeep better tours, checkpoints, lineage and diagnostics for continuation.
Rank, don't eliminate. TripOpti inherits a core TSP R&D lesson: a method that looks weak in one representation or phase may become useful later. The engine therefore ranks and reallocates rather than treating a temporary loser as permanently dead.
Current browser evidence
These are diagnostic results, not a claim that TripOpti equals the full Python/Rust/GPU research stack.
qa194 · known optimum 9,352
Repeated exact result
On the 194-city Qatar benchmark, nine real-browser R1.2.1 diagnostic runs reached and independently confirmed the known optimum 9,352. That established that the browser branch can do more than “good enough” routing on a controlled benchmark.
uy734 · paired 1 CPU evidence · 18 Sep 2026
1 CPU Firefox A/B
| Engine | Elapsed snapshot | Best | Gap to 79,114 | Status |
|---|---|---|---|---|
| Deep | 24.05 h | 84,217 | +6.450% | complete |
| Deep · MDL×DCC | 22.46 h | 79,451 | +0.426% | running |
Same uy734 input, Firefox 158 and one CPU worker. Classic Deep exhausted its full budget at 84,217; after reaching that result it spent more than three additional hours without improvement. MDL×DCC is still running: at 22.46 h it had reached 79,451, only 337 units above the 79,114 optimum, with its latest improvement recorded at 18.68 h. The final 24 h MDL×DCC export is still pending. Diagnostic work-unit counters are not treated as directly interchangeable between engines.
Product boundary
TripOpti is the deployment branch, not a rename of the whole TSP research program.
In the browser
Local stop-order compute
The core route-order optimization executes on the user's device. Deep runs can maintain local encrypted checkpoints and continue later. Supporting geocoding, maps, road directions or AI features may contact their respective external providers.
In the research stack
Six TSP arenas stay six
TSPES, DEV2.3, DEV2.4, BD-RPHS and the two 8zTSP-R lines remain distinct research arenas with different scientific roles. TripOpti is the research → product transfer that distills selected mechanisms into a browser-safe engine.
Related TSP research
The pages below are intentionally cross-linked so product behavior, benchmark evidence and research lineage stay connected without collapsing into one leaderboard.
Claim discipline. The Classic 24 h baseline is complete; the MDL×DCC side is still an interim 22.46 h snapshot and should be replaced or extended by its final export. TripOpti should be judged by reproducible browser diagnostics and controlled baselines, not by marketing language.