Wind-Aware Pacing: Building A Race Plan Around The Forecast

Most pacing plans are built for a course that exists only in GPX form. Elevation, distance, maybe corner radius if the tool is clever. Then you show up at Ripon on a Sunday in October, the wind is 22 mph from 250°, and the “optimal” 40k TT plan you generated on Wednesday tells you to hold 290 W flat for 52 minutes on a course where 11 minutes of it is into a gale and 9 minutes has you spinning out at 48 km/h. You will ride that plan. You will also lose about 90 seconds to someone who didn’t.

That gap is the whole argument. Wind isn’t a footnote to gradient, it’s a bigger lever than gradient on most British race courses, and a wind pacing cycling calculator that doesn’t ingest forecast data is doing arithmetic on a fiction.

Why wind outranks gradient on flat British courses

Here’s the physics, stripped down. Aerodynamic drag scales with the square of your air speed, not your ground speed. Power to overcome it scales with air speed squared times ground speed. So a 5 m/s headwind on a course where you’re doing 11 m/s means you’re pushing against 16 m/s of air: drag force goes up by (16/11)² = 2.1x.

Run actual numbers. Take a rider with CdA 0.24, mass 75 kg total, Crr 0.004, air density 1.225.

A 20 km/h wind is a 365 W swing in what the same speed costs you. Compare that to a 2% gradient at 40 km/h, which is roughly 165 W for the same rider. The forecast is worth more than the elevation profile, and it’s the one input almost every AI pacing tool treats as optional.

Yaw angle is where the sign flips

Cyclists talk about “headwind” and “tailwind” like there are two states. There are 360, and the interesting ones are in between.

Yaw angle is the angle between your apparent wind and your direction of travel. It’s a function of your ground speed, the wind speed, and the relative bearing. At 40 km/h ground speed with a 25 km/h wind at 90° to the road, your yaw is atan(25/40) = 32°. That matters because:

Deep sections and disc wheels produce net thrust between roughly 10° and 20° of yaw. This isn’t marketing. Wind tunnel data on an 80mm front consistently shows negative drag area in that band. So there exists a range of relative wind angles where a crosswind makes you faster than still air, and your pacing plan should be reducing power there, not holding it.

Above about 25° to 30° yaw, most deep front wheels stall. Drag climbs sharply, handling load goes up, and you start steering rather than pedalling. On a gravel race with a 30 km/h side wind and a 28 km/h average speed, you’ll live at 47° yaw for hours. Anyone who has ridden Dirty Reiver in a westerly knows the feeling: you’re not fighting resistance so much as fighting the bike.

So a competent plan needs the yaw time-series, not the wind speed. Two courses with identical “average headwind component” can need wildly different power distributions depending on how the yaw histogram is shaped.

A worked example: the 40k out-and-back

Standard CTT-style out-and-back. 20 km out, turn, 20 km back. Flat. Rider FTP 300 W, target normalised power 285 W for the hour. Forecast: 18 km/h steady wind, aligned with the road, so it’s a straight headwind out and tailwind back.

The naive plan. Hold 285 W throughout. You’d do:

• Out (headwind): 33.8 km/h → 35:30
• Back (tailwind): 51.2 km/h → 23:26
• Total: 58:56

The wind-optimised plan. Push harder into the headwind, ease in the tailwind, keeping the same total work (the same NP, roughly). Try 310 W out, 258 W back:

• Out: 34.9 km/h → 34:23
• Back: 49.6 km/h → 24:12
• Total: 58:35

21 seconds for free, same physiological cost. On a 10-mile TT the effect is smaller in absolute terms but the same in sign. On a hilly-plus-windy course where gradient and wind interact, I’ve seen models find 60 to 90 seconds over an hour.

The principle is not “ride harder into the wind because it’s harder.” It’s marginal-gains maths: you should spend watts where a watt buys the most time, and a watt buys more time when you’re going slowly, because you’re spending more seconds per kilometre there. Headwind and climbs are the same problem wearing different hats.

But here’s the part that trips people up. The optimal power variation is bounded by your durability, not by the physics. The physics would happily tell you to do 340 W into the wind. Your legs will tell you something else by kilometre 14. The right answer is a constrained optimisation, and the constraint is your own W’/CP curve, which is exactly why generic calculators fail and why tools that read your actual ride history should win.

What the tools actually do with wind

I’ve pushed the same course and forecast through several of these. Results vary a lot more than the marketing suggests.

Best Bike Split is still the most honest implementation. It pulls forecast wind (Dark Sky historically, now other providers) per race day, computes yaw per segment, and lets you set a variability constraint. Its plan output gives per-segment target power alongside predicted yaw. It’s the only mainstream tool where you can watch the plan change when the forecast changes, which is the actual test.

MyWindsock does the wind side better than anyone: per-kilometre relative wind, yaw, wind-adjusted “effective gradient”. Its coaching side is thinner but for reading a course before a race, it’s the reference.

intervals.icu stores wind data on activities and will show you weather on the ride, which is essential for the retrospective half of the job. It won’t build you a wind-aware plan, and Chad doesn’t pretend otherwise.

