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 concise top-level overview with merge confidence, review stats, blast radius, and a hardened Mermaid sequence diagram where it adds value.
• PR-description release notes. Optionally append an AI-generated Summary by Mira block to the PR/MR description, or replace the description entirely. Re-reviews update the existing marked block without duplicating it.
• 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.
• Agentic verification. The reviewer can call read_file and grep_repo to verify callers and dispatch paths beyond pre-fetched context, whether or not the repository already has an index.
• 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.

Security and vulnerability scanning

Mira combines model-based security review with deterministic scans.

• Focused security model. A dedicated security pass looks for injection, XSS, auth bypass, CSRF, SSRF, unsafe deserialization, and cryptographic mistakes alongside the main review. Set llm.security_model independently when this pass needs a different model.
• Cross-file verification. The security pass can use read_file and grep_repo before filing a finding, reducing speculative reports that depend on code outside the diff.
• Added-line secret scan. Regex and entropy checks catch committed keys, tokens, and passwords locally, without an LLM or network request.
• Review-time OSV check. Packages added or upgraded by a PR are checked in one OSV.dev batch request, before the change merges.
• 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.
• Chat Completions or Responses API. OpenAI-compatible endpoints can use either protocol via llm.api_style.
• Codex CLI. Use an existing Codex OAuth session with an isolated, read-only invocation instead of an HTTP API key.
• 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.
• Draft-aware reviews. Draft GitHub PRs are skipped and picked up when they become ready for review.
• 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.
• Natural GitHub thread replies. Plain replies in Mira's own review threads are classified as questions, disagreements, or acknowledgements even without an explicit mention, so Mira can answer or resolve the conversation without adding noise.
• 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.