Features

This page is a quick tour of what Mira does. Everything below is included in the self-hosted version at no extra cost.

Review engine

This is how Mira reviews a pull request.

• Inline comments with severity and confidence. Every comment is tagged blocker, warning, suggestion, or nitpick and carries a confidence score. The filter block in .mira.yaml controls which comments make it past the noise filter.
• PR walkthrough and summary comment. A top-level comment with file coverage, per-severity counts, and a Mermaid sequence diagram where it's useful.
• Streaming. A placeholder comment posts within about a second, the walkthrough within ten, and the full review within a minute.
• Multi-file reasoning. Mira reasons across the whole diff rather than taking each file in isolation.
• Parallel chunk review. Large diffs are split into chunks and reviewed in parallel (max_concurrent_chunks).
• Dedupe. Comments that repeat across chunks and files are collapsed using Jaccard similarity on their titles and bodies.
• Cross-PR overlap detection. While reviewing a PR, Mira compares it against the repo's other open PRs and flags ones stepping on it — same files (merge-conflict risk) or same goal (duplicate effort) — in the walkthrough. A cheap deterministic pre-filter runs first, so only genuine candidates cost an LLM call. Tune or disable via review.overlap in configuration.
• GitHub suggestion blocks. Actionable fixes are posted as suggestion blocks the author can accept in one click.
• Confidence clamping. A single blocker finding forces an overall "Do not merge", regardless of the model's initial read.

Configure: .mira.yaml → review, .mira.yaml → filter.

Codebase intelligence

Here's what Mira already knows about your repo before the model ever sees a diff.

• Full-repo index. Every file gets an LLM-generated summary, stored in SQLite or Postgres.
• Manifest extraction. Mira reads package.json, requirements.txt, pyproject.toml, go.mod, and Dockerfile, capturing versions exactly at zero LLM cost.
• Dependency graph. Symbol-level relationships across files, shown in the dashboard as a draggable ReactFlow graph.
• Cross-repo relationships. When two repos share a dependency, Mira surfaces the link, which is handy for blast-radius analysis.
• Blast-radius rendering. An SVG and interactive view of what depends on a symbol you're about to change.
• Relationship overrides. You can add or override edges by hand when the detector misses one.
• External reference tracking. Mira tracks which external packages are used where.

Vulnerability scanning

Mira watches for CVEs in every package across every repo.

• OSV.dev poll. A background poll runs every hour, configurable via MIRA_VULN_POLL_INTERVAL.
• Severity coverage. It surfaces critical, high, moderate, and low CVEs, each with advisory links and known fix versions.
• Per-repo CVE badges. Vulnerabilities show up inline next to the package listings.
• Dashboard widget. An org-wide view of open vulnerabilities, broken down by severity.

Combined with the package index, this gives you a fast incident-response answer to questions like "which repos use lodash@4.17.20?"

Org-wide package search

Search for any package or version across every repo you've indexed.

• One query, every repo. Search by name, version, ecosystem, or dev-vs-prod.
• Lockfile-aware dedupe. When the same package shows up in both a manifest (pyproject.toml) and a lockfile (uv.lock), the lockfile row wins, so you see the resolved version.
• Built for incident response. It answers "which repos use lodash@4.17.20 after this CVE?" in a single query, instead of grepping across a pile of clones.

Custom rules

Codify the conventions your team always follows.

• Per-repo rules. Full CRUD, with no limit per repo.
• Global rules. Rules that apply to every repo in the org.
• Auto-injected. Rules are added to the review prompt automatically, so you don't have to restate them on every PR.
• Dashboard editor. Manage them on the /rules page.

Learning from feedback

Mira gets better over time without you having to write rules yourself.

• Reject signal. Comment @miracodeai reject on a Mira comment to mark it as unhelpful, and Mira records the event.
• Deterministic rule synthesis. When rejections cluster in a category or directory, Mira writes a rule that suppresses similar comments going forward. Tune it with the MIRA_FEEDBACK_* env vars.
• LLM-powered human-pattern synthesis. On merged PRs, Mira reads the human reviewers' comments and turns recurring themes into rules.
• Feedback stats API. Inspect the learning loop from the dashboard.
• Quarantine for new learnings. Freshly synthesized learnings land in a pending queue on the Learnings page and only apply to reviews once you approve them. Decline one and it stays suppressed — future feedback keeps its evidence count fresh but can't resurrect it.
• Edit and delete. Reword any learning inline (manual edits survive re-synthesis) or delete it outright. Deleting forgets the learning, so the same pattern can return as pending; declining suppresses it for good.

Bring your own LLM

• OpenRouter routing. One OPENROUTER_API_KEY covers Anthropic, OpenAI, Google, DeepSeek, and more.
• Pay your provider directly. There's no Mira markup and no SaaS middle tier.
• Split indexing and review. Use a cheap, fast model for indexing and a stronger one for review. See Choosing a model.
• Fallback chain. If the primary model errors, Mira retries with fallback_model.

Platform integration

• GitHub App. Auto-reviews every PR.
• GitLab. Auto-reviews every merge request with full feature parity, via a group or project access token. See Set up GitLab.
• Forgejo / Codeberg. Auto-reviews pull requests via an access token and webhook. See Set up Forgejo.
• Self-managed / Enterprise. Point MIRA_GITHUB_API_URL at GitHub Enterprise Server, MIRA_GITLAB_API_URL at a self-managed GitLab instance, or MIRA_FORGEJO_API_URL at a self-hosted Forgejo.
• Author allow/deny lists. Restrict auto-review to certain PR authors (filter.allowed_authors) or exclude bots and specific authors (filter.blocked_authors) — the blocklist wins, and a dependabot entry matches dependabot[bot].
• Chat with the bot. Mention @miracodeai <question> on any PR or MR thread and the bot answers using the indexed code as context.
• Cancel in-progress indexing. Stop a long-running indexing job from the dashboard.

PR chat commands

Mention the bot (@miracodeai by default; whatever you set MIRA_BOT_NAME to otherwise) on a PR comment to trigger one of these commands. Anything that doesn't match a command falls through to the free-form Q&A handler.

Dashboard and analytics

• Org-level stats. Total reviews, comments, tokens, and per-severity counts.
• Time series. Daily, weekly, and monthly bar and line charts.
• Severity breakdown. A stacked view of issue severity per period.
• Category breakdown. Issues grouped by category per period.
• Per-repo view. Files indexed, dependencies, blast radius, packages, and the last-indexed timestamp.
• Cost estimates. Estimated indexing spend per repo.
• Review event stream. A live feed for troubleshooting.
• Review page (admin). Stale and waiting PRs (how long open, how long idle, who they're waiting on), a reviewer-responsiveness leaderboard (pending queue + median time to respond), throughput trends (time-to-first-review and time-to-merge, this week vs last), rubber-stamp detection (approvals with no substantive review), and an open-PR status board. Captured live from webhooks; seeded by a GitHub backfill on repo add, admin Refresh, or the mira backfill-contributors CLI.
• Contributor analytics. Per-contributor authoring stats (commits, PRs, lines), a year-long contribution heatmap, and a review-quality signal — blockers/warnings their PRs triggered plus the accept rate of Mira's feedback.

Storage and deployment

• SQLite or Postgres. See Pick a database.
• Single Docker image. ghcr.io/miracodeai/mira:latest.
• Reference deploy configs. Railway, Fly.io, and Render. See Deployment.
• No phone-home or required telemetry. See Security.