I am publishing my ŁUT 150 time
before I start
I built a model that takes a course profile and my last four ultras and works out how long I will be out there. Until now I only ever checked it backwards, on races I already knew, which is the easy part. So here is something I cannot take back: at 1:00 a.m. on 17 October I start Łemkowyna Ultra Trail 150 and I am publishing the prediction before the race, not after. If the model is wrong, you will see it with me.
The number
The model does not give a point, it gives a band. The width is not decoration: it comes from how closely the model reproduced my earlier races. The course is 149.5 km with 5,860 m of climbing, which in my terrain model costs as much as 179 km on the flat. The profile of this course, segment by segment is on a separate page.
| Moving time | Stops | Finish time | |
|---|---|---|---|
| Faster end | 25:13 | 2:06 | 27:19 |
| Centre | 28:17 | 2:36 | 30:53 |
| Slower end | 31:22 | 3:09 | 34:31 |
The moving time comes from the model. The stops are a separate, weaker estimate: across my four races they took between 4.2 and 7.7 percent of the clock and grew with race length. For a race with one night out that works out at roughly eight percent. This is the part I can get wrong more easily than the running itself.
Swipe the figure sideways to see the whole course.
Why this is not guesswork
The model only receives the course profile. It is not told the result. I run it on four of my own races from 2024 to 2026 and compare it with what I actually did.
| Race | My moving time | Model prediction | Difference |
|---|---|---|---|
| Bieg Rzeźnika | 12:24 | 12:12 | −12 min |
| Krynicka Setka | 14:42 | 14:42 | 0 min |
| Chudy Wawrzyniec | 15:06 | 15:54 | +48 min |
| Szlak Ultra Orlich Gniazd 160 | 25:54 | 25:24 | −30 min |
The worst miss is 48 minutes on a fifteen-hour race. That is exactly why I publish a band rather than a single number. One caveat I do not want to hide: the longest race in that set ran over far gentler terrain than Łemkowyna. For a long race over steep ground the model is more likely optimistic than cautious.
The same model can be read two ways
The self-check above has a limit I have to name, or the band looks narrower than it is. The curve rests on four races, and those four points are collinear: the three shorter runs were steep (44–50 m per kilometre) and the only long one was flat (20 m per kilometre). In my data, duration and steepness move together.
So the same four points allow two readings. If I fade with time, the moving time comes out at 28:17. If I fade with flatter ground, it comes out at 22:16 — and that second reading actually fits slightly better. Six hours apart, and the data does not settle which mechanism I am really measuring.
I am saying this plainly because it means the band of 27:19–34:31 understates the uncertainty: it covers the scatter of the fit, not the choice of model. I publish 30:53 because the time reading is the one I built and the one the whole app stands on — but an honest range covering both readings is wider. And that is why this race interests me more than the result: ŁUT is the first start that is both long and steep, the only configuration that separates the two effects. Afterwards, one of these readings stops being possible.
Two numbers for the climbing, two and a half hours apart
Last year’s GPX track gives 4,721 m of climbing. The race rules say 5,860. The gap is not someone being wrong: the track has one point every forty metres and simply cannot see the small undulations. On this course the missing metres are worth two hours and forty-two minutes: the track gave 25:35 of moving time, the rules give 28:17.
I took the number from the race rules. A model that picks the more convenient input for itself is not a model.
Twenty-nine minutes
The cut-off is 35 hours. The slower end of my band lands at 34:31. There are 29 minutes between my worst predicted case and the cut-off. I do not like that number and I am not going to quietly drop it: the model says that with bad weather, a stomach problem or one long stop I may not make it in time.
Why my own site says 17:19
The analysis of the same course on ultraflow.run says 17:19–21:11. That is not a contradiction, they answer two different questions. That number answers „how long would this take if you held the pace”. This one answers „how long will it actually take”. The gap between them is exactly what decides an ultra, and it is invisible in any fitness test done on fresh legs.
Through Łemkowyna I will hold just under half of the threshold power I can hold for an hour. Not because I will be badly prepared. Because that is what thirty hours of running does.
What would prove this wrong
1. A finish outside the band. Faster than 27:19 or slower than 34:31 means the model does not carry over to this terrain. I will write that up exactly as carefully as I am writing this prediction.
2. A DNF. It is possible and I will not hide it. The model predicts a time, not whether I finish; an injury or a stomach will not refute it, but I will record that the prediction was left unsettled.
3. A hit proves nothing either. One race is one data point. A prediction published before the race is worth exactly this much: it cannot be quietly adjusted afterwards.
This race is also the first long outing over steep ground in my data. Whatever the result, the model will know more afterwards than it does today.
Run it on your own course
This number does not come from the fatigue curve alone. Underneath it sits RUP, the route analysis that colours the profile by run and hike mode and shows which sections will cost the most. UltraFlow builds my training block for this race from that same material, so what gets predicted is not just the day of the finish, but the weeks meant to carry me to it.
Route analysis in UltraFlow is free and needs no account: upload the GPX of your race and you get the profile, the sections that will cost you most, and your carbohydrate demand. A time prediction on your own curve needs your watch data and is part of the app.