How to export, migrate, and own every message you’ve ever sent to an LLM — before the platform decides you can’t.
There’s a scenario nobody in the AI industry wants to talk about openly.
You’ve spent months and maybe even years in some cases having deep, productive conversations with an AI assistant. Technical sessions where you worked through architecture decisions. Creative sessions where you refined your thinking. Research sessions that took hours to build context. Every one of those exchanges trained your workflow, shaped how you think about problems, and contained institutional knowledge you’d never want to lose.
Then one morning: access denied. The platform shuts down. Your account gets suspended. The API terms change. The company pivots. A government blocks the service in your region.
Your entire conversation history is gone. This is a reality of the world we live in with cloud services.
Services can shut down without warning. Platforms have deleted user data. APIs have been revoked mid-project. And unlike a Word document sitting on your hard drive, your AI conversation history lives entirely on someone else’s infrastructure, subject entirely to their policies, their solvency, and their continued interest in keeping the lights on.
The question isn’t whether you trust any particular platform today. The question is whether you should have to.
The Walled Garden Problem
Every major LLM platform has built a slightly different export format, a slightly different API, and a slightly different schema for storing conversations. This isn’t an accident — it’s how you build switching costs. When your memory, your context, and your conversation history only exist inside one provider’s system, you become dependent on that system continuing to exist and continuing to serve you.
The irony is that the AI systems themselves are getting better at understanding and working with your history. VEKTOR, Mem0, Zep, Supermem, and Claude’s/ ChatGPT’s memory features, all of these are building toward agents that know you, know your projects, and carry real context between sessions. The more useful that memory becomes, the higher the cost of losing it.
Vector databases are the infrastructure layer where this memory actually lives. A vector DB stores not just the text of your conversations but their semantic meaning — encoded as high-dimensional float arrays that allow an AI to find relevant memories by meaning rather than keyword. When you ask “what did we decide about the auth setup?” the system doesn’t search for the word “auth” — it searches for meaning, and finds the relevant conversation even if you never used that exact phrase.
That infrastructure is yours to own. The conversations are yours. The problem is the tooling to move them hasn’t existed — until now because we created it.
Thank us later!
Three Tools. One Mission.
Over the past few months we’ve been building a suite of open-source tools designed to make AI memory truly portable. The core thesis is simple: your conversations and memories should be as moveable as any other file on your computer.
Vex — Vector Exchange
Vex is a command-line tool that speaks every vector database dialect. It exports from VEKTOR, Qdrant, Pinecone, ChromaDB, Weaviate, and pgvector. It imports into all of them. And as of v0.6.0, it reads directly from Claude and ChatGPT conversation exports — turning your conversation history into portable .vmig.jsonl files that any vector DB can ingest.
The .vmig.jsonl format is deliberately simple. One JSON record per line. Every record has an id, a text field, an optional vector field, and a metadata object. Records without vectors are still valid — they can be imported into VEKTOR immediately and are BM25-searchable, then re-embedded later when you have an embedding API available.
Export your entire Claude conversation history
vex export --from claude-export \
--file conversations.json \
--output my-claude-history.vmig.jsonl
Import into VEKTOR local memory
vex import --from my-claude-history.vmig.jsonl \
--to vektor \
--db memory.db
Convert for OpenAI fine-tuning
vex convert --from my-claude-history.vmig.jsonl \
--adapter openai-finetune \
--output finetune.jsonl
Convert for Groq / Perplexity / Mistral
vex convert --from my-claude-history.vmig.jsonl \
--adapter generic-chat \
--output chat.jsonl
The convert adapters are where things get interesting. Once your conversations are in .vmig.jsonl format, you can transform them into the exact shape any LLM provider needs. OpenAI fine-tuning format. Anthropic Messages API format. The generic OpenAI-compatible chat format that works with Groq, Together AI, Fireworks, Cerebras, Mistral — any provider that speaks the same dialect. You're not locked into the ecosystem you started in.
Via — The CLI Companion
Via handles format conversion between different AI tool ecosystems — turning memory exports from one system into the schema expected by another. Where Vex focuses on vector DB migration, Via handles the broader landscape of AI tool interoperability: converting between memory formats, normalising metadata schemas, and bridging the gaps between tools that were never designed to talk to each other.
via convert --from mem0 --to vektor --input memories.json --output memory.db
Vek-Sync — Continuous Sync
Vek-Sync keeps your local VEKTOR memory in sync with remote vector DBs. Instead of one-shot migrations, it runs a continuous sync pipeline — watching for new memories, pushing them to your backup store, pulling from remote when you switch machines. Think of it as git for your AI memory.
How to Export Your Conversations Right Now
Before you can migrate anything, you need the raw export files. Here’s how to get them from the two platforms that support it today.
Claude (claude.ai)
Go to claude.ai and sign in
Click your profile icon in the bottom left
Select Settings
Go to the Privacy tab
Click Export Data
Claude will email you a download link — usually within a few minutes
Download the zip file and extract it
Inside you’ll find conversations.json — this is your full conversation history
The file is a JSON array where each conversation has a uuid, name, created_at, and a chat_messages array. Each message has a sender (human or assistant), text, and created_at. Vex reads this natively.
ChatGPT (chat.openai.com)
Go to chat.openai.com and sign in
Click your profile icon in the top right
Select Settings
Go to Data Controls
Click Export Data
OpenAI will email you a download link — this can take up to a few hours, sometimes a few days
Download the zip file and extract it
Inside you’ll find conversations.json
ChatGPT’s format is more complex — conversations are stored as trees rather than flat arrays, because ChatGPT supports branching when you edit a message. Vex handles this automatically, walking from the current_node to root and reconstructing the active conversation thread.
Beyond Chat History: Code Editors, Databases, and Agent Memory
Conversations from Claude and ChatGPT are just the starting point. Vex speaks a wider ecosystem. If you use Cursor or Windsurf as your AI coding editor, your project context and agent memory can live in a local vector DB and migrate with you when you switch tools.
If your team stores embeddings in pgvector inside a Postgres database, Vex exports the full table — schema-introspecting the column layout automatically — and imports it into Qdrant, Pinecone, or a local VEKTOR instance with a single command. ChromaDB collections, Weaviate classes, Qdrant clusters — all read and written through the same interface.
The pattern is always the same: one export command, one portable .vmig.jsonl file, one import command into whatever target you choose. The vector DB market is fragmented by design; Vex treats that fragmentation as a solved problem.
What Happens to Your Conversations into VEKTOR
Once you’ve imported your conversations into VEKTOR Slipstream, they become first-class memories. They live in a local SQLite database on your machine. They’re immediately searchable via BM25 full-text search. When you add embeddings, they become semantically searchable — you can ask VEKTOR to find relevant conversations by meaning.
The MAGMA graph layer will eventually draw edges between related conversations — connecting the session where you first discussed a concept to the session where you refined it, to the session where you shipped it. Your conversation history becomes a knowledge graph, not just a flat list.
Crucially: it’s all local. The database is a file on your hard drive. You can copy it, back it up, migrate it to a new machine, or export it again at any time. You own it.
Beyond Chat History: Code Editors, Databases, and Agent Memory
Conversations from Claude and ChatGPT are just the starting point. Vex speaks a wider ecosystem. If you use Cursor or Windsurf as your AI coding editor, your project context and agent memory can live in a local vector DB and migrate with you when you switch tools.
If your team stores embeddings in pgvector inside a Postgres database, Vex exports the full table, schema-introspecting the column layout automatically, and imports it into Qdrant, Pinecone, or a local VEKTOR instance with a single command. ChromaDB collections, Weaviate classes, and Qdrant clusters, all read and written through the same interface.
The pattern is always the same: one export command, one portable .vmig.jsonl file, one import command into whatever target you choose. The vector DB market is fragmented by design; Vex treats that fragmentation as a solved problem.
pgvector → Qdrant (team DB to local cloud)
vex migrate --from pgvector \
--url postgres://user:pass@your-host/db \
--to qdrant \
--url http://localhost:6333 \
--collection memories
ChromaDB → VEKTOR (local experiment → production)
vex migrate --from chroma \
--collection my-agents \
--to vektor \
--db memory.db
Qdrant → Pinecone (self-hosted → managed)
vex migrate --from qdrant \
--url http://localhost:6333 \
--collection memories \
--to pinecone \
--api-key $KEY \
--index my-index \
--host $HOST
The Deeper Point
The AI industry is at an inflection point. The capabilities are advancing faster than the infrastructure around data ownership. Right now, most people’s relationship with AI memory is entirely passive — the platform decides what to remember, how to store it, and whether you get it back.
That’s not a stable arrangement. It puts enormous trust in the continued goodwill and solvency of a handful of companies. It creates a world where the person who has been using an AI assistant for three years has genuinely more to lose when a platform shuts down than someone who started last week. The more useful these tools become, the worse the lock-in gets.
The tools exist to fix this. The formats are open. The databases are open. The migration tooling is open. What’s been missing is a clear, simple path from “I want to own my conversation history” to “I own my conversation history.”
That path now exists.
Getting Started
Install Vex
npm install -g @vektormemory/vex
Install VEKTOR Slipstream (local memory SDK)
npm install -g vektor-slipstream
Check what you have
vex --help
Then follow the export steps for whichever platform you use, and run:
vex migrate --from claude-export --to vektor \
--file conversations.json \
--db ~/my-memory.db
Your conversations are now in a local SQLite database you control entirely. You can search them, back them up, migrate them to any vector DB on the market, or convert them into fine-tuning data for any LLM provider.
That’s what data ownership looks like in practice. Not a privacy policy. A file on your hard drive.
VEKTOR, Vex, Via, and Vek-Sync are open-source tools built by VEKTOR Memory. Vex is available at github.com/Vektor-Memory/Vex and on npm as @vektormemory/vex. VEKTOR Slipstream is available at vektormemory.com.
Agentic Workflow
Generative Ai Tools
Llm Applications
Vector Database
Open Source
Top comments (0)