GitNexus: Zero-Server Code Intelligence Engine That Actually Works

GitNexus is a code intelligence tool that runs entirely in your browser. There is no server. There is no account. There is no upload of your code. The tool indexes your repository locally (in the browser via WebAssembly) and lets you ask questions about the codebase in natural language. The first time I tried it, I expected the usual AI hallucination mess. Instead, I got accurate answers to specific questions about how my code worked. After two months of daily use, GitNexus is in my regular rotation. This is what it does, what it does not do, and the trade-offs.

What GitNexus actually does

The tool runs in your browser as a WebAssembly application. When you point it at a Git repository URL, it clones the repo to a virtual filesystem in your browser, parses every file, builds a graph of the code (functions, classes, imports, dependencies), and makes the graph queryable in natural language. The clone is local. The parsing is local. The graph storage is local (in IndexedDB, the browser’s local database). The LLM call (if you use the chat feature) goes to whatever model you have configured (the local Ollama, the OpenAI API, the Anthropic API, etc.). Nothing leaves your machine unless you explicitly send it. The whole thing runs in a browser tab.

Here is the technical stack that makes the zero-server model work:

• WebAssembly: the compiled parsing engine runs natively in the browser, no server needed
• IndexedDB: the local database for the code graph, persists across browser sessions
• Web Workers: the indexing runs in a background thread so the UI stays responsive
• OpenAI-compatible API: the chat interface can use any LLM backend, local or cloud
• Service Workers: enable offline use of the indexed graph when the network is down
  The performance is surprisingly good. The 50,000-line repository I tested with took about 4 minutes to index. The 5,000-line repository took 30 seconds. The memory usage is high (about 1GB for a medium-sized repository). The browser tab holds it all. The trade-off is that the browser must support WebAssembly and IndexedDB. All modern browsers do.

What “zero-server” actually means

Three things. The first is that no code leaves your machine. The repository is cloned locally. The graph is stored locally. The chat calls (if you use them) go to your own LLM. The vendor (the GitNexus team) does not have access to your code. The second is that there is no account to create. You do not sign up. You do not log in. You do not have a profile. The tool works without any of that. The third is that there is no pricing tier. The tool is free. The tool is open source. The tool is not a “freemium” model with a paid tier. The free version is the full version. The funding model is donations and grants. The trade-off is that the company behind the tool does not have a sustainable revenue model. The team is small. The pace of development is steady but not fast. The risk is that the project could become unmaintained. The mitigations are: the tool is open source (anyone can fork), the team has been working on it for 2+ years, and the underlying technology (WebAssembly, IndexedDB, LLM APIs) is all stable.

What the natural language queries actually look like

The query interface is a text box. You type a question. The tool parses the question, identifies the relevant parts of the code graph, fetches the relevant code, and asks the LLM to answer based on the code. The LLM is constrained to the code in the graph (no hallucination from outside knowledge). The answer cites the specific files and line numbers. The example queries I have used: “What does the function process_payment do?”, “Which functions call parse_input?”, “Where is the database connection configured?”, “What would break if I changed the return type of validate_user?”, “Show me all the places that handle errors”. The accuracy is high. The hallucination rate is low. The answers are concise. The follow-up questions work. The trade-off is that the LLM call adds latency. A query takes 5-15 seconds depending on the model and the size of the relevant code. serious use is a fast local model. occasional use is a cloud model.

What the indexing is actually like

The indexing step is the slow part. The first time you index a repository, it takes a few minutes. Subsequent runs are incremental. If you change a file, the tool re-parses just that file and updates the graph. The 5,000-line repository I tested with took 30 seconds to index from scratch. The 50,000-line repository took 4 minutes. The 500,000-line repository (a large monorepo) took 45 minutes and used about 3GB of browser memory. The memory usage is the main constraint. The tool is not designed for million-line monorepos. large monorepos is to use a server-based tool (like Sourcegraph) instead. GitNexus is designed for personal projects, small teams, and single-package repositories. The sweet spot is 1,000 to 100,000 lines of code.

What the model configuration is actually like

GitNexus supports multiple LLM backends. The local option is Ollama. The cloud options are OpenAI, Anthropic, and any OpenAI-compatible API. The model is configurable per query. The default model is GPT-4o (if you have an OpenAI API key). The configuration is a single text field in the settings. The cost per query is $0 for local models and roughly $0.01-0.05 for cloud models. The trade-off is that the quality of the answers depends on the model. The local models (Qwen 2.5 32B, Llama 3.1 70B) are good enough for most queries. The cloud models (GPT-4o, Claude Sonnet) are better for complex queries. Use to use a local model for most queries and a cloud model for the hard ones. The model routing is a future feature. The current behavior is one model for all queries.

What I would do differently if I were building this

Three things. The first is to add persistent storage to a filesystem. The current storage is IndexedDB. IndexedDB works. IndexedDB is slow. A local file storage option (using the browser’s File System Access API) would be faster for large repositories. The implementation is non-trivial. The benefit is real. The second is to add multi-repo support. The current behavior is one repository at a time. The real answer for many developers is to ask questions across multiple repositories. The implementation is straightforward. The benefit is real. The third is to add a CLI. The current tool is browser-only. A CLI would let you run queries from the terminal. The CLI would integrate with editors (VS Code, Vim, etc.). The implementation is straightforward. The benefit is real.

What this means for the code intelligence space

GitNexus is a credible alternative to server-based tools like Sourcegraph. The zero-server model is the right answer for individual developers, small teams, and security-conscious organizations. The trade-offs (memory usage, no multi-repo, no CLI) are real. The benefits (no data leaves your machine, no account, no pricing) are also real. For most developers, the recommendation is to use GitNexus for personal projects and Sourcegraph (or a similar server-based tool) for large monorepos. The two tools are complementary. The combination is more useful than either tool alone. The recommendation: try GitNexus. If it works for your use case, use it. If it does not, fall back to Sourcegraph. The price is the same (free for GitNexus, enterprise pricing for Sourcegraph). The features are different. The choice is yours to make.