Izu Climbing

Building a Long-Ride Prediction Tool with AI, Part 1

In the previous post, I wrote about building a long-ride prediction tool with help from AI and then taking it out for a test ride to West Izu.

The idea was simple enough: load a route created in Strava, have the tool estimate the total elapsed time and where I would be every hour, then put nutrition cues and convenience-store availability into a stem sheet, with a map I could check on my phone.

When I actually tried it on a route of about 220 km with roughly 4,000 m of climbing, the predicted elapsed time was 13 hours 17 minutes. The actual elapsed time was 13 hours 23 minutes. A six-minute difference on the first real test was, frankly, far better than I expected.

That previous post, though, was mostly about the ride itself. I barely touched on the more important question: how did I actually make that thing?

This is the development story.

Before going any further, I should say this clearly: the AI is not making riding decisions inside the prediction tool. I talked things through with AI, asked it to help with design, code, and corrections, and gradually built a prediction tool for my own use. I cannot really program, and this was also my first time using AI for this sort of purpose.

So why did I want to make something like this in the first place?

When planning a long ride, I often find myself wondering how long a route will actually take.

Strava can tell me the distance and elevation gain. It also gives a rough estimated time. But I have always treated that as a rough guide. It does not really tell me how long the route will take when I ride it, including breaks, traffic lights, food stops, and the fatigue that builds up in the second half.

Once a ride gets longer than ten hours, distance and elevation alone are not enough.

The same 200 km ride can feel completely different depending on whether it has 2,000 m or 4,000 m of climbing. It matters whether the major climbs come early or late, whether the route is a chain of rolling climbs, whether the city sections have endless traffic lights, or whether there is a 40 km stretch with almost no stopping. All of those things change the actual riding time quite a lot.

With that in mind, I wanted a way to make predictions that were a little more specific to me.

I Want to Get Home Before Sunset

The root of this whole idea was not simply, “What time will I get home?” It was more like, “What time do I need to leave if I want to get back before sunset?” That might sound like the same question, but for me there is an important difference.

The roads near my home are urban, so unless it is late at night or very early in the morning, there is a fair amount of traffic. At the end of a long ride, when fatigue has built up, I would rather not be riding through the city at dusk.

It is the same in the countryside or in the mountains. I would prefer not to ride unlit roads after dark, especially on unfamiliar routes where the road surface is hard to read.

So the goal was not just to predict whether I would return at 8 p.m. or 11 p.m. It was to know how much margin I needed at the start in order to get back safely before sunset.

Of course, if I was going to build a route-wide prediction system, I also wanted to include information that would be useful during the ride.

Where would I be after each hour? Where could I refuel? Which sections had no convenience stores? Where should I plan a longer break? Would the pace I was riding at make me fall apart later? I gradually started wanting all of that information in a form I could check both before and during the ride.

Strava Alone Is Not Quite Enough

Strava route planning is useful.

It shows distance, elevation gain, and the overall shape of the course. For linking together roads I do not know and planning a long ride, it is a very dependable tool.

But it is harder to get more detailed information, or predictions that reflect my own riding characteristics.

For example: total elapsed time including breaks and traffic lights, predicted locations for each hour, calories to take in, timing for water refills, sections with no convenience stores, weather and rain risk on the day, and how much I should eat before entering a long climb.

Those things are difficult to see from general averages.

Even for the same 200 km distance, the time required varies depending on the course profile and the rider. Some people are strong on flats but slow down a lot on climbs. Some are not especially fast but can keep going steadily into the second half. Some are better with frequent short stops, while others feel worse if they stop too much. Age obviously matters, and so do cycling history and general athletic background. Strava gives a broad sense of trends, but I did not feel it could give me a prediction truly adapted to me.

So I wondered: could I use my own past riding data to make a prediction tool for myself?

First, I Asked AI

Once I had thought that far, I started asking AI.

I do not know much about programming, data analysis, or exercise physiology. So from the beginning, I threw the problem at it rather bluntly.

I want to know the predicted elapsed time and hourly locations for routes longer than ten hours. I have my own past ride data. I have heart rate, cadence, and speed, but no power meter. I do not yet know what kind of system it should become, but I want to build it while discussing it.

That was more or less how I started.

The AI seemed oddly enthusiastic.

It said that instead of a simple route completion estimate, I might be able to build something like a personal adaptive pacing strategy engine for long rides by combining my own fatigue model, nutrition model, stopping tendencies, terrain adaptation, and weather tolerance.

A personal adaptive pacing strategy engine.

Suddenly it sounded grand.

But I understood the idea.

In other words, it would not be based on the average cyclist. It would be based on my own past logs. How fast do I go on a 5% climb? How much do I slow down after 150 km? How does my heart rate behave on hot days? How much does my pace drop at night or when tired? What kind of break interval keeps me stable?

If those pieces of information accumulate, the prediction should move closer to “this is what will probably happen to me,” rather than “this is generally what happens.”

