API throttling finally helped me to move this project forward again. As a game development student building a route planner AI, I had reached a point where the logic itself was becoming more interesting, but the actual requests behind it were still too unstable. Between database-related timeouts, OpenStreetMap issues and too many calls hitting external services too aggressively, the project often felt more difficult than necessary.
So the aim of this phase was not to invent a huge new system from scratch. It was about improving the current system.
And, honestly, that made a noticeable difference.
Slowing the system down made it work better.
One of the strange things about projects like this is that 'doing less at once' can actually feel like progress. This is exactly what API throttling did for me.
Rather than firing off too many requests too quickly and then wondering why parts of the route pipeline were timing out, I started to control the request flow more carefully. This didn't magically solve every problem, but it made the whole setup behave more predictably.
This was important because Route Planner AI depends on several moving parts. If too many of these become unstable at the same time, the entire user experience becomes unpredictable. With better throttling, the planner felt less chaotic. It was not yet perfect, but it was finally moving in the right direction again.
This was one of those updates that sounds small on the surface, but made a big difference internally.
Adding TomTom improved the car routes.
Another significant development in this phase was the integration of the TomTom API to enhance the car-related aspects of the planner.
Up to this point, the car routing layer had been one of the project's weaker areas. While it was functional, it was not always convincing enough for the kind of route quality I wanted. Since the first-mile logic and mixed-mode planning depended increasingly on decent driving routes, I needed to improve this area.
This is where TomTom came in.
Its routing documentation describes the Calculate Route service as providing route distance, estimated travel time and route geometry, making it a much better fit for the automotive side of my pipeline than my earlier setup.
For me, this was less about 'adding another API just because I can' and more about upgrading a weak link in the chain. If Route Planner AI is supposed to compare real travel options, the car routes also need to be taken seriously.
And with TomTom integrated, they did.
I let users enter their own fuel consumption.
Another feature I added during this phase was a new setting where users can enter their car’s fuel consumption.
This was important to me because 'car' should not just be displayed as a travel time. There is also a cost, and that cost varies from vehicle to vehicle. Small cars, larger cars and less efficient cars should not all look identical in the planner.
So I added a simple, user-controlled fuel consumption value, which feeds into the route calculation on the pricing side.
The idea is straightforward:
fuelCost =
(distanceKm / 100) *
litersPer100Km *
fuelPricePerLiter;This formula makes the car route feel much more realistic. Rather than showing driving as just another line on the map, Route Planner AI can now show the actual cost of that decision.
Pulling in live fuel prices
Once the consumption setting was in place, the next logical step was to incorporate fuel prices.
I connected the car-route pricing to a fuel-price API, started fetching current fuel prices and displayed them. I also used them to estimate the cost of the driving segment. This gave the project something it had been lacking: a more realistic price estimate for car travel rather than a vague assumption.
In Germany, this concept aligns well with the practical handling of fuel price data. The Bundeskartellamt’s Markttransparenzstelle für Kraftstoffe receives price data for Super E5, Super E10 and diesel, and Tankerkönig makes current fuel price data available to developers through an API.
This made the feature particularly useful for Route Planner AI because the project was always intended to facilitate practical route comparison rather than merely theoretical trip planning.
If the planner indicates that a car route is the fastest option, it should also be able to provide an estimate of the likely cost.
Why did this update matter?
What I liked about this phase is that it improved both sides of the project simultaneously.
On the one hand, API throttling made the system behave better.
On the other hand, TomTom and the fuel-pricing logic made the car routes more useful.
This combination is important because the Route Planner AI is designed to compare realistic travel options. A route is not just geometry. It's not just about duration. It also involves cost and convenience, as well as whether the result feels believable enough to trust.
This update brought the project closer to achieving that.
The project was not finished yet, and I was still dealing with fragile external services, but this was one of the first points at which I felt the planner becoming more practical rather than just more technical.
Final thought:
This was a small update, but an important one.
API throttling helped reduce some of the instability that had been slowing me down. TomTom provided a more robust routing layer for the automotive side. The new fuel-consumption and fuel-price setup also meant that car routes could finally be judged by cost as well as time.
This made the Route Planner AI feel much closer to the tool I originally wanted to build.
It's not finished yet though.
But it's definitely more realistic than before.