ChatGPT, Claude, and Gemini asked cold will produce plausible-sounding pacing advice that is physically wrong in specific, repeatable ways. Ask for a plan for a windy 40k and you’ll typically get “ride steady, don’t chase speed into the headwind” which is precisely backwards, or “increase power by 10% into the headwind” with no reference to your FTP, your CdA, or the wind’s actual bearing relative to the road. The models know the physics. They don’t reach for it unless you make them.

That’s a prompting problem more than a model problem, and it’s fixable. If you want the broader map of how route and pacing tools fit together, our AI route planning and race pacing pillar covers the tool landscape in more depth.

A prompt that actually produces a defensible plan

The difference between useless and useful output is whether you force the model to do the physics explicitly rather than pattern-match on cycling forum advice. Give it the numbers and demand the intermediate steps.

You are pacing a 40 km time trial for me. Do the physics, show your working.

MY DATA
- CP/FTP: 300 W (20-min test 315 W, 8 weeks ago)
- W': 18 kJ
- Total mass rider+bike: 78 kg
- CdA: 0.235 (measured via Chung method, aero position)
- Crr: 0.0040 (25mm GP5000 TT, good tarmac)
- Target duration: ~58 min, so ~95% CP average

COURSE
- Out-and-back, 20 km each way, net flat (+/- 15 m)
- Road bearing outbound: 118 degrees true
- Surface: good tarmac throughout
- One 180 turn at halfway, slows to ~12 km/h

FORECAST (Met Office, 10:00 start)
- Wind: 24 km/h sustained, gusts 38 km/h
- Direction: from 250 degrees true
- Temp 14 C, pressure 1012 hPa, RH 70%

DO THIS
1. Compute air density from temp/pressure/humidity, don't assume 1.225.
2. Resolve wind into headwind/crosswind components for each leg
   using the road bearings.
3. For each leg, compute yaw angle at the speed that leg will
   actually be ridden (iterate, don't use my average speed).
4. Optimise target power per leg to minimise total time subject to:
   - Average power <= 285 W
   - No leg above 108% of CP
   - W' depletion stays above 6 kJ at all times
5. Output a table: leg, distance, target power, predicted speed,
   predicted yaw, predicted split.
6. State the time saved vs constant 285 W.
7. Tell me which wheels: I have an 80/disc and a 50/50.
   Use the yaw numbers to justify it.

Flag any assumption you had to make.

The “iterate, don’t use my average speed” line matters more than it looks. Yaw depends on ground speed, ground speed depends on power and yaw, so it’s a fixed-point problem. Models that skip the iteration get yaw wrong by 8° to 12° on windy days, which is enough to flip a wheel recommendation from “80 front” to “50 front, you’ll be stalled all day”.

Run this against Opus 5 or Sonnet 5 and you’ll get the working shown, the air density computed (1.219 for those conditions, not 1.225), and a wheel call with a reason attached. Run the lazy version of the same question and you get vibes.

The crosswind case nobody plans for

Out-and-backs are the easy problem because the wind resolves cleanly. Circuit races and gravel events are harder, and the failure is subtler.

Take a 60 km gravel loop, roughly square, 15 km per side, wind 28 km/h from the west. One side is a headwind, one a tailwind, and two sides are pure crosswind. On those crosswind sections at 26 km/h ground speed, yaw is atan(28/26) = 47°. Every deep wheel is stalled. Your effective CdA is up maybe 12% from a wheel perspective, plus you’re riding less aero because you’re bracing.

A calculator that resolves wind only into a head/tail component will tell you those two sides are free: no net headwind, hold steady power, fine. They are not free. They cost you roughly 15 W at target speed compared to still air, and they cost you more in concentration than in watts. If you’ve pre-committed your W’ to the headwind leg on the basis that the crosswinds are neutral, you arrive at the last 15 km with nothing.

The fix in practice: treat high-yaw sections as a 5% to 8% power penalty at fixed speed, and plan positioning rather than power. In a group, the crosswind sections are where the race is decided anyway, and no calculator models “third wheel in an echelon” for you.

The retrospective half

All of this is checkable, which is the part that separates it from advice. After the race, pull the .fit file into intervals.icu, look at the wind overlay, and ask a specific question: on the headwind leg, was my actual power within 5 W of plan, and did my speed match prediction?

Three failure modes show up:

1. Speed matched, power was low. Your CdA estimate is pessimistic. Re-run the Chung analysis.
2. Power matched, speed was low. Either CdA is optimistic, or the wind was stronger than forecast, or you sat up. Check the forecast against the station data.
3. Both matched, you still felt destroyed on the return leg. Your W’ constraint was too loose. Tighten the floor to 8 kJ next time.

That loop, forecast to plan to file to correction, is what turns a calculator into a coach. Two or three iterations and your CdA number stops being a guess.

What to do on Saturday night

Pull the forecast twelve hours out and again two hours out, because UK wind direction forecasts at 48 hours are close to worthless and the difference between 230° and 260° can move your plan by 40 seconds. Get the road bearings off the GPX. Feed both into something that resolves yaw properly, whether that’s Best Bike Split, MyWindsock, or a well-prompted model with your own numbers in it. Then write two numbers on your stem tape: the headwind target and the tailwind target.

If the plan on your stem is the same number twice, you’ve planned for a course that isn’t there.