New default optimization algorithm

The HERE Tour Planning API switches to a new default optimization algorithm that produces significantly better solutions across a wide range of problem types. This is the most significant algorithm update since the launch of the service. The new algorithm becomes the default automatically, so existing integrations require no changes.

Release plan

• Asynchronous requests: The new algorithm becomes the default for the /async endpoint only beginning on November 4, 2026.
• Synchronous requests: The /sync endpoint keeps using the previous algorithm by default. However, you can opt in to the new algorithm in your requests.
• Customer feedback: Both algorithms remain available for a period of time to provide you the ability to compare results and share feedback.

See the HERE Tour Planning API Changelog for further updates, such as the deprecation date of the previous algorithm.

What's changing

The following sections provide a detailed breakdown of the changes related to the release of the new optimization algorithm.

New algorithm

This release bundles many improvements to the optimization algorithm. It introduces a state-of-the-art metaheuristic to replace the previous optimization engine, reworks solution evaluation, improves how the algorithm uses multiple CPU cores, and refines many other internal components. Together, these changes produce significantly better solutions across a wide range of problem types.

Improved termination behavior

The new algorithm reworks the termination settings. It continuously evaluates whether it is making meaningful progress and stops when improvement stalls. When you don't provide an explicit stagnationTime, the algorithm computes a default based on problem size.

With the same stagnationTime, the new algorithm typically runs longer than the previous algorithm because it detects progress more precisely. See Recommendations for guidance on adjusting your configuration.

New searchEffort parameter

At release, the new algorithm adds the optional searchEffort parameter, which works with stagnationTime to determine when the algorithm stops. At each check, the algorithm measures how much its best solution has improved over the preceding stagnationTime interval. The searchEffort parameter determines how much improvement during this period counts as meaningful progress:

The following snippet shows a searchEffort configuration example:

{
  "configuration": {
    "termination": {
      "maxTime": 300,
      "stagnationTime": 60,
      "searchEffort": "balanced"
    }
  }
}

How to switch between the algorithms during the transition period

During the transition period, the default algorithm depends on the endpoint:

• /async endpoint: new algorithm enabled by default
• /sync endpoint: new algorithm disabled by default

Use the classicMode flag to select which algorithm each request uses. Compare the results in your internal deployments before offering the new algorithm to customers.

Using the previous algorithm for async requests

For the /async endpoint the new algorithm becomes the default one starting on November 4, 2026. The previous algorithm remains available by setting the classicMode flag to true. For example, see the following snippet:

{
  "configuration": {
    "classicMode": true
  }
}

Using the new algorithm for sync requests

By default, the /sync endpoint continues to use the previous algorithm while the new algorithm undergoes further refinement. However, starting on November 4, 2026, you can enable the new algorithm in your /sync requests by setting classicMode to false, as shown in the following example.

{
  "configuration": {
    "classicMode": false
  }
}

Benchmark results

The evaluation measured each metric on the subset of problems where that objective was the deciding factor in solution quality. Actual improvements vary depending on problem structure, constraints, and objective configuration.

• Cost, distance, and duration: improved by 2% on average, with many problems seeing improvements between 3% and 12%.
• Unassigned shipments: reduced by about 1% on average.
• Tour overlap: drastically reduced for problems using the minimize-overlap objective.

With stagnationTime reduced by a factor of 10, the new algorithm still produced better results in about 70% of instances while running approximately 4x faster than the previous algorithm with its original settings.

Recommendations

Although the new algorithm requires no changes to any of your existing problem definitions and integrations, use these recommendations to evaluate and tune the new algorithm:

• If you keep the same stagnationTime, measure execution times before release. The new algorithm typically runs longer because it detects ongoing progress more precisely. To manage execution time, reduce stagnationTime by a factor of 5 to 10, or set maxTime as a hard upper bound.
• Try the searchEffort parameter to find the right balance between speed and quality for your use case.
• Use classicMode to compare algorithms and share feedback through your account team.

Frequently asked questions

Find answers about compatibility, running time, solution quality, and switching between algorithms.

Next steps

• For request structure and available options, see the API Reference.
• To configure termination settings, see Configuration.
• To interpret the results produced by the optimization algorithm, see Solution.