How to turn the Garmin Fenix 9 into a Self-Coaching Machine with Claude

Sorted Pixels，From the desk of Tommaso Nervegna, an ongoing exploration of design, technology, and human creativity.关注

Garmin announced the fēnix 9 and fēnix 9 Pro on August 25, 2026. Nine hundred and ninety nine dollars for the base model, eleven hundred for the Pro with the titanium case, the 3,000 nit AMOLED and inReach satellite. The press release is a good one. Stamina zones and a stamina curve. Indoor rowing VO2 and power. Expanded rucking. A new activity grouping feature they’re calling Garmin Epic.

Read the release again and notice what is not in it. There is no AI coach. There is no assistant. There is nothing that looks at the eighteen months of physiological data already sitting in your Garmin Connect account and says a single interesting sentence about it.

Garmin’s AI, such as it is, lives somewhere else. It’s called Active Intelligence, it launched in March 2025 as part of Connect+, and it costs $6.99 a month on top of the thousand dollar watch. It produces the kind of insight you get from a fortune cookie. Your Body Battery was low yesterday. You slept less than usual. Consider recovery.

I want to be precise about the criticism, because it isn’t that Garmin is bad at this. It’s that Garmin is structurally incapable of being good at this. Active Intelligence can only see Garmin data. It cannot see your calendar. It cannot see that you were in Milan on Tuesday and Zurich on Wednesday. It doesn’t know you had three glasses of wine at the client dinner, or that the Thursday deck went to 2am, or that you’ve been fighting something since the flight. Every genuinely useful observation about your body lives at the intersection of your physiology and your life, and the vendor only owns one half of that.

You own both halves. That’s the whole thesis. The sensor company builds the sensor. You build the intelligence layer.

Here’s how.

What your watch already knows

Before the plumbing, the inventory, because the reason this is worth an hour of your Saturday is the sheer density of what’s already been recorded.

A modern Fenix writes into Garmin Connect: sleep stages and a nightly sleep score, overnight HRV status, Body Battery, Training Readiness, Training Status, VO2 max, all day stress, resting heart rate, steps, recovery time, acute and chronic training load, Endurance Score, Hill Score, respiration rate, wrist temperature, Pulse Ox, ECG on supported models, and a full FIT file for every activity with per second heart rate, pace, power and running dynamics.

Body Battery and Training Readiness are built on Firstbeat Analytics models, which Garmin bought in 2020. You cannot get those numbers from anyone else. That matters later.

So the data is there, it’s longitudinal, and most of it has never been looked at by anything smarter than a dashboard widget.

The part where Garmin makes this annoying

Garmin has no personal API. I want to state that plainly because a lot of tutorials dance around it.

The Garmin Connect Developer Program is real, and it’s good, and you cannot have it. The Health API, the Activity API, the Training API, all of them require you to apply as a legal entity. A company, a university, a hospital, a research institution. Personal use applications get rejected. Commercial use of the Health API requires a license fee, and third party reports put the one time administrative setup somewhere around five thousand dollars, though Garmin doesn’t publish pricing. Approval takes one to four weeks.

This is why an entire cottage industry of workarounds exists, and why that industry periodically catches fire. Which brings me to the thing you need to know before you install anything.

In March 2026, Garmin changed its SSO login flow and broke almost every unofficial tool at once. Around March 16, the scrapers stopped working. On March 27, garth, the authentication library that basically everything depended on, was formally deprecated at version 0.8.0. For about two weeks the entire community was dead in the water.

It got fixed. cyberjunky shipped python-garminconnect 0.3.0 on April 2 with a rewritten native authentication engine that uses the mobile SSO flow and handles Cloudflare via TLS impersonation. It’s at 0.3.11 as of August 19, 2026, and it’s actively maintained. Nearly every Garmin MCP server you’ll find is sitting on top of it.

The lesson is not “don’t do this.” The lesson is: build so that a broken login costs you live sync, not your archive. I’ll come back to that.

The five routes, ranked

  1. Manual export into a Claude Project. Zero code, fifteen minutes, good for a one off retrospective. Tedious as a habit.
  2. GarminDB into local SQLite, analyzed by Claude Code. Moderate setup, best privacy, best power, survives auth breakage. This is the one I actually run.
  3. A community MCP server. Best for conversational access. Depends on the fragile login.
  4. Official Health API plus a custom MCP server. Enterprise only. Not for you.
  5. Aggregators like Terra or Spike. They normalize a dozen wearables behind one API. Overkill for personal use, and it puts a third company inside your health data.

