Runspector — AI running coach for Garmin

Runspector — AI running coach for Garmin

Formerly runcoach-ai: same project, renamed in v0.5.0. Old links redirect here. Coming from it: three steps to switch over, and your data moves by itself.

A free, open-source AI running coach for Garmin watches. Runspector syncs your Garmin Connect data - HRV, sleep, Body Battery, resting heart rate, training load and every run - into a file on your own computer, decides each day whether to go hard, keep it easy or rest, and lets Claude explain why and plan your week: in a small local web app, or as a Garmin MCP server in Claude Code and Claude Desktop. No cloud, no API key needed - your own Claude Code sign-in is enough.

I came to running late, and for a long time my VO2max would not move. I had always trained a lot, and it had never really shown up in that number — so I assumed more of the same would eventually work. It did not. I was training wrong, in ways the watch on my wrist had the data to show me and never did: Garmin collects everything and explains nothing.

That was the idea. The data is already there; let an AI read it and coach — with the training aimed squarely at raising VO2max rather than at collecting kilometres, and with the decision rules written down so the coach explains them instead of improvising. This repository started as that tool for one athlete. It is now installable for anyone with a Garmin watch and Claude Code (a Claude plan is enough).

No cloud backend, no API key needed, no Docker. One Python package that syncs your Garmin data into a SQLite file on your machine, shows it in a small web app, and lets Claude act as your coach — with a deterministic readiness engine underneath, so the AI explains decisions instead of inventing them.

If you came for the engineering rather than the running, the five decisions this repository is actually about — each with the measurement behind it — are in Design decisions. The short version: the verdict is pure code and only the explanation is AI · the agent runs on an allowlist, not a denylist (--tools "", one MCP server, empty temp cwd) · prompts are regression-tested by an LLM-as-judge suite whose last run is in the repo · quantities that exist in two languages are pinned by executing the shipped JavaScript against the Python · and the release gate scans binaries too, with a false-positive counter-case. CI runs lint, 991 tests, 80 frontend tests and that gate on three operating systems and two Python versions, with every action pinned to a commit SHA — and a second job that builds the wheel, installs it as a user would and drives the installed executable through this quick start on all three systems, because the suite proves the code and only an install proves the package.

https://github.com/user-attachments/assets/0b4d7d86-5ab7-439b-82cb-89a004b71405

The 90-second demo, with voice-over: the synthetic demo athlete, rebuilt from this repo by scripts/video.py (file). No player above? The GitHub mobile app shows no videos: ▶ play the demo in the browser.

The built-in synthetic athlete (runspector serve --demo). Every image is regenerated by python scripts/screenshots.py, and the coach card is an unedited agent run against that same demo database, kept in demo-card.json so the picture cannot drift from the app — the decision it explains (EASY, a day after a hard session) is the one on the Today tab beside it. docs/screenshots/ has each of the five tabs full-length, in both themes — e.g. today.png and today-light.png.

Not affiliated with Garmin. Uses the unofficial python-garminconnect library against your own account. This is a training tool, not medical advice.

Quick start

# 1. install (needs uv: https://docs.astral.sh/uv/)
uv tool install runspector
#    without uv: pipx install runspector

# 2. look around without any account
runspector serve --demo

# 3. the real thing
runspector serve        # first start: checks Garmin and Claude, opens http://127.0.0.1:8765 -
                        # sign in to Garmin right there (Setup → Sign in to Garmin; only a
                        # session token is stored) - and syncs the last 30 days in the background

Garmin is signed into on the page itself (Setup → Sign in to Garmin, or Sign in again when the session has expired): e-mail, password and Garmin's code if your account uses one, and the sync starts right after. runspector login does the same from any terminal, and a running app picks it up on ↻ - no restart. Claude is only needed for the coach cards: see Connecting Claude.

runspector doctor tells you what is missing — it checks the Garmin session by actually using it, and reports the data age, because a token that quietly expired is how this kind of app dies. Use runspector doctor --offline to skip the Garmin call. Exit 1 means something needs fixing, so runspector doctor || notify-me works in a cron; a missing Claude CLI is reported but does not set it, since everything except the coach cards works without it.

Garmin MCP server for Claude Code and Claude Desktop

