Understand your codebase without paying your agent to rediscover it.

Repowise indexes your code, dependency graph, git history, tests,
documentation, and decisions once, then gives agents and developers cited answers,
change impact, and concrete code-health fixes.

−31.6%	97.2%	2.3×
less agent output 3.8 vs 7.2 tool calls n=43 · p<0.0001	smaller context payload 393 vs 13,984 tokens 30 Flask commits	more defects surfaced same 20%-of-lines budget 2,770 files · p=0.003

_{Graph accuracy leader at matched coverage.
No tool finding as much was more precise in all 7 compiler-graded cells.
5 tools · 37,853 oracle edges}

_{Zero LLM calls for graph, risk, health, tests, dead code, and PR review. Generated prose is optional. Every benchmark publishes its sample, method, limitations, and losing rows.}

_{Free and self-hosted · core analysis stays on your infrastructure · no API key needed · AGPL-3.0 or commercial}

Why Repowise · Agents · Changes · Code health · Workspaces · Evidence · Enterprise · Docs

One index. Three ways to use it.

These are not disconnected scanners. The graph locates what git history flags; code health measures it; tests show what guards it; decisions explain why it exists; and the same evidence reaches your agent, editor, pull request, local dashboard, and cross-repository system map.

_{A dashboard tour recorded on this repository. The same local index powers the UI, MCP tools, editor views, and PR analysis. No API key and nothing uploaded.}

Pick your front door

Start in minutes (no API key)

pip install repowise
cd /path/to/your/repo
repowise init --no-prose -y
repowise serve

That builds the graph, git, decisions, health, dead-code and structural-wiki layers locally. Connect Claude Code, Codex, Cursor or any MCP host, or open the dashboard. init wires Claude Code automatically. Then ask your agent: "Use Repowise get_overview to summarize this repository" or "What breaks if I change src/auth.py?"

Full setup, every agent, and optional model-written prose →

Your agent stops guessing

Every question your agent asks about a repository has an answer that could have been computed ahead of time. Who calls this function? What breaks if I change it? Why is it written this way? Which files are actually dangerous? Without an index, the agent rediscovers that answer on every task: grep, read, re-read, forget.

Repowise exposes ten task-shaped MCP tools to Claude Code, Codex, Cursor, VS Code and anything else that speaks MCP: graph, git, docs, decisions, and ten MCP tools behind one index. See the canonical surface. Most tools are built around data entities (one file, one symbol), which forces agents into long chains of sequential calls. These are built around tasks: pass several targets in one call, get complete context back.

Because the exploration work is already done, that phase mostly disappears. In a measured agent loop across 43 questions on django/django, Repowise cut the agent's own output by 31.6% (p<0.0001) and reached the answer in 3.8 tool calls instead of 7.2. That is the end-to-end result.

One mechanism is much larger but narrower: loading a commit's context through get_context costs 393 tokens instead of 13,984, or 97.2% less. That is one retrieval payload, not a claim of 97.2% total agent savings. Both measurements and every competitor row are published in the benchmark report.

And it arrives without being asked. Optional hooks push context into the session at the moment it matters: the governing architectural decision when your agent edits a file that decision covers, a warning when it touches a file with a run of recent bug fixes, a compact briefing at session start. Repowise also generates your CLAUDE.md and AGENTS.md from the real index, so even an agent with no MCP support starts informed.

It learns from how you actually work. Repowise reads your own agent transcripts for the corrections you keep making ("use the shared HTTP client, not raw requests") and turns the durable ones into tracked decisions it delivers back later. The wiki generation budget tilts toward the modules you and your agent ask about most. All local, all deterministic, no extra LLM calls.

Also: stop paying for output nobody reads

Most of what an agent reads back from a shell command is noise: 300 lines of passing tests wrapped around 4 failures, full commit bodies when it asked "what changed recently". repowise distill <cmd> compresses command output before the agent reads it, errors first, exit code preserved.

repowise distill pytest          # 61% fewer tokens, all 11 failure lines kept
repowise distill git log -50     # 89% fewer tokens
repowise saved                   # what distillation saved you, in tokens and dollars

