Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Upgrade from 0.2

MiRMiR 0.3.0 changes the application from a collection of separate command paths into several control surfaces for one local runtime. The TUI, CLI, web dashboard, and HTTP API now observe and operate the same loaded models, configuration, request activity, and telemetry.

Choose who owns the runtime

  • Run mirmir serve for a persistent runtime shared by local clients and, when enabled, the HTTP API and web dashboard.
  • Run mirmir to open the TUI. It attaches to an existing runtime or starts a temporary one when none is available.
  • Model and prompt commands follow the same rule: attach when possible, otherwise start a temporary runtime for the operation.

A client only shuts down a temporary runtime that it started. Exiting a TUI or CLI command attached to mirmir serve leaves the persistent runtime running.

Manage models as a lifecycle

Model discovery, storage, compatibility, and accelerator residency are separate operations in 0.3.0:

mirmir model search "Qwen 3" --limit 20
mirmir model pull Qwen/Qwen3-4B
mirmir model inspect Qwen/Qwen3-4B
mirmir model load Qwen/Qwen3-4B
mirmir model unload Qwen/Qwen3-4B

Search and pull perform bounded remote inspection. Load performs structural, backend, and memory preflight before allocating accelerator weights. --force can override only the conservative memory-fit decision; it cannot admit an unsupported checkpoint.

Move settings into the shared configuration

Use mirmir config instead of maintaining per-command runtime flags:

mirmir config init
mirmir config show
mirmir config validate
mirmir config set default_model Qwen/Qwen3-4B

Configuration records effective values and their source. Secrets live in a separate protected file and remain redacted in every control surface. When a persistent server is running, configuration mutations go through it so there is one writer.

Review model compatibility

Version 0.3.0 admits a checkpoint from its task, architecture, tokenizer, tensor schema, weight encoding, and selected backend. Family names and Hub tags are not support guarantees. The release adds typed SafeTensors paths for dense, integer, block-floating-point, and codebook quantization, including bitsandbytes NF4 and FP4 checkpoints without a Python runtime.

See Model compatibility for the complete 0.3.0 matrix.

Check the public API boundary

The OpenAI-compatible surface remains deliberately smaller than the complete OpenAI platform. Existing clients should target the documented chat, embedding, reranking, model-list, and health endpoints. Management operations belong to the TUI, CLI, web dashboard, or private local control protocol.

Upgrade checklist

  1. Install the 0.3.0 binary and run mirmir --version.
  2. Run mirmir config validate against the existing configuration.
  3. Inspect each checkpoint on its target Metal or CUDA machine.
  4. Start mirmir serve if the runtime must outlive an interactive client.
  5. Confirm API authentication, CORS, and dashboard settings before binding beyond a local development workflow.