Claude Code Codebase Intelligent Brain: 27× Token Saving, Killer Open-Source Tool.
https://github.com/repowise-dev/repowise…
This is Repowise — a codebase intelligence platform built for AI‑assisted engineering teams. It indexes your entire codebase (even multiple repositories) into four intelligence layers in one shot: dependency graph, Git history, auto‑generated documentation, and architectural decisions. Then, through seven MCP tools, it feeds directly into Claude Code or any MCP‑compatible agent — so AI no longer blindly reads entire files, but truly understands why, who changed it, where it’s dead, and how things are connected. Your codebase finally has a real brain.

repowise-dev/repowise

Source: https://github.com/repowise-dev/repowise

The codebase intelligence layer for your AI coding agent.

Four intelligence layers. Seven MCP tools. Multi-repo workspaces. Auto-sync hooks. One pip install.

PyPI version (https://pypi.org/project/repowise/) · License: AGPL v3 (https://www.gnu.org/licenses/agpl-3.0) · Python (https://pypi.org/project/repowise/) · MCP (https://modelcontextprotocol.io) · Stars (https://github.com/repowise-dev/repowise)

Explore real codebases → (https://www.repowise.dev/explore) · Hosted for teams → (https://www.repowise.dev/#contact) · Docs (https://docs.repowise.dev) · Discord (https://discord.gg/cQVpuDB6rh) · Contact

Your AI coding agent reads files. It doesn’t know which ones change together, which ones are dead, or why they were built the way they were. It has the source code and no memory of how the codebase got there.

repowise fixes that. It indexes your codebase into four intelligence layers — dependency graph, git history, auto-generated documentation, and architectural decisions — and exposes them to Claude Code (and any MCP-compatible AI agent) through seven precisely designed tools.

Multi-repo? Initialize a workspace and get cross-repo co-change detection, API contract extraction, and federated MCP queries across all your services.

27× fewer tokens per query. 36% cheaper. Same answer quality.

The result: your agent answers “why does auth work this way?” instead of “here is what auth.ts contains.”

🏆 Benchmarked against frontier LLMs

repowise-bench → (https://github.com/repowise-dev/repowise-bench) — an open SWE-QA benchmark that grades how well standard LLMs answer real software-engineering questions over real repositories.

On 48 paired tasks from pallets/flask (claude-sonnet-4-6, end-to-end), repowise-augmented Claude Code matches baseline answer quality while being dramatically leaner:

Metric (per task, mean)	Baseline	+ repowise	Δ
💰 Cost	$0.1396	$0.0890	−36 %
⚡ Wall time	41.7 s	33.9 s	−19 %
🛠️ Tool calls	7.4	3.8	−49 %
📄 Files read	1.9	0.2	−89 %

32 / 48 (67 %) tasks are cheaper with repowise — at parity quality (judge Δ ≈ −0.01).

Token efficiency — because context windows aren’t free

There’s a small genre of “token efficiency” benchmarks going around. It would be impolite not to contribute one. Ours runs on the 30 most recent non-merge commits of pallets/flask and asks one question: to understand a commit, how many tokens does each strategy ask the model to read?

209× less than naive (mean), 26.8× pooled, 1,214× best case. 41.7× less than git diff (mean), 6.2× pooled. Same file list, same tokenizer (cl100k_base), no per-strategy fudge. We report mean, pooled, and median together because picking just one would be the kind of thing other people in this genre seem to do.

Full methodology, per-task tables, and the actual SWE-QA evaluation (which has third-party ground truth and an independently-scored LLM judge — unlike this sanity-check): repowise-bench → (https://github.com/repowise-dev/repowise-bench)

What repowise builds

repowise runs once, builds everything, then keeps it in sync on every commit.

◈ Graph Intelligence

tree-sitter parses every file across 14 languages into a two-tier dependency graph — file nodes and symbol nodes (functions, classes, methods). A 3-tier call resolver with confidence scoring handles import aliases, barrel re-exports, and namespace imports. Heritage extraction covers extends, implements, trait impls, derive macros, mixins, and extension conformance. Leiden community detection finds logical modules even when your directory structure doesn’t reflect them. PageRank, betweenness centrality, SCC analysis, and execution flow tracing from entry points identify your most central, most coupled, and most traversed code.

◈ Git Intelligence

Your git history turned into signals: hotspot files (high churn × high complexity), ownership percentages per author, co-change pairs (files that change together without an import link — hidden coupling), and significant commit messages that explain why code evolved.

Rolled up into contributor profiles (per-author module rollups, top files, co-authors, silo modules, dead-code burden), module health scorecards (composite score over churn × ownership × docs × dead code × bus factor), and reviewer suggestions for any PR file list, weighted by direct authorship, co-change history, and recency.

◈ Documentation Intelligence

An LLM-generated wiki for every module and file, rebuilt incrementally on every commit. Coverage tracking. Freshness scoring per page. Semantic search via RAG. Confidence scores show how current each page is relative to the underlying code.

◈ Decision Intelligence

The layer nobody else has. Architectural decisions captured from git history, inline markers, and explicit CLI — linked to the graph nodes they govern, tracked for staleness as code evolves.

# WHY: JWT chosen over sessions — API must be stateless for k8s horizontal scaling
# DECISION: All external API calls wrapped in CircuitBreaker after payment provider outages
# TRADEOFF: Accepted eventual consistency in preferences for write throughput

These become structured decision records, queryable by Claude Code via get_why().

Quickstart

pip install repowise

Or install the CLI into an isolated, uv-managed environment:

uv tool install repowise

Single repo

cd your-project
repowise init                          # builds all four intelligence layers (~25 min first time)
repowise serve                         # starts MCP server + local dashboard

Multi-repo workspace

cd my-workspace/                       # parent dir containing backend/, frontend/, shared-libs/
repowise init .                        # scans for git repos, indexes each, runs cross-repo analysis
repowise serve                         # workspace dashboard + per-repo pages

That’s it. repowise init automatically registers the MCP server, installs PreToolUse/PostToolUse hooks in ~/.claude/settings.json, generates .mcp.json at the project root, and offers to install a post-commit git hook that keeps everything in sync after every commit. See Auto-Sync for all sync methods (hooks, file watcher, GitHub/GitLab webhooks, polling).

To manually add the MCP server to another editor:

{
  "mcpServers": {
    "repowise": {
      "command": "repowise",
      "args": ["mcp", "/path/to/your/project"]
    }
  }
}

Note on init time: Initial indexing analyzes your entire codebase — AST parsing, git-history mining, LLM doc generation, embedding indexing, and decision archaeology. This is a one-time cost (~25 minutes for a 3,000-file project). Every subsequent update after a commit takes under 30 seconds and only regenerates the few pages affected by your changes.

Full docs: Quickstart · User Guide · CLI Reference · MCP Tools · Workspaces · Computed Glossary · Auto-Sync

Workspaces — multi-repo intelligence

Most codebases aren’t one repo. repowise workspaces let you index and query multiple repositories together — with cross-repo intelligence that single-repo tools can’t provide.

cd my-workspace/                       # backend/, frontend/, shared-libs/ under one parent
repowise init .                        # scan, select repos, index each, run cross-repo analysis

What you get on top of per-repo intelligence:

Workspace CLI:

repowise workspace list                                    # show all repos and their status
repowise workspace add ../new-service                      # add a repo (auto-indexes + docs by default)
repowise workspace remove api-gateway                      # remove a repo (doesn't delete files)
repowise workspace scan                                    # re-scan for new repos
repowise update --workspace                                # update all stale repos + first-time index any new ones
repowise update --repo backend                             # scope to one repo (auto-detected from cwd too)
repowise watch --workspace                                 # auto-update all repos on file change
repowise doctor --workspace --repair                       # validate every repo; sync state drift; drop dead entries
repowise hook install --workspace                          # install post-commit hooks for all repos

Most commands also accept --no-workspace to force single-repo mode and --repo <name> to scope to one repo. See CLI Reference.

Full guide: docs/WORKSPACES.md

Seven MCP tools

Most tools are designed around data entities — one module, one file, one symbol — which forces AI agents into long chains of sequential calls. repowise tools are designed around tasks. Pass multiple targets in one call. Get complete context back.

Full reference: docs/MCP_TOOLS.md

Tool call comparison — a real task

“Add rate limiting to all API endpoints.”

The 5 calls for that task:

get_overview()                              # orient: understand the architecture
get_context(["middleware", "api/routes", "payments"])  # understand 3 modules at once
get_risk(["middleware/auth.ts"])            # assess: 47 dependents, co-changes
get_why("rate limiting")                    # check: any prior decision?
search_codebase("rate limit OR throttle OR retry")  # find: any prior implementation?

How Claude Code uses it

User: Implement rate limiting on all API endpoints  

Claude Code:  
→ get_overview()  
"Express API. Entry points in api/routes/. Middleware in middleware/."  

→ get_context(["middleware", "api/routes", "payments"])  
middleware/: existing chain is cors → auth → routes. Owner: @alex.  
api/routes/: 23 route files. No existing rate limiting.  
payments/: Owner @sarah (71%). Decision: all side effects must be idempotent.  

→ get_why("rate limiting")  
"No prior decision found. No prior implementation detected."  

→ get_risk(["middleware/auth.ts"])  
"47 files import this. Co-changes with all 4 service listeners.  
Risk summary: any interface change here touches 47 dependents."  

→ search_codebase("rate limit throttle retry")  
"Found: payments/retry.ts already has RetryQueue class.  
Found: payments/middleware.ts has idempotency key middleware."  

Implementing rate-limiting middleware, inserting after cors, before auth. Will also update tests/middleware.test.ts — detected as historical co-change partner. Flagging payments/ for @sarah review — hotspot, high ownership concentration.  

This is what happens when an AI agent has real codebase intelligence.

Local dashboard

repowise serve starts a full web UI alongside the MCP server. No separate setup — browse your codebase intelligence directly in the browser.