Do 1 to find out if you care. Then do 2. Add 3 if you want to chat with it.

Route 1: the fifteen minute version

Two things, in parallel.

First, go to garmin.com/account/datamanagement/exportdata and request your full archive. This is your GDPR data portability right, it’s completely within terms, and it contains everything: every FIT file, sleep, stress, Body Battery, the lot. It arrives by email as nested zips. Garmin doesn’t document the turnaround, so assume a day or more, and grab it fast because the link expires.

Second, while you wait, don’t wait. Open any activity in Garmin Connect and export it as TCX, which is the friendliest text format for a single workout. The activity list also dumps a summary CSV. Drop a month of that into a Claude Project along with a plain text file where you write, honestly, what your life looked like. Travel days. Drinking days. Deadline weeks. Illness. Two lines per day is enough.

Then ask something the Connect app structurally cannot answer:

Correlate my sleep score, HRV and Body Battery against the annotations in life-log.txt. Group the days by annotation type and show me the mean and spread for each. Where the sample is too small to say anything, say so.

That last sentence matters more than you’d think. We’ll get to why.

If the answer makes you sit up, keep going. If it doesn’t, you’ve spent fifteen minutes and you’re done.

Route 2: GarminDB plus Claude Code, which is the real answer

This is the setup worth having, and it’s worth having specifically because your data never leaves your machine. Claude reads what it needs, computes on it locally, and sends back analysis. The raw archive stays on your disk.

Install it:

bash

pip install garmindb

Configure credentials. GarminDB reads from ~/.GarminDb/GarminConnectConfig.json. The file it ships with has a credentials block for your Garmin email and password, and a data block where you set your start dates so it knows how far back to pull.

Then do the initial full download, which will take a while the first time:

bash

garmindb_cli.py --all --download --import --analyze

After that, incremental updates are cheap:

bash

garmindb_cli.py --all --download --import --analyze --latest

What you get is a set of SQLite files under ~/HealthData/DBs: monitoring, activities, sleep, resting heart rate, weight. You can poke at them with DB Browser for SQLite to get your bearings, but you don’t need to.

Now the good part. Open a terminal in that directory and run Claude Code. It can read the files, write SQL, write Python, run it, and hand you back charts and reports, all locally.

Before you ask it anything, give it a CLAUDE.md in the project root. This is the single highest leverage thing in this entire article:

markdown

# Rules for this project

This directory contains my Garmin health data as SQLite databases.

- Never estimate, eyeball, or recall a number. Every statistic you state
  must be computed by SQL or Python that you actually run in this session.
- Show the query or the code alongside the result.
- Report sample sizes. If n is small, say so before you interpret.
- Distinguish correlation from causation explicitly, every time.
- You are a training and recovery analyst, not a physician. Flag anything
  that looks clinical and tell me to see a doctor. Do not diagnose.
- Prefer trends over absolute values. The sensors are noisy.

Every serious version of this setup in the wild converges on some form of rule one, and there’s a good reason. Ask a language model for a mean in prose and it will produce a plausible number with total confidence. Ask it to compute the mean in Python and show you the code, and it produces a correct number. The difference between this being useful and this being dangerous is almost entirely that one instruction.

Note also what you’ve just built: an archive that keeps working when Garmin next changes its login. The download breaks, the analysis doesn’t.

Route 3: an MCP server, for when you just want to ask

If you want to talk to live Garmin data from the Claude app rather than a terminal, use a Model Context Protocol server. Three worth knowing, all read via python-garminconnect or its equivalent:

Run it as a local stdio server, which means it executes on your machine and your credentials never travel. Edit claude_desktop_config.json, which lives at ~/Library/Application Support/Claude/ on macOS and %APPDATA%\Claude\ on Windows:

json

{
  "mcpServers": {
    "garmin": {
      "command": "npx",
      "args": ["-y", "@nicolasvegam/garmin-connect-mcp"],
      "env": {
        "GARMIN_EMAIL": "you@email.com",
        "GARMIN_PASSWORD": "your-password"
      }
    }
  }
}

