<div align="center">

Loki Mode

The spec-driven autonomous builder with verified completion.

The free, source-available autonomous coding agent by Autonomi. Same Loki CLI, SDK, and MCP for everyone; the commercial editions for teams and enterprises are sold under the Autonomi brand (Autonomi Cloud, Autonomi Enterprise).

Hand it a spec. It does not accept "done" on an empty diff or failing tests.

Website | Documentation | Installation | Changelog

Current release: v9.16.0

</div>

---

Install

bun install -g loki-mode          # recommended (npm, Homebrew, Docker below)

<details> <summary>Other install methods</summary>

| Method | Command | Notes | |--------|---------|-------| | Bun (recommended) | bun install -g loki-mode | Fastest startup for CLI commands. | | npm | npm install -g loki-mode | Works without Bun (bash fallback). Migrate any time with loki self-update --to bun. | | Homebrew | brew tap asklokesh/tap && brew install loki-mode | Auto-installs Bun as a dep. | | Docker | docker pull asklokesh/loki-mode:latest | Bun + Claude CLI pre-installed. See DOCKER_README.md. |

Upgrade with loki self-update. Long form: Installation Guide.

</details>

Use it

loki quickstart                   # guided first build: asks a few questions, quotes cost, builds

That is the whole happy path. It asks for a one-line idea, picks a template, shows the real cost and time estimate before spending anything, then builds. Press Enter through every step and you get a sample Todo app.

Or go straight at it:

loki quick "build a landing page with a signup form"     # one-shot task
loki start prd.md                                        # build from a spec you wrote
loki modernize heal ./your-repo --assess                 # existing codebase, read-only

Loki needs a model to drive. An ANTHROPIC_API_KEY alone is enough (the Claude Agent SDK ships inside Loki); or point it at Claude Code, aider, cline, or an open model. Run loki doctor and it tells you exactly what is missing.

export ANTHROPIC_API_KEY=sk-...
loki doctor                       # checks your setup, names any blocker

Try it first, without installing

npx loki-mode tour                # no install, no API key, no spend, no network

Prints a real Evidence Receipt from a past build, headline and all:

Headline: VERIFIED WITH GAPS

| Fact          | Value                                    |
| Files changed | 8                                        |
| Diff sha256   | c2be6fff3e774c387f276277b25fc424f07b667… |
| Tests         | verified (node-test)                     |
| Build         | not_run                                  |
| Security      | findings                                 |
| Cost          | $10.3218                                 |

"WITH GAPS" is the point. Build was not run, security has findings, and the receipt says so on its own front page. Recompute the diff hash yourself and check it matches -- you are not asked to trust the agent's self-report.

---

How it works: Drop a spec -- a PRD, GitHub issue, OpenAPI/JSON/YAML, or one-line brief. Loki Mode classifies complexity (run.sh:detect_complexity()), assembles an agent team from 41 specialized agent roles across 8 domains - prompt-defined specifications the orchestrator adopts per phase, with parallel review (blind council) and optional worktree streams on Claude Code, sequential on other providers - and runs autonomous RARV cycles (Reason - Act - Reflect - Verify, see run.sh:run_autonomous()) with 8 quality gates (see skills/quality-gates.md). Code is not "done" until it passes automated verification. Output is a Git repo with source, tests, configs, and audit logs.

---

<details> <summary><b>Why verified completion matters</b> -- the failure this exists to fix</summary>

