Vesti (abraxas914/VESTI): a local-first memory hub for AI conversations

The scattered-transcript problem Vesti targets

If you think in chat windows, your reasoning is spread across accounts you do not control. A product decision argued out in ChatGPT, a migration plan drafted in Claude, a market question asked in Gemini: none of those transcripts sit in one place, and none of them are searchable together. Vesti's stated goal is to reverse that. The README frames the situation as platforms holding both ownership and interpretation of the data, and positions Vesti as a local-first hub that captures conversations as you have them and keeps the copies on your machine.

The intended user is narrow and identifiable. You browse ChatGPT, Claude, Gemini, DeepSeek, Qwen or Doubao in Chrome, you have accumulated months of threads you occasionally need to revisit, and you would rather not paste them into a third-party SaaS. The README also states a second, softer goal: not to archive everything, but to help you decide what is worth keeping. That distinction matters, because a capture tool that stores indiscriminately produces a corpus you will never search.

Two layers: a capture extension and a knowledge view

The architecture is split in two. The capture layer is the Chrome extension itself, built with Plasmo and React according to the README badges. It listens on the supported platform pages, extracts the conversation, and writes it to local IndexedDB through Dexie.js. The README says capture is automatic and that the system detects and skips duplicates, storing full multi-turn content plus timestamps and a platform identifier.

The knowledge layer is a separate web view built against a StorageApi contract interface. It exposes four modules: Library for classified browsing, Explore for natural-language question answering, Network for a semantic-relation graph drawn with ECharts, and Notes for manual curation. The two layers talk over the Chrome Extension Message protocol, and the README states that the UI layer is transparent to the storage implementation. That indirection is the load-bearing part: it is what lets the knowledge view stay local while still being a normal web app.

Summaries come from what the README calls a Gardener agent running a multi-step decision chain in the background, and semantic retrieval uses a local vector store with embeddings served through ModelScope. Retrieval is described as cross-platform RAG with citation tracing back to the source conversation.

Installing from source and capturing a first conversation

The repository is a pnpm monorepo. The root package.json declares the workspaces as frontend, vesti-web and packages/*, and defines scripts for Playwright-based helpers and two weekly-knowledge verification scripts. There is no published extension listing described in the README, so the path in is a local build from the repository.

Start by enabling pnpm and installing the workspace dependencies from the repository root:

corepack enable
pnpm install

The README does not print a build command for the extension, so the entry point has to be read from the frontend workspace's own package.json rather than assumed. The root scripts you can run today are the verification helpers, for example:

pnpm test:weekly-knowledge
pnpm test:weekly-time-machine

Both invoke node scripts under scripts/ and are the only test commands the root manifest exposes. Loading the built extension into Chrome is the next step, and the README describes the result rather than the procedure: once it is running on a supported platform page, a floating capsule appears in the corner, shows one of six capture states, and can be expanded to archive the current conversation or open the sidebar. Position is remembered per domain, and the widget's styles are scoped inside a Shadow DOM so they do not leak into the host page.

Where Vesti breaks down

The README is unusually direct about its own limits, and they are worth taking at face value. It names three: the scale boundary of vector retrieval, the confidence limits of agent-based classification, and the absence of cross-device sync. The last one is the most consequential for daily use. Because everything lands in the browser's IndexedDB, the archive is tied to one Chrome profile on one machine. Reinstall the browser, switch laptops, or lose the profile, and the memory hub goes with it. There is no export path documented in the README either, despite export being part of the project's one-line description.

Capture is also platform-bound by construction. The extension watches six named services; a conversation held in a tool outside that list is invisible to it. And because capture depends on reading the page DOM, any redesign of those chat interfaces is a potential silent failure: the archive simply stops growing, with no server-side alert to tell you. Finally, the release list shows version v1.2.0-rc.9 dated 2026-08-16, with earlier candidates in March. A release candidate numbering scheme means the project does not yet promise interface stability across the storage contract.

How this differs from server-side conversation archiving

The obvious alternative is a self-hosted archiving stack such as Karakeep or Hoarder, or a general read-later service with full-text search. Those take a different route: a server process holds the database, and clients push content to it. The payoff is that every device sees the same archive, and a scheduled job can crawl or sync in the background without a browser open.

Vesti inverts the trade. Nothing leaves the browser, which removes the hosting, backup and access-control questions that come with running a server, and it means the embedding and retrieval pipeline runs against a local index. The cost is exactly the thing the server model gives you for free: one archive, many devices. If your primary requirement is reaching yesterday's Claude thread from your phone, Vesti is the wrong shape. If your requirement is that no transcript ever touches a machine you do not own, the server model is the wrong shape. The two are not substitutes so much as answers to different questions.

Maintenance, licence and what a version bump costs you

The repository is not archived and the last push was on 2026-09-10, so development is recent. That recency is not the same as a stability guarantee. The release history shows v1.2.0-rc.9, v1.2.0-rc.7 and v1.2.0-rc.6, all release candidates, with the newest dated 2026-08-16. Nothing indicates a stable v1.2.0. Upgrading therefore means moving between pre-releases, and the README does not document a migration path for the IndexedDB schema. The CHANGELOG.md at the repository root is the file to read before pulling a new candidate.

Licensing is genuinely ambiguous. The README carries an MIT License badge, while the repository metadata reports the licence as unknown. Those two sources disagree, and the README is not the authority. Check the LICENSE file in the repository before you plan to redistribute anything or embed the code in another product. The README also does not state terms for the ModelScope embedding API that the retrieval pipeline depends on, so the network and quota conditions of that dependency are undocumented here.

Editorial conclusion

Adopt Vesti if you keep long-running threads on several AI platforms, work in Chrome, and accept a pre-1.0 release candidate whose storage lives in IndexedDB. Do not adopt it if you need cross-device sync, Safari or Firefox support, or a stable tagged release: the newest tag in the release list is v1.2.0-rc.9, and the README itself lists the absence of cross-device sync as a real constraint. Before installing, check the LICENSE file in the repository, since the README shows an MIT badge while the repository metadata reports no license, and confirm which of the six supported platforms you actually use.

Frequently asked questions

Official sources

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