The Amnesia Tax

AI coding agents — Claude Code, Cursor, and everything else built on the Model Context Protocol (MCP) — are genuinely good within a session. They can read a codebase, hold a lot of it in context, and reason through a gnarly bug faster than most humans would. Then the session ends, and all of that gets thrown away.

The next session, whether it's the same engineer tomorrow morning or a teammate an hour later, starts from a blank slate. It doesn't know that the team already tried switching the retry backoff to exponential and it caused a thundering herd in production. It doesn't know the payments service intentionally violates the lint rule about floating-point currency math because the accounting team requires it. It doesn't know that “just bump the Node version” was tried three weeks ago and broke the Lambda cold-start budget.

So it re-derives all of that. Sometimes it gets there fine, just slower — burning tokens and minutes to rediscover something the team already knew. Sometimes it gets there wrong, and reintroduces a fix that was already tried and reverted for a reason nobody told it about. Multiply either version across every engineer's agent, every session, every day, and you've got a real ongoing cost that never shows up as a single line item — we call it the amnesia tax.

The models aren't the bottleneck here. The gap is that agents have nowhere durable and shared to put what they learn. A scratch file in one engineer's home directory doesn't reach a teammate's machine. A chat transcript in Claude Code doesn't reach a Cursor session. Code comments, when they exist at all, explain what the code does — almost never why it's written that way, and never what the team already tried and ruled out.

We're not going to hand you a made-up industry statistic like “teams waste 34% of their AI spend on redundant context.” Nobody has that number, and anyone who quotes one to you made it up. What you can reason about directly is where the cost actually comes from:

• Tokens. Re-deriving something from scratch means an agent has to read the relevant files again and reason through them again — that's input tokens for every file it opens and output tokens for the reasoning trace. Recalling a written-down answer is one short query. The gap between those two, per occurrence, is usually an order of magnitude or more, though the exact number depends entirely on how deep the original investigation was.
• Time. The token bill is the part you can see on an invoice. The part you feel is the engineer sitting there while the agent re-explores a codebase it's effectively already explored, on someone else's machine, last week.
• Wrong answers. This is the expensive one. An agent that doesn't know a fix was already tried and reverted will happily propose it again, with full confidence, and nothing in its context will contradict it.

Watch a few agent sessions back to back on the same repo and the pattern is obvious:

None of this needs a smarter model to fix. It needs a place for the team's agents to put what they learn — something small and fast enough that writing to it is free of friction and querying it is cheaper than re-deriving the answer.

That's threadctx: an MCP server that gives AI coding agents durable, team-shared memory. When an agent figures out something worth keeping — a root cause, a convention, why a decision went the way it did — it writes a short entry scoped to that repo. The next agent to touch the repo, on any tool, for any teammate, can pull it back with one query instead of rebuilding it from nothing.

The entries stay small on purpose — a sentence or two, not a transcript dump and definitely not your source code. Think of it as the note a good senior engineer would leave in a Slack thread, except an agent actually reads it before repeating the mistake.

Most engineering teams aren't on one AI coding tool anymore. Some people are on Claude Code, some are on Cursor, and whoever's hiring next quarter will probably bring in something else. If your memory layer only works inside one of those tools, it's not really a team memory layer — it's one person's notes with a nicer UI.

threadctx runs on the Model Context Protocol, the open standard Anthropic introduced for connecting agents to external tools and data, which Cursor and most of the rest of the ecosystem have since adopted too. In practice that gives you three things:

• One install, every client. The same threadctx config works in Claude Code and Cursor today, and in whatever MCP-speaking tool your team picks up next.
• Nothing to migrate away from. Local mode is free, MIT-licensed, and stores memory as plain JSON on disk (~/.threadctx/local.json). You can read it, grep it, or delete it whenever you want.
• You're not betting on our roadmap. If we disappeared tomorrow, the protocol and your local memory files would still be yours. Try saying that about a memory feature bolted onto a single vendor's editor.

Concretely, here's what changes:

The part worth noticing: someone pays the cost of figuring something out exactly once. After that, it's a cheap read for everyone else on the repo, indefinitely. A team of five doesn't just save five times what a solo developer saves — every extra person you add is another agent that might hit the same wall, and now they don't have to.

The obvious question is what a tool like this actually sends off your machine, so here's the honest answer:

• Not your source code. Entries are short, agent-written learnings — not file contents, not diffs, not the codebase itself.
• Local mode never phones home. The only network calls it makes are whatever your LLM provider already requires. Memory sits in a JSON file on your machine and nowhere else.
• Cloud mode is scoped per repo and per team. Only entries your own team wrote for that specific repo come back on a query, and only with your API key.