Your notes outlive the model that reads them

There is a line in every AI tool a team adopts that nobody reads at the time, and it is the retirement date. Last week two labs filled one in on models that are running in production right now. That is not a scandal, it is just the shape of the industry, and it tells you something useful about which half of your setup you should be careful where you put.

What did the labs actually announce?

Two deprecations, one day apart.

On 30 September 2026, Anthropic deprecated claude-sonnet-4-5-20250929 and set its retirement for 30 November 2026, with claude-sonnet-5-5 named as the replacement. That is 61 days of notice, against a published commitment of "at least 60 days' notice before model retirement for publicly released models".

On 1 October 2026, OpenAI deprecated GPT-5.3-Codex, GPT-5.1 and GPT-5.4-Nano, with a shutdown date of 1 April 2027. OpenAI's stated policy is longer: at least 6 months for generally available models, at least 3 months for specialized variants, and preview models that "may be retired with much shorter notice, such as 2 weeks".

Worth noting a third line, because it is the one that makes the pattern concrete rather than abstract. Anthropic's model status table lists claude-haiku-4-5-20251001 as Active, with a tentative retirement date of "not sooner than October 15, 2026". That is nine days from the date of this post. Not a promise it goes then, just a floor. Every active model in that table carries one.

Both companies publish the whole lifecycle openly, which is more than most software vendors do. Anthropic goes further than it has to and names the costs itself: users who value specific models have to migrate, researchers lose access for comparative studies, and "model retirement introduces safety- and model welfare-related risks". It has committed to long-term preservation of model weights. None of this is a company behaving badly. It is a company being honest that the thing you are building on is scheduled.

Why does a retirement date matter for a team's knowledge?

Because the clock does not stay on the model. It spreads to whatever the model is holding.

Split your AI setup in two. On one side is the model and everything downstream of it: the weights, the prompts tuned to its quirks, the evals, the latency and cost profile, the things it is unusually good at. That side was always going to churn. Nobody sensible expects the model they picked in March to be the model they run in December.

On the other side is what your team knows. The decision you made in a meeting eleven months ago and why. The runbook. The spec that explains the odd shape of the billing code. The onboarding note. That side is supposed to churn on a completely different clock, measured in years, and often in people rather than in releases.

The failure is putting the second kind of thing on the first kind of clock. It happens quietly, and usually not through a decision anyone remembers making. Knowledge ends up inside a model's memory feature, or a vendor's chat history, or a workspace that only exists because one assistant is wired into it. None of that is wrong on its own. It is wrong in combination with a 60-day notice window, because a team of five to fifty people does not have a migration budget for its own institutional memory twice a year.

This is where a team second brain is a structural answer rather than a preference. Baalda keeps the durable half in plain markdown files on your own disk, edited by several people at once, and lets the AI reach those same files over MCP. The point is not that markdown is nicer. The point is that a .md file has no retirement date, because there is no vendor in a position to set one.

What does model-portable actually mean in practice?

It means the thing that names the model and the thing that holds the knowledge are two different files, and only one of them is yours to keep.

Here is the whole of the model-specific part of a Baalda setup. You mint a token in the app under Vault settings → MCP, then register the endpoint with whatever client you are using:

claude mcp add --transport http context https://api.baalda.com/api/mcp \
  --header "Authorization: Bearer mcp_…"

On a self-hosted server that URL is your own host plus /api/mcp. That command is the entire coupling between your team's knowledge and the AI reading it. When claude-sonnet-4-5-20250929 stops answering on 30 November, nothing in that line changes, because the line does not mention a model. When you move from one client to another entirely, you run the equivalent command for the new one and you are done.

Underneath, the server exposes 22 tools over POST /api/mcp, the ordinary ones a person would want: search_notes, read_note, create_note, edit_note, update_note, list_folders, manage_access and the rest. Any MCP-speaking client gets the same 22, limited by the same per-folder permissions that govern the human whose token it is. There is no per-vendor integration to maintain, because the protocol is the integration.

And the files themselves are the real test. Open the vault folder in Finder and you will find .md files. Not an export of your notes, not a database you can dump to markdown if you ask nicely. The files are the storage format, and each device re-derives its own copies from the sync stream. Nothing in any of them records which model wrote which paragraph, so there is nothing in them that can expire. If every MCP client on earth disappeared tomorrow, the vault is still a folder of text your team can read, grep and edit.

That is also why local agents need no MCP at all. Claude Code, Codex or any CLI tool already has filesystem access, so it edits the .md files on disk directly and the watcher syncs the change to everyone. MCP is the path for cloud and autonomous agents that cannot reach your disk. Two routes to the same files, and neither of them owns the files. We wrote up the mechanics of that in connecting an AI to your notes over MCP and in the MCP docs.

What does this not protect you from?

The model half. All of it. This is the part worth being plain about, because the opposite claim is the one that would make this post an advertisement.

A vault does not preserve model behaviour. If Sonnet 4.5 was better at your particular task than its replacement, your notes will not bring that back. Anthropic's weight-preservation commitment might eventually, but that is Anthropic's call and not yours, and it does not help you on 1 December.

Your prompts and evals still have to be redone. Everything tuned against a specific model's quirks is coupled to that model on purpose. Keeping your knowledge in files does nothing for a prompt that relied on how one model handled a long instruction. Budget for the migration anyway, just not for migrating your institutional memory along with it.

Baalda's MCP surface is an interface too. Those 22 tools are a versioned API. They are open source under Apache-2.0 and self-hostable, so you can pin a server version and nobody can switch it off remotely, but "it is a file on disk" protects the notes, not every integration you build on top of them.

And for one person, this problem is smaller than it looks. If you are solo, your notes are probably already in files, and Obsidian is still the better single-user editor. Nothing in last week's deprecations changes that. If your team's knowledge already lives in Notion and works, a model retirement does not break Notion either, and Notion's hosted MCP server is easier to stand up than running anything yourself. Ownership is the reason to move, not model churn on its own.

What should a team actually do this week?

Not much about Sonnet 4.5 specifically. If you use it through the API, you have until 30 November and a named replacement, which is a normal migration.

The useful exercise is one question, asked honestly: if the AI tool your team relies on were switched off at the end of the month, what would you lose that is not in a file somewhere you control? If the answer is "nothing, we would just be slower", your setup is already in good shape. If the answer includes decisions, context or anything a new hire would need, that part is sitting on someone else's clock.

Anthropic publishes an audit path for exactly the narrow version of this: Console → Usage → Export gives you a CSV of your API usage broken down by key and model, so you can find deprecated models still in production. There is no equivalent export for "which of the things we know only exist inside a vendor's product". That audit is manual, and it is the one worth doing. The ownership argument is easiest to make on a quiet week, which this is, rather than in the last fortnight before a shutdown date.