Developer tooling · 2026

Context Mesh

Context Mesh helps AI coding assistants find their way around a project.

Real terminal output from `cm guard runBuildPipeline`: a blast-radius table listing 64 affected files, which have guarding tests and which have none.
Real terminal output from `cm guard runBuildPipeline`: a blast-radius table listing 64 affected files, which have guarding tests and which have none.

01The problem

Ask an AI coding agent what calls a given function. Without an index it greps, gets partial matches, opens four files to confirm, spends several thousand tokens, and still misses the caller that reaches the function indirectly.

That loop repeats on every question. On a large repository it becomes the main cost of working with an agent, and it gets worse exactly when the codebase is big enough for the help to matter most.

02What it does

Context Mesh indexes a repository once and then answers structural questions (where is this defined, what calls it, what depends on it) in a single lookup instead of a search loop.

One index is exposed three ways: as static files any tool can read, including editor modes that cannot call tools at all; as a command-line binary that runs anywhere a shell does, including inside subagents that do not inherit their parent's tools; and as an MCP server. There is also a Claude Code Skill that teaches the CLI for about forty tokens of context, against the full schema cost of twenty-eight MCP tools on every turn.

The question it answers that plain search cannot is the one you ask before editing: is this safe to change? `cm guard` returns the blast radius, the tests that cover it, the files no test covers, and what changed there recently, in one call.

~/Code/ContextMesh
Real cm output replayed in a terminal and recorded: where a function lives, then what a change to it would touch and which files no test coversOutput unedited

03It keeps itself fresh

A fast index is useless if it is stale. For months every repository had to be rebuilt by hand, so an index was exactly as fresh as the last time someone remembered. When I finally counted, twelve indexed repositories on my own machine had no live watcher between them.

Now `cm init` finds the repositories on a machine and installs a startup hook, and `cm start` builds each one before watching it, so the first answer after a reboot is already current. It works the same way on Linux, macOS, Windows, WSL and OrbStack, and a written handover covers setting up the next machine from a fresh clone.

New repositories are picked up too. When I start a project in one of the folders it watches, the next terminal I open registers it, builds it and starts watching it. It only does this for repositories I wrote, so a project cloned from someone else is never indexed without my say-so.

04The measurements

There is a benchmark in the repository, pinned to specific public commits so the results reproduce. A smaller version runs in CI on every push.

Retrieving the same answers against a grep-loop baseline: 5,155 tokens and 13 tool calls, versus 2,007,316 tokens and 632 tool calls. Across a thirteen-task run over four open-source repositories, task success was 100% against the baseline's 53.8%.

99.7%
Fewer tokens than baseline
97.9%
Fewer tool calls
100%
Task success vs 53.8% baseline
2,310
Test cases

The same run also compares it with similarity search, the kind of lookup many AI editors build in. Context Mesh used 87% fewer tokens and found nine answers that the top ten search results missed.

One disclaimer, written against my own results: the scoring checks whether the expected answers were found, not how well a real model then uses them or how much irrelevant material came along, so the success-rate gap is softer than the number suggests. Read the cost figures as the result and the success rate as directional.

Measured on real use, too. Before deciding what to build next, I went through three weeks of my own agents' sessions across six repositories: 874 calls over MCP and about 530 from the command line, with a median answer time of 19 ms. That review and the passes after it produced more than eighty numbered fixes, each written up with what was wrong and how it was checked. Three of the findings turned out to be wrong themselves, and those corrections are written down as well.

05How it is built

tree-sitter does the parsing, which lets the call graph work across languages rather than just the one the tool happens to be written in. Route extraction covers more than twenty web frameworks. The call graph crosses language boundaries too: a React Native bridge call resolves through to its Swift or Kotlin implementation.

Incremental rebuilds are checked byte for byte against a full rebuild by the performance harness, and run between 1.6× and 30× faster when a single file changes. An optional SQLite full-text index engages automatically once a repository is large enough to need it.

Every query can also return structured JSON, so scripts can use the answers too. An example script uses it to write a pull-request note of what changed, what depends on it and which tests to run.

2,310 test cases across 260 files. CI runs build, typecheck, the test suite and a benchmark regression gate on every push, so a change that makes retrieval worse fails before it merges, whether or not anyone noticed.

06Status

Private. It is packaged for release and has not been released: the repository is not public and nothing is on any package registry. It runs on every repository on my machines, including the one behind the site you are reading.

Want something similar built?

Share what you have in mind and roughly when you need it. Every enquiry gets a personal reply within one business day.

Portrait of Cheah Bing Wen, software developer based in Singapore.
Bing Wen
Start a project

Replies within one business day