Nothing is lost. Every omission leaves an inline [repowise#<ref>] marker that repowise expand <ref> reverses in full, so the agent can always pull the detail back without re-running the command. Small outputs pass through untouched. An opt-in hook rewrites noisy commands automatically, shown to you for approval first.

_{The Costs dashboard tallies both savings surfaces, priced at your own agent's model. Example from a week of heavy local use.}

Full guide: docs/agent/DISTILL.md →

Know what's dangerous before you merge

Four deterministic signals, all computed from the graph and git history, no LLM:

• Change risk. Score any commit or base..HEAD range 0-10 from the shape of the diff, ranked against your repo's own recent commits. PR mode returns directives rather than vibes: may_break, missing_cochanges, missing_tests, tests_to_run. One command: repowise risk main..HEAD. (reference →)
• Bug history. Which files and symbols actually get bug-fixed, and how recently. Doc, test and config commits are filtered out so the count means what it says, and a file with a run of recent fixes gets flagged as a bug magnet while you edit it. (reference →)
• Test intelligence. Which tests reach a file and which ones a diff actually exercises, from the call graph, with or without a coverage report. (reference →)
• Change coordination. Which other open branches edit the files you are editing, every row saying why it is listed (same file, or a co-change pair with the commit counts behind it), and whether the diff in front of you is one change or several groups the index links nothing between. Both stay quiet when there is nothing to report. repowise overlap and repowise risk. (reference →)

Plus the free Repowise PR Bot, which puts all of it on every pull request. Zero LLM calls.

Which tests cover this file, without a coverage report

Ingest LCOV, Cobertura or Clover and you get the measured answer. Most repositories never produce one, so the graph answers instead: a test file that imports a source file reaches it, which is a recorded edge rather than the name-shaped guess everything else falls back to.

That fallback fails in both directions, and this repo is the proof. Five of its six worst bug-magnet files have no test named for them and read as untested while the graph names 3 to 23 test files each. The sixth is worse: matching on basename paired the health engine with the distill engine's tests and called it tested.

repowise impacted-tests main..HEAD   # only the tests this diff actually exercises
repowise health                      # untested hotspots, now graph-aware

_{Dogfooded against a real coverage run --contexts=test: 95.7% precision on what reaches a file and 97.5% on the run list, at a 100% hit rate, against 72.1% and 94.8% for the one-hop import walk this replaced. The two tiers are never averaged: rows are stamped basis: "measured" or "inferred", measured wins outright where both can answer, and the inferred tier may never produce a percentage. Sound as a floor, unsound as a quantity, and labelled so. Test intelligence →}

The PR bot

Install the GitHub App and the index shows up where the decision actually gets made. One comment per pull request, edited in place on every push rather than reposted, and a green PR gets no comment at all.

_{See a real comment on a real PR, not a mockup: repowise-dev/repowise#1204.}

What decides a review is inline. What is context sits behind one fold, so the comment stays about seventeen rows whatever it finds.

• Blast radius, at symbol level. The contracts this PR changed and every caller of them in a file the PR does not touch. Importing a module says nothing about whether the function you changed is the one being called, so file-level impact is the wrong altitude for the question a reviewer actually has.
• Before you merge. The tests that import your changed files, and the files that changed alongside them in past commits but are missing here.
• A Check Run that can gate the merge, with annotations on the specific lines the PR added. Advisory by default.
• Change risk, scored against the repository's own commit distribution rather than an absolute scale, so it stays meaningful on a repo whose typical commit is large.
• AI vs human authorship of the changed files, with the average health of each.
• Then hotspots, hidden coupling, declining health, dead code and the change map, one fold down.

And a page the comment links to

Markdown runs out. The comment shows three callers and says "+6 more"; the page shows all nine. Public, no sign-in, on a repository the reader has never seen.

_{The page leads with change risk and newly introduced findings, then maps every changed file and outside caller across the repository. See it live →}

Install the PR bot → · how it works →

★ Know exactly what to fix

A score that says "this file is risky" is where most tools stop. Repowise scores every file, locates where the risk concentrates, and then names the specific fix.

Every file is scored 1-10 by 49 deterministic detectors (McCabe complexity, brain methods, LCOM4 cohesion, god classes, native Rabin-Karp clone detection, untested hotspots, change entropy, prior-defect history and more), split into three lenses: defect risk, maintainability, and performance: static N+1 and I/O-in-loop risk traced across files through the call graph, where file-local linters found 0 of the cross-function cases and repowise surfaced ~90. Only 26 of the 49 are permitted to move the defect number, because that is the number carrying published accuracy claims.

Zero LLM calls, zero cloud, zero new runtime dependencies. Pure Python over tree-sitter and git data, under 30 seconds on a 3,000-file repo, a budget enforced by a CI test, not an estimate. Marker weights are calibrated against a real defect corpus, not hand-tuned: every file scored at a commit preceding the bug window so nothing leaks backward, and an L2-logistic fit with file size as an explicit control, so a marker only earns weight for defect lift beyond being big. Only the learned constants ship.

It proves itself on your repo, not just on a benchmark. After every index, Repowise checks its own flags against your git history and reports what it found: "16 of the 20 lowest-health files had a bug fix in the last 6 months, 3.3x the 24% baseline." If that number is bad on your codebase, you will see it. (It is an association on your indexed history, not a forward prediction, the leakage-free version is in the benchmarks.)

Then it names the fix. Not "this class is too big", but Extract Class, Extract Helper, Move Method, Break Cycle, Split File, or Extract Method, with the exact methods, edges and symbols that move, the blast radius of callers and co-changing files that have to move with them, and a graph-aware ranking so a fix on a central hub outranks the same fix on a leaf. Extract Method goes down to an intra-procedural dataflow pass that lifts the exact span and infers a behavior-preserving signature.

repowise health                        # KPIs and lowest-scoring files
repowise health --refactoring-targets  # ranked, concrete plans
repowise health --trend                # snapshots plus declining-health alerts

The dashboard renders each plan as a card with a copy-to-agent button. An optional LLM step, never in the indexing path and only on request, expands any plan into generated code and a unified diff.

_{Validated on 21 open-source repos across 9 languages (2,826 files, scored at a fixed point and checked against the following 6 months of bug fixes, keyword-labelled): ROC AUC 0.737 [0.683, 0.787]. The signal is correlated with file size and weakens sharply within a fixed size band, which we report rather than bury. Independently recomputed from the raw data.}

_{Against CodeScene, the leading commercial code-health tool, on the same 2,770 files and the same defect labels, ranking by repowise health surfaces 2.3x the defects under a fixed review budget (paired, p = 0.003). Full head-to-head, methodology and limitations →}

Guides: code health · refactoring

See all of it

repowise serve starts the full web dashboard next to the MCP server. No separate setup, all local.

Architecture · the dependency graph, laid out and explorable, with per-node context and change coupling	Code Health · every file as a bubble, hover any one to inspect its score, size, coverage and findings
Chat · ask the codebase a question, answers cite the files and pages they came from	Docs · auto-generated wiki pages for the whole codebase, with confidence and freshness badges

Also in there: Chat (ask the codebase in natural language) · Docs (the generated wiki, with Mermaid and a graph sidebar) · Architecture and C4 (Context → Containers → Components) · Knowledge Graph plus a zoomable canvas map · Risk, Hotspots, Coupling and Blast radius · Contributors · Decisions (evidence drawer and evolution timeline) · Symbols · Security · Dead code · Stats · Costs · Workspace.

Every view and what each one answers: docs/start/DASHBOARD.md →

One intelligence layer across your software estate

Real systems are not one repository, and the expensive failures live in the gaps between them. Change a backend contract and Repowise can name the frontend calls that consume it, the services downstream, the historical companion files missing from the change, and the architecture rule the new dependency violates before it ships.

The system map models services, not merely repository boxes, and never conflates a real contract with “these files often changed together.” HTTP field-level comparison supports the bounded OpenAPI 3.x JSON subset documented in the workspace guide; matched consumers prove endpoint exposure, not field use or runtime failure.

Workspace guide and exact support matrix →

Worktrees and updates stay lightweight: a linked worktree seeds its index from the base checkout automatically, and post-commit hooks, file watching, webhooks, or polling keep each repository and the cross-repo graph current.

In your editor

The Repowise VS Code extension puts the index where code actually gets written: know what your change breaks before you push (riskiest files ranked, what is downstream, forgotten companion files, missing tests, suggested reviewers), health in the gutter and status bar, callers and ownership on hover, refactoring plans as CodeLens, and the full dashboards inside the editor. One install also registers the MCP server with VS Code, so the same local index serves both you and your agent, and exposes six tools to GitHub Copilot. Quiet by default, everything toggleable, nothing leaves your machine.

Install from the Marketplace (search Repowise) or Open VSX, then run Repowise: Set Up This Repository. Guide: docs/agent/VSCODE.md →

Supported agents

Six agents wired end to end · two at the Full tier · every other MCP host one paste away.

Supported languages

25 languages parsed to AST · 39 on a five-rung ladder · framework-aware across all of them.

"Do you support X" has five useful answers, not two, so languages land on a ladder and every rung says what it buys you.

pip install repowise          # Windows: python -m pip install repowise
repowise --version

cd /path/to/your/repo
repowise init

repowise init --no-prose -y    # free, no key, no questions
repowise init --prose -y       # model-written subsystem pages, cost pre-approved

export ANTHROPIC_API_KEY="sk-ant-..."   # or OPENAI_API_KEY / GEMINI_API_KEY
repowise generate                       # write the unwritten subsystem pages, behind one cost estimate
repowise generate --path src/api        # or just one area first
repowise generate --all                 # or rewrite the prose on every subsystem page

repowise init . --resume

repowise agents add --target=claude-code

/plugin marketplace add repowise-dev/repowise
/plugin install repowise@repowise

claude mcp add repowise -- repowise mcp

{ "mcpServers": { "repowise": { "command": "repowise", "args": ["mcp"] } } }

[mcp_servers.repowise]
command = "repowise"
args = ["mcp"]

The ten MCP tools

Every response carries an _meta envelope with index_age_days, indexed_commit, and a stale_warning that fires only when the indexed HEAD diverges from live .git/HEAD, so your agent always knows how much to trust what it just read.

Measured against the field

Six open-source agent-context tools, the same repositories, the same pinned commits, the same questions, each one given its own full advertised tool surface. The full page carries the rows we lose beside the rows we win.

Token reduction needs a denominator. If the comparison is one context payload, Repowise reduces 13,984 naive-read tokens to 393, a 97.2% reduction. If the comparison is the agent's complete output across a real task loop, the reduction is 31.6%. Competitor pages often publish the first kind as "token savings"; we publish both and call only the second one agent savings.

The same rule applies to graphs: coverage without correctness rewards fake edges, while precision without recall rewards drawing almost nothing. Our compiler-graded claim is therefore the pair: in all seven comparisons, no tool that recovers as much of the call graph gets more of it right.

• Finds the right files. 0.876 file coverage against CodeGraph's 0.610 on a sealed 42-instance split, held out from every improvement round. 19 wins, 1 loss per instance. Deterministic grading, no LLM judge. n=42, sign test p=0.00004. CodeGraph scores the same on both halves to three decimals, so neither half is the easy one.
• Less work in a real agent loop. -31.6% output tokens against a bare agent, leaner on 37 of 44 questions. n=43, p<0.0001. CodeGraph is a genuine second at -24.4%: more than one tool here works, and we lead the field rather than being alone in it.
• Fewer steps to get there. 3.8 tool calls where the bare agent needed 7.2, and 3.0 files opened instead of 7.2, the mechanism behind the token saving, visible directly rather than inferred.

The full results, the methodology, and the rows we lose →

How it compares on capability

No single product competes with all of this, so there is no single table. Three axes, three sets of real peers. Rows marked measured are head-to-head numbers, and they link to docs/BENCHMARKS.md where the sample sizes, the tests and the rows we lose all live.

For teams and enterprises

AI makes producing a change cheaper; it does not make understanding its consequences cheaper. In a large estate, the answer crosses repositories, ownership boundaries, service contracts, test suites, and years of architectural history. Repowise gives developers, agents, reviewers, and platform teams the same evidence about what exists, what depends on it, what is risky, and what will break.

That is the engineering reason to deploy it. The security reason is structural: graph, git, health, change risk, tests, dead code, and PR review make zero LLM calls. Documentation prose is optional and can use your provider contract or run fully offline through Ollama.

Self-host with pip install or run the API, workers, dashboard, Postgres, and LanceDB/pgvector containers on your infrastructure. Deterministic analysis needs no provider. When optional prose is enabled, provider choice is per repository. Stored data includes the graph, embeddings, wiki pages, and git metadata; raw source is processed transiently and is not persisted.

Past one repository. Workspaces index an estate as one unit: API contracts matched producer to consumer so a breaking change is caught before it ships, cross-repo co-change, and one federated MCP endpoint that answers across all of it. (Estate-scale dashboards: in development.)

Not on git? Only the history layer needs a commit log. Point repowise init at a plain directory, an export, or a Perforce or SVN workspace and the graph, documentation, decisions and code-health layers all build normally; what is missing is hotspots, ownership, co-change and bug history until the history layer learns to read your system. (Perforce, SVN, Endevor and ChangeMan on the roadmap →)

The complete capability matrix is maintained in COMMERCIAL.md, with every item labelled GA, rolling out, in development, or planned.

repowise.dev runs the same engine fully managed, at feature parity with self-hosted. We run it on our own codebase in the open: live snapshot → · explore public repos →.

Commercial detail and pricing models → · Security review pack → · Roadmap → · hello@repowise.dev · security@repowise.dev

Privacy

• Deterministic or offline mode: with --no-prose, code-derived content stays on your infrastructure. The CLI reports anonymous, opt-out usage telemetry (command names and coarse environment only); disable it with repowise telemetry disable, DO_NOT_TRACK=1, or by running fully offline. What's collected →
• Optional LLM features: generated prose, decision extraction and code-generating refactoring can send code-derived prompts directly to the provider configured with your own key. Repowise does not proxy those calls; provider handling and retention follow your account and provider terms.
• What's stored: the graph, embeddings, generated wiki pages, and git metadata. Raw source is processed transiently and never persisted. See the security review pack for the threat model and data-flow boundaries.
• Fully offline: Ollama plus a local embedding model means zero external calls.

Doing a security review? docs/business/SECURITY_COMPLIANCE.md →

CLI

repowise init [PATH]      # index a codebase (one-time; asks, or --no-prose -y needs no LLM)
repowise generate [PATH]  # write wiki pages with a model, on demand (upgrade a keyless wiki)
repowise serve [PATH]     # MCP server + local dashboard
repowise update [PATH]    # incremental update (seconds; --workspace for every repo)
repowise watch            # auto-sync daemon, re-index on file change
repowise search "<q>"     # hybrid search (fulltext / semantic / symbol / path)
repowise ask "<q>"        # a synthesized answer with citations
repowise context <files>  # triage card: layer, hotspot, fix history, freshness
repowise symbol <id>      # one symbol's body, with verified line bounds
repowise why <q|path>     # decisions, rationale, git archaeology
repowise health           # code-health KPIs and lowest-scoring files
repowise risk main..HEAD  # score a branch or PR range for defect risk
repowise risk -t <file>   # what history says about touching a file
repowise impacted-tests   # only the tests a diff actually exercises
repowise dead-code        # unreachable-code report
repowise decision list    # architectural decisions
repowise export --format structurizr  # the architecture as Structurizr DSL, no LLM
repowise distill pytest   # compact, errors-first, reversible command output
repowise saved            # tokens and dollars saved by distillation
repowise workspace add    # multi-repo workspace management
repowise doctor           # check setup, API keys, index drift
repowise uninstall        # remove what repowise wrote, and say what it left

Every command and flag: docs/reference/CLI_REFERENCE.md · config: docs/reference/CONFIG.md · examples: examples/

Contributing

git clone https://github.com/repowise-dev/repowise
cd repowise
uv sync --all-packages
uv run repowise --version
uv run pytest tests/unit/

New here? You do not have to read 3,000 files to start. We keep a public index of this repo built by repowise itself, re-indexed on every push: explore repowise with repowise → (architecture, hotspots, ownership, decisions, and a ranked refactoring backlog you are welcome to pick from).

Full guide, including how to add languages and LLM providers: CONTRIBUTING.md · architecture: docs/architecture/

License

AGPL-3.0. Free for individuals, teams and companies using repowise internally.

For commercial licensing (the enterprise security and compliance layer, SSO/SCIM, RBAC, workflow integrations, priority support and SLA, or embedding repowise in a product without AGPL obligations), see docs/business/COMMERCIAL.md or contact hello@repowise.dev.