Recently, Mark Cuban asked on X if consumer AI switching costs would ever approach zero without a standard way to export what a model remembers. He pointed out that the more you use a model, the more it stores, making it tougher to switch.
Craig Tracey, founder and CEO of SixDegree, replied on LinkedIn that Cuban was missing the point. He said AI memory today is just a bunch of random facts, like "prefers aisle seats" or "has a dog named Biscuit." Moving that around is just like relocating a messy junk drawer. Cuban disagreed. He argued that each Claude project has its unique skills, chats, and repeatable tasks; dismissing that as junk is like saying everything in a spreadsheet is trash.
Portability is going to become a big deal in the next 6 to 12 months, not just between providers, but across teams, workstreams, and time. So, what’s the state of portability today? Most of the literal commands you give to AI tools can be transferred easily. But the insights those tools get about you and the work you've done together? Not so much. And the companies that could fix this have mostly created pathways that only work in one direction.
Why the Clock is Running
Most people still choose one AI tool and stick with it. I think this won't last, and there are a bunch of reasons piling up.
- Local models are improving. More tasks will run on personal computers or private servers, and your context needs to go with it.
- Frontier models are leveling out. When the best models are nearly the same in quality, people start choosing based on price and features. If switching isn’t easy or cheap, it limits your options.
- Projects grow beyond their limits. A long-term project often breaks into multiple streams, each needing its own context. That’s a portability challenge even if you keep the same vendor.
- Tools are evolving quickly. In the past year, Google replaced its Gemini CLI for personal, Pro, and Ultra users with Antigravity CLI. Windsurf turned into Devin Desktop. Cursor dropped its Memories feature while Roo Code shut down. If your context is tied to a single tool, it's at the mercy of that tool's updates.
There's also the slow problem of outdated context.
As projects age, irrelevant facts and old instructions build up, creating clutter. Past attempts become dead ends, which are especially frustrating: when you lose track of what didn’t work, the next time (or the next tool) is likely to try it again. This increases your context window, costing you time and money, while muddying the project's original goals.
And then there’s the issue of team handovers. Passing an AI-driven project to someone else these days often feels like a scavenger hunt through various vendor platforms, chat histories, dotfiles, and external datastores.
So when I talk about portability, I’m not just talking about swapping one chatbot for another: I mean being able to switch platforms and devices, hand off work to a teammate, and break apart big projects without dragging along the entire convoluted history.
Seven Types of Context
Cuban and Tracey were focusing on different layers of the same problem. Tracey was concerned with learned facts, while Cuban dove in specifically on projects, skills, and chats. All are types of context, but they are very different forms.
| Layer | Example | Portability today |
|---|---|---|
| Instructions | AGENTS.md or CLAUDE.md, GitHub copilot-instructions.md, GEMINI.md, Cursor rules, Claude and ChatGPT Project instructions | High |
| Skills & commands | Agent Skills (SKILL.md folders), Copilot prompt.md files, slash commands | Medium-High |
| Tools | MCP server configs (kept in a different files and formats, depending on the client) | Medium |
| References & artifacts | Project’s knowledge files, generated outputs, links, etc. | Medium |
| Memory | Facts learned and stored by the specific coding agent / tool | Low |
| History | JSONL transcripts, SQLite databases, chat exports | Very low (easy export, poor input) |
| Metadata | The who, what, when, and why of conversations and decisions | Very low |
The closer a layer is to simple text you wrote, the easier it is to move around. The more the tool generated or understood, the harder it becomes.
Tracey's junk drawer situation is found in the lower three rows. Most of what Cuban talked about is near the top, with the exception of chat histories.
What Mostly Transfers
Good news first: the top layer's format is fairly consistent, and getting better.
Files like AGENTS.md are used by various platforms like Codex, Copilot, and others, with around 60,000 repositories sharing it. It now has partnerships with the Linux Foundation's Agentic AI Foundation (AAIF), which includes major players like AWS and Google. The SKILL.md format from Anthropic works in about 46 clients. Almost every tool speaks MCP.
Generating configurations for multiple tools from a single source is also solved, though it's a crowded field: rulesync has a million npm downloads each month, and convert bidirectionally between 70+ targets. Also available: Microsoft's APM, Ruler, Vercel's skills CLI, and skillshare cover much of the same ground. And add-mcp can build native MCP configs for 22 different agents.
But there are some catches. Here’s the short list:
Claude Code might ignore AGENTS.md: if a CLAUDE.md is in your project directory, it ignores all AGENTS.md files. The workaround? A CLAUDE.md that simply imports @AGENTS.md … adding bloat to every single project.
MCP isn’t always universal: some clients want different formats (YAML vs TOML) for their configurations. There are competing formats for packaging skills (Agent Plugins by Vercel vs claude-plugin). And credentials don’t transfer at all.
Skill folders are confusing: some clients check root, some expect a named folder, some check multiple folders, and collisions can occur.
- Codex, Copilot, Cursor, Gemini/Antigravity, Devin, OpenCode, Goose, Amp, Junie: .agents/skills/
- Claude Code, Copilot, Cursor, OpenCode, Goose, Amp, Cline: .claude/skills/
- Kiro: .kiro/skills/
Where Memory Lapses
Portability issues really show up with memory and history, where vendor export/import features highlight the problems.
| Platform | Exporting data | Importing data |
|---|---|---|
| Claude apps | ZIP of conversations, projects, memory (if allowed by admin) | Experimental “Import Memory” (March 2026): paste another assistant’s prompt response) |
| Claude Code | JSONL transcripts & memory folders | From Codex, Gemini, and Cursor: claude import instructions, rules, skills, MCP |
| ChatGPT | conversations.json (ZIP) | None |
| Codex | Session JSONL in ~/.codex/sessions | From Claude Code, Cowork, Cursor: instructions, skills, plugins, MCP, memories, chat (30 days) |
| Gemini app | Google Takeout | Paste a prompt, or import chats from ChatGPT and Claude zipfiles |
| GitHub Copilot | JSON or links (VS Code chat); CLI sessions (GitHub sync) | None |
| Cursor | Chat (Markdown) | None |
Getting raw chat data out is usually doable, but clean memory exports? Not a chance. And none of these platforms has APIs for reading or writing memory.
Transferring memory often involves pasting results in, but it’s like a game of telephone: results vary. This process isn't true portability.
Plus, memory can shift on its own. Some tools drop unused entries after a while. Whatever you get today is a snapshot of something that changes regularly.
History isn’t in much better shape. Different platforms have various proprietary transcript formats that can change without notice. Moving records to another machine often requires rewriting paths.
Proposed standards are abundant, but actual adoption is the real hurdle. There are lots of solutions out there, but progress is slow:
- STS format (Hugging Face): minimal but easy to adopt
- Conversation history schema (Data Transfer Initiative): one major adopter
- ATIF (Harbor Framework): lossy native-format conversion
- Agent File (Letta): bundles prompts, memory, history, and tools; only Letta uses it
- Portable Memory (MacPaw): supports supersession and deletion tombstones; five GitHub stars
As for metadata, it's often just not recorded at all, leaving target platforms unsure who said what, when, and what’s still true. This is the messy reality Tracey was pointing to.
A Crowded Middle
Where vendors end, the open-source world rushes in.
Let’s start with memory. There are tons of external memory systems sitting next to your agents, usually connected via MCP and other tools, and many have stats that would make any project envious. For instance, claude-mem has about 102,000 GitHub stars. Mem0 is close to 67,000 and has raised a hefty \$24 million. Hindsight is about 52,000. And agentmemory, which just popped up in February, is nearing 30,000 (with provenance on every memory).
The bright side is many of these are using plain Markdown files with git-style versioning as the go-to method. Projects like Basic Memory, Letta's MemFS, EverOS, and Serena all work this way, so at least you can open your memories in a text editor.
But there’s a downside: churn. ByteRover archived its repo on September 27. Meta bought Limitless, the brains behind Rewind, last December and pulled the plug on its capture product. A memory layer that you choose to avoid vendor lock-in can become another dead end.
History has its own crowd. SpecStory saves sessions from about 15 agents as Markdown in your repo, and with specstory resume\, you can rebuild a session in another agent's format. Entire keeps transcripts as git refs that move along with your code. Traces offers shared hosting and session resuming across 19-plus agents.
Then you’ve got handoff tools that let you stop in one agent and continue in another. ai-memory combines work from over 20 systems into a shared, git-backed Markdown wiki with typed handoffs: stop in Claude Code, pick up in Codex. cli-continues reads 16 agents and puts a structured summary into the next one. Mem0's openmemory allows you to move coding sessions back and forth between Claude Code, Codex, and OpenCode. Amp's Handoff is interesting: you set a goal, and it creates a prompt and a file list for a new thread. It only works in Amp, but it inspired opencode-handoff.
Picking up a session in a different coding agent on the same machine is becoming more common. Most of this action is aimed at developers, though; regular chat users don’t have as many options, mostly browser extensions like MemoryPlugin (costing \$89 to \$180 a year across 21-plus chat apps) and smaller tools to copy a transcript from one app and paste it into another.
Who's Making Moves
If vendors won’t open things up from the inside, someone else will.
The Data Transfer Initiative put out AI portability principles back in August 2025 and this year has been pushing for both chat and memory import and export. In September, they called for a full agent harness (tools, memory, workspace, and guardrails) to be the unit of portability, which is pretty close to the layered view we talked about. DTI's members include Amazon, Apple, Google, and Meta, but not Anthropic, OpenAI, or Microsoft.
On another note, the Agentic AI Foundation hosts MCP, AGENTS.md, goose, and A2A, and has Agent Skills in the works. They've got groups focused on identity and trust as well as workflows, but none for memory or user context.
Regulators are starting to pay attention, but they’re not very clear yet. GDPR’s portability right includes the data you provided, like your prompts; however, the memory a model infers about you might only falls under the right of access. The EU Data Act's switching rules, effective since September 2025, cover inputs, outputs, and metadata… but nobody’s definitively figured out if a chatbot counts as a "data processing service." The Digital Markets Act is the one to keep an eye on. ChatGPT was flagged above the gatekeeper thresholds in July but hasn't been officially labeled yet. If it is, Article 6(9) would demand real-time data portability. In the US, I haven’t found any laws on chatbot portability or any industry commitments.
So: Right or Wrong?
Cuban kicked off his post with that question, so here’s my take.
He’s spot on that switching costs aren’t going to drop without standard formats. For the top of the stack, we’re almost there, and turning them into each tool's native config is already a busy open-source field. But when it comes to memory and history, there’s no standard format yet, and companies with the data have built importers that only bring it in.
Tracey is correct too; just having a format won’t fix everything. A memory that comes in without its source or links to everything else is a piece of information you can’t fully trust.
Neither post mentioned the costs of not switching. That same mess makes it tougher to hand a project to a teammate or to keep a long-running one from getting stuck in old context.
Until that changes: only the parts of your context that live in plain text files, that you control, are the parts you actually get to keep.
Top comments (0)