The durable context layer for Cursor and every agent.
repowise is not an editor, and it does not replace Cursor. It is the structured, cross-agent context layer that Cursor's built-in index is not: an architecture-aware wiki, dependency graph, decisions, git intelligence, and defect-validated code health, served to any MCP agent.
Cursor's index is great at one job: feeding the model a few relevant chunks inside the editor. But it is embeddings-only, single-repo, ephemeral, and locked to Cursor, so the context dies at the editor boundary.
repowise builds a durable, structured model of your codebase once, then serves it to every agent. The same architecture-aware wiki, dependency graph, decisions, git intelligence, and defect-validated health score feed Cursor, Claude Code, Cline, and Codex alike, through ten task-shaped MCP tools rather than raw nearest-neighbor retrieval.
Which one is right for you?
Choose repowise if
- You want a durable, structured context layer, not an ephemeral embeddings-only index
- You want the same context across every agent (Claude Code, Cursor, Cline, Codex), not locked to one editor
- You want curated answers (get_answer, get_context) instead of raw nearest-neighbor chunks
- You want an architecture wiki, dependency graph, decisions, git intelligence, and defect-validated code health, not just retrieval
- You want to self-host so code never leaves your infrastructure
Choose Cursor's index if
- You want a full AI IDE with inline editing, autocomplete, and agents in one place
- You want zero-setup in-editor retrieval that just works the moment you open a repo
- You only need ephemeral context inside a single repo, inside Cursor
- You want everything to live in one tool with no extra MCP server to register
repowise vs Cursor's index
| Capability | repowise | Cursor's index |
|---|---|---|
| In-editor codebase retrieval (RAG over chunks) | Included | Included |
| Full AI IDE: inline editing, autocomplete, agentsrepowise is a context layer, not an editor | Not included | Included |
| Zero-setup in-editor retrievalCursor's index just works; repowise needs an index + MCP registration | Partial support | Included |
| Works offline in-editorrepowise can run fully offline via Ollama; Cursor embeds on its servers | Partial support | Included |
| Durable, structured index (not ephemeral) | Included | Not included |
| Cross-agent via MCP (Claude Code, Cline, Codex, more)Cursor's index is Cursor-only | Included | Not included |
| Curated answers (get_answer / get_context), not just chunks | Included | Partial support |
| Architecture-aware wiki and documentation | Included | Not included |
| Tree-sitter dependency graph | Included | Not included |
| Defect-validated code-health score | Included | Not included |
| Git intelligence (hotspots, ownership, coupling) | Included | Not included |
| Architectural decision records | Included | Not included |
| Multi-repo workspace context | Included | Not included |
| Command-output distillation for agent terminal callsrepowise distill cuts 60-90% of tokens off noisy test/build/git output | Included | Not included |
| Dedicated VS Code extension (works inside Cursor too)Cursor is itself a VS Code fork with its own built-in context | Included | Partial support |
| Open source and self-hostable | Included | Not included |
Self-assessed against publicly documented features as of June 2026. A dash means partial or limited support. Vendor capabilities change, so please verify against Cursor's index's current docs before deciding.
Cursor's index ends at the editor. repowise does not.
Keep Cursor. Add a durable, structured context layer that every one of your agents can call, with the architecture, history, and health signals an embeddings-only index was never built to hold.
A structured model of your code, not a bag of vectors
Cursor's index stores chunks, line ranges, and file paths so the model can retrieve nearest neighbors. repowise builds five durable intelligence layers and serves curated, task-shaped answers, so an agent gets a real model of your code instead of a handful of similar snippets.
- Architecture-aware wiki, rebuilt incrementally on every commit
- Tree-sitter dependency graph across 16 languages, two-tier file and symbol nodes
- Architectural decisions mined from eight sources, with lineage and staleness
- Defect-validated code health: 21 deterministic markers, cross-project ROC AUC 0.74
Build context once, use it in every tool
Cursor's index only works inside Cursor. repowise is exposed over MCP, so the same context serves Claude Code, Cursor, Cline, Codex, and Windsurf. Switch editors and you keep your context instead of re-indexing and re-paying for it per tool.
- Ten MCP tools: get_overview, get_answer, get_context, get_risk, get_why, and more
- Register once in any MCP client, including Cursor itself
- Multi-repo workspaces: cross-repo co-changes and API contracts in one query
- Curated answers with cited sources and calibrated retrieval quality
up to 96% fewer context tokens, self-hostable, no telemetry
Every MCP call replaces a read-and-re-read loop with a curated answer, and the savings are measured in paired benchmarks. The core is open source under AGPL-3.0, so you can self-host the whole thing and your code never leaves your infrastructure.
- up to 96% fewer tokens to load context, 69% to 89% fewer file reads, 49% to 70% fewer tool calls
- Answer quality on par with the baseline in paired SWE-QA runs
- Self-host under AGPL-3.0, bring your own LLM key or run fully offline via Ollama
- Zero telemetry; raw source is processed transiently, never persisted
Every raw file read is a token bill.
Cursor's context window is the same one your agent burns through re-reading files it already saw. repowise's MCP tools replace that read-and-re-read loop with curated answers, and distill compresses the noisy command output around it, measured on paired benchmarks, not a vendor's estimate.
up to 96% fewer tokens to load context
In paired SWE-QA runs (same model, same harness, with versus without repowise), loading context through get_context used 2,391 vs 64,039 tokens, a reduction of up to 96%, at answer quality on par with the baseline.
Fewer file reads, fewer tool calls
69% to 89% fewer file reads and 49% to 70% fewer tool calls across the same benchmarks. Every avoided read is a round trip Cursor's agent mode does not have to make.
distill for the terminal output around the diff
pip install repowise, then repowise distill <cmd> compresses 60 to 90 percent of the tokens out of a noisy test run, build, or git log/diff before an agent reads it, keeping every error line. Curated context and distilled command output attack the same token bill from two sides.
Ten task-shaped tools, not raw retrieval
get_overview, get_answer, get_context, get_risk, get_why, get_change_risk, get_health, get_dead_code, get_symbol, and search_codebase. Each answers a specific question with citations and a calibrated confidence score, instead of returning nearest-neighbor chunks for the model to interpret.
Add repowise in four steps.
Keep Cursor open the whole time. repowise indexes your repo independently and registers as an MCP server; nothing about Cursor's own setup changes.
Install
pip install repowise. No Docker required, no account to create first.
Index for free
repowise init --yes --no-prose builds the wiki skeleton, dependency graph, git history, and full code-health score with no API key and no LLM spend.
Register the MCP server
Add repowise to Cursor's MCP config like any other server, and the same ten tools are available to Claude Code, Cline, and Codex too.
Add the VS Code extension
Because Cursor is a VS Code fork and supports VS Code extensions, the repowise VS Code extension can surface health scores and risk signals directly in Cursor's editor, alongside the MCP tools, not instead of them.
Two different answers to where your code runs.
Cursor's index is a hosted service by design. repowise's core is a self-hostable, open-source alternative for teams that want the context layer on their own infrastructure.
Source availability
repowise's core is open source under AGPL-3.0: every marker, every scoring rule, every heuristic is public and inspectable. Cursor is closed-source; its indexing and retrieval internals are not published.
Where your code runs
repowise can run on your own infrastructure, your VPC, or a laptop, and can operate fully offline with a local model via Ollama. Cursor's own docs describe indexing as a service running on Cursor's servers.
Cost model
Self-hosting repowise is free indefinitely, with optional hosted and enterprise tiers for zero-ops convenience. Cursor is priced as an editor subscription; verify current tiers on Cursor's own pricing page before comparing.
Portability
Because repowise is exposed over MCP rather than built into one editor, switching from Cursor to Claude Code, Cline, or Codex keeps the same index. There is no re-indexing tax per tool.
The honest version
Cursor is a genuinely great AI IDE, and there are things it does that repowise simply does not. Cursor is a full editor with inline editing, autocomplete, and agents in one place, while repowise is a context layer and not an editor at all, so you keep using your editor alongside it. Cursor's codebase index requires zero setup: it just works the moment you open a repo, with no index to build and no MCP server to register. And because retrieval runs inside the editor, it stays out of your way during ordinary in-editor work in a single repo. If ephemeral, in-editor retrieval is all you need, Cursor's built-in index is enough. repowise wins when you want context that is durable, structured, portable across every agent, and self-hostable, the layer an embeddings-only index was never meant to be.
What repowise costs.
The repowise core is open source under AGPL-3.0 and free to self-host, with every heuristic public. Hosted tiers: Free for public repos, Pro at $15 per month, Teams at $60 per month, and custom enterprise licensing when you need it. Cursor's index's pricing changes, so verify it on their site, then compare it with a tier you can read line by line.
Questions, answered
Does repowise replace Cursor?
No. repowise is not an AI editor and it does not replace Cursor. Cursor is an excellent IDE, and you keep using it. repowise is a context layer that sits underneath your agents: it builds a durable, structured model of your codebase and serves it to Cursor and every other MCP agent. Think of it as an upgrade to the context your editor already uses, not a competitor to the editor itself.
How is repowise different from Cursor's codebase index?
Cursor's own documentation describes its codebase index as embeddings over your files, computed and stored so the editor can retrieve nearest-neighbor chunks for @Codebase and inline chat. That is a good fit for "what looks related," but it is embeddings-only, effectively single-repo, and scoped to the Cursor editor. (Cursor's index details can change between releases, so treat the exact mechanics as Cursor's to document, not repowise's to describe precisely.) repowise builds durable intelligence layers instead, an architecture-aware wiki, a tree-sitter dependency graph, mined architectural decisions, git intelligence, and a defect-validated code-health score, then serves curated answers through ten MCP tools rather than raw nearest-neighbor chunks.
Can I use repowise with Cursor?
Yes, and that is the point. repowise exposes its index through the Model Context Protocol, so you register it in Cursor like any MCP server and your Cursor agent can call get_overview, get_answer, get_context, get_risk, and get_why. The same server also works with Claude Code, Cline, Codex, and Windsurf, so the context you build once is available in whichever tool you happen to be using.
Is repowise locked to one editor?
No. Cursor's built-in index only works inside Cursor. repowise is exposed over MCP, so the same structured context is available to Claude Code, Cursor, Cline, Codex, Windsurf, and any MCP-compatible client. You are not re-indexing per editor or re-buying context when you switch tools.
Is repowise self-hostable?
Yes. The repowise core is open source under AGPL-3.0, so you can run the whole platform yourself. You bring your own LLM key or run fully offline with Ollama, code never leaves your infrastructure, and there is zero telemetry. Cursor's index is a hosted service: chunks are embedded on Cursor's servers and the embeddings live in their vector database.
Does repowise cut token usage?
Yes, and it is measured. In paired SWE-QA runs on real repositories with the same model and harness, repowise cut the tokens needed to load context by up to 96% (2,391 vs 64,039 tokens through get_context, about 27 times fewer), with 69% to 89% fewer file reads and 49% to 70% fewer tool calls, all at answer quality on par with the baseline. Curated, task-shaped answers replace the read-and-re-read loop that raw retrieval leaves agents in.
What is distill, and why does it matter next to Cursor?
distill is index-aware output distillation: run repowise distill <cmd> in front of a noisy command, a test run, a build, git log or git diff, a search, and it compresses 60 to 90 percent of the tokens while keeping every error line, fully reversible. An agent working in or alongside Cursor still shells out to run tests and read diffs; distill cuts the token cost of that surrounding output, on top of the up to 96% already saved on loading context itself.
Does repowise work inside Cursor's own editor, not just as an MCP server?
repowise ships its own VS Code extension that surfaces health scores and risk signals directly in the editor. Because Cursor is a VS Code fork and supports standard VS Code extensions alongside its native MCP support, the extension can run inside Cursor too, in addition to the MCP tools, not as a replacement for them. Verify extension compatibility against your Cursor version, since fork compatibility can shift release to release.
Why not just rely on the editor's built-in index?
If all you need is ephemeral in-editor retrieval inside a single repo, Cursor's built-in index is genuinely enough and requires zero setup. repowise earns its place when you want context that is durable, structured, and portable: architecture-aware documentation, a real dependency graph, architectural decisions, git intelligence, and a defect-validated health score, reusable across every agent and self-hostable. The two are complementary, not mutually exclusive.
The ten MCP tools, in depth.
The defect-validated score, explained.
Give your agent real context, fewer file reads.
How the ten MCP tools cut agent context tokens.
Setting up repowise as an MCP server inside Cursor.
The read-and-re-read loop repowise's MCP tools and distill both target.
An earlier survey of the category; repowise now ships ten flagship tools.
See the wiki, dependency graph, and health score on a real index.