Configuration overview

Mira's configuration is layered. Highest priority wins.

Most teams point Mira at one mira.yaml, tune the noise filter from the admin Settings page, and never touch a per-repo .mira.yaml. Reach for .mira.yaml only when one repo needs to deviate from the rest of the org, typically a noisier or quieter confidence_threshold, occasionally a different model.

Why model selection isn't in the admin UI

Model swaps have spend implications and are something you set deliberately once per deployment, not iterate on weekly. Two surfaces cover them:

• mira.yaml: the canonical place for the deployment's default model and fallback chain. Version-controllable.
• Dashboard → Settings → Models: a searchable picker over your backend's live catalog (any free-form id works too) for changing the indexing and review models without rewriting mira.yaml. Persists to the same DB the admin overrides use. A saved picker choice overrides mira.yaml until you select Inherit from deployment config; Mira logs the effective model and its source on every review, so the override is never silent.

If you genuinely need a different model on a single repo, set llm.model in that repo's .mira.yaml. There's no equivalent UI for it because the use case is rare enough that requiring a file commit is the right friction level.

Decision tree

• Setting up a new Mira deployment? → write a mira.yaml and pass it via --config.
• Tuning the noise filter or review behaviour? → Dashboard → Settings → Review behaviour overrides. No restart required.
• One repo wants different review behaviour? → commit a .mira.yaml at its root.
• Switching models for the whole deployment? → either edit mira.yaml and restart, or use Settings → Models.
• Need to set credentials, DB URL, or admin password? → environment variables only; never commit secrets to YAML.

Precedence

For any given setting, Mira resolves in this order (highest priority first):

1. CLI overrides passed via --override key=value (rare; see the CLI docs for mira review).
2. Per-repo .mira.yaml in the repo's working tree.
3. Admin UI overrides (DB-backed, filter + review only).
4. Deployment-wide mira.yaml loaded via --config at server startup.
5. Environment variable fallbacks (MIRA_MODEL, DATABASE_URL).
6. Built-in defaults.

The indexing/review models have one extra layer: a model saved in Settings → Models (DB-backed) beats mira.yaml's llm.indexing_model / llm.review_model. Select Inherit from deployment config in the picker to clear it and hand control back to the file.

Where to next