You have probably explained your setup to an AI three times this week. Once to Claude, once to ChatGPT, and once more to a fresh terminal session that had never heard of your project. Same stack, same conventions, same list of things not to do. Typed again, from scratch, because the window was new.
The context you rebuild every morning
The retyping is the visible cost. It is annoying, and it is the smaller half of the problem.
The larger half is that your decisions evaporate with the window. You spent forty minutes last month working out that a particular approach was wrong for your codebase. You landed on a reason. That reasoning existed in a chat that has since scrolled away, so today the assistant proposes the same rejected approach with the same confidence, and you either argue it down again or you do not notice and ship it.
Notes in a document do not fix this, because the assistant cannot read your document unless you paste it, and if you are pasting it you are back where you started. What is missing is not storage. It is storage the model can reach on its own, in the middle of the work, without you.
One store, every model
Keynodex Memory is a memory server your assistant talks to over the Model Context Protocol. MCP is the open standard for how an AI application connects to an outside tool. Because the standard is shared, the same memory store answers to any client that speaks it.
That is the whole design. Not a memory feature inside one assistant. A store that sits outside every assistant, at https://memory.keynodex.com/, which each of them connects to.
Three things follow from that, and they matter more than any individual feature:
- Claude, Claude Code, ChatGPT, and Codex read and write the same memories. Save a decision in one, and the next one already knows it.
- Your store is isolated per account. No other account can read it, and the assistant only ever sees what your own tool calls return.
- There is no API key. Sign-in is Google with OAuth 2.1 and PKCE, done once in the browser per client. Nothing to generate, paste, or rotate.
Connect it once
Setup takes about a minute per client, and it is the same store behind all of them.
Claude, from the directory
Open Settings, then Connectors, and search the directory for Keynodex Memory. Click Connect, sign in with Google when the consent page opens, and approve. This is the recommended path because updates and reconnects are handled for you.
Claude, by URL
If you would rather add it by hand: Settings, Connectors, Add custom connector, and paste https://memory.keynodex.com/mcp. Same browser sign-in, same store.
Claude Code
One line in the terminal:
claude mcp add --transport http keynodex-memory https://memory.keynodex.com/mcpThen open the /mcp menu and authenticate. Sign-in still happens in the browser.
ChatGPT and everything else
ChatGPT support is in beta through a manual developer-mode setup, and the walkthrough at memory.keynodex.com/connect/chatgpt covers each step, including the OpenAI data controls worth reading before you approve. Codex and any other client that supports remote MCP connectors over HTTP work the same way: point it at the endpoint and complete the browser sign-in.
Once you are connected, type Keynodex setup in a new chat. That is the canonical first-run trigger. It runs a short guided session that gets your first memories in rather than leaving you at an empty store wondering what to type. Full per-client steps live in the setup docs.
What to save on day one
This is the section that decides whether the product is useful to you or just installed. An empty memory store is worth nothing, and the instinct to "save everything important" produces a pile nobody can search. Keynodex Memory holds three different kinds of record, and knowing which is which is most of the skill.
Memories are atomic durable facts
One fact per memory, phrased so it is still true next month. We use pnpm, not npm. Marketing copy never uses em dashes. The staging database is a copy, so destructive migrations are fine there and never fine in production. These are the rulings you would otherwise repeat in every new chat.
The test for a good memory is whether it would change what an assistant does. "The project is a Next.js app" is visible from the repo and wastes a slot. "We rejected server actions for form submission because of the error-handling story, and that decision stands" is not visible anywhere, and it is exactly what gets re-litigated.
Playbooks are procedures that remember their own runs
When a sequence of steps is one you repeat, store it as a playbook rather than as prose. How you cut a release. How you onboard a client. What the four checks are before anything touches production. A playbook keeps run history, so the record is not just what the procedure says but what happened the last several times it was followed.
Claims are facts that check themselves
This is the one almost nobody sets up, and it is the answer to a real failure. A stored fact is a snapshot, and snapshots rot. Six months on, your assistant is reasoning confidently from something that was true when you wrote it and is not true now, and neither of you knows.
A claim is a fact stored together with the command that re-checks it and a window after which it should be doubted. "Production runs Node 24" is a claim; the command that proves it is node -v; the window is thirty days. After that it shows up as stale rather than as truth. You can ask for stale claims at any point and get back the list of things worth re-verifying before you trust them.
A memory that can check itself is worth more than ten that cannot, because the ten will eventually lie to you with a straight face.
Working with it in a normal session
The connection does nothing by itself. Three small habits are what turn it into leverage.
- Ask before you touch. Before you open a file you have not seen in a while, or debug an error you have hit before, ask what the store already knows about it. Recall on the specific thing beats a general context dump.
- Save with the anchor attached. A memory tied to a file path, an error string, or a command gets found later by the agent working on that exact thing. A loose note does not.
- Ask for account status when something looks wrong. It reports your email, your plan, and your memory count. If the store looks unfamiliar, that reading usually explains it: you are signed in with a different Google account than the one holding your memories.
None of this requires a new interface. It happens in the chat you were already in.
The part that compounds
Everything above is useful on a Tuesday. This is the part that matters over a year.
Anything you teach an assistant inside that assistant dies with that assistant. Custom instructions, a carefully tuned project, a long thread full of context: all of it is locked to one product, and the moment a better model ships or your team standardizes on something else, the teaching does not come along. You start over, and starting over is the reason most people never bother teaching an AI anything durable in the first place.
The model you will be using in a year probably does not exist yet. Memory sits outside the model, so that is fine. The rules, decisions, and playbooks you save now carry into whatever you use next, and switching costs you a browser sign-in.
Set it up once, and keep it for every model after. That is the actual product.
When the free plan stops being enough
Free is not a demo. It includes the full consumer tool surface, every tool, nothing feature-gated, with a cap of 100 active memories.
One hundred is more than it sounds when memories are atomic and you are disciplined about what earns a slot. Most people spend a long time under it. When you do reach the cap, the assistant tells you and links to billing, and nothing is deleted. Pro removes the cap and adds priority support.
The honest advice is to start free and upgrade when the cap actually bites, not in advance. If you find yourself deleting a useful memory to make room for a more useful one, that is the signal. Details are on the plans page, and plan changes always happen on the website, never as a purchase inside a chat.
Where to start
Connect one client, type Keynodex setup, and save the five things you are tired of repeating. That is a ten-minute exercise, and it is enough to tell you whether the rest is worth it.
Setup steps for every client are in the setup docs. What is stored, who can read it, and how deletion works are in the privacy docs. Common privacy and plan questions are in Is It Safe to Give an AI a Permanent Memory?. An overview of the product is at Keynodex Memory.
Common questions
Do I need an API key?
No. Sign-in is Google with OAuth 2.1 and PKCE, completed in the browser once per client. There is no key to generate, store, or rotate.
Can more than one AI use the same memory at the same time?
Yes, and that is the point. Claude, Claude Code, ChatGPT, and Codex all read and write the same store. Save something in one and the next one already has it.
What happens when I hit the 100-memory free cap?
The assistant tells you and links to billing. Nothing is deleted, and no tools stop working. Pro removes the cap.
Can Keynodex read my memories, or train on them?
Your store is isolated per account and encrypted in transit and at rest. It is not end-to-end encrypted: like most cloud products, our systems can technically access stored content in order to operate the service. Keynodex does not train models on your memories and does not sell your data. Your assistant sees only what its own tool calls return from your own store.
Do I have to reconnect every time you ship an update?
Usually not. Keynodex Memory is hosted, so improvements to existing tools apply on your next tool call. If a brand-new tool never shows up, start a new chat first, and reconnect the connector only if it is still missing.