VESTI (心迹): a local-first capture layer for AI chats, reviewed from its README

The problem VESTI targets: chat history you cannot own or search across

Every AI platform keeps its own conversation log, and none of them let you move that log somewhere else. A product decision you worked through on ChatGPT, a technical discussion on Claude, a market analysis on Gemini: three separate silos with three separate search boxes. The README frames this as a data ownership problem and points at the practical consequence, which is that you have to remember which platform hosted a given conversation before you can find it again. VESTI's answer is to capture the conversation at the point of display, in the browser, and write it to storage you control. The target user is someone who treats AI conversations as working material rather than disposable queries: engineers, writers, researchers, anyone who returns to an old thread weeks later. The README is explicit that the project does not try to record everything. Its stated first principle is that attention sovereignty comes before data sovereignty, meaning the tool is supposed to help you decide what is worth keeping rather than vacuuming up every page you visit. That is a design intention in the README, not something the supplied material proves about the running code.

Two layers, one message protocol: how capture and knowledge management are separated

The architecture described in the README has two cooperating parts. The capture engine is the Chrome extension itself, built on Plasmo, and it handles listening to conversations on ChatGPT, Claude, Gemini, DeepSeek, Qwen and Doubao, generating structured summaries, and persisting everything to local IndexedDB through Dexie.js. The knowledge layer is a separate web view that sits behind a contract interface called StorageApi. That view exposes four modules: Library for browsing and classifying conversations, Explore for natural language question answering, Network for a semantic association graph rendered with ECharts, and Notes for manual curation. The two layers talk over the Chrome Extension Message protocol. The detail worth noticing is the StorageApi boundary. Because the UI talks to an interface rather than to IndexedDB directly, the storage implementation is meant to be replaceable without touching the knowledge view. That is the kind of decision that matters later, when you want to move from browser storage to a server or a file-based store. The README also describes a floating capsule injected into supported platform pages, with six capture states and a position that persists per domain, scoped inside a Shadow DOM so it does not leak styles into the host page. Search matches both titles and full conversation bodies, with a platform filter.

Semantic retrieval and the Gardener agent: what the README claims versus what it admits

The knowledge layer generates embeddings through the ModelScope embedding API and stores vectors locally for retrieval, which is what makes Explore able to answer questions in natural language with citation back to source conversations. A second component, the Gardener agent, is described as running a multi-step decision chain to extract key threads from complex conversations and produce structured summaries. The README is unusually candid about the gap between earlier versions and this one. It states plainly that early releases claimed meaning was relational while the product had no mechanism to discover or present relationships between conversations at all, and that each stored conversation was an isolated island. The current version is presented as the first where the philosophy has an engineering counterpart. Two constraints are named directly in the README: the scale boundary of vector retrieval, and the confidence limits of agent classification. Those are the two places where this kind of tool usually breaks. Vector search degrades as the local index grows, and an LLM-driven classifier will sometimes file a conversation under the wrong topic. Neither is solved here, and the README says so. Cross-device sync is also listed as absent, which is a real constraint for anyone who works across two machines.

Getting it running: what the README gives you and what it does not

The supplied material does not include a setup section with install commands. What it does give you is the stack: TypeScript, React, Plasmo for the extension, Dexie.js over IndexedDB for storage, ECharts for the graph view, and the ModelScope embedding API for vectors. A Plasmo extension is normally built with the plasmo CLI and loaded into Chrome as an unpacked extension from the build output directory, but the README text available here does not spell out the exact scripts, so treat any command you use as coming from the repository's package.json rather than from this article. The one configuration fact that is visible is that embeddings go through ModelScope, which means the semantic search path depends on an external API and on whatever credential that API requires. If you want a fully offline setup, the embedding step is the part that will not be offline unless the repository offers a local model option, and nothing in the supplied material indicates that it does. The other configurable surface is the StorageApi contract, which is where a different persistence backend would plug in. Beyond those, the README does not document config keys, environment variables, or a migration path for the IndexedDB schema, and that absence is itself information: budget time to read the source before you deploy this on a machine you care about.

Where VESTI is the wrong tool

Three cases stand out. First, if you need your conversation archive on more than one device, VESTI in its current form is not it. The README lists the absence of cross-device sync as a current constraint, and since everything lives in browser-local IndexedDB, a second laptop starts empty and a cleared browser profile takes the archive with it. Second, if you need a stable release, look at the version history. The most recent releases listed are v1.2.0-rc.9, v1.2.0-rc.7 and v1.2.0-rc.6, all release candidates, with the newest pushed in August 2026 and the previous one five months earlier. That cadence suggests a project still settling its interfaces, not one you build a long-term archive on without a backup plan. Third, if your conversations happen somewhere other than the six named platforms, the capture engine has nothing to attach to. The README names ChatGPT, Claude, Gemini, DeepSeek, Qwen and Doubao. A local model running in a terminal, a mobile app session, or a platform not on that list will not be captured. And if you are looking for a server-side archive that survives a reinstall, a self-hosted export pipeline or a plain Markdown vault is a better fit than a browser extension.

How it compares to the obvious alternatives

The closest thing to a direct alternative is a browser extension that exports chat transcripts to Markdown or JSON, of which several exist. The difference in approach is where the intelligence sits. An exporter gives you files and stops; the search problem is then yours, and you solve it with ripgrep or a notes app. VESTI keeps the data in IndexedDB and builds the retrieval layer on top, so Explore can answer a question across conversations and cite the source, and Network can draw the associations between them. That is more machinery and more failure surface: an embedding API, a vector index, an agent that classifies. The second alternative is a note-taking tool with a chat clipper, which gives you cross-device sync and a mature editor but treats each conversation as a document rather than as a node in a graph. VESTI's bet is that the relationships between conversations are the valuable part, and the README's own history section admits that bet went unfulfilled for several versions. If you only want durable copies of your chats, the exporter route is simpler and has fewer moving parts. If you want to ask questions across a year of conversations, VESTI is aiming at something the exporters do not attempt.

Maintenance, licence and what to check before you rely on it

Maintenance cost here is not trivial. The extension has to keep working as ChatGPT, Claude, Gemini, DeepSeek, Qwen and Doubao change their DOM, and platform UI changes are the classic failure mode for capture extensions: the selector breaks and capture silently stops. The README's six-state capsule is presumably how the extension signals that, but a silent capture failure is still the thing to watch for. The embedding dependency on ModelScope adds an external service to your critical path, and any change to that API affects Explore and Network together. On licensing, the repository metadata supplied here does not state a licence, while the README displays an MIT badge. Those two facts disagree, and the badge is not a licence file. Before you build anything on VESTI, check whether a LICENSE file exists on the main branch and what it actually says, because the answer determines whether you can fork it, bundle it, or ship it inside another product. The README also mentions a Notion export topic, which implies a path out of the local store, but the supplied text does not describe how that export works, so do not assume it is a full round-trip.

Editorial conclusion

Adopt VESTI if you already live in Chrome and want your ChatGPT, Claude, Gemini, DeepSeek, Qwen and Doubao histories in one local IndexedDB store with semantic search on top. Do not adopt it if you need cross-device sync, a stable release, or a guarantee about the licence, since the repository metadata does not state one and the README badge claims MIT without a licence file being visible in the supplied material. Verify three things before committing: whether a LICENSE file exists on the main branch, whether the StorageApi contract is documented well enough for you to swap the storage backend, and how the ModelScope embedding calls behave on your own conversation volume.

Official sources

1. abraxas914/VESTI on GitHub
2. Issues
3. README
4. Releases