AI Running

Teaching the Model to Periodise: Base, Build, Peak, Taper

Ask a chatbot for a sixteen-week marathon plan and you will get one in about ten seconds. It will look wonderful. Neat table, weekly mileage climbing, a taper at the end. Then you will run it, and somewhere around week nine you will notice that the numbers don’t quite add up to a plan that knows who you are.

I think the one-shot request is the wrong way to build an ai periodized training plan. The better method is slower and a bit fussier: prompt one phase at a time, state what that block is for, feed the result of each block back in, and only then ask for the next. Below I run both approaches on the same runner and show what comes out.

The runner

Sam is 38 and has a spring marathon in sixteen weeks. Recent Strava history, last eight weeks:

  • Average 34 km per week, peak week 41 km
  • Long run of 16 km, done twice
  • Three runs per week, one of them a hilly tempo-ish effort
  • 10K PB of 52:10 (Garmin estimates a marathon of about 4:15)
  • No injuries, but calves get grumpy above 40 km weeks

Goal: 3:55 marathon, which is about 5:34/km.

Attempt one: everything in a single prompt

The prompt:

Make me a 16-week marathon plan. I run 34 km a week, 10K PB 52:10,
goal 3:55. Four runs a week.

The weekly totals that came back (typical of what I get from both ChatGPT and Claude when asked this way):

Wk  km    Long   Note
1   40    16     Base
2   44    18     Base
3   48    20     Base
4   52    22     Base
5   56    24     Build
6   60    26     Build
7   64    28     Build
8   56    24     Recovery
9   66    30     Build
10  70    32     Peak
11  72    32     Peak
12  74    32     Peak
13  60    26     Taper starts
14  48    20     Taper
15  36    14     Taper
16  20    Race   Race week

Read it as a coach would. Week 1 is already 40 km, which is Sam’s previous peak week. The long run goes from 16 to 22 km inside four weeks. The “base” phase climbs 30% in total mileage in three weeks, which is not a base, it’s a ramp. There is no pace guidance beyond “easy” and “tempo”. And a 32 km long run three weeks running from a runner who has done 16 twice is the sort of thing that sends people to a physio in week 11.

The shape is plausible. The content underneath is a template. The model has produced the average marathon plan found in its training data, scaled up from a number you gave it.

Attempt two: one block at a time

Block 1: Base (weeks 1 to 5)

The prompt states what the block is for, not just how long it lasts:

Phase 1 of 4, Base, weeks 1-5. Goal of this block: raise weekly volume
from 34 km to about 46 km without any week rising more than 10% on the
previous one, and build the long run from 16 km to 20 km. No quality
sessions beyond strides and one gentle hill session. Keep a cutback
week in week 4. Calves flare above 40 km so flag any week where the
increase is mostly in one run. Four runs a week. Give me easy pace as
a range based on a 52:10 10K.

The output:

Wk  km   Runs                          Long
1   36   8 / 8 / 6 (hills) / 14        14*
2   39   8 / 9 / 6 / 16               16
3   43   9 / 10 / 7 / 17              17
4   36   8 / 8 / 6 / 14               14  (cutback)
5   46   10 / 10 / 8 / 18             18
Easy pace: 6:25-6:55/km

(*I’d trimmed week 1 to ease in. It also noted week 5 is +28% on the cutback week but only +6% on week 3, and suggested judging by the three-week trend.)

Spot the difference. Every number now traces back to a stated rule. The model checked its own increases because I gave it a ceiling to check against.

Block 2: Build (weeks 6 to 11)

Now I paste in what Sam actually did, because real life rarely matches the table. Sam missed one run in week 3 and averaged 6:40/km on easy days with a heart rate around 148 on the Garmin 255.

Phase 2 of 4, Build, weeks 6-11. Actual block 1: 35, 39, 40, 36, 44 km.
Easy runs averaged 6:40/km at 148 bpm (max HR 184). Goal of this block:
introduce marathon-pace work (5:34/km) and lift weekly volume from 44
to 58 km. One quality session a week, long run to 28 km with the last
6 km at marathon pace in weeks 9 and 11. Cutback in week 9... 

(In practice I’d place the cutback at week 10, so the 28 km run doesn’t land on a tired week. The model happily moved it when I asked why it had chosen week 9.)

The point here is the feedback loop. A one-shot plan assumes you ran every kilometre as written. This one starts from week 5’s 44 km, not the planned 46.

Block 3 and 4: Peak and Taper

Peak gets its own brief: two 30 to 32 km long runs at most, three weeks, volume capped at 64 km, race-specific sessions only (for example 3 x 5 km at 5:34/km with 1 km easy between). Taper is told to drop volume roughly 20%, 40% and 60% over the last three weeks while keeping some pace in the legs. A taper written with that instruction looks different from a taper the model invented: 52, 40 and 24 km before race week, with a final 8 km including 3 x 1 km at goal pace on the Thursday.

Side by side

One-shotPhase by phase
Week 1 volume40 km (Sam’s old peak)36 km
Largest weekly jump+12%+10% (stated cap)
Peak week74 km64 km
Longest run32 km, three times32 km, twice
Pace guidance“easy”, “tempo”6:25-6:55 easy, 5:34 MP, with heart rate
Adjusts to actual trainingNoYes, from block 2 on

The phase-by-phase plan is actually less ambitious on paper. That is the point. A plan that goes up to 74 km for a runner whose body has handled 41 is a guess dressed up as a schedule.

Why it works

A language model produces the likeliest plan for the words you gave it. “Sixteen-week marathon plan” is a very common phrase, and the likeliest continuation is the generic one. When you name a block’s purpose, a ceiling and a constraint, you shrink the space of plausible answers down to ones that fit you. Each block is also short enough that the model can hold the arithmetic together, which long tables are bad at.

Checks to run on any AI plan

Whichever way you generate it, test it against your own data before week 1:

  1. Week-on-week change. Over 10 to 12% is a flag. Sum it yourself.
  2. Longest run versus your recent longest. Aim for no more than about 10% longer than anything in the last month, except when you’ve had a cutback.
  3. Long run share. A long run above roughly 35% of the week for a four-day runner needs a reason.
  4. Hard days. No more than two sessions a week that you would not call easy, and not in back-to-back days.
  5. Stated paces against reality. Compare to your Strava pace on a recent 10K or a recent race result, not a calculator’s optimism.

If a plan fails two of these, send it back with the numbers in the prompt.

The cost

It takes five prompts rather than one. You’ll spend maybe forty minutes in total across the sixteen weeks, and you’ll need to paste in your real weeks at each handover. If that’s too much, a one-shot is better than nothing, but treat it as a rough draft and run the checklist above.

If you want the prompt templates, the data to paste in and the handover wording I use for each block, they are in Building Your Own Plan With ChatGPT and Claude. Take block 1, run it this weekend, and compare week 1 against what your watch says you did last week.