The same data, and the same rules, as an MCP server with 16 tools - among them today's readiness verdict, recovery, training load, recent runs, intensity distribution, the VO2max history, what the coach has learned about you, a Garmin sync - and propose, apply and undo for a workout on your watch.

claude mcp add runspector -- runspector mcp
# then just ask: "should I train today?"
# or: "plan me an easy 40 minutes for tomorrow" - you see the session, and it goes
# on your watch only after you say yes ("take it back off" undoes it)

In Claude Desktop, or any MCP client with a JSON configuration (sign in once first: runspector login):

{ "mcpServers": { "runspector": { "command": "uvx", "args": ["runspector", "mcp"] } } }

Keep it fresh without the app (cron / Task Scheduler): runspector sync.

Later on:

uv tool upgrade runspector     # the newest release; your data and Garmin session stay where they are
uv tool uninstall runspector   # removes the program only - delete ~/.runspector yourself if you want the data gone

uv tool install runspector takes the latest release from PyPI (runspector==0.5.1 pins one; pipx install runspector and pipx upgrade runspector do the same without uv); uv tool install git+https://github.com/edxleon/runspector takes whatever is on main.

Connecting Claude

runspector does not connect to Claude itself and never asks for a Claude password or key. The coach runs on Claude software you sign into with your own account, through Anthropic's own sign-in.

What "a Claude plan" means. Claude Code needs a paid Claude subscription from claude.com/pricing - Pro, Max, Team or Enterprise - or an Anthropic Console (API) account, which is billed per use. The free Claude plan does not include Claude Code. On a plan, the coach cards count against that plan's usage like any other Claude Code use: there is no key to create and no bill per card. runspector itself is free.

With Claude Code (needed for the coach cards)

Claude Code is Anthropic's command-line tool. You only install it and sign in once; runspector starts it in the background for each card.

# 1. install - macOS / Linux (Windows PowerShell: irm https://claude.ai/install.ps1 | iex)
curl -fsSL https://claude.ai/install.sh | bash        # or: brew install --cask claude-code

# 2. sign in - opens your browser, sign in with your Claude account
claude auth login

# 3. check
runspector doctor        # "Claude: signed in with your Claude subscription"

More install options (WinGet, npm, Linux packages): Claude Code setup. If Claude Code was missing when you started runspector serve, reload the page afterwards - no restart.

If your Claude Code is signed in with a Console API key or a cloud provider (Bedrock, Vertex) instead of a plan, the cards run on that and are billed there; the setup check says so. An ANTHROPIC_API_KEY that is only exported in your shell, for other work, is removed from the card runs unless you set RUNSPECTOR_ALLOW_API_KEY=1.

With Claude Desktop only (no command-line tool for Claude)

If you use the Claude desktop app (claude.ai/download), you can coach in its chat without Claude Code:

1. Install runspector and sign in to Garmin once (runspector login, or the page of runspector serve).

2. In Claude Desktop: the Claude menu → Settings… → Developer → Edit Config, and add:

    { "mcpServers": { "runspector": { "command": "runspector", "args": ["mcp"] } } }

   (the file is ~/Library/Application Support/Claude/claude_desktop_config.json on macOS, %APPDATA%\Claude\claude_desktop_config.json on Windows; keep any servers already in it).

3. Quit and restart Claude Desktop, then ask: "should I train today?"

If the server does not show up, Claude Desktop may not find the command: put the full path from which runspector (Windows: where runspector) into "command". The web app's coach cards still need Claude Code; in Desktop the same coaching happens in the chat.

Without Claude

The readiness verdict and its reasons, the runs, the trends and the sync all work. What needs Claude is everything the coach writes: the cards, and the sessions it proposes for your watch.

Questions people ask

How do I connect my Garmin data to Claude?

Install runspector, sign in to Garmin once (runspector login, or the button on the page), and either open the app (runspector serve) or add it to Claude Code as an MCP server: claude mcp add runspector -- runspector mcp. Then ask "should I train today?". See the MCP server for Claude Desktop.

Do I need a Garmin developer account or an API key?

No. runspector signs in with your own Garmin account, through a community library - see Can Garmin block my account? below. On the Claude side no API key is needed either: a Claude plan and Claude Code are enough.