Self-reported completion is the failure users actually hit. A survey of the open issue trackers of seven coding harnesses (OpenHands, Cline, Aider, SWE-agent, Roo-Code, OpenCode, Continue) found the recurring complaint is the agent silently not doing the work -- "always stuck at Preparing write" (opencode#11112, 76 comments), "Continue not making changes to code" (continue#7143), "Agent does not execute functions" (continue#5696). None of those seven publishes a machine-checkable completion artifact.

We measured every named competitor that ships a local CLI -- opencode 1.18.9, aider 0.86.2, codex-cli 0.146.0, Claude Code 2.1.220, cursor-agent -- and none exposes a command that verifies the agent's own output. Rerun it yourself with bash tests/test-competitor-verify-surface.sh.

That is a measurement of the CLI surface, not of whole products: a web UI or an API could expose something --help does not, and Devin and Replit Agent ship no local CLI so they are not covered.

Evaluating this against something else? docs/EVALUATING.md puts a runnable command next to every claim we make, and states plainly what we do not have (no enterprise case studies, no independent benchmark placement, and generation is not air-gapped). It ends with the one question worth asking any agent vendor, including us.

</details>

Already have a codebase? Start read-only.

Most agents are built to create new apps. The harder, more valuable problem is the ten-year-old repo that pays the bills. Loki works on both, and on an existing codebase it starts by changing nothing:

loki modernize heal ./your-repo --assess          # read-only. no writes, no commits.
loki modernize heal ./your-repo --assess --json   # same, machine-readable

You get a modernization readiness report: language mix, a 4-level maturity rating, technical-debt signals (test coverage, TODO density, oversized files, dependency staleness), and a ranked list of where to start -- ordered by blast radius, so the first change is the one least likely to break something.

Then, if you want it to act:

loki modernize heal ./your-repo --strict          # block ALL behavioral change without approval
loki modernize heal ./your-repo --phase archaeology   # extract knowledge only
loki modernize heal ./your-repo --compliance healthcare   # or fintech | government

The healing pipeline runs in phases -- archaeology, stabilize, isolate, modernize, validate -- and the validate phase checks behavioral equivalence against the pre-change baseline, not just that the tests are green. Friction points (the weird code that exists for a reason nobody remembers) are cataloged before anything touches them, because in a legacy system the strange code is usually load-bearing.

The Evidence Receipt: don't trust the agent, check it

Every coding agent tells you it finished. Loki hands you something you can check yourself.

We are not the only tool that checks its own work, and you should be suspicious of anyone who claims to be. Lovable runs a security scan on every publish and can block the publish outright. Claude Code's review has a step that checks findings against actual code behavior. Replit says its agent tests its own work.

The difference is what you are left holding. Their output lives in their dashboard: a findings count in a dialog, a check run that by design never blocks a merge. Ours is a file. It is bound to a specific diff by diff_sha256, it records what was NOT proven as prominently as what was, and someone who has never installed Loki can re-verify it from the repository alone. Commit it, attach it to the PR, hand it to an auditor.

Portable, diff-bound, and honest about its gaps -- that is the claim, and it is the one worth checking.

Each run writes a receipt to .loki/proofs/<run_id>/ that separates deterministic FACTS (the git diff with base and head SHAs plus a diff_sha256, the test command and its exit code, the build command and its exit code, each gate verdict) from AI ASSESSMENTS (the council verdict, labeled as judgment, never as proof). The headline is computed from the facts alone:

| Headline | Means | |---|---| | VERIFIED | tests ran a real command and exited 0, diff non-empty, nothing skipped | | VERIFIED WITH GAPS | each gap listed by name | | NOT VERIFIED | a check ran and failed |

loki proof list            # every receipt from this project
loki proof show <id>       # the facts, the assessments, and the headline
loki proof verify <id>     # re-hash the receipt and re-derive the diff

loki proof verify exits 0 clean, 1 on tamper or drift. Receipts are attached to pull requests automatically (LOKI_PROVEN_PR=0 to opt out), so a reviewer sees the evidence next to the code.

What the receipt does NOT claim. On the unsigned path the generator is trusted: someone who rewrites both the facts and the headline into a mutually consistent lie and recomputes the hash will still pass verification. That is defense-in-depth, not non-forgeability, and neutral non-forgeability needs the signed record. We tested for exactly this and locked the limitation into the suite (tests/test-proof-forgery-defense.sh), and in v7.111.0 we removed our own earlier "non-forgeable" claim once we found it was false on that path. An honest boundary you can verify beats a marketing claim you cannot.

To close that gap, sign your receipts: export LOKI_PROOF_GPG_KEY=<key-id> and every receipt carries a detached GPG signature that any third party with your public key can verify offline. See docs/SIGNED-RECEIPTS.md.

Why Loki Mode?

• Spec-driven, autonomous, with a built-in trust layer -- Hand Loki a spec, walk away, come back to working code with tests. The full RARV-C closure loop (Reason - Act - Reflect - Verify - Close) runs until the work is actually done, not just attempted. The verified-completion evidence gate (skills/quality-gates.md) refuses any "done" claim on an empty git diff against the run-start commit, blocks completion when tests run red, and (v8.0.0) also blocks when a serveable app is confirmed unhealthy (runtime-boot axis, opt out LOKI_EVIDENCE_BOOT_GATE=0) or a credential is detected in the changed files (secret-leak axis, opt out LOKI_EVIDENCE_SECRET_GATE=0), so "complete" means proven, not promised.
• A checklist verifier that is honest, not brittle -- Each completion checklist item is checked deterministically before the completion council will accept "done". The verifier speaks extended regex (grep -E) so real LLM-emitted patterns match instead of erroring, and it is runner-agnostic: it runs the project's own declared test command rather than assuming a fixed runner. Crucially, a check that cannot be established is reported as inconclusive (pending), never as a false pass and never as a false failure. rc == 0 alone is not a pass; a test check goes green only on a real "N passed" signal from the runner (v7.121.x).
• Production quality built in -- 8 quality gates (skills/quality-gates.md), blind 3-reviewer code review (`run.sh:r