I’m having an interesting result after asking to “assess today’s ride execution”, even providing the ride’s ID.
I’m not able to get it working, it’s ignoring the ride on Intervals.icu. Any advice on why this might be happening? What you see on the screenshot is an hallucination, I believe.
Hi amteza,
Apologies and thanks for spotting this issue, it’s been on my to do list and now fixed. You can now ask for to
Alternative commands are:
“load last activity”,“analyse last activity”,“analyze last activity”,“deep dive last activity”,“full activity analysis”,“break down yesterday’s activity”,“detailed activity analysis”
It will give you a response like this 
Here is your Montis activity analysis for
Canicross trail run with Otto (i123456789)
TRAINING LOAD
Session load: 69 TL
Intensity: IF 1.05 → above threshold session
Strain score: 130 → moderate–high stress for durationStructure
Short session (~39 min) but high density
Significant time in Z4–Z6 (threshold → anaerobic)
Repeated spikes:
- 56s @ 433W
- 58s @ 485W
- 4m49 @ 383W
- Late-session efforts still high
This is not an easy run — it’s a neuromuscular + VO2 mixed stimulus
Load interpretation
- High intensity per minute
- Low volume → targeted stimulus, not fatigue accumulation
Good for:
- VO2 stimulation
- Neuromuscular recruitment
- Uphill strength (trail context)
PHYSIOLOGY RESPONSE
HR avg: 126 bpm
HR max: 145 bpm (well below LTHR 157)Key insight:
Cardio response is suppressed relative to power
This is classic for:
- Trail running variability
- Canicross assistance dynamics
- Neuromuscular-dominant work
Decoupling: ~9.5%
- Slightly elevated for short session
- Late-session drift visible
- Fatigue accumulation > aerobic limit
- Not a pure endurance limiter
PERFORMANCE INTELLIGENCE
1. Repeatability
Strong early spikes:
- 433W → 485W
Mid-session:
- 383W sustained (4m49) → very solid
Late session:
- Still producing 332–345W efforts
But:
- W′ depletion high (~26.9 kJ max depletion)
2. Durability (key signal)
Late-session markers:
- 332W block → decoupling 12.6%
- HR rising relative to output
- Slight drop in control vs earlier efforts
This answers directly one of your core questions :
Are you maintaining efficiency late in the session?
3. Pacing & Control
Variability index: 1.12
→ Moderately stochastic (expected on trail)However:
- Efforts are intentional, not random
- Good clustering of hard efforts
ADAPTATION SIGNAL
What this session develops
Strong stimulus to:
- VO2 system
- Anaerobic capacity (W′ usage)
- Muscular strength (trail + dog resistance)
Limited stimulus to:
- Aerobic base stability
- Long-duration durability
System balance
From your question bank :
Which system is limiting?
- You can produce power
- You can repeat efforts
- But efficiency fades under sustained load
COACHING DECISIONS
1. This was a high-quality session
Keep it.
But understand what it is:
2. Key improvement target
You need sessions where:
- Power stays sub-threshold
- HR stays stable
- Duration is extended
3. Immediate recommendation
Add one of these next:
Option A — durability builder
- 60–75 min
- 75–85% FTP steady
- Minimal surges
Option B — controlled tempo trail
- Same terrain
- Cap efforts at ~90% FTP
- Focus on smooth output
4. Intensity management insight
You are currently:
- Very capable of high output
- Slightly biased toward over-activating W′
- Turning many sessions into “hidden hard days”
Bottom line
- Excellent repeatability
- Strong VO2 / anaerobic capacity
- Good control of high-intensity efforts
- Durability (efficiency fades late)
- Add controlled aerobic work to convert power into sustainable performance
Amazing!!! Thanks heaps, Clive. Some extra beer/coffee heading your way, enjoy!
@Clive_King, sorry mate, still does not work, not even with old activities. I thought it might be because it is a long ride (over 5 hours). It looks like something else is going on. See the following snapshot:
Very different from your example.
Is there anything else I need to do?
For some reason the problem is that it does no talk to your backend anymore. Weird.
love ChatGPT sometimes! OK I tried the same command request in a new chat and it works fine.
As I updated the schema, you may need to refresh the chat conversation (if in browser) or start a new chat in the Montis GPT app. I have noted it can take a time to refresh in mobile and desktop app sometimes.
Tbh, just ask “load last activity from today / yesterday” is easier 
Please be aware that long chats can completely lose context and even forget what it does. “Start over” can help but long chats can be troublesome in a browser (and slow).
Clive
Hi Clive,
Hi, I’m following a program managed by your app to get in shape for the summer.
Sometimes the AI goes off track.
Are there any specific commands to prevent this from happening?
Thanks a lot
Gigi
Clive,
Love the new commands list. Really useful.
I have been hitting some minor sticking points lately. Minor as I say but mainly related to AI confusion over ISO weeks. It doesn’t seem to recognise ISO weeks every time I ask? Is that normal?
I also review my next week’s training after I finish my current week and I find that sometimes, unless I’m really specific about what I type, it doesn’t pull the next week’s calendar and review whats on there, it just spits out a recommended week.
Finally, in relation to training review, i find that it sometimes loses track of the bigger picture when I’m asking it to review training. I have my phases added as notes with dates etc but it sometimes ignores them and again spits out a generic week instead of looking at where we are in the macro cycle and when we’re moving to the next phase etc.
Is this just me or can you recommend a specific order in which to ask the correct questions to make sure my training is appropriate as I approach my target event.
Still loving it and as I said these are just minor frustrations!
Al
Well that depends on the question, I find that as long as you have the latest report loaded it normally responds based on those facts returned (those are the rules). Remember I dont expose all the data in the report, but ChatGPT has it in the background.
So, for example, after a weekly report loads you can ask what commands to ask and it will show the context.
e.g. what command questions can i ask for this report ?
Here are the most useful command questions you can ask based on your current weekly report. I’ve grouped them so you can quickly pick what to explore next.
TRAINING LOAD & FATIGUE
Focus: You’re in a productive but slightly rising fatigue state
evaluate fatigue stateassess training straincheck training balanceevaluate training monotonycheck load variabilityevaluate load progression
Focus: Stable HRV but slight fatigue accumulation
evaluate recovery statusevaluate readiness todaycheck HRV trendsanalyze resting heart rateassess sleep impact
Focus: Durability drift + low anaerobic load
analyze decoupling trends←most relevant
evaluate heart rate driftassess efficiency factorreview intensity distributioncheck intensity densityreview high intensity days
Focus: Aerobic building, VO₂ declining
assess aerobic developmentassess VO2 progression←identify weak systemsidentify strengthsassess adaptation state
Focus: Maintain structure + add VO₂ + manage durability
adjust next week training←plan next microcycleoptimize weekly plansuggest VO2 workoutsuggest endurance sessionsuggest recovery strategy
NUTRITION (CRITICAL THIS WEEK)
Focus: Severely underfuelled
check fueling adequacy←analyze carbohydrate needsoptimize fueling strategy
If you want to go deeper into this exact week:
analyze training blockcompare recent weeksanalyze performance trendsshow training load detailsshow performance intelligenceshow adaptation insights
RECOMMENDED NEXT 3 COMMANDS
If you want the smartest progression from this report:
check fueling adequacyanalyze decoupling trendsadjust next week training
If you want, I can guide you interactively (like a coach) and pick the next best command step-by-step.
Thanks for the feedback Alan! commands are good - helps me too!
For an ISO weekly report i think you mean, if you ask run a weekly report for the current ISO, it will show from Mon-Sun of the current ISO week, as opposed to 7 days rolling. If you are asking for ISO week historically say run a weekly for ISO #12 it will show Period: 2026-03-17 → 2026-03-22.
Since I now changed that calendar planned events is now longer in the weekly report, ask for “future planned events” after a current weekly report is loaded and it will then do a query and show these. you can say next 14 days (longer can break the payload response, but it will tell you that). ADDED new lite option
To review the bigger picture always ask for run a season report this then takes into context the phases over 90 days (the pertinent training period). The weekly report returned does not show phase macrocycle over last 90 days (I had to remove this to reduce the growing weekly payload), but the whole report has used 90 day context for its intelligence, so if you want to plan from there, weekly and season combined provide a good basis for looking ahead at what’s needed.
Regards recommend a specific order of questions, this is why I prompt the command questions feature. But a really useful feature now I added is to ask this → what command questions can i ask for this report ? this illustrates the questions well. e.g. here (Yet Another) AI ChatGPT Coach - #235 by Clive_King?
What i mean is that if i ask: “review planned training for iso week 14 or week 15”, it often uses the current week. I then have to specify dates to get it to recognise that week 14 commences on that date and is not the current week. Minor.
Ok this is useful and I’ll be sure to do that from now onwards. Thanks! I guess that you’re limited by data size hence why you recommend 14 days but what I want is the ability to ask the coach to take into account the long term picture and basically give me the ability to sketch out a rough plan between now and my event which is on June 28.
Noting the limitations of the system how can I best do that, or am I being unrealistic? I’m new to self coaching so maybe needing some reassurance!
ISO week will be determined by ChatGPT to it should pass ISO-8601 dates. This was my test using same command.
For the longer planned events view let me have a look to see if we can get a lite view added to reduce payload for each event. That way you will see all the way to June 28.
Clive
Noted, it worked. Thanks, Clive.
Now added “lite option”.
you can ask for load planned events for next 30 days lite and it will show events with core fields only:
"id", "start_date_local", "type", "moving_time", "category", "name", "icu_training_load", "icu_atl", "icu_ctl"
Payload is much reduced for larger retrievals.
Full Command tool list is (these can be asked in natural language or tool name)
- **Weekly report** → short-term performance review + lite
- **Season report** → current training block progression + lite
- **Wellness report** → recovery and fatigue status
- **Summary report** → long-term training trends
- **Data quality report** → audit and integrity checks
- Analyse activity {id} → full session breakdown with intervals and metrics
- Get activity by date → retrieve all activities for a given day
- Get power curves → peak power modelling across durations
- Get HR curves → heart rate response across durations
- Get power-HR curve → relationship between power and heart rate
- Get pace curves → pace profiling across durations
- Get MMP model → maximal mean power model and fatigue profiling
- Get training plan → structured upcoming training schedule
- Get wellness data → HRV, fatigue, and recovery signals
- Read calendar → view planned workouts and events + lite
- Write calendar → create planned workouts
- Delete calendar → remove planned workouts or events
- Get athlete profile → athlete configuration and settings
- Send message to coach → interact with coaching assistant
runWeeklyReportV2(test?: string, lite?: boolean, start?: string)
runSeasonReportV2(lite?: boolean)
runWellnessReportV2()
runSummaryReportV2(start?: string, end?: string)
runDataQualityReportV1()
readCalendarV1(start: string, end: string, lite?: boolean)
writeCalendarV1(planned_workouts: [{ date: string, title: string, tss?: number, duration_minutes?: number, carbs_per_hour?: number, notes?: string }])
deleteCalendarV1(id?: any, date?: string, dates?: string[])
listActivitiesLight(oldest?: string, newest?: string, fields?: string)
getOneDayFullActivityV1(date?: string, activity_id?: string)
getOneDayWellnessV1(date: string)
getPowerCurvesExtV1(type: "Ride" | "Run" | "VirtualRow" | "VirtualSki" | "Swim", curves?: string, pmType?: "MS_2P" | "MORTON_3P" | "FFT_CURVES" | "ECP")
getPaceCurvesExtV1(type: "Run" | "Swim", curves?: string)
getHRCurvesV1(curves?: string, type?: "Ride" | "Run" | "Swim")
getPowerHRCurveV1(start: string, end: string)
getMMPModelV1(type?: "Ride" | "Run" | "Swim")
getSportSettingsV1()
getAthleteProfileV1()
getAthleteTrainingPlanV1()
sendChatMessageV1(content: string, chat_id?: string, to_athlete_id?: string, to_activity_id?: string)
Clive
Nailed. It. Just tested in on my next 4 weeks of training. Exactly what I was after. Perfect!
Added
Fixes
getonedayfull parameters (supports activity ID or date)Refactored
Changes
Full details here Change Note Week 13 · Issue #36 · revo2wheels/intervalsicugptcoach-public
Hey @Clive_King ,
first of all, I want to thank you for your amazing work. Seems to work very well, I’m having a great time with it!
I’m a total beginner in cycling so I’m not sure if I should even use it yet as the stats look very advanced. I’m also a total stats nerd though 
I have a question regarding my first 7 day report. There report mentions this:
It says I’m accumulating fatigue. However, in the fitness diagram on intervals everything looks fine as I’m in the green zone (optimal). According to the diagram the optimal zone is between -10 and -30.
When asking GPT to explain deeper, it says that TSB below -15 is too much fatigue.
Why do the explanations not match the “green” zone in the intervals diagram for me?
Thanks for your help and keep up the great work!
hey Sprinz87
TSB and Fatigue Trend measure different things: TSB is a snapshot of how fresh or fatigued you are right now, while Fatigue Trend shows whether fatigue is building or reducing over time.
Having some accumulated fatigue is actually essential, not harmful—it’s the signal your body uses to trigger adaptation.
The goal isn’t to avoid fatigue, but to build it gradually while staying functional, then allow recovery so your body can adapt and improve.
Fatigue Trend is a trajectory metric (direction of fatigue over time);
Compares 7-day load vs 28-day baseline
What it tells you:
Positive → fatigue is building
Negative → fatigue is reducing
Around 0 → stable
I hope that helps.
Clive
So if I understand correctly:
TSB shows current fatigue (I’m at -18, so fairly fatigued)
Fatigue Trend shows that fatigue is currently building
The green zone is a general guideline, but doesn’t account for my low CTL yet
So even though I’m in the green zone, my current fatigue might still be high relative to my fitness, which is why I see signs like HR drift and reduced efficiency.
I just let GPT create the workouts for next week in Intervals icu according to the report and synced them to Zwift. Will report back in a week how it went and what the results in the next weekly report are. Thanks again, really happy I found this 
A post was merged into an existing topic: IntervalCoach - AI workouts that adapt daily to your recovery and goals
Looking at you recently 90 day you have limited data, I recall something like 11 activities.
As an athlete who has just started on the training curve your fatigue will be higher than normal as you have a limited baseline, this reflects the truth. You are under load pressure, you need to be build slowly to adapt to the increasing load trend.
Your report signals will soon tell you otherwise, if you train with Power you will start to see durability drift and then maybe also a surpressed HRV. In ADE decisions there is a simple two step guideline, keep loading or seek recovery, it will soon tell you 
The good news is that the bell curve is your advantage now, you will see strong gains at the start before it gets harder to improve depending on your planned and execuuted workload. 
Keep going!, ask the coach all these questions, it has the data to help you plan and build. It can also explain every metric and signal, I provide all the context and science backed formulas to AI.
for example:
Fatigue Trend in your report is primarily based on the Banister Model (TRIMP framework) — the same foundational model behind CTL, ATL, and TSB.
- Banister Model
Developed by Eric Banister
Describes performance as the balance between:
Fitness (chronic load)
Fatigue (acute load)
Exponentially Weighted Moving Averages (EWMA)
Used in modern platforms (like Intervals.icu)
Gives more weight to recent training
7-day load = “acute fatigue”
28-day load = “baseline fitness”
Fatigue Trend =
Load Progression Theory (modern coaching)
Also aligned with:
Acute:Chronic Workload Ratio (ACWR)
Progressive overload principles
Whether you are building stress
Or recovering / deloading
In simple terms
Fatigue Trend is:
A modern extension of the Banister model that tracks how quickly fatigue is changing, not just how much you have.
Br
Clive
Hi All,
From today we finally move Montis.icu to ADE v2 (What Changed and Why It Matters)
Please note that in order to incorporate this we have made some changes to how phases are determined (for the better!) - This has not been an easy change to deliver, and I’ve spent more in time research and planning, than actually make it happen
To get the best from the system create some future events in your Intervals Calendar. We use the projected forecast phase as part of the alignment for where you are headed.
1) What the ADE system actually is
ADE v2 is not guessing or “AI coaching.”
It is a rules-based decision layer built on established physiology.It combines:
- Load response (fatigue vs fitness)
- Risk detection (monotony, strain)
- Block structure (when to stop pushing)
- Performance timing (when to absorb training)
→ In simple terms:
It decides when to push and when to stop — not just how much.
Layer 1 — Phase (Strategy)
What your training should be doing
- Build
- Deload
- Taper / Recovery
This is based on pattern over time, not today’s numbers.
remember that
- Base → just early Build
- Peak → outcome of taper, not a control state
What your body can handle right now
- ACWR
- Fatigue trend
- HRV / recovery
- Load balance
What changed
Previously:
- Metrics could dominate
→ “You look fine → keep loading”Now:
- Phase can override metrics
→ If your system detects accumulated fatigue:
- It advises recovery, even if numbers look acceptable and you can accept more load
Why this matters
Because endurance training fails in one specific way:
You keep training because you can — not because you should
This leads to:
- Delayed adaptation
- Durability decline
- Hidden fatigue accumulation
- Plateau and loss of adaptation
ADE v2 stops that loop
What the science is doing (translated)
- Banister → detects fatigue vs fitness balance
- Foster → detects risky load patterns
- Issurin → defines when a block must end
- Seiler → separates execution vs strategy
- Mujika → proves recovery drives performance
→ ADE v2 combines these into one rule:
When fatigue outweighs adaptation → stop pushing
Not:
- Stopping training
- Losing fitness
But:
- Reducing load so adaptation can occur
This includes:
- Recovery weeks
- Deloads
- Tapers
→ Same physiological purpose:
Absorb the work you’ve already done
What this means in practice
Phase: Fatigue accumulation → recovery required
Load: High (≈710 TSS)
Metrics: Acceptable (ACWR ~1.08)But:
- Fatigue rising
- Durability drifting
Metrics say continue → Phase overrides → Recover
Where this fits in the Montis Intelligence Stack inside reports
Macrocycle └── Phase (goal) └── Mesocycle (structure) └── Microcycle (execution) └── Sessions (events) Summary = Macrocycle Season = Mesocycle (90-day multi-phase block) Weekly = Microcycle + inferred phase state
- Phase = strategic control
- ADE = operational control
→ And now:
Strategy (phase) overrides execution (metrics)
Links to the performance engine
Montis already measures:
- Durability (ISDM) → fatigue drift over long sessions
- Anaerobic repeatability (WDRM) → supra-threshold stress
- Neural load (NDLI) → intensity clustering
These are not just metrics — they are early warning signals
ADE v2 uses them to:
- Prevent overload before it becomes visible
- Block intensity when repeatability drops
- Force recovery when durability degrades
Bottom line (coaching version)
Metrics answer:
→ “Can you train more?”Phase answers:
→ “Should you train more?”
“Should” always wins over “can.”
The system does not optimise just load.
It optimises timing of adaptation.That is the difference between:
- Training more
- And actually improving
How it works in practice ; I did an Everest basecamp this last weekend (5365m) and because of this large load spike, I’ve had to realign my planned week ahead from “build” to “deload” based on its guidance.
Planned phase: Build
Actual trigger: Large load spike (Everest Base Camp effort)→ Acute fatigue exceeds planned progression
Build → Deload
Why:
- Load spike not planned in progression
- Fatigue now dominates adaptation window
Override weekly plan → reduce load to absorb effort
Give me feedback as always; hope it works for you!
Top tip. After a weekly or season report ask Show full ADE 
Clive