Of course, at that point nothing existed yet. It was only a conversation, and the dream was expanding.

Still, it was enough for a first step.

I Do Not Have a Power Meter

One thing I was slightly concerned about was the lack of a power meter.

What I use is basically a heart-rate sensor, cadence sensor, and speed sensor. At first, I wondered whether that meant I could not do anything very meaningful.

But when I asked AI, the answer was that even without power data, there was still a lot of information that could be useful for long-ride prediction.

How heart rate changes. How much speed drops at different gradients. How cadence changes when fatigue builds. Long-duration declines in cruising speed, stopping frequency, and whether I recover properly after breaks might also be visible in past logs.

Even without power, tracking those changes might still reveal something about how long I can keep riding without falling apart.

I found that very interesting.

How steadily can I ride in a long ride? Where do I tend to slow down? What kinds of conditions wear me down?

To get home before sunset, that is the kind of thing I need to know. I am not racing.

Listing What I Wanted

What I wanted at first was the total elapsed time, including breaks and traffic lights. I also wanted predicted locations for each hour.

As I thought about it more, I started wanting more: where to take breaks longer than 15 minutes, how much food to carry, what the weather and rain risk looked like for the ride day, and how much I should eat before entering a long climb.

Written out like that, it sounds greedy.

But as long-ride planning information, all of it is genuinely useful.

Especially on routes longer than ten hours, small decisions along the way affect the second half. Starting too hard, delaying nutrition, underestimating the heat, assuming there will be a convenience store and then finding nothing for a long stretch. Small things like that can become the cause of a much bigger collapse later.

So what I wanted was not just an arrival-time prediction, but a broader planning tool for long rides.

Long Rides Are About How You Fall Apart

There is one more important idea.

In a long ride, how you fall apart is harder than how strong your legs are.

That phrase also came out of my conversation with AI, and it felt very true.

Of course leg strength matters. Being able to ride faster is useful. If you are strong on climbs, you can choose a wider range of routes.

But the really difficult part of a long ride is not how fast you can go in the first half. It is how little you fall apart in the second half.

The same 5% climb is completely different at 30 km and at 180 km.

A climb that feels manageable early on can suddenly bite hard later. Heat drains you. Delayed nutrition makes it hard to produce force. A long stop can leave the body feeling heavy. If it gets late at night, sleepiness enters the picture too.

All of those things accumulate, and at some point the pace can suddenly drop.

That, I think, is what is frightening about long rides.

Being a little behind schedule is fine. But if fatigue or poor fueling causes a major collapse in the second half, the whole plan to get back before sunset falls apart.

So what I really want to predict may not be simply “this gradient means this speed.” It may be closer to “after riding this far, in this condition, what happens when I enter this climb?”

Suddenly it had become much more difficult.

I Cannot Build Everything at Once

Once I started thinking this way, the list of things I wanted kept growing.

Fatigue, nutrition, breaks, weather, wind, temperature, sunset, convenience stores, city traffic, traffic lights, long climbs, late-ride fading. The more I thought about it, the more variables I wanted to include.

It was starting to become a lot.

But trying to build everything from the beginning would probably break the whole project.

So I decided to think much more simply at first.

The first thing to build should be a tool that reads a route and uses my past ride data to estimate finishing time and predicted speed by segment. Then it should add hourly predicted locations and, if possible, rough nutrition guidance.

That should be enough for the first version.

Even that alone should reduce a lot of the anxiety before a long ride.

At this point, the first shape of the tool was beginning to appear.

Load a route made in Strava. Use my past riding data to predict speed from gradient and distance. Add total elapsed time including breaks, hourly locations, nutrition, and convenience-store information. If I could do that, it would become much easier to decide what time I needed to leave in order to get home before sunset.

I Want a Stem Sheet

The first output format that came to mind was a stem sheet.

I have always had a little admiration for the way professional riders tape course information and nutrition plans to their stems.

If I were to do the same thing for a long ride, it would be useful to have hourly predicted locations, nutrition timing, convenience-store availability, and break cues compressed into a small format.

It is easier to glance at something on the stem than to pull out a phone. At least as a first idea, it felt quite realistic.

That was when the first goal finally became clear.

Read a GPX route created in Strava. Use my past ride data to predict total elapsed time. From that, calculate predicted hourly locations, add nutrition and convenience-store information where possible, and finally output it in a printable stem-sheet format.

That was enough for the first target.

Looking back, this was still the peaceful stage.

What began as the question “What time should I leave if I want to get home before sunset?” had already started turning into a personal long-ride prediction tool.

So how would I actually build it?

That was where the hard part began.

Next time, I will write about the prototype stage: analyzing past ride data with ChatGPT, trying to create gradient-based speed estimates, nutrition plans, and a stem sheet, while scripts and output files multiplied faster than I expected.

At this point, I still had no idea that I would eventually end up making a phone map with current-location display as well.