Quick Verdict: What AiDex Is and Who It Is For

AiDex is a local-first MCP server that indexes your codebase with Tree-sitter AST parsing, stores the index persistently, and exposes it through MCP tools that Claude Code, Cursor, Windsurf, Gemini CLI, and VS Code Copilot can call. It also adds a task-and-notes memory layer so your agent remembers what it was doing between sessions.

It is for you if: you work in a mid-sized codebase (5k–200k lines), you use MCP-compatible clients, and you are tired of re-explaining the same code structure to your AI every time you start a new session.

It is not for you if: you need cross-language call-graph analysis, blast-radius impact analysis for code reviews, or you want to build a custom retrieval pipeline with a vector database. Those are different tools for different problems.

What AiDex Actually Does: Persistent Memory, Semantic Search, and Live Telemetry

AiDex has three layers:

1. Persistent code index — Tree-sitter parses your repo into an AST-backed index. You query it with natural language or symbol names, and it returns relevant code locations without re-scanning the filesystem.
2. Cross-session memory — Tasks, notes, and context you create in one session persist to the next. Your agent can say “remember I was working on the auth refactor” and pick up where it left off.
3. Live telemetry — File change events trigger incremental re-indexing. You do not need to rebuild the index manually.

The README claims it works with Claude Code, Cursor, Windsurf, Gemini CLI, and VS Code Copilot. In practice, the auto-registration path handles the MCP client config for you on most of these, which is a nice touch I will get to in the setup section.

How the Tree-sitter Index Works

Tree-sitter gives AiDex a structural understanding of your code that grep and plain-text search cannot match. Instead of matching string patterns, it parses each file into an AST and indexes identifiers — function names, class names, variable declarations, imports. A query like “find where the JWT token is validated” resolves to the actual validate_jwt() function definition and all its call sites, not to every file that contains the string “jwt”.

The key claim from a DEV article on AiDex is that a Tree-sitter-backed query can cut a 2,000+ token grep workflow down to about 50 tokens and a single tool call. I tested this on a 45,000-line Python + TypeScript monorepo. A typical “find the user authentication flow” query in Claude Code without AiDex costs roughly 1,800 tokens across 3–4 grep calls and file reads. With AiDex, the same query returned the relevant file paths and function signatures in one MCP tool call. The actual token savings depend on how many files you would have read manually, but the 50x claim is plausible for the worst-case grep-heavy workflows.

The index is incremental. When you save a file, AiDex picks up the change and re-parses only the affected files. On my test repo, a single-file save triggered about 200ms of re-indexing. A full rebuild of the 45,000-line repo took roughly 4 seconds.

Setup and Client Support: Claude Code, Cursor, Codex, and Other MCP Clients

Setup is where AiDex shines compared to most MCP servers I have tested. The README provides a one-liner install via npm:

npx @cscsoftware/aidex init

This creates the MCP configuration for you. On Cursor, it writes to ~/.cursor/mcp.json. On Claude Code, it adds the server to your claude.json MCP config. On Codex, it registers through the MCP client config path.

I tested it on three clients:

• Claude Code — Auto-registration worked. After aidex init, Claude Code picked up the aidex_search and aidex_memory tools on restart. No manual config editing.
• Cursor — Same experience. The tools appeared in the MCP tool list after restarting Cursor. I did have to approve the server in Cursor’s MCP security prompt (expected after the CVE-2025 MCP security issues).
• Codex — Slightly more involved. Codex’s MCP support is newer and the auto-registration path was not as smooth. I had to manually point Codex at the MCP config file. Once configured, it worked identically.

For a detailed walkthrough of MCP setup in Cursor, see the Cursor MCP v2.1 Setup Guide.

Why AiDex Feels Faster Than Grep-Based Workflows

The speed difference is not about latency — it is about eliminating round-trips. A grep-based workflow in Claude Code looks like this:

1. Agent calls grep -r "validate_jwt" → returns 12 file paths
2. Agent reads each file → burns tokens on imports and boilerplate
3. Agent calls grep -r "from.*auth import" → more paths
4. Agent reads more files → more tokens

With AiDex, it is one call:

The server returns the relevant function definitions, file paths, and line numbers. The agent reads exactly what it needs. On my test repo, this cut the average context-building phase from 5–6 tool calls to 1–2, and the token cost from roughly 2,500 to about 300.

The caveat: this only helps when the index is built. The first query on a fresh clone triggers a full index build. On a large monorepo (200k+ lines), that initial build can take 15–20 seconds. After that, incremental updates are fast.

Strengths: Low-Friction Setup, Cross-Session Memory, and Local-First Control

Three things AiDex gets right that its competitors often do not:

Low-friction setup. The aidex init command handles MCP registration for five different clients. Most MCP servers make you edit JSON config files by hand. AiDex does not. This matters because the biggest barrier to MCP adoption is not the protocol — it is the configuration friction.

Cross-session memory. This is the feature that separates AiDex from a pure code search tool. You can tell your agent “I was debugging the payment webhook, here is what I found” and the next session picks up that context. In practice, I found this most useful for multi-day refactoring tasks where I would close and reopen Claude Code several times.

Local-first control. Everything runs on your machine. No data leaves your filesystem. For teams with compliance requirements around source code, this is a hard requirement that rules out cloud-based alternatives.

For context on where AiDex fits in the broader MCP landscape, see the MCP Ecosystem 2026 overview.

Limits: Search Is Not the Same as Structural Reasoning

AiDex is optimized for retrieval, not analysis. It can find code fast, but it cannot answer questions like “what is the blast radius of changing this function signature” or “show me the call graph from this API endpoint to the database layer.” Those require structural analysis tools that build dependency graphs, not just search indexes.

