Install

Three install paths — pick whichever fits your machine.

$curl -fsSL https://llmstatus.ai/install.sh | bashCopy

Verifying the install

mm --help            # short form
llmstatus --help     # same binary, descriptive name

If mm isn’t on your PATH, the most common cause is your install dir isn’t included. The shell installer drops the binary in ~/.local/bin by default (user-owned, so auto-update never needs sudo); the npm install path uses npm’s global bin (npm prefix -g).

Custom install location

The shell installer respects two env vars:

# Install elsewhere (no sudo needed if you own the dir):
MM_INSTALL_DIR=$HOME/bin curl -fsSL https://llmstatus.ai/install.sh | bash
 
# Pin a specific version (defaults to "latest"):
MM_VERSION=v0.1.0 curl -fsSL https://llmstatus.ai/install.sh | bash

A dir you can’t write to without sudo (e.g. /usr/local/bin) disables auto-update — the binary can’t replace itself there.

What ships in each install method

Available binaries (R2 CDN, public)

The shell installer auto-picks the right one, but you can grab any of these directly:

https://cdn.llmstatus.ai/cli/latest/modelstatus-cli-darwin-arm64
https://cdn.llmstatus.ai/cli/latest/modelstatus-cli-darwin-x64
https://cdn.llmstatus.ai/cli/latest/modelstatus-cli-linux-x64
https://cdn.llmstatus.ai/cli/latest/modelstatus-cli-linux-arm64
https://cdn.llmstatus.ai/cli/latest/modelstatus-cli-windows-x64.exe

Version-pinned URLs swap /latest/ for /v0.1.0/ (or any tag we publish). Each version is immutable — latest is a mutable alias that we update on every release.

Auto-updates

The shell-installed binary checks for updates in the background on basically every run (throttled to once per ~30 seconds to protect against tight loops) and silently replaces itself when a new version is available. The check runs in parallel with whatever command you ran, so it never adds latency to anything you’re doing. New releases reach you within a minute of being published. You see a one-liner when an update completes:

✓ Updated mm 0.1.2 → 0.1.3 — your next run uses the new version.

How the update path stays safe:

• Verified: the new binary’s sha256 is checked against the signed cli/latest/version.json manifest before it replaces the running binary.
• Atomic: the file is downloaded next to the current binary, then renamed over it (single inode swap on POSIX — no half-state).
• Fail-safe: any network / disk / permission error is swallowed silently. Your command never breaks because the updater hiccupped.
• npm-installed users aren’t auto-updated — npm manages those installs. Use npm update -g @modelstatus/cli.

Opt out

export MM_NO_AUTO_UPDATE=1

Auto-update is also skipped automatically when you pass --json or --ci (machines shouldn’t get surprise updates mid-pipeline).

Pin a specific version

MM_VERSION=v0.1.2 curl -fsSL https://llmstatus.ai/install.sh | bash

Pinned installs still auto-update unless you also set MM_NO_AUTO_UPDATE=1.

Release channels

The channel is baked into the binary at install time. A stable install only ever pulls stable updates; an experimental install only ever pulls experimental ones. To switch channels, re-run the installer with the channel you want.

# Confirm what you have
mm --version    # 0.1.3   = stable
mm --version    # 0.2.0-alpha.1 = experimental

Why two channels? So we can ship rough edges + breaking changes to opt-in users without affecting everyone else on stable. Same setup most modern CLIs use (gh’s prerelease, supabase’s beta, etc.).

Experimental releases are CDN-only — they’re not published to npm. If you’d rather pin via npm, stick with stable: npm i -g @modelstatus/cli.

Uninstall

# Shell-installer path:
rm ~/.local/bin/mm ~/.local/bin/llmstatus
 
# npm path:
npm uninstall -g @modelstatus/cli