Skip to content
Mimir

How Mimir works

Mimir groups agent work into sessions. Each session records its harness, machine, repository, models, duration, token use, files, errors, capture state, and work outcome.

Agent harnesses send proxy exchanges, reconstructed turns, and lifecycle events to a private Mimir Worker. The CLI handles setup and search.

Capture paths

Section titled “Capture paths”

Mimir receives three kinds of data:

  1. Proxied model traffic. The Worker records complete OpenRouter requests and streamed responses, redacts them, stores the full exchange in R2, and writes searchable metadata to D1.
  2. Reconstructed exchanges. Pi, OpenCode, Claude Code, Codex, and Cursor can report the prompts, responses, and tool activity their integrations expose. These records may omit transport details, exact token use, or timing.
  3. Lifecycle events. Harnesses report starts, turns, heartbeats, titles, session ends, and outcomes. These events keep the session state current.

When a harness supplies x-mimir-session, Mimir uses it as the session ID. Traffic without one is grouped by repository, harness, machine, and inactivity.

Each installation has a stable ID and an editable device name. Sessions keep that device association.

Compare capture paths by harness and provider.

Capture and outcome

Section titled “Capture and outcome”

Mimir keeps storage state separate from work results.

  • Capture state: empty, pending, saved, failed, or partial.
  • Work outcome: landed, discarded, abandoned, or unresolved.

A session can be saved even when the work failed. A landed outcome does not prove every exchange was saved.

Query the memory

Section titled “Query the memory”
Terminal window
mimir search "token validation" --json
mimir session get <id> --json
mimir session outcome <id> landed --reason "merged in PR 42" --json
mimir dashboard

Use Verify capture when you need proof that a session was stored.