swapnanil/vectr

> **Delivery, not storage.** A local daemon that gives an AI code editor semantic search over your codebase, plus working memory that shows up on its own when it is relevant.
Version 1.12.0 · Last updated 2026-09-03 · CHANGELOG
In 30 seconds
Your AI code editor pays for the same knowledge twice. It re-reads files it read yesterday, re-greps symbols it already found, and loses the exact signature it discovered at turn 5 the moment the conversation is compacted. Vectr is one local process that removes both halves of that bill:
- **Retrieval that understands code.** AST-aware chunks, a symbol and call graph, and hybrid semantic plus BM25 ranking. Describe a behaviour and get the whole function back, in one call instead of a grep loop and three blind file reads.
- **Working memory that gets delivered.** Save a finding once. It comes back verbatim in under 50ms, and on editors that expose session hooks it arrives automatically at the moment it applies, without the agent choosing to ask for it.
- **Local, keyless, zero config.** One pip install, one vectr start. The embedding model runs on your machine. Nothing is transmitted anywhere, and there is no API key.
That is the whole setup. Vectr writes the MCP config for your editor, then indexes in the background.
---
How vectr differs from other AI agent memory tools
There is a healthy category of general-purpose memory layers for AI agents, and the good ones solve a real problem well. Vectr is most often compared to them, so here is the difference stated plainly. The left column describes the design these tools tend to share, not any one product; individual tools vary, so check the one you are considering.
| | A typical memory layer | Vectr |
|---|---|---|
| **How memory reaches the model** | The agent or developer calls an explicit store-and-retrieve API, add() and search() or the equivalent. Memory arrives only when something decides to ask for it. | Every note carries trigger conditions over {path, symbol, semantic, event, temporal}. On editors with session hooks the harness evaluates them deterministically and injects the match. The agent never has to remember to ask. |
| **Domain** | Generic conversational memory, aimed broadly at assistants and applications rather than at source code. Notes are strings about a user or a session. | Code native. A symbol graph, AST chunking, semantic code search, and working memory fused in one daemon, so a note can be anchored to a real symbol or path rather than a string. |
| **Inference** | Commonly runs note extraction through an LLM and embeds through a provider API, so an API key and a provider account are part of the setup. | Zero internal LLM calls, by design. A local embedding model, no provider account, no API key. |
| **Deployment** | Usually a library or a self-hosted server, frequently with a managed cloud tier alongside it. | One local daemon bound to 127.0.0.1, one per workspace. Team mode is available and opt in. |
**Why the first row is the one that matters.** Storage is not the bottleneck. Retrieval that an agent must volunteer to call is, because it largely does not call it. In our controlled evaluation the agent performed **0 memory operations across 114 turns** even when the store was pre-seeded with knowledge directly relevant to its task. Deterministic injection delivered in every injection-equipped run, with zero false-alarm fires across the audit-logged trigger evaluations. Under repeated compaction, ten facts held only in the conversation were absent from 106 of 108 forced compactions, while the same ten facts injected from a harness-owned store arrived intact across 138 of 138 compact-resumes.
Full method and results: Delivery, Not Storage: Cue-Anchored Working Memory as a Harness Property for Coding Agents (arXiv:2607.20972).
---
What it costs and what it saves
**Measured, not hypothetical.** Recalling 3 stored notes with vectr_recall costs 360 tokens in one tool call. Re-deriving the same three facts with grep plus Read costs about 2,060 tokens across six tool calls on the same 182-file Python repo. That is roughly **5.7x fewer tokens and 6x fewer tool calls**, in under 50ms (chars/4 tokenization, full breakdown in Measured costs, honestly).
Notes are persisted to disk, not held in the conversation, so they survive /compact and a fresh session equally. The session boundary does not matter: saving at turn 5 and recalling at turn 15 is the same mechanism as recalling three days later.