NextPlaid and ColGREP: multi-vector search from index to coding agent
NextPlaid, ColGREP: Multi-vector search, from database to coding agents.
At a glance
- What is it?
- NextPlaid is a local-first multi-vector database in Rust with a REST API, and ColGREP is the semantic code search CLI built on top of it. Here is what the repository documents, where the design trades off, and who should install it.
- Who is it for?
- Adopt ColGREP if you want semantic code search that stays on your machine and you are willing to run colgrep init once per project and per model. Adopt NextPlaid if you need a multi-vector index that accepts documents as they arrive rather than in one batch.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 21 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The lossy-summary problem NextPlaid addresses
Standard vector search compresses a whole document into one embedding. The README calls that a lossy summary and argues it is fine for short text but poor for code, where a single function carries a name, parameters, a docstring, control flow and dependencies. Multi-vector retrieval keeps roughly 300 embeddings of dimension 128 per document instead of one, and at query time each query token finds its best match across all document tokens, a scoring step the README names MaxSim. The cost is storage, and that is the gap NextPlaid exists to close through quantization and memory-mapped indexing. The audience is narrow on purpose: teams running retrieval over code or other long structured documents, who want the index on their own disk rather than behind a hosted endpoint. ColGREP is the packaged form of that idea for developers who never want to think about vectors at all.
How ColGREP turns a repository into searchable units
The pipeline in the README runs from codebase to Tree-sitter to a structured representation, then to the LateOn-Code-edge model (17M parameters, running on CPU), then into a NextPlaid index, then to search. The interesting stage is the second one. Each code unit is converted to structured text before embedding: a comment header naming the function, its signature, description, parameters, return type, calls, variables, uses and file path, followed by the source itself. The README's example shows a fetch_with_retry function rendered this way. That header is what gives the model signal that raw code does not carry, and it is also why the index is tied to a parser. Tree-sitter has to recognize the language and extract functions, methods and classes; a file whose structure the parser cannot recover becomes a weaker unit. The README does not document what happens to unsupported languages, which is a question worth answering before indexing a polyglot monorepo.
Installing ColGREP and running a first search
Two install paths are documented. Homebrew for macOS and Linux, or a shell installer that fetches the latest release. The installer detects your platform and downloads an optimized binary, with CoreML and Accelerate on Apple Silicon and Accelerate on Intel Macs, according to the release notes embedded in Cargo.toml.
brew install lightonai/tap/colgrepcurl --proto '=https' --tlsv1.2 -LsSf https://github.com/lightonai/next-plaid/releases/latest/download/colgrep-installer.sh | shThen build the index. You can point it at a path or let it default to the current directory. The README notes there is no server, no API and no separate dependencies, so this step is local work on your own files.
colgrep init /path/to/project
colgrep initSearch is a quoted natural-language string. After the first init, the README states that every search detects file changes and updates the index automatically before returning results, so you are not expected to re-run init as you edit.
colgrep "database connection pooling"The combination that distinguishes it from plain grep is a regex flag alongside the semantic query. The README's example filters to async functions that await before ranking by meaning.
colgrep -e "async.*await" "error handling"If you use a coding agent, there are one-shot integration commands for Claude Code, OpenCode, Codex and Hermes. The README asks you to restart the agent afterwards and states that only Claude Code has full hooks support; the other three are described as basic for now.
Switching models without rebuilding everything
The default model is lightonai/LateOn-Code-edge, and the README says any ColBERT-style model on HuggingFace can be substituted. The design detail worth noticing is that each (project, model) pair gets its own index directory. Switching models therefore does not corrupt existing indexes, and you can move between them without re-indexing. That is a real operational decision: it costs disk, and it means a query issued with the wrong model silently searches a different index rather than failing loudly. The status command is how you check which model an index was built with, and clear is scoped to the active model while clear --all wipes every index. Private models are reached by setting HF_TOKEN before set-model. If your team shares a repository and each developer picks a different model, expect duplicated index directories rather than a shared one.
NextPlaid as a service, and where the API stops
NextPlaid is the engine under ColGREP but is positioned as a general-purpose retrieval service with a REST API. It bundles ONNX Runtime for ColBERT models, so you pass text and get results without standing up a separate inference server. Indices are memory-mapped and paged in from disk on demand, which is how the RAM footprint stays low. Product quantization at 2-bit or 4-bit is what the README claims lets a million documents fit in memory. Updates are incremental: documents can be added and deleted without a rebuild. Metadata filtering runs as SQL WHERE clauses against a built-in SQLite store, applied before search so only matching documents are scored. The docker-compose file documents the operational surface: RATE_LIMIT_ENABLED defaults to false, RATE_LIMIT_PER_SECOND defaults to 50 when enabled, CONCURRENCY_LIMIT defaults to 100, and MAX_QUEUED_TASKS_PER_INDEX defaults to 10. That last default is the one to watch. A queue of ten pending updates per index is small, and the compose file does not describe what the API returns when it fills.
NextPlaid against FastPlaid
The README draws the line itself. FastPlaid is a GPU batch indexer for large-scale, single-pass workloads. NextPlaid wraps the same algorithm in a production API that handles documents as they arrive: incremental updates, concurrent reads and writes, deletions, and built-in encoding. The practical difference is the shape of your workload, not raw speed. If you rebuild an index nightly from a static corpus, a batch indexer is the simpler fit and NextPlaid's incremental machinery is overhead you will not use. If documents arrive continuously, or you need to delete individual records without a rebuild, the batch model forces you to re-run the whole pass. The README's own advice is to use FastPlaid for bulk offline indexing. Note that the two share an algorithm, so results should be comparable; the choice is about ingestion pattern and serving, not retrieval quality.
Licence, build cost and what the README leaves open
Both the workspace and the published crates are Apache-2.0, declared in Cargo.toml with Raphael Sourty and LightOn as authors and docs.rs/next-plaid as the documentation target. Apache-2.0 permits commercial use and modification and includes a patent grant; it also requires you to keep the licence and notice files. That is a summary of the identifier, not legal advice, and any redistribution or hosted offering should go past your own counsel. The build story is heavier than the CLI story. The workspace has four members (next-plaid, next-plaid-api, next-plaid-onnx, colgrep) with a release profile using LTO, one codegen unit and opt-level 3, so a from-source release build is slow by construction. The Makefile exposes build, release, test, lint and a long list of benchmark targets, and the release pipeline is cargo-dist at version 0.30.3. The last push to the default branch was on 2026-08-25, and v1.7.0 was released on 2026-08-18. What the top-level README does not cover: rollback of an index, a migration path when the embedding model changes, and the exact behaviour when the per-index update queue is full. The README points to colgrep/README.md for install variants, performance tuning and the full flag list, so treat that file as the reference rather than the front page.
Editorial conclusion
Adopt ColGREP if you want semantic code search that stays on your machine and you are willing to run colgrep init once per project and per model. Adopt NextPlaid if you need a multi-vector index that accepts documents as they arrive rather than in one batch. Do not adopt either if your retrieval fits a single-vector index or your team cannot rebuild indexes when the embedding model changes. Before committing, run colgrep status to confirm which model an index was built with, and read colgrep/README.md for the flag list, because the top-level README does not document every option.
Frequently asked questions
Does ColGREP send my source code to a server?
No. The README states that search is all local and your code never leaves your machine, and describes ColGREP as a single Rust binary with no server, no API and no separate dependencies. Model weights are downloaded from HuggingFace, but the encoding runs on your CPU.
What happens when I switch the embedding model in ColGREP?
Each (project, model) pair has its own index directory, so switching models never corrupts existing indexes and you can flip back and forth without re-indexing. Run colgrep status to see which model an index was built with, and note that clear is scoped to the active model while clear --all wipes every index.
Can NextPlaid delete a document without rebuilding the index?
Yes. The README lists incremental updates and says documents can be added and deleted without rebuilding the index, which is one of the differences it draws against FastPlaid. Deletes go through the API and are subject to the per-index queue limit documented in docker-compose.yml.
Community notes