Does it work with Apple Watch, Coros, Polar or Strava?

No - Garmin only. Every number comes from Garmin Connect, including Garmin's own readings (HRV status, Body Battery, training load, VO2max), and the workouts it plans go back onto a Garmin watch.

Is my Garmin password stored?

No. It goes to Garmin once, to sign in. Garmin answers with a session token, and only that is kept, on your computer, in a folder only your user account can read. The page's sign-in takes the password only on the computer runspector runs on: opened from a phone, the page is plain HTTP across your network, so there it points to runspector login instead.

Does it cost anything extra?

runspector is free (MIT). Coach cards use your Claude plan the way any Claude Code use does, with no API key and no bill per card. Without Claude, everything except the cards still works.

What does Claude see?

The numbers this app shows (readiness, recent runs, zones, weekly load), and only when you start a card or ask in Claude Code. It never sees your Garmin password, the session token or any raw file. It reaches Claude through your own account, under your plan's terms.

Can it mess up my watch or my calendar?

Reading is all it does on its own. Something goes to Garmin only when you press "Put on watch" or say yes in Claude Code, and then only the session shown to you. "Take off watch" removes it again. The coach's own card runs cannot write at all.

Can Garmin block my account?

runspector signs in through python-garminconnect, a community library that Garmin does not officially support. A daily sync makes about 25-40 requests and the first one (a month of data) a few hundred. It pauses between workout downloads, never fetches more than 90 days, and stops at the first rate-limit answer instead of retrying into it. That is no guarantee, but it is not scraping either.

Is this medical advice?

No. It is a training tool. Pain, dizziness or anything that feels wrong goes to a doctor, and the coach says so instead of planning around it.

How do I remove everything?

