AI coding agents stopped being a novelty and became a category. There are terminal agents, IDE agents, and desktop agents, and the list grows every quarter. OpenCode is one of the open source ones, and if you have seen it in a terminal near a developer, the first question is usually simple: what is OpenCode, exactly, and how is it different from the assistant I already pay for?
This article answers that, and then answers the question people ask second, after they have used it for a week: where does everything I teach it go?
What OpenCode does
OpenCode is an open source AI coding agent. It runs in your terminal, as a desktop app, and as an IDE extension, and it works against the model provider of your choice. The catalog is long, more than seventy providers through Models.dev, from the big hosted models to local ones, and you can sign in with accounts you already have, including GitHub Copilot and ChatGPT subscriptions. You are not locked to one vendor's model.
Inside a session it behaves like the coding agents you know. It reads and writes files, runs commands, loads language servers for the languages in your project, and can run several agents in parallel on the same repository. Sessions can be shared with a link when you want a second pair of eyes on what happened.
It is also open source, which matters for a tool that runs on your own machine with access to your own code. OpenCode states that it does not store your code or context data, and you can read the code that makes that claim. That is not true of every agent you might install.
Chat history, project instructions, and shared memory
These three things get confused with each other, and the confusion is the reason people expect memory that is not there.
Chat history is the transcript of a session. It is useful, and it is scoped to the tool and usually to the session. It does not follow you to another agent, and it is not a durable store you curate.
Project instructions are the rules you commit to a repository, like an AGENTS.md file. They are durable, but they are scoped to the project and to the agents that read that file. They are for conventions, not for the ruling you made last month about an approach the project rejected.
Shared memory is a third layer: a durable store outside any single agent that every connected agent can read and write. It carries decisions, conventions, and procedures across sessions, projects, and tools. OpenCode does not ship one; it connects to one over MCP.
Where MCP fits
The Model Context Protocol is the open standard for connecting an AI application to an outside tool or data source. The agent is the client, the tool is the server, and because the protocol is shared, one server works with every client that speaks it.
OpenCode supports both local MCP servers, which run as a process on your machine, and remote ones, which you reach over HTTP. Keynodex Memory is a remote MCP server: one endpoint, https://memory.keynodex.com/mcp, that you add to OpenCode once. When the agent calls a memory tool, the request goes to that endpoint, the server works against your own isolated store, and the result comes back into the session. Sign-in is Google with OAuth in the browser, and there is no API key to create or rotate. For the longer explanation of the protocol itself, we wrote a plain-English guide to MCP servers.
What belongs in a shared project memory
The value of a memory store is decided by what you put in it, and the instinct to save everything produces a pile nobody reads.
The records that earn their place are the ones that stay true next month and are invisible in the repository: the architecture decision and the reason behind it, the convention your team follows that is written down nowhere else, the error that took an afternoon to diagnose and the fix that worked. A memory tied to the file, command, or error it belongs to gets found later by the agent working on exactly that thing.
A small example. Suppose your team decided not to use a particular library after a bad experience, and the decision lives nowhere except in the memory of whoever argued for it. Save one sentence about the decision and one about the reasoning. The next agent that proposes that library finds the note before it wastes your afternoon. That is the whole trick, repeated.
Connect OpenCode when you are ready
Setup is two commands plus a browser sign-in. You add the server, you authenticate with Google, you restart OpenCode, and you verify the connection. Both config shapes are documented, so the guide matches the config file you actually have, and the whole thing takes a few minutes. The step-by-step walkthrough lives in the Memory docs: Connect OpenCode to Keynodex Memory.
If privacy is the question before you connect anything, the honest answers are in the questions post, including what is encrypted, what is not end-to-end encrypted, and how deletion works.
Common questions
Is OpenCode an AI model or a coding agent?
It is a coding agent. The model is the engine you connect to it: Anthropic, OpenAI, Google, a local model, or another provider from the catalog. That separation is why OpenCode can outlast any single model generation, and it is also why the memory you give it should live outside the model.
Does OpenCode already keep conversation history?
It keeps sessions, which you can resume, and it reads project instructions from files like AGENTS.md. What it does not have by default is a durable, curated store that follows you across tools and projects. That is the layer Keynodex Memory adds.
Can OpenCode use memories saved through another AI client?
Yes. The store is per account, not per client. Connect Claude, Claude Code, or another MCP client with the same Google account and they read and write the same memories. The agent still has to make a tool call to use them; the connection loads nothing by itself.
Do I need an API key for Keynodex Memory?
No. Sign-in is Google with OAuth 2.1 and PKCE in the browser, and the tokens stay on your machine. Model provider credentials are separate; those belong to whatever provider you use with OpenCode.