When I brought aide back, the headline was "context as code": your project's memory and decisions live in the repo as reviewable records rather than in some vendor's hosted store. That's a nice slogan right up until your tool only works with one vendor's assistant, at which point you've just moved the lock-in by one box.
So this is the part that makes the slogan true: aide isn't tied to Claude Code. It started there, picked up OpenCode support a couple of days after the first release, and as of this week runs on Codex CLI too. Three harnesses, one knowledge store.
The trick is an adapter layer. Each assistant has its own lifecycle (session start, tool calls, the hook points where aide injects context or captures a memory) and each names and shapes those events differently. The adapters map every harness's events onto one shared set of core functions; the Go binary doing the actual work (storage, search, the MCP server) doesn't know or care which assistant is on the other end. Add a harness, write an adapter, done.
What the store actually holds
Portability only matters because of what moves with you, and that's the part I care about most. The failure mode of an AI assistant isn't that it's stupid, it's that it confidently works from the wrong context: a stale decision, a half-remembered convention, a fact that was true three refactors ago. Garbage in, plausible garbage out. aide's whole design is aimed at that, by storing only things that are current and checkable and handing them over as fact rather than vibes.
Decisions are constitutional. A decision in aide is an ADR: a topic, a choice, a rationale. It behaves like a clause in a constitution, injected into every new session automatically, so the assistant starts already knowing "we use JWT with refresh tokens, because…". When you change your mind you don't edit the old one, you record a new decision for the same topic; the latest supersedes and the full history stays readable. Amendments, not overwrites. The agent only ever sees the current law, and you can always read how it got there.
Memories are scoped. Not everything should be shouted into every session. A memory carries a scope: scope:global rides along in every project, project:<name> only surfaces in the project it belongs to, and session memories group what was learned in one sitting. The injector pulls the global preferences and the current project's context and leaves the rest in the index, searchable but quiet. The session gets the facts relevant to here, not the union of everything aide has ever heard.
The code index is fact on demand. The other half is structural truth about the code itself, served over MCP: where a symbol is defined, who calls it, the shape of a file, built from a tree-sitter parse rather than a guess. When the assistant needs to know something about the codebase it asks and gets the current answer, instead of pattern-matching from whatever happened to be in the context window.
The through-line is that every one of these surfaces current, material fact and nothing else. That's the antidote to context poisoning: you can't be dragged off course by stale context if the store only hands over what's true now. And because a precise fact is small (the one symbol, the one decision, not a wad of maybe-relevant text) it costs a fraction of the tokens that stuffing the window full of "context" would.
Which is why portability matters
Put those together and the reason to keep it vendor-neutral becomes obvious. This isn't a chat history you'd shrug off losing; it's your team's accumulated, curated, current understanding of a codebase. Switch assistant, or run two side by side, and the .aide/ directory comes with you: same decisions, same scoped memories, same code map. Records you can read, diff and move aren't just tidier than embeddings in someone's cloud, they're the only version of "memory" that survives you changing your mind about which AI you use. Repo and docs on GitHub.