How accurately does AeroPacer calculate your bike split? Replaying 64 real power files

AeroPacer calculates finish times from physics, not by fitting a statistical formula to a pile of past results. The upside is that a brand-new course works from day one. The downside is that I have to prove it is actually accurate.

How I tested it

The method is called a replay, and the idea is simple. Take the power an athlete actually produced on race day, feed it through the engine segment by segment, and add the slowing the corners force on you. Where weather station data exists, add that day's hourly wind direction and speed too (37 of the 64 rides; the other 27 had no station close enough and were calculated with no wind). Let the engine work out how long riding like that should take, then check it against the actual moving time the head unit recorded.

First, to be clear about what this measures. The engine is given the power the athlete actually rode on the day, so what it tests is this: if we know how many watts you put out, does it get the bike split right? When you plan before a race, the power is a target and the weather is a forecast. Whether you hit that target on the day, and whether the forecast holds, both add error on top. Validating that part has to wait until enough post-race files have come back, and it will be published separately.

One detail matters more than any other: CdA (drag area, how hard it is for you to push through the air). Solving for CdA from a race's own file and then using it to predict that same race would be peeking at the answers. So every race uses a CdA taken only from that athlete's other races: a median, weighted toward the most recent ones. The race's own data plays no part at all.

Sample

• Nine people (myself included), all from one coaching team, 2019 to 2026, 75 files in total.
• All body weights are measured values, and bike types are handled separately (Tri/TT bikes and road bikes each get their own CdA baseline).
• Files with clear-cut problems were excluded up front: two with no power, four with a broken barometer, one duplicate upload, three with GPS jumping around in tunnels, and one that recorded only 73 km of a 180 km course before cutting out. The CdA from those files still counts toward the baseline; only their finish times are left out of the statistics.

That leaves 64 rides to evaluate, across 15 countries and regions: 61 races plus 3 training rides at close to race length (93, 122 and 132 km). Three outliers with errors beyond ±7% were then set aside: Shanghai Chongming 70.3 2025 (+8.7%), the 2025 70.3 World Championship in Marbella (+7.4%) and Port Macquarie 2023 (−8.0%). To be clear, those three were set aside after the results were in, which is a different kind of decision from the eleven files excluded above on data quality. The results below show both: all 64 rides, and the 61 left without those three. Everywhere else on the site, the figures quoted are from all 64, with nothing excluded.

Results

First, what a median is: line up the errors from all the rides from smallest to largest, and the one in the middle is the median. Unlike an average, it does not get dragged around by a few extreme results.

The site quotes the left-hand column: a median of 2.1% and 86% within ±5%, with nothing excluded. In time, that is about 8 minutes over a full distance.

The +0.3% in the last row is close to zero, but it does not mean the engine is "conservative overall". Split it up and the flat courses (less than 3 m of climbing per km, 18 rides) came out 2.2% slow on average, with 15 of those 18 calculated slow; the hillier courses came out slightly fast, and the two happen to cancel out. One possible reason the flat courses come out slow: in a race there are riders ahead of and behind you, so the air resistance is a little lower than riding alone, and the engine does not account for that.

How far off a lookup CdA is

Same replay, but with CdA taken from the lookup table (the typical value for a Tri/TT bike, scaled by body weight): the median error across the 64 rides rises to 2.6%, the share within ±5% drops to 81%, and the largest miss is 11.2%. The gap is not huge, because most people's CdA is not far from the typical value anyway. But for riders whose CdA is especially good or especially bad, the lookup is wrong from start to finish, and that is why you solve it from your own files.

How the errors are distributed

Predicted vs. actual

Where the error comes from

1. Weight. Oddly enough, the median looks better with guessed weights. The reason is that a wrong weight pushes the estimated CdA the other way, which happens to cancel out the error. Only once measured weights went in did the mismatches in equipment and era show up. This is why the dashboard asks for your real weight.
2. Equipment changes. One athlete's estimated CdA was 0.22 to 0.23 in 2022 and got as low as 0.175 by 2026, but it did not come down in a clean line: 2024 alone ranged from 0.194 to 0.237. A median over the whole history cannot keep up with a moving target like that. That is the price you pay for estimating CdA from an athlete's other races.
3. Too far from a weather station. There is no weather station near Port Macquarie, and it blew hard that day. Two athletes in the same race came out at −8.0% (the race dropped above) and −4.1%.
4. On long, flat courses the barometer inflates elevation gain. This one affects the course data, not the engine. The course library handles it by treating the official route as the reference and cross-checking against multiple sources.

Races used for validation

The table below is the 61 rides left after setting aside the three outliers, from 46 race-and-year combinations (the three outliers' values are given above). Where a race has several files, each one is a different athlete. The error is each file's prediction against the actual time (plus = the prediction was slower). The three training rides are sessions at close to race length (93, 122 and 132 km; the table shows the average), added to fill out the 2026 sample.

What this means

For most athletes, here is what these numbers mean: if you actually ride the plan's power on race day, your bike split should land within about ±5% of the prediction. A real race adds two more sources of error: whether you can hold the target power, and whether the weather forecast is right. Upload your file after the race and the post-race report breaks the gap down into power, CdA, stops and so on, so you can see where it came from; your own CdA also keeps getting more accurate.

Notes on trustworthiness

• Every number in this article comes straight from the backtest results table, and the charts are drawn from the same data. The lookup CdA figures come from re-running the same script with only the CdA source swapped.
• The data-quality exclusion rules were applied consistently: for example, any file with barometer noise above the threshold was excluded, including files whose error looked normal. That said, a few of those rules were added only after the first run turned up absurd results. The only rides set aside after seeing the results are the three outliers, their values are all listed above, and everywhere else on the site uses the 64 rides with them included.
• Two global parameters were tuned on the same set of files: the corner slowdown multiplier (calibrated on the Hamburg files, and Hamburg is in the sample), and the weighting between recent and older races when estimating CdA.
• The sample is nine people, all from one coaching team, and three of them account for more than half the rides; the courses span Asia, Europe, North America, Oceania and the Middle East. This is not a random sample: a different group of people or a different set of courses could give different numbers.
• The backtest script and results table are kept in the project and re-run with every engine upgrade. If the numbers change, this article will be updated with the reason why.