Head to head
Direct Alternative
jCodeMunch vs RepoMapper
At a glance: jCodeMunch vs RepoMapper
| jCodeMunch | RepoMapper | |
|---|---|---|
| Token reduction on code exploration | ✓ ~95 % | ~ Token-budgeted map (not retrieval) |
| Symbol-level extraction (functions, classes) | ✓ 79 languages (incl. YAML/Ansible, Razor/Blazor, SQL/dbt, Erlang, Fortran, Pascal, MATLAB, Ada, COBOL, Zig, PowerShell) | ~ Signatures only, no retrieval |
| Doc section search | ✓ via jDocMunch | ✗ |
| Requires pre-indexing | ✓ One-time, incremental; SHA-based freshness managed automatically via freshness_mode config (relaxed/strict); list_repos exposes git_head for agent-side freshness reasoning; index_file for single-file surgical updates; watch-claude auto-discovers Claude Code worktrees | ~ Per-query map generation |
| Works with AI agents (MCP) | ✓ Native MCP server (stdio, SSE, streamable-http); Claude Code hook integration (PreToolUse/PostToolUse → index-file); 5 built-in MCP prompt templates (workflow, explore, assess, triage, trace). Adaptive tool surface keeps the agent's tool budget in check: core/standard/full tiers, or tool_surface=counter collapses to a 3-tool front door (order/menu/route) that fits any tool-count cap (e.g. a 50-tool limit) with zero capability loss | ✓ Native MCP server |
| Import graph / reference tracing | ✓ find_importers (with has_importers flag), find_references, check_references, get_blast_radius (depth-scored risk + has_test_reach per file), get_changed_symbols, get_dependency_graph; get_untested_symbols (import-graph test reachability); TS/SvelteKit path alias resolution; cross-repo via cross_repo=true on find_importers, get_blast_radius, get_dependency_graph + dedicated get_cross_repo_map | ~ Dependency graph for ranking only |
| Architecture-decision context (revert/tradeoff/root-cause history surfaced during analysis) | ✓ get_blast_radius / get_impact_preview surface git-mined decision-bearing commits (revert/perf/refactor/rename/bugfix) + a volatility read (v1.108.59, opt-in include_decisions); get_symbol_provenance adds a per-symbol decision narrative. Read-only: surfaced from the commit record, never persisted | ✗ |
| Write / modify files | ✗ Read-only by design | ✗ |
| Runs fully offline / local | ✓ Local index, no backend | ✓ |
| Commercial use permitted | ✓ Paid license available | ✓ MIT |
| License | Free non-commercial; paid commercial | MIT |
| Dead code detection | ✓ find_dead_code: free; confidence-scored; cascading dead-code chains; entry-point heuristics | ✗ |
| Semantic / hybrid search | ✓ Opt-in BM25+vector (embed_repo); 3 providers: sentence-transformers, Gemini (task-aware), OpenAI; pure BM25 when disabled | ✗ |
| Token-budgeted retrieval | ✓ get_ranked_context (BM25 + PageRank strategies) + get_context_bundle budget params | ~ Map-based (not retrieval) |
| Works alongside the others | ✓ Complements all of them | ✓ |
RepoMapper
is an open-source Python MCP server that generates a token-budgeted "map" of a repository
by applying PageRank to a dependency graph built with Tree-sitter: a direct port of the
"Repo Map" feature Aider uses internally. Given a token budget (e.g. --map-tokens 2048),
it selects the most important files and surface-level signatures to fill that window.
Small, focused project: 198 stars, ~25 commits, last activity December 2025; intentionally one-tool scope.
RepoMapper
Ranked overview of the whole repo
- PageRank over a Tree-sitter dependency graph identifies the most-referenced files
- Binary search fills a specified token budget to within ~15% of the limit
- Surfaces class/function signatures, not bodies, to maximise breadth per token
- 34+ languages via Tree-sitter grammars
- Single
repo_maptool: simple API, low learning curve - MIT-licensed; based on Aider's proven RepoMap algorithm
jCodeMunch
On-demand retrieval + direct one-tool parity
get_repo_map(v1.101.0): direct RepoMapper parity. Query-less, token-budgeted, signature-only repo overview ranked by PageRank. One tool, four optional parameters.search_symbolsfinds a function by name: no map to scan, no signatures to skimget_symbol_sourcereturns the complete implementation body, not just the signature- Index is built once; subsequent queries are O(1) and sub-millisecond
find_importersandfind_referencestrace call graphs across the whole repoget_symbol_importanceranks symbols by PageRank or in-degree: on demand, no static mapget_ranked_contextassembles a token-budgeted context bundle ranked by BM25 + PageRank combined score: same idea asrepo_map, but query-driven and with full bodiesget_tectonic_mapgoes further than PageRank: fuses structural (imports), behavioral (shared symbol references), and temporal (git co-churn) signals to surface logical module boundaries, drifters, and god-module risk- jDocMunch covers documentation: section search across .md, .rst, .ipynb, HTML
- 90+ tools covering outlines, content, search, context bundles, import graphs, dead-code detection, and refactor planning
The core architectural difference:
RepoMapper is a summariser. It compresses an overview of the repo into
a fixed token budget for the agent to orient itself.
jCodeMunch is a retriever, the agent asks a precise question
(
search_symbols("authenticate")) and gets a precise answer.
Summarisers are great for "What matters here?": retrievers are great for
"Where is this, exactly?" Both questions arise in a real coding session;
they are not in competition.
v1.101.0 closes the last gap:
get_repo_map(repo, token_budget=2048) is a direct one-call counterpart
to repo_map(project_root). Query-less, signature-level, token-budgeted,
PageRank-ranked. Same job, same API shape, on jCodeMunch's already-built index.
You also get get_tectonic_map (multi-signal orientation:
imports + shared references + git co-churn) and get_ranked_context
(query-driven retrieval with full bodies). The orientation toolkit goes broader
and deeper than a single PageRank map.
Verdict: jCodeMunch covers both jobs at parity or better
For retrieval (find this function, read its body, trace its callers), jCodeMunch is
strictly faster and cheaper: a single
search_symbols call costs a fraction
of any map-based approach. For orientation, get_repo_map gives RepoMapper
parity at the API surface (one call, token budget in, ranked signature map out), while
get_tectonic_map and get_ranked_context exceed what
repo_map offers algorithmically. RepoMapper remains a fine choice when
you want a tiny single-purpose dependency and no index lifecycle at all.
Keep comparing
More comparisons
jCodeMunch vs caveman · jCodeMunch vs RTK · jCodeMunch vs Headroom · jCodeMunch vs CodeGraph · jCodeMunch vs GitNexus · jCodeMunch vs Serena · jCodeMunch vs Repomix · jCodeMunch vs Context Mode · jCodeMunch vs codebase-memory-mcp · jCodeMunch vs Ponytail
The full comparison of all 47 tools, with every one side by side in a single table.
caveman vs Ponytail vs RTK vs Headroom vs jCodeMunch: which one saves which tokens.