Feeding the Model Your Strava History Without Feeding It Junk
There is a specific failure mode that happens when a runner first asks ChatGPT or Claude to look at their training. They export everything, paste 900 lines of activity data into the chat, and ask “am I ready for a sub-4 marathon?” The model responds with something that sounds authoritative, cites a few of their runs by name, and produces a plan that is quietly wrong. Not obviously wrong. Wrong in the way that only shows up in week seven when the calf goes.
The reason is boring and mechanical: you gave the model a haystack and asked it to describe the farm.
What actually happens when you paste a raw export
Strava’s bulk export gives you activities.csv, and it is not built for reading. Mine has 96 columns. Here is a single row, trimmed to the fields you can actually see:
Activity ID,Activity Date,Activity Name,Activity Type,Elapsed Time,Distance,Max Heart Rate,Relative Effort,Moving Time,Average Speed,Elevation Gain,Average Heart Rate,Calories
10284719355,"Jul 14, 2026, 5:42:11 AM",Morning Run,Run,3241,8.04,178,64,3198,2.514,43.0,151,612Note Distance is 8.04, but is that kilometres or miles? In the CSV it’s kilometres. In the column labelled Distance further right in the same file, it’s metres. Elapsed Time is seconds. Average Speed is metres per second. There are columns for Dirt Distance, Newly Explored Distance, Bike Weight, and Perceived Exertion, most of which are empty.
Now multiply by 84 rows for twelve weeks of running. You have handed the model roughly 40,000 tokens of mixed-unit, mostly-empty tabular data and asked it to infer a training pattern. Three things go wrong.
The model spends its reasoning budget on parsing rather than on training logic. It has to decide what the units are, reconcile Moving Time against Elapsed Time, and work out which of your “Morning Run” entries was an interval session. That is attention you wanted spent on whether your long run progression is sane.
Long-context recall degrades in the middle. Models are reliably better at recalling material near the start and end of a long input. Your week-six mileage spike, sitting in the middle of the dump, is exactly the thing you needed it to notice, and it is exactly where recall is weakest. You will get a plan built around your most recent three weeks and your first two, with a blind spot over the part that matters.
And it will hallucinate arithmetic. Ask a model to sum 84 distance values and it will produce a number that looks right and is off by 15 kilometres. I have watched this happen with a weekly total that should have been 52 and came back as 47. The plan that followed was built on the wrong base.
The ten-line table that fixes it
Here is the same twelve weeks, condensed. This is what I actually paste:
Athlete: 41F, 5K PB 24:18 (Mar 2026), HM PB 1:52:40 (Oct 2025)
Goal: Marathon, 14 Apr 2027, target 4:05
Current plan: Runna marathon 16wk, week 4 of 16
Wk | Dates | km | Runs | LongRun | Quality sessions | Avg RPE | Notes
1 | 07-13 Jul | 38 | 4 | 14 km | 1 (6x800 @ 4:35/km) | 4.2 |
2 | 14-20 Jul | 42 | 4 | 16 km | 1 (tempo 20min @ 5:10) | 4.5 |
3 | 21-27 Jul | 45 | 5 | 18 km | 2 (8x800, tempo 25min) | 5.1 | R calf tight after wk3 long
4 | 28-03 Aug | 30 | 3 | 12 km | 0 | 3.8 | cutback, calf niggle
5 | 04-10 Aug | 44 | 5 | 18 km | 1 (tempo 25min @ 5:08) | 4.6 |
6 | 11-17 Aug | 52 | 5 | 21 km | 2 (10x800, 3x2km @ 5:00) | 5.4 | poor sleep all week
7 | 18-24 Aug | 55 | 5 | 24 km | 2 | 5.6 |
8 | 25-31 Aug | 38 | 4 | 16 km | 1 | 4.1 | cutback
9 | 01-07 Sep | 58 | 6 | 26 km | 2 (12x800, tempo 30min) | 5.9 |
10 | 08-14 Sep | 61 | 6 | 28 km | 2 | 6.1 | HR drifting on easy runs
11 | 15-21 Sep | 64 | 6 | 30 km | 2 | 6.3 | legs heavy Thu+Fri
12 | 22-28 Sep | 46 | 5 | 22 km | 1 | 4.8 | cutback
Easy pace: 6:20-6:45/km, avg HR 142-149
Threshold pace: 5:05-5:15/km, avg HR 168-172
Max HR observed: 184. Resting HR: 52 (was 48 in July).
Longest run in last 12 weeks: 30 km. Longest ever: 32 km.
Constraints: 5 runs/week max, no Wednesdays, treadmill only in winter.That is about 450 tokens. It is not a lossy summary in the sense that matters. Every decision a coach would make about the next block is visible: the trend, the cutback rhythm, the quality-session load, where the niggles clustered, the pace-to-heart-rate relationship, and the constraints.
Paste that and the model can reason instead of parse. Ask “is my long run progression safe?” and it can see 14, 16, 18, 12, 18, 21, 24, 16, 26, 28, 30, 22, notice the jump from 21 to 24 to 26 landed in weeks where RPE was already climbing, and say something useful about it. Ask the same question of the raw CSV and you will get a paragraph about general principles of progressive overload.
Building the table without spending your Sunday on it
Go to strava.com/athlete/delete_your_account (yes, really, that is where the export button lives, and no, clicking through to the export page does not delete anything). Choose “Request your archive”. Strava emails you a zip within a few hours. Open activities.csv.
The columns you actually need: Activity Date, Activity Type, Distance, Moving Time, Average Heart Rate, Elevation Gain, and Perceived Exertion if you log it. Delete everything else. Filter Activity Type to Run. Cut to the last twelve weeks.
Now add a Week column. In Google Sheets, if your dates are in column A, something like =ISOWEEKNUM(A2) gets you there, then pivot on it: sum of distance, count of runs, max of distance for the long run. Ten minutes of spreadsheet work, once.
Two shortcuts if that sounds tedious. Garmin Connect’s Reports view already gives you weekly totals: Reports, then Running, then set the range to twelve weeks and it shows distance per week directly. Read the numbers off and type them in. Or, if you would rather not touch a spreadsheet at all, paste your trimmed seven-column CSV into the model and ask it to produce the weekly table, then check the totals against Strava’s own weekly view before you use it. Do check. This is the one step where the model’s arithmetic is load-bearing, and verifying twelve sums takes ninety seconds.
The Notes column is the part no export will give you and the part that changes the answer most. “Poor sleep all week” next to a 52 km week with RPE 5.4 is a completely different data point than 52 km at RPE 5.4 after a good week. Write those in from memory. You remember them.
What to actually ask once the table is in
The table is the input. The question is the other half, and vague questions waste a good table.
Weak: “Does my training look good?”
Better: “Given the table above, my long run went 26, 28, 30 in weeks 9-11 while average RPE went 5.9, 6.1, 6.3 and resting HR rose from 48 to 52. I have 28 weeks until the marathon. Is the rate of increase in long run distance appropriate, and what specifically would you change about weeks 13-16?”
The second question gives the model something to disagree with. It can tell you that a 4 km jump in long run distance across two weeks while resting heart rate climbs 8% is the pattern that precedes a stress injury, and that the fix is to hold at 28 km for two weeks rather than to cut mileage. Or it can tell you the trend is fine and the resting HR shift is probably the August heat. Either answer is checkable against how you feel on Thursday.
A few more that produce real answers from this format:
“My easy runs average 6:20-6:45/km at HR 142-149 and my threshold work is 5:05-5:15 at 168-172. That is a 75-second gap between easy and threshold. For a 4:05 marathon goal, is my easy pace too fast, too slow, or about right?”
“Runna has me doing two quality sessions a week at 64 km. Based on the RPE trend in weeks 9-11, should I be doing two or one?”
“Rewrite weeks 13-16 as a four-week block, 5 runs per week, no Wednesdays, peaking at 68 km with a 32 km long run in week 15. Give me distances and paces per day.”
That last one is where the summary pays off most, and it is the workflow covered in more depth in Building Your Own Plan With ChatGPT and Claude if you want to go from auditing a plan to generating one.
The things people get wrong with the summary too
Averaging away the shape. If you condense twelve weeks to “averaged 48 km/week, longest run 30 km”, you have deleted the information. 48 km every week for twelve weeks and 48 km averaged across a 30-to-64 swing are different athletes with different injury risks. Keep the weeks separate.
Leaving out the cutbacks. I have seen people delete their down weeks because they look like failures. Weeks 4, 8 and 12 in the table above are the load-management structure. A model that cannot see them will assume you never recover and will either build a plan that is too conservative or flag a problem that does not exist.
Rounding paces into uselessness. “Easy runs around 6:30” is fine. “Easy runs, about a 6 minute something pace” is not, because the whole easy-pace question turns on 20-second differences.
Hiding the injuries. The calf niggle in week 3 is the single most decision-relevant line in that table. A plan that ramps calf-loading work in week 14 is a different risk for you than for someone with a clean twelve weeks. Put it in, including the ones that resolved.
Giving it your watch’s opinion instead of your data. Garmin’s Training Status, VO2 max estimate and Race Predictor are derived numbers with their own assumptions baked in. Passing “Garmin says my VO2 max is 46 and predicts a 3:52 marathon” to the model adds a layer of someone else’s model output to reason over. Include it if you want, labelled as such, but the weekly volume and the heart rate ranges are the load-bearing inputs.
One more pass before you trust the plan
When the model returns weeks 13-16, check three arithmetic things yourself. Does each week’s daily distances actually sum to the weekly total it claims? Is the week-on-week increase under about 10%, and if it is over, did it say why? Does the long run as a fraction of weekly volume stay under roughly a third?
Models get these wrong at a rate that is low enough to be dangerous. A plan where week 14 claims 66 km and the days add to 71 is the kind of error you will only find by adding it up, and it is your legs that absorb the extra five.
Keep the summary file. Update it every Sunday night with one new row, drop the oldest. Four weeks from now you paste the same format with weeks 5-16 and ask what changed, and the model is looking at a consistent record instead of reconstructing your season from scratch every time you open a new chat.