Timefold Solver is an open-source constraint solver for planning and scheduling problems such as vehicle routing, shift rosters, and timetables. Its Community Edition is licensed under Apache 2.0, while a separate Enterprise Edition is commercial. The project began on April 20, 2023, as a fork of OptaPlanner and is built for Java and Kotlin.
Key takeaways
- The Community Edition is Apache 2.0 open source. The Enterprise Edition is not open source and needs a license from Timefold for production use.
- Timefold continues OptaPlanner, and its creator and several core engineers moved to the new company.
- A problem is described with planning entities, planning variables, and a score built from hard and soft constraints.
- The search builds a first solution, then improves it with metaheuristics. It looks for the best answer in the available time, not a proven optimum.
- Vehicle routing is one of the listed use cases, and the traveling salesman problem is its one-vehicle special case.
Where the project came from
OptaPlanner was a long-running Java planning engine created by Geoffrey De Smet and developed under Red Hat. According to De Smet's account on the Timefold blog, Red Hat's priorities shifted after the IBM acquisition, and by late 2022 the project had no sustainable future there. He also did not own the project's web domain, and trademark ownership was unclear. His stated reason for the fork was that it was the only way to rescue the project.
The repository dates the fork to April 20, 2023, and the public announcement followed on May 2, 2023. The company behind it, Timefold BV, was founded by Maarten Vandenbroucke and De Smet, and OptaPlanner engineers Lukáš Petrovický, Radovan Synek, and Christopher Chianelli joined it. Its legal notice calls Timefold a derivative work of OptaPlanner and OptaPy, keeps the original Red Hat and contributor copyrights, and states that every source file has been modified.
Community and Enterprise editions
The code in the public GitHub repository is the Community Edition, released under the Apache License 2.0, which allows commercial use, modification, and redistribution under its terms. The Enterprise Edition is a separate commercial product. The repository states that it is not open source and that production use requires a license from Timefold.
The fork announcement names two features that sit in the Enterprise Edition: multithreaded solving and nearby selection. Both matter for large problems, because they affect how fast the search can explore alternatives. Teams evaluating the project can build a working model on the Community Edition and measure whether those extra features are needed for their data size. License terms can change between releases, so the current repository text is the reference, not any summary.
How a planning problem is described
The documentation for the current 2.x line describes Timefold Solver as a lightweight, embeddable constraint satisfaction engine that runs on Java 21 or higher. Modeling follows a fixed vocabulary. A planning entity is an object the solver may change, such as a visit that needs a vehicle. A planning variable is the property it changes. Problem facts, such as vehicles and locations, stay fixed. The planning solution class wraps all of these and stores the score. For routing, the docs describe a list variable that holds an ordered list of values, which suits a sequence of stops.
Business rules become score constraints. Hard constraints must not be broken, soft constraints express preferences, and a medium level exists for scarce resources. A score such as 0hard/-257medium/-6119520soft is compared level by level, so any hard violation outweighs every soft penalty. Constraint Streams, the documented way to write these rules, resembles Java Streams or SQL, and the engine recalculates only the part of the score affected by each change.
From the traveling salesman problem to vehicle routing
The traveling salesman problem asks for the shortest single route that visits every location once and returns to the start. The vehicle routing problem generalizes it to a fleet that leaves a depot and serves customers under shared limits. Common variants add vehicle capacity (CVRP) or delivery time windows (VRPTW). Dantzig and Ramser introduced the vehicle routing problem in 1959 under the title "The Truck Dispatching Problem."
The difficulty is the number of orderings. For one vehicle visiting 10 stops from a depot there are 3,628,800 possible sequences, and for 15 stops there are 1,307,674,368,000. At a rate of one million evaluated routes per second, the 15-stop case would take about 15 days to enumerate. This arithmetic is an illustrative example, but it explains why solvers rely on heuristics instead of checking everything.
| Candidate plan (illustrative example) | Late arrivals (hard) | Total drive minutes (soft) | Score |
|---|---|---|---|
| Plan A: shortest total driving | 1 | 310 | -1hard/-310soft |
| Plan B: slightly longer driving, all windows met | 0 | 335 | 0hard/-335soft |
In this toy comparison, Plan B scores higher even though it drives 25 more minutes, because a hard violation always outweighs soft penalties. The numbers are invented to show the scoring rule and do not come from a real fleet.
How the search works
The optimization algorithm documentation explains that a solver usually starts with a construction heuristic, which builds an initial solution quickly and ends on its own, and then runs one or more metaheuristics such as tabu search, simulated annealing, or late acceptance. The same page states that local search usually performs best on real-world problems under real time limits.
The documentation is also direct about limits. Exhaustive search can run for billions of years on a real planning problem, and the optimal solution usually cannot be proven. The solver therefore aims to find the best solution in the available time, and a result should be read as a strong plan, not a certified minimum.
Checklist before adopting any routing solver
- List the hard rules (capacity, legal driving hours, time windows) separately from soft preferences.
- Confirm that travel times come from a real road network, not straight-line distance.
- Compare solver output with the current manual plan on the same historical day.
- Run the search for several time limits and see whether results stop improving.
- Check the license of the edition that will actually run in production.
- Treat vendor-reported savings percentages as unverified until reproduced on local data.
FAQ
Is Timefold Solver free to use?
The Community Edition is free and open source under Apache 2.0. The Enterprise Edition requires a commercial license for production use.
Is Timefold the same as OptaPlanner?
Timefold is a fork and continuation of OptaPlanner by its creator and core engineers. It is a separate project with its own repository, name, and company, and the original copyrights are preserved in the source.
Does it guarantee the shortest route?
No. Its own documentation says the optimal solution cannot usually be found or proven, so the goal is the best solution within a time limit.
Which programming languages does it support?
The repository describes it as an AI constraint solver for Java and Kotlin, and the documentation says it runs on Java 21 or higher.
Related reading
- Optimization problems and the techniques used to solve them
- AI algorithms for the salesman problem
- Solving the traveling salesman problem with AI
- Route optimization in practice
More in Traveling salesman problem.
Last verified: October 2026
Sources
- Timefold Solver repository and legal notice, TimefoldAI, GitHub, accessed October 2026
- Timefold Solver documentation, optimization algorithms overview, Timefold, 2026
- OptaPlanner fork announcement, Timefold blog, May 2, 2023
- Timefold Solver documentation, introduction, domain modeling, and Constraint Streams, Timefold, 2026
- Vehicle routing problem overview, Timefold, 2026
- Dantzig, G. B. and Ramser, J. H., "The Truck Dispatching Problem," Management Science 6(1), 1959