Skip to Content
How it works

How it works

A short tour of why mm status can run offline, with no account, and still trust what it reads.

The signed registry

The model lifecycle registry is published as a date-versioned, signed snapshot on cdn.llmstatus.ai. Every snapshot is an immutable JSON blob; a separate signed pointer tells the CLI which one is current.

pinned root key (in the CLI binary)
   → root-signs ─→ keys.json (names the current signing key)
                       → signing-key-signs ─→ latest.json (pointer + sha256)
                                                  → blob: VERSION.json (immutable)

This is a mini-TUF  trust chain:

  1. The CLI ships with the root key’s public half baked in. It only ever trusts updates to the signing key that the root key has signed.
  2. keys.json (root-signed, on the CDN) names the current signing key and when it’s allowed to be used.
  3. latest.json (signing-key-signed, on the CDN) is a pointer with the version id and sha256 of the actual snapshot blob.
  4. The snapshot blob (registry/20260528T060033Z.json) is immutable — once published, never changes. The pointer moves; the blobs don’t.

What the CLI does on every fetch

1. GET keys.json,  verify with the pinned root public key
2. GET latest.json, verify with the signing key from #1
3. Anti-rollback: if latest.json's version < the version we last trusted, refuse it
4. If latest's content_hash matches our cache, reuse the cached snapshot
5. GET VERSION.json, verify its sha256 matches latest's
6. Hand the snapshot to the resolver

If step 5 fails (network down, blob 404, bad hash) we fall back to the local cache at ~/.config/llmstatus/registry-cache.json and warn if it’s older than 30 days. Anti-rollback means a man-in-the-middle can’t downgrade you to an older, validly-signed snapshot.

Key rotation without CLI updates

Because the signing key lives in a root-signed keys.json, we can rotate it any time without shipping a new CLI release: publish a new keys.json signed by the same root key, with the new signing key listed. The next CLI run picks it up automatically.

The root key never lives on Vercel or any server. It’s an offline key kept in 1Password, used only to sign keys.json during key rotations or initial bootstrap.

Refresh cadence

A cron in the LLM Status app rebuilds the snapshot every 6 hours:

  1. Sync new models from upstream sources (models.dev, OpenRouter, provider APIs).
  2. Run the publish step: build the snapshot, sign latest.json, upload to R2.
  3. Content-deduped: if nothing meaningful changed (sorted providers + models + detection, minus volatile timestamps), it skips the publish. Most cycles are no-ops.

On-device resolution

Once the snapshot is in hand, all model resolution and health computation happens on your machine. Inputs the CLI scans (regex matches, env vars, etc.) are joined against the snapshot’s model_strings table; nothing leaves your network.

The same logic that drives mm status powers the web inventory + alerts — same registry, same health rules, same canonical model ids.

Privacy details

  • Secret-source scans (env, aws-secrets, k8s, helm, sql) shell out to your already-authenticated CLIs, run read-only, redact every snippet, and only ever upload model ids. Secret values never leave your machine.
  • mm status runs entirely offline (after the first registry fetch), no API calls at all.
  • No telemetry — the CLI doesn’t phone home about usage.
  • Your scan inputs (file paths, snippets) are stored in our database only if you’ve signed in and run mm scan (the upload step). mm status never uploads anything.

See also

CommandsFree vs Pro