Delete ~/.runspector (the app's footer shows the folder) and run uv tool uninstall runspector. To cut the token off at Garmin as well, change your Garmin password.

What you get

How it works

flowchart TD
    G[Garmin Connect] -- "token resume, read" --> S[sync.py]
    S --> DB[(SQLite<br/>~/.runspector)]
    DB --> L[logic.py<br/>readiness · decision<br/>intervals · bands]
    L --> SNAP[snapshot.py]
    SNAP --> WEB[web app<br/>127.0.0.1:8765]
    L --> MCP[MCP server<br/>16 tools<br/>13 read-only · sync · apply · undo]
    WEB -- "spawn job" --> A["claude --print<br/>(your Claude sign-in)"]
    A -- "only mcp__runspector__*" --> MCP
    A -- "JSON card" --> WEB
    MCP --- CC[Claude Code / Desktop]

Design decisions

The verdict is code, the explanation is AI. GO/EASY/REST, today's decision, interval detection and intensity bands are pure functions in logic.py — unit-tested, no network, no LLM. The facts and the decision are computed once there, and the agent is handed the finished decision through get_training_readiness rather than left to derive its own: a coach card is a reading of that decision, not a second, independently produced verdict. Claude may explain it, add the context a rule cannot — or disagree, in which case it has to say which number it disagrees with. Claude's job is the part rules are bad at: weighing a conflict, phrasing a plan, answering a follow-up.

Your own Claude Code sign-in, not a key in the app. Coach jobs run claude --print as a subprocess, signed in the way you signed Claude Code in. On a Claude plan there is no key to leak, no per-token bill, nothing to configure. API-key variables exported for other work are stripped from the card runs by default, so they never bill a card unasked; RUNSPECTOR_ALLOW_API_KEY=1 keeps them. A key or a cloud provider configured in Claude Code itself is beyond any variable: the cards use it, and the setup check says so - it asks Claude Code in the same environment and the same kind of empty directory the cards run in. If your quota is exhausted the job waits for the next window instead of failing.

The agent gets an allowlist, not a denylist. Workout titles are attacker-controlled text that ends up in a prompt. So the coach agent runs with --tools "" (no Bash, no file access, no web), --strict-mcp-config with exactly one server — this one — and only mcp__runspector__* pre-approved, in an empty temp directory. The card comes back as JSON and is validated and written by the app, not by the agent — and an answer produced without a single tool round trip is discarded: a model that cannot reach the data will otherwise invent it (this was measured, not assumed). See web/agent.py.

What that does and does not buy, stated plainly: an injected workout title cannot reach anything but this app's own tools — no shell, no filesystem, no network, no other MCP server, and no write path from a card run: every tool is read-only except sync_garmin, which triggers authenticated requests to your own Garmin account and so is worth a rate limit rather than nothing, and apply_workout, the one tool that writes to Garmin — which the app's card runs cannot call at all (--disallowedTools, pinned by a test), because applying a proposal is a human's click on the card or their word in a Claude Code session, never a job's decision. What it can still do is influence what a card says — and the card is the product. And cards are remembered: the previous card of the same kind is fed back as context for the next one, so a bad card echoes forward until you delete it (the UI has a delete button per card).

Aggregates for the model, series for the UI. MCP tools never return day-by-day rows for a period — daily series bloat a context window and get misread. The agent sees summaries and weekly buckets; only the frontend, which draws curves, gets points.

Honest numbers. A few examples of what that means in practice:

• Garmin carries VO2max forward on days without a measurement, so a change is only reported when the value actually varied — never as a difference of window endpoints.
• A self-computed ACWR needs ≥ 21 days and ≥ 8 workouts, is labelled computed, and may dampen a verdict to EASY but never drive REST.
• A GO from fewer than two recovery signals is downgraded: thin data is not green.
• If the sync is stale, today's decision is unknown rather than yesterday's verdict in today's clothes.
• An incompletely fetched calendar month does not replace the local mirror ("nothing planned" would be a lie from a degraded source).
• Garmin's lactate-threshold pace field is off by a factor of ten; it is normalised, range-checked, and loudly dropped if the unit ever changes.
• A planned week lands on the athlete's own days: how many days, which weekdays and the long-run day are read from the last eight weeks with running (looking back half a year, and before a pause while coming back from one), and the quality sessions keep clear of a weekly other sport and the day after it - a gym Tuesday leaves room for one quality session, not two. A rotating every-other-day rhythm has no weekdays of its own and is planned in the default rhythm. Each value says where it came from: "long run on sat - your longest run fell on sat in 8 of 8 weeks".
• A planned week is sized from the athlete's own running weeks - rolling weeks ending on the day of planning, never more than 10 % over the bigger of the last two - and then read against their history, in code: the load ratio can hold or unload it, every fourth week is a down week, ten days without a run make a return week of easy running only (half the weeks before after more than three weeks off), and twenty-eight days without a new VO2max value put a steady block in the threshold slot. A budget too small for the planned days plans a shorter week - one quality session at three days, never a lone hard one - instead of inflating the sessions. A week with one quality session takes the one that is due (VO2max until the zone-5 stimulus is set, then threshold, or the measurement). Back from a pause the athlete rebuilds: the step grows from the last seven days, not from a median that lags the climb, and there is no down week until the weeks are back to 80 % of the level before the pause. A step is never smaller than the week planned before it, and a week held or unloaded on the load ratio is never bigger: the median it holds rises with every week run above plan, which is what raised the ratio. Each rule is a named assumption on the proposal, none of them a prompt's discretion. On a hard day the decision also says which hard session, from what the last seven days did and did not contain; after a pause the day is easy instead.
• Without a measured threshold pace, sessions are sized from Garmin's own 5 km and 10 km predictions rather than from a 5:00/km default that fitted one athlete.
• Those rules are run, not only unit-tested: evals/sim.py puts eight synthetic athletes - one who follows the plan, one who skips 40 %, one who takes three weeks off, one who falls ill, one who always runs harder - through sixteen weeks of the app, day by day against the real tools, and checks what a runner would expect of a coach over the whole course. It found the two planner bugs above. It cannot tell whether the training works - its body is a toy - and it finds only what its data model knows, so the live test on a real account stays.

Prompts are tested like code. The coach's behaviour lives in two Markdown files (skills/) with an LLM-as-judge regression suite (evals/): 32 cases such as "a run already happened today → no second hard session", "warning signs of low energy availability are not explained away", "an instruction inside a workout name is not followed". They run without Garmin data against the real CLI — though only over those two files, not over the other two pieces of the shipped prompt (templates.json and the JSON-card frame in web/agent.py, which tests/test_web.py covers deterministically instead), and under --safe-mode on whichever model the suite is pointed at, neither of which production can use. The framing itself is imported from the app rather than copied, so the suite cannot drift from what ships. --no-skills re-runs a case with the skill files removed: a case that still passes is testing the model, not the prompt.

Boring technology. Python stdlib HTTP server, sqlite3, vanilla ES modules, inline SVG charts. No framework, no build step, no ORM. ~40 SQL queries, all in store.py. Runs on Windows, macOS and Linux (CI matrix).

More detail: docs/architecture.md.

Privacy

Everything stays in ~/.runspector/ (override with RUNSPECTOR_HOME): the SQLite database, Garmin session tokens, coach cards. Your password is never stored. On Linux and macOS the directory is created 0700, so on a shared machine other local accounts cannot read those files; Windows inherits the user profile's ACL instead. While runspector serve runs, that no longer covers them: without a token any local account or process can ask 127.0.0.1:8765 for your data, and since v0.2 apply or undo a proposal with your Garmin session. On a machine you share, start it with RUNSPECTOR_TOKEN set - the server then wants the token on loopback too, and prints the link to open once. The only outbound connections are to Garmin (sync) and — when you trigger a coach card — to Claude through your own CLI session, carrying aggregated training data. The server binds to 127.0.0.1; listening on the network requires RUNSPECTOR_TOKEN and the server refuses to start without it. Note that --host 0.0.0.0 serves plain HTTP with no TLS, so on that network the token and everything the app returns travel unencrypted and readable by anyone who can see the traffic — it is meant for your own phone on your own LAN, not for a network you do not control.

Configuration

Four more (RUNSPECTOR_DB, RUNSPECTOR_DEMO, RUNSPECTOR_CLAUDE_CMD, RUNSPECTOR_PII_EXTRA) exist for internal plumbing and tests; they are not part of the supported surface.

Optional athlete profile: runspector profile --max-hr 182 --goal "sub-50 10k". Your week - days per week, your days, long run, days off, another sport - is set on the You tab (or with --days-per-week and --long-run-day); whatever you leave open the planner reads from your history: the days you usually run, and the weekday your longest run falls on. A day off is never planned on. The note to your coach is context for the coach, not a rule: the days are what the planner itself keeps to.

Development

git clone https://github.com/edxleon/runspector && cd runspector
uv run pytest -q                   # no database server, no network, no Garmin account needed
node --test "web-tests/*.test.mjs" # frontend logic
uv run ruff check                  # lint — config is real and the backlog is zero
npx --yes @biomejs/biome@2.5.15 lint --error-on-warnings   # frontend lint (biome.jsonc)
uv run python evals/run_evals.py   # prompt regression (uses your Claude subscription)
uv run python scripts/pii_gate.py  # release gate

Status & roadmap

v0.1 was read-only towards Garmin. v0.2 adds the write path: propose_workout builds a session for your route from your own zones and files it, propose_week files a polarised week as one package, a proposal can replace the hard session the calendar had on a red day, and apply_workout uploads, schedules, pushes to the watch and reads back to verify. The app's card runs cannot apply anything; in the app a proposal is applied by a click on the card ("Put on watch", two taps), in Claude Code by your answer — and taken back off the same way, because a write you cannot undo is a write nobody makes the first time.

What has been run against a real account, not only the fake Garmin client the suite uses: on 2026-10-28, one easy session through runspector mcp — proposed from the athlete's own zones, uploaded, scheduled, pushed, seen on the watch, read back and verified, then undone — with every step cross-checked by a second, independent Garmin client. The app's button calls the same plan.apply and plan.undo. Not yet run for real: propose_week as a package, and the red-day swap that unschedules a calendar entry. One athlete, one account, one watch.

Roadmap

docs/roadmap.md is the backlog, ordered by what it would do for the runner: an athlete's own check-in (ill, sore, how it felt), sessions with your own structure, the proposed session matched against the run that followed, a runspector today for the morning, deeper history, body weight and Garmin's own readiness alongside the app's, and race preparation for those with a date. v0.3 made the planner read the history for what comes next; the rest is there with the reasoning and the order.

License

MIT