Canceling a tool should not delete the shape of your thinking.

That sounds obvious until you try to leave one. You downgrade a plan, or a provider sunsets a product, or you simply want to move, and you discover that the months of work you did inside that tool were never really things. They were states of an interface. The summaries, the project context, the back-and-forth that slowly taught the system how you work: all of it lived in a place you don't control and can't open anywhere else. When the subscription ends, the shape goes with it.

We used to have a clean word for this. Lock-in. And we used to know exactly where it lived: in the file format. The reason people stayed on a particular word processor or design app for a decade was that their documents were written in a dialect only that app could read. The threat was legible. You could point at the .proprietary extension and say, that's the cage.

That cage still exists, but it is not where the danger is anymore.

Lock-in moved

In AI tools, the work you'd most hate to lose often isn't a file at all. It's the accumulated context, and I mean specific products: ChatGPT's memory of you, a Claude Project with its instructions and uploads and prior threads bundled into one container, the dozens of small artifacts buried in months of conversation history (a burial I take apart in The Scrollback Graveyard). None of that has an extension. None of it exports cleanly, because it was never designed to exist outside the interface that produced it.

This is a quieter kind of lock-in, and a stickier one. A proprietary file format at least leaves you with a file. You can hunt for a converter, pay someone, brute-force your way out. Provider-shaped memory leaves you with nothing portable. The value lives in a relationship the tool has with itself, and you cannot carry a relationship out the door. Switch models and you don't migrate it. You start over.

The trend is making this worse, not better. The pitch for the current generation of assistants is that they remember more, that the project gets richer over time, that the system learns you. Every one of those improvements deepens the well. The more useful the container becomes, the more it costs to leave, and the more of your actual thinking lives somewhere you can't open after you cancel.

So the old instinct, distrust the weird file format, points at the wrong thing now. The format was never the real lock-in. The format was a symptom. The real question has always been: when this tool goes away, what do I still hold in my hands?

Boring formats survive

Here is the unfashionable answer. The work you want to keep for years should be stored in formats that have already survived for years.

Markdown. HTML. SQLite. PDF. PNG. These are not exciting. Nobody is raising a round to reinvent the text file. But that is exactly the point: a format becomes durable by being boring, widely implemented, and uninteresting to disrupt. You can open a Markdown file in a hundred editors, a terminal, a phone, a tool that hasn't been written yet. An HTML page renders in any browser made in the last twenty years and almost certainly any browser made in the next twenty. SQLite is a single file on disk that a thousand programs can read, with a stated design goal of being readable in the year 2050. A PDF from 2004 still opens.

Call the position actuarial rather than nostalgic. When you choose a format, you are placing a bet on how long something will still be readable, and the boring formats have the best survival record we have. They have outlived the companies that popularized them. That is the property you actually want.

It matters which formats, specifically. A brief stored as Markdown is a brief you can still read when the thing that wrote it is gone. A dashboard stored as an HTML page is a page that opens on its own, with no server to phone home to. A dataset stored as a SQLite file is a database you can query with off-the-shelf tools, not a row in someone else's cloud that vanishes with your account. The agent might build something elaborate on top of that SQLite file, a small app, a live view. Set that aside. Underneath, it is still one file you can copy to a USB stick. The richness sits on top of something plain, and the plain thing is what you keep.

Compare that to "your project, remembered." One of these you can hold. The other you can only rent.

Portability includes the model

There is a second half to this, and it is the part the agent era adds.

It is no longer enough to own your files if only one vendor's model can work with them. If your documents are durable but the only thing that can read, extend, and maintain them is a single provider's assistant, you have just moved the lock-in up a layer. The format is free; the intelligence that operates on it is captive. You can open the file, but you can't keep working the way you'd grown used to working, because the working depended on one company's model staying available, affordable, and pointed at your stuff.

So model-portability belongs in the same argument as file-portability. The two are the same promise at different layers. Your work should be writable and readable by whatever agent you choose, and that choice should be revisable. Claude this month, a different model next month, a local one the month after, all writing into the same place, because they speak to it over an open protocol rather than through a private door only one of them holds the key to. MCP is the unglamorous plumbing that makes this true (if you are checking whether your Claude or ChatGPT plan supports MCP connectors, I keep a rundown here). What the plumbing buys you matters more than the acronym: the place your work lives does not belong to the model, so swapping the model doesn't cost you the work.

This is what turns "you own your files" from a slogan into something operational. Ownership that you can only exercise by abandoning your workflow is not much of an ownership. Real portability means you can leave the model and keep the work, or keep the work and change the model, in either direction, without either choice being a hostage to the other.

What "export" should mean

Most tools have an export button. Very few of them mean it.

A real export is not a JSON dump that only the same vendor can re-import. It is not a zip of opaque blobs. A real export hands you the work in the durable formats, laid out the way you'd organize it yourself: the Markdown is Markdown, the pages are pages that open, the data is a database file, the folder structure is the folder structure. You should be able to take the whole thing, drop it somewhere else, and have it make sense without the original tool present in the room. The test is simple. Delete your account, open the export, and see whether you still have your work or just a souvenir of it.

That test is the one worth applying before you pour months into any AI tool. Not "how much will it remember," which is the question the category wants you to ask. Ask instead: what do I walk away with? If the answer is a smarter interface I no longer have access to, the memory was never yours. It was a feature of a product you were renting, and it ends when the rental does.

The models are going to keep changing. That is the one safe prediction. The good one this year will be the average one next year, and you will want to move, and you should be able to move without grief. You protect yourself by making sure the thing you care about, the actual work, lives in formats and in a place that don't depend on guessing the winner.

Build on whatever model is best today. Just keep the work somewhere you can still open after you cancel.