The snag everyone hits, in advance: MCP servers run headless, so there’s nowhere to type your MFA code. Every one of these projects solves it with a one time command line pre-authentication that prompts you once and caches an OAuth token locally. For the server above it’s npx -y @nicolasvegam/garmin-connect-mcp setup. Taxuspt ships garmin-mcp-auth. Do this before you restart Claude, or you’ll spend twenty minutes debugging a silent failure.

Two more things. That cached token file grants access to your Garmin account, so treat it like a password. And tokens expire, roughly every six months per Taxuspt’s own warning, so budget for occasional re-auth.

One important architectural note, because people get this wrong: a local stdio server works in Claude Desktop and Claude Code. It does not work in claude.ai in the browser, because remote connectors are reached from Anthropic’s servers, and Anthropic’s servers cannot see your localhost. For health data this constraint is a feature.

What you actually do with it

Setup is not the point. Here’s the point.

Cross source correlation, which is the whole ballgame. Nothing Garmin sells ingests your calendar, your weather, your journal and your nutrition together. Once Claude can see all of it, ask:

Join my sleep and HRV data against my calendar export. Compare weeks with more than fifteen hours of meetings to weeks with fewer. Compute the deltas, report n for each group.

One builder running this kind of setup found that going to bed after 2am cost him fifteen to twenty points of Training Readiness the next day, and that all night coding sessions tracked with worse HRV and reduced REM. Neither of those is a hard insight. Both were invisible until something looked across two datasets at once.

Illness and overtraining early warning. Elevated resting heart rate, suppressed HRV and rising respiration moving together is the classic signature, and it usually shows up a day or two before you feel it. Standing instruction:

Every Monday, check the last seven days of resting HR, overnight HRV and respiration against my 28 day baseline. If two or more are more than one standard deviation in the wrong direction, flag it and recommend a deload.

Taper and load decisions. Acute to chronic workload ratio, the 0.8 to 1.3 sweet spot popularised by Tim Gabbett in the British Journal of Sports Medicine in 2016, with risk climbing above roughly 1.5. Claude can compute yours from the activity table and plot it against a race date. Be honest about the caveat though: when Wang and colleagues reanalysed the data in 2020, removing outliers and treating the variable as continuous, the injury relationship disappeared. Use ACWR as a framing device, not scripture.

Querying years of your own life in a sentence. “Show me what my sleep looked like in the ten days before every race where I underperformed my predicted time.” That query is trivial to ask and impossible to execute in the Connect interface. This is the capability that feels like magic the first time.

A doctor ready one pager. Compress twelve months of resting HR, HRV, weight, blood pressure and sleep into a single page before your annual physical. Your GP has seven minutes. Hand them a page.

Metrics the vendor will never build. You want a personal readiness index that weights HRV at 40 percent, sleep debt at 30, and subjective mood at 30? Define it, have Claude compute it nightly, backtest it against how you actually felt. Garmin will never build your metric. You can build it this afternoon.

Apple Watch and Apple Health: same idea, different shape

Yes, this works. The architecture is different, and understanding why is useful.

HealthKit lives on device, encrypted, with no cloud API. There is no Apple equivalent of pulling from Garmin Connect, because there is no Apple cloud to pull from. So the pattern is always export then analyse.

The built in route is Health app, your profile, Export All Health Data. You get an enormous XML zip that is slow to generate and unpleasant to parse. It works. It’s not a habit.

The route worth paying for is Health Auto Export, which exports over 150 metrics as JSON or CSV and can push them on a schedule to iCloud, Dropbox, Google Drive, a REST endpoint, MQTT or Home Assistant. Point it at a local folder, point Claude Code at that folder, done. Apple’s constraints apply: automations only run while the device is unlocked, background tasks get about thirty seconds and tight memory, and large payloads fail. Export narrow and often rather than everything at once.

There are also several Apple Health MCP servers, all local first, most of them loading exports into DuckDB: neiltron/apple-health-mcp, the-momentum/apple-health-mcp-server, alphonsekoh/apple-health-mcp for Health Auto Export JSON, and PhilipAD/health-export-mcp covering 190 metrics. RyanLisse/Vitalink is the interesting outlier, a macOS Swift CLI that reads live HealthKit, though it needs to be code signed with an Apple Developer certificate.

Apple Shortcuts is the lightweight bridge if you don’t want another app. The Log and Find Health Sample actions plus Get Contents of URL will get you a functional on device export automation.

Worth noting that Apple shipped more consumer health AI than Garmin did this cycle. watchOS 26 added a nightly sleep score, hypertension notifications built on 30 day optical vascular analysis for Series 9 and later plus Ultra 2 and 3, and Workout Buddy, the Apple Intelligence generative coaching voice.

The honest comparison. Garmin has far richer physiology, Body Battery, Training Readiness, HRV status, real training load, per second activity data, and is the hardest mainstream platform to connect to anything. Apple has a shallower training story and a cleaner if more manual export path, with genuinely on device data. Garmin wins on depth, Apple wins on ergonomics, neither gives you interpretation.

For context on who’s actually open: Whoop has a proper public developer API with OAuth 2.0 covering recovery, strain, sleep stages, HRV and skin temperature. Oura’s personal API is excellent. Fitbit’s legacy Web API is being sunset in September 2026 with new developer registrations already closed, as Google funnels everyone toward its own health API and its Gemini based coaching. Polar, Suunto and Withings all have APIs. So if openness is your only criterion, buy an Oura. If data depth is your criterion, keep the Garmin and do the work.

Where this breaks, which you need to hear

I’ve written the enthusiastic part. Here is the part that keeps this honest, and it’s the section I’d want to read.

The model will get numbers wrong. Not sometimes. Reliably, if you let it. Asked to summarise a table in prose, it will produce averages that look right and aren’t. The mitigation is the compute-don’t-estimate rule above, and it is not optional.

The sensors are worse than you think. This is the deeper problem. A 75 participant multicentre validation study, Lee and colleagues in JMIR mHealth and uHealth, 2023, compared eleven consumer trackers against polysomnography across 349,114 epochs and 543 hours of sleep lab data. Macro F1 for sleep staging ranged from 0.26 to 0.69 depending on device, and that range includes Apple Watch 8, Oura Ring 3, Fitbit Sense 2, Pixel Watch and Galaxy Watch 5. Wrist HRV and resting heart rate vary by device, degrade with motion, and are measurably less accurate on darker skin because green light PPG is absorbed differently. Wrist Pulse Ox is rough at the best of times.

Which means when Claude tells you your deep sleep dropped twelve percent, it may be interpreting noise with total confidence. Garbage in, eloquent garbage out. Trust trends across weeks. Distrust single nights. Distrust any absolute number.

This is coaching, not medicine. Google’s PH-LLM paper in Nature Medicine in October 2025 is the strongest evidence that models can do this well: 79 percent on sleep medicine exam questions against 76 percent for a panel of five sleep specialists averaging 25 years of experience, and 88 percent on fitness questions against 71 percent for five athletic trainers, across 857 case studies. Genuinely impressive. Also: that was a fine tuned, code executing, purpose built model, not a chat window, and its own authors are emphatic about safety caveats. Read it as proof the category works, not as permission to skip the doctor.

Privacy, concretely. Since Anthropic’s September 2025 terms change, conversations on consumer plans can be used for model training unless you turn it off in Settings, Privacy. Opting in also extends retention to five years. API and enterprise traffic are not trained on. Consumer Claude is not HIPAA compliant. So: turn training off before you start, keep the database local, and send aggregates and derived features rather than raw per second streams, which is better for your privacy and your context window simultaneously.

The actual argument

Garmin sold two hundred thousand people a thousand dollar computer that measures their nervous system overnight, and then charges seven dollars a month to tell them they slept badly.

That gap is not a product failure. It’s a structural one. Vendors can only interpret the slice of you they own, and the slice they own is never the interesting slice. The interesting slice is the seam between what your body did and what your week did to it, and only one entity has access to both.

The pipeline is an afternoon. GarminDB, a SQLite file, Claude Code, and about eight lines of rules in a CLAUDE.md telling the model to compute instead of guess. The Fenix 9 is a very good sensor. Buy it for that. Then build the part Garmin didn’t.

添加评论
点赞收藏
点踩分享查看原文
评论
?
参与讨论