Probe: AST-Aware Code Search Without an Index or an Embedding Model

The problem Probe targets: grep returns lines, not units of code

The README opens with a blunt framing: we read code far more than we write it, and existing AI coding tools use what it calls a caveman approach, grepping some files and reading random lines. That is not a rhetorical flourish. It describes a real failure mode. A regex match gives you a line, and a line is rarely the thing you needed. The function signature is above it, the type it returns is in another file, and the closing brace is forty lines down. An agent that receives line fragments has to spend further turns reassembling them. Probe's stated goal is to return complete semantic code blocks, meaning whole functions, classes or structs, in a single call. The intended audience is narrow and specific: people building or driving AI coding assistants, and engineers doing spec-driven development, code review or onboarding on codebases large enough that reading them by hand is not an option.

How the engine works: ripgrep for candidates, tree-sitter for boundaries

The mechanism the README describes has two stages. First, ripgrep scanning finds candidate matches, accelerated with SIMD pattern matching and rayon for parallelism. Second, tree-sitter parses the source into an AST, so the engine knows where a function or class actually begins and ends, and can expand a hit into the enclosing block. Ranking is layered on top: BM25, TF-IDF and hybrid algorithms, with optional BERT reranking. The query surface is deliberately not natural language. It is Elasticsearch-style boolean syntax with operators like AND, OR, +required, -excluded, quoted exact phrases, and field filters such as ext:rs and lang:python. There is no indexing step and no vector database. The README's central argument is that when the consumer is an LLM, the model itself resolves vocabulary mismatch: asked to find the authentication logic, the model generates a query like verify_credentials OR authenticate OR login OR auth_handler, and Probe answers it in milliseconds. That is a coherent design position, and it is also the project's biggest bet. It assumes the agent can write a good boolean query. When it cannot, the user pays for it in retries.

Getting it running: four entry points and the config keys that matter

The README documents four ways in. The recommended one is the built-in agent as an MCP server, added to ~/.claude/claude_desktop_config.json with command npx and args ["-y", "@probelabs/probe@latest", "agent", "--mcp"]. The README states this piggybacks on Claude Code or Codex authentication, so no extra API key is needed, though a provider key such as GOOGLE_API_KEY works too. Dropping the agent word from those args mounts the raw search, query and extract tools instead. Third, direct CLI use with no MCP at all: npx -y @probelabs/probe search "authentication AND login" ./src, npx -y @probelabs/probe extract src/main.rs:42, and npx -y @probelabs/probe query "fn $NAME($$$) -> Result<$RET>" --language rust. Fourth, a one-shot CLI agent: npx -y @probelabs/probe@latest agent "How is authentication implemented?". The agent accepts --path to set the search directory, --provider to choose a backend, and --allow-edit to permit code changes. A Node.js SDK is listed as a usage mode and appears in the topics, but the supplied README excerpt does not document its API, so treat that surface as unverified until you read the full docs.

The trade-off Probe makes: no embeddings means the query is the interface

Probe's comparison table places it against grep and ripgrep on one side and embedding tools such as grepai and Octocode on the other. The differences it claims are concrete: embedding tools need minutes of indexing plus an embedding service, and their chunks can split mid-function, while Probe needs no setup, works offline, and returns AST-bounded blocks. The cost of that position is that Probe has no semantic fallback. If the code calls a thing verify_credentials and you or your agent only ever search for authentication, the boolean query must contain the right synonym, because nothing in the engine will infer it. The README's answer is that the LLM supplies the synonyms, and that session-based dedup lets an agent run three or four rapid searches to cover the same ground. That is a reasonable bet for agent use and a weaker one for a human typing a single query at a terminal. Determinism cuts both ways here: the same query always returns the same results, which is good for reproducibility and bad for the case where your query was simply wrong.

Token budgets and session dedup are the parts that matter for agents

Two features deserve more attention than the feature list gives them. The first is --max-tokens, a budget on how much context a call is allowed to return. The second is session-based dedup, which the README describes as a way to avoid repeating context across calls. Together they address the actual failure of naive code retrieval in an agent loop: you either flood the context window with whole functions the model did not need, or you return fragments it cannot use. A budget plus dedup means the second search in a session does not re-send what the first one already delivered. That is the mechanism behind the README's claim that one Probe call captures what takes other tools ten or more agentic loops. I cannot verify that ratio from the material supplied, and the README offers no benchmark for it. Treat the ten-loop figure as a design claim, not a measurement.

Where Probe is the wrong tool

Three cases stand out. The first is a codebase in a language tree-sitter does not cover here. The README lists Rust, Python, JavaScript, TypeScript, Go, C and C++, Java, Ruby, PHP, Swift, Solidity, Crystal and C#, with more implied, but if your repository is mostly something outside that set, the AST stage has nothing to work with and you are left with the ripgrep layer, which is what you already had. The second is a need for a stable, frozen search service. The published releases in the supplied material are v0.6.0-rc339, v0.6.0-rc338 and v0.6.0-rc337, dated within days of each other in September 2026. Release candidates at that cadence mean the CLI flags and MCP surface can move. The third is a genuine vocabulary problem with no reliable query author. If nobody in the loop can turn intent into verify_credentials OR authenticate OR login, an embedding index is the more forgiving design, and Probe's zero-setup advantage buys you nothing.

What to compare it against, and on what axis

The honest comparison is not Probe versus ripgrep, because ripgrep is not trying to solve the same problem and Probe uses it internally. It is Probe versus an embedding-based retrieval stack such as the grepai and Octocode tools the README names. The difference in approach is the whole story: an embedding tool converts your code into vectors ahead of time and answers with cosine similarity, which handles synonym and paraphrase mismatch automatically but requires an indexing pass, an embedding model or API, and accepts that chunks may cut a function in half. Probe does no precomputation and answers boolean queries against live source, which means instant startup and deterministic output, but the query must be written well. If your agent is capable of writing structured queries and you want nothing running in the background, Probe's model is the better fit. If your queries are vague and your repository is stable enough to index once, the embedding path costs you setup and returns more forgiving results.

Maintenance cost, licence and what to check before adopting

Probe is licensed Apache-2.0, which permits commercial use and modification and includes a patent grant, but this is not legal advice and you should have your own counsel review it if you plan to redistribute. The practical maintenance question is version pinning. The README's install snippets use @probelabs/probe@latest, which will pull whatever release candidate is current. In an MCP config or a CI job that is a liability, because a new rc can change agent flags or tool schemas without warning. Pin an explicit version instead. Beyond that, the upgrade surface is the MCP tool definitions and the CLI flags, both of which the release notes are the place to check. The project is not archived and last pushed in September 2026, so the cadence is active. Before you commit, verify two things against your own repository: that your primary languages appear in the supported list, and that the query syntax documented for search and query covers the filters you actually need, such as ext: and lang:.

Editorial conclusion

Adopt Probe if you are feeding an AI coding assistant or a terminal workflow that needs complete functions and classes rather than grep line fragments, and if you can tolerate a pre-1.0 release cadence. Skip it if you need a frozen, versioned search service, or if your real problem is vocabulary mismatch that only embeddings solve. Before installing, check the release tag you are pulling, since the newest published versions are v0.6.0-rc339 and v0.6.0-rc338, and confirm which languages your repository actually uses against the supported list in the README.

Official sources

1. License: Apache-2.0
2. probelabs/probe on GitHub
3. Project website
4. README
5. Releases