The most tiring thing about AI coding tools is re-explaining yourself. You spend twenty minutes establishing that this project uses JWTs, that the database layer is Supabase, that you've deliberately avoided an ORM. Then the session ends, and tomorrow the assistant suggests adding Prisma.
Vexi's Context Compression Engine exists to end that loop.
The actual problem
Every model has a finite context window, and long agentic sessions fill it fast: file contents, tool outputs, diffs, error messages. The naive fix is truncation: drop the oldest messages when you run out of room.
Truncation is exactly backwards. The oldest messages are usually where the decisions live. You established the architecture at the start and spent the rest of the session on implementation detail. Dropping the front of the conversation throws away the durable part and keeps the disposable part.
Compress instead of truncate
Rather than deleting old context, Vexi distills it. As a session grows, it maintains a running summary of what was decided, not what was said. The distinction matters:
- Kept: "User chose JWT over sessions for auth." "Project uses Supabase, not Prisma." "User prefers named exports."
- Dropped: the file listing from step 4, the stack trace that's since been fixed, the three refactors that were tried and reverted.
The result is a compact set of statements that stays useful long after the conversation that produced it is gone. It persists in .vexi/ in the project, so it survives closing the terminal.
What it looks like in practice
When memory informs an answer, Vexi shows you which decision it drew on:
› fix the JWT bug in auth.ts
↳ memory: "User chose JWT for authentication"That line is deliberate. Memory that operates invisibly is memory you can't correct. When the agent does something strange, you need to see which stored belief caused it. Surfacing the recalled decision turns a black box into something debuggable.
Memory goes stale, and that's the hard part
This is the honest limitation of every persistent-memory system, and it deserves saying plainly rather than being buried.
A stored decision reflects what was true when it was written. You might have chosen JWTs in March and migrated to sessions in June. The memory doesn't know that. Worse, a confidently wrong memory is more harmful than no memory at all, because it produces plausible-looking work built on a false premise.
Two things mitigate it. The memory is a plain readable file in your project, not a hidden vector store, so you can open it, see exactly what Vexi believes, and edit or delete entries that have gone stale. And because recalled decisions are printed when used, a wrong one announces itself the first time it affects an answer, rather than silently steering the session.
It's worth skimming that file occasionally, the same way you'd skim a stale README.
Memory versus project scanning
These are separate systems and it's easy to conflate them. On startup, Vexi scans your codebase (respecting .gitignore, skipping node_modules) and builds a compact structural map. That's current state: what files exist, how they relate. It's rebuilt every run because it goes out of date the moment you edit something.
Memory is intent: why the code is the way it is. Scanning can tell the model you use JWTs. Only memory can tell it you chose them on purpose, after considering the alternative, which is the thing that stops it from helpfully suggesting you switch every week.