llmwiki status - Inspect Project Health at a Glance

llmwiki status prints a read-only snapshot of your project: how many pages and sources it has, when it last compiled, which pages are stale or orphaned, what is waiting to be compiled or reviewed, and whether .llmwiki/state.json is healthy. It is the same snapshot the MCP wiki_status tool and the SDK status() method return, surfaced on the command line. No LLM calls are made and no provider credentials are required - everything is derived from disk. Freshness is computed on demand by re-hashing sources against the recorded compile state, so the command’s runtime grows with the size of sources/.

Basic usage

llmwiki status

Example output for a healthy project:

llmwiki status
──────────────────
i Pages: 12 concept(s), 3 quer(y/ies) — 15 total
i Sources: 9
i Last compiled: 2026-07-14T09:12:44.000Z
✓ Fresh: no stale or orphaned pages
✓ State: ok

When there is work to do, status says what and points at the next command:

! Stale: 3 page(s): transformer, self-attention, positional-encoding — run `llmwiki refresh --stale`
~ Pending changes: 2 source(s) awaiting compile — run `llmwiki compile`
? Pending review: 4 candidate(s) — run `llmwiki review list`
! State: missing — no compile has run yet — run `llmwiki compile`

The command always exits 0 on a successful inspection; problems are reported in the output, not the exit code.

Embedding refresh warnings

Status distinguishes pages awaiting another embedding attempt from pages whose automatic retries have stopped:

embeddings-refresh-pending: pages waiting for an embedding refresh.
embeddings-refresh-quarantined: pages that reached the retry limit for their current content. The warning persists until their content changes or you reset their retry entries, even if no pending work remains. It includes exhausted entries retained in the pending file, and notes entries from earlier versions that the next enabled compile will re-queue once.
embeddings-quarantine-unavailable: the quarantine marker cannot be read safely, so status cannot verify which retries have stopped.

These warnings also appear in status --json, SDK status, and MCP wiki_status. Inspection never retries embeddings or changes either marker. Fix the provider or page before resetting retry entries; see embedding retry recovery.

Flags

Flag	Description
`--json`	Emit the full status snapshot as JSON on stdout instead of the human summary. The shape matches the MCP `wiki_status` tool and the SDK’s `status()` return value, so scripts and agents can share one contract across all three surfaces.

JSON output

llmwiki status --json

{
  "pages": { "concepts": 12, "queries": 3, "total": 15 },
  "sources": 9,
  "lastCompiledAt": "2026-07-14T09:12:44.000Z",
  "stalePages": [],
  "staleCount": 0,
  "orphanedPages": [],
  "orphanedCount": 0,
  "stateStatus": "ok",
  "pendingCandidates": 0,
  "pendingChanges": [],
  "pendingChangesCount": 0
}

stateStatus is ok, missing (no compile has run), corrupt (unreadable state.json - run llmwiki compile to rebuild it), or too-new (written by a newer llmwiki version - upgrade llmwiki rather than recompiling). The stalePages, orphanedPages, and pendingChanges lists are each capped at 100 entries; staleCount, orphanedCount, and pendingChangesCount always carry the true totals. Projects with an active non-default profile additionally include a profile block with per-entity-type counts and any validation problems.

For deeper diagnostics than a status summary - broken wikilinks, citation problems, confidence and provenance rules - run llmwiki lint. To repair the stale pages that status reports, run llmwiki refresh --stale (preview with --dry-run).

Get Started

Core Concepts

CLI Reference

Configuration

Guides

Troubleshooting

llmwiki status - Inspect Project Health at a Glance

Basic usage

Embedding refresh warnings

Flags

JSON output

​Basic usage

​Embedding refresh warnings

​Flags

​JSON output

Basic usage

Embedding refresh warnings

Flags

JSON output