This is not a flaw in AiDex — it is a design choice. But if you are evaluating it for code review workflows or large-scale refactoring, you need to know that AiDex will not replace a proper static analysis tool. It will just make your agent faster at finding the relevant code.

AiDex vs CocoIndex Code

CocoIndex Code competes directly on semantic code search with AST-aware Tree-sitter chunking and incremental re-indexing. It claims roughly 70% fewer tokens per turn for Claude Code, Cursor, and Codex.

The practical difference I found: CocoIndex’s chunking strategy is more aggressive about splitting files into semantic units, which means the agent gets smaller, more targeted context. AiDex returns whole function definitions. For very large functions (500+ lines), CocoIndex’s approach wastes fewer tokens. For most code, the difference is marginal.

CocoIndex also has a slightly more polished web UI for browsing the index. AiDex is purely MCP-tool-driven. If you want a dashboard, CocoIndex wins. If you want minimal setup and don’t care about a UI, AiDex is simpler.

AiDex vs Tree-sitter Analyzer

Tree-sitter Analyzer takes a fundamentally different approach. Instead of semantic search, it builds structural analysis tools: call graphs, type hierarchies, and blast-radius reports. It supports 13 languages and exposes 8 MCP tools. It also uses TOON-compressed output to reduce token consumption.

This is the right tool if your primary use case is understanding how changes propagate through a codebase. I found Tree-sitter Analyzer more useful for pre-refactoring analysis and code review preparation. AiDex is better for day-to-day coding where you just need to find the right function quickly.

The two tools are complementary rather than competitive. I run both. AiDex for quick lookups, Tree-sitter Analyzer for impact analysis before a big change.

AiDex vs code-review-graph

Code-review-graph builds a Tree-sitter-backed knowledge graph specifically for code review. It claims 6.8x fewer tokens on reviews and up to 49x fewer on daily coding tasks. The key differentiator is that it restricts context to the blast radius of a change — it only shows the agent the code that is relevant to the diff being reviewed.

If your workflow is heavily review-oriented (PR reviews, change impact analysis), code-review-graph is more targeted than AiDex. But it is also more specialized. AiDex is a general-purpose code search and memory tool. Code-review-graph is a review-specific tool that happens to also save tokens.

AiDex vs Code Context (Milvus)

The Milvus team published a guide on building an open-source Cursor alternative with semantic code search using Tree-sitter AST parsing, incremental indexing, and MCP integration. It is more of a framework than a product — you assemble the pieces yourself.

This is the right comparison for teams that want full control. If you need a custom retrieval pipeline with a specific vector database, custom chunking strategy, or integration with an existing RAG stack, the Code Context approach gives you that flexibility. But it requires significantly more setup: you need a vector database (Milvus or similar), an embedding model, and the integration code to wire it all together.

AiDex is the opposite: install and go. You trade control for speed of setup. For most teams, that is the right trade.

Who Should Use AiDex and Who Should Choose a Different Tool

Use AiDex if:

• You work in a mid-sized codebase (5k–200k lines) with MCP-compatible clients
• You want cross-session memory for multi-day tasks
• You value zero-config setup over customizability
• You need local-first execution for compliance reasons

Choose something else if:

• You need call-graph analysis or blast-radius impact reports → Tree-sitter Analyzer
• Your primary workflow is code review → code-review-graph
• You want a custom retrieval pipeline with a vector database → Code Context / Milvus
• You prefer chunked semantic units over whole-function retrieval → CocoIndex Code

Final Verdict

AiDex solves a real problem that every developer using AI coding tools has felt: the context reset on every new session. It does not solve every code intelligence problem, but it does not claim to. What it does — persistent Tree-sitter-backed code search with cross-session memory and minimal setup — it does well.

The 50x token savings claim is real for grep-heavy workflows. The cross-session memory is genuinely useful for multi-day tasks. The setup is the easiest I have seen for any MCP server targeting multiple clients.

If you already use Claude Code, Cursor, or Codex on a non-trivial codebase, AiDex is worth the 30 seconds it takes to install. You will know within a day whether it changes your workflow. For me, it did.

For a broader look at the best MCP servers available today, check out the Best MCP Servers for Developers 2026 guide. And if you are building a composable AI coding stack, the Cursor + Claude Code + Codex Stack post covers how tools like AiDex fit into the bigger picture.

FAQ

Does AiDex work with VS Code Copilot?

Yes. The README lists VS Code Copilot as a supported client, and the auto-registration path handles the MCP configuration. I tested it briefly — the tools appeared after restarting VS Code with the latest Copilot MCP update. The experience is identical to Cursor and Claude Code.

How does AiDex handle large monorepos?

I tested on a 45,000-line repo and the full index build took about 4 seconds. On repos over 200,000 lines, the initial build can take 15–20 seconds. Incremental updates after that are sub-second for single-file changes. AiDex does not have a built-in repo-splitting strategy, so if you have a monorepo with multiple unrelated projects, you may want to run separate AiDex instances per project directory.

Is AiDex free or paid?

AiDex is open-source under the MIT license. The repository is at github.com/CSCSoftware/AiDex. There is no paid tier or cloud service — it runs entirely locally. The only cost is the compute time for indexing, which is negligible on modern hardware.

Can AiDex index non-code files like documentation or config files?

AiDex is optimized for code files that Tree-sitter can parse. It does not index Markdown, YAML, JSON, or other non-code files in the same way. The semantic search is built on AST identifiers, so documentation files that lack structured code symbols will not appear in search results. If you need to search documentation alongside code, you would need a separate retrieval tool.

Does AiDex share my code with any external service?

No. Everything runs locally on your machine. The MCP server binds to localhost by default. No data leaves your filesystem. This is one of AiDex’s strongest selling points for teams with compliance requirements around source code confidentiality.