Magic Context: persistent agent memory for OpenCode, Pi and OMP
Unbounded context. Memory that manages itself. One session, for life. The hippocampus for coding agents, part of CortexKit.
At a glance
- What is it?
- Magic Context is a TypeScript plugin that captures durable knowledge from a coding session, consolidates it in the background, and recalls it on later turns. The idea is sound and the install path is documented, but the required historian model configuration is where an unattended setup will break.
- Who is it for?
- Adopt Magic Context if you run long-lived sessions on OpenCode, Pi or OMP and you are willing to pick and pay for a historian model, because the plugin will not summarise older history without a real provider/model-id in historian.opencode.model. Do not adopt it if you want a drop-in memory layer with no model dependency, or if you cannot disable the host's built-in compaction, since the README states the two will double-compress.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Magic Context is aimed at: agents that start every task from zero
The README frames the target problem with an analogy rather than a benchmark: you do not hire a developer to fix one bug and fire them when it ships, but coding agents work that way. Each task begins with no memory of the project, and each session ends by discarding whatever the agent learned. The README also points at compaction pauses, which it describes as breaking the flow and quietly dropping what the agent knew. The stated goal is one session per project, kept alive for weeks, months or years. That is a specific claim about session lifetime, not about context window size. The intended audience is people running OpenCode, Pi or OMP who already treat an agent as a long-running collaborator and who are tired of re-explaining conventions, constraints and past decisions. If your work is a sequence of unrelated one-shot prompts, the memory layer has little to store and the setup cost is not repaid.
Three stages: capture, consolidate, recall
The README describes the mechanism as three named stages. Capture happens while a component it calls the historian compresses your history; during that compression it lifts durable knowledge such as decisions, constraints and conventions into project memory. The README's phrasing is that you get a memory system for free, from work you are already doing. Consolidate runs overnight, using agents the project calls dreamers, which the README says verify memories against the codebase, curate duplicates and stale entries, and promote what recurs. The comparison drawn is to sleep. Recall surfaces memories automatically every turn, and the README states the agent can also search across memories, past conversations and git history on demand. Two components are named beyond the historian: the dreamer and the sidekick, the latter tied to a command written as /ctx-aug. The README lists dreamer and sidekick as optional blocks in configuration, and says omitting them leaves periodic consolidation and /ctx-aug off. So the only stage that is mandatory is capture, and capture depends entirely on the historian model being configured.
Installing: the wizard, the manual opencode.jsonc edit, and the model key that must be real
The README gives three install paths. On macOS and Linux it pipes scripts/install.sh from the master branch into bash. On Windows PowerShell it does the equivalent with scripts/install.ps1. The third is npx @cortexkit/magic-context@latest setup, which the README says works on any OS. The wizard auto-detects which harnesses are present, adds the plugin, disables built-in compaction, helps pick models for historian, dreamer and sidekick, and resolves conflicts with other context-management plugins. It can be pointed at one target with --harness opencode, --harness pi or --harness omp. Manual setup for OpenCode means adding the plugin to opencode.jsonc and setting compaction.auto and compaction.prune to false. The README explains why: Magic Context manages context itself, and the host's compaction would interfere with its cache-aware deferred operations and double-compress. Then magic-context.jsonc needs historian.opencode.model set to a real provider/model-id. The README is blunt that without it the plugin still loads but historian runs fail, older history is not summarized, and repeated failures surface a notice reading Magic Context, history comparting needs attention. Note the typo in that notice string as the README prints it. The README also warns that a bare plugin entry gets pinned to the downloaded exact version before restart, so OpenCode does not remove the active package mid-session, and that you must write @latest explicitly if you want it unpinned.
Where it will bite you: silent failure, host coupling, and a model you must supply
The most concrete failure mode is documented by the project itself. A missing or invalid historian.opencode.model does not stop the plugin from loading. It fails at run time, and the visible symptom is that older history is simply not summarized until the attention notice appears. That is a quiet degradation: the agent keeps answering, the memory layer keeps looking present, and the capture stage is not doing its job. If you install via the wizard and it mis-detects your provider, you may not notice for a while. The second constraint is coupling to the host. The README requires disabling built-in compaction, which means Magic Context is not additive to whatever compaction your harness already does. It replaces it. If your harness or another plugin insists on managing compaction, you have a conflict the wizard is only described as resolving, not guaranteed to resolve. Third, the system is not self-contained: it needs a model for the historian and optionally for the dreamer and sidekick. That is a recurring cost and a dependency on a provider being reachable. The README does not state what happens to consolidation if the dreamer model is unreachable overnight, and I cannot confirm that from the material. Treat the overnight consolidation as best-effort until you observe it.
How this differs from a plain vector store or a hand-rolled memory file
The obvious alternative is the pattern most teams already have: a markdown file or a notes directory the agent reads at the start of a session, plus an embedding index over past transcripts. That approach is fully under your control, has no model dependency, and costs nothing beyond storage. Its weakness is that nothing curates it. Entries go stale, duplicates accumulate, and there is no step that checks a remembered constraint against the current codebase. Magic Context's distinguishing move is the consolidation pass, where dreamer agents are described as verifying memories against the codebase and promoting what recurs. A static file has no equivalent. The trade is that you hand the curation to a model-driven process you do not directly inspect, and you accept a historian model in the loop for capture. A second alternative is simply keeping one very long session and never compacting. That avoids the summarization problem entirely but runs into the context window, which is the constraint Magic Context exists to work around. The README's own framing, one session for life, is only achievable because something is compressing history on your behalf.
Maintenance, releases and the MIT licence
The repository is not archived and the last push recorded is 2026-09-10. Recent releases listed are v0.41.4 on 2026-09-06, dashboard-v0.15.0 on 2026-09-05, and v0.41.3 on 2026-09-04. The version numbering is worth reading carefully: the core package is in the 0.41 range, which signals that the API and configuration surface can still move, and the dashboard ships on its own version line. That means upgrades are a real maintenance item rather than a background concern. The README's note about plugin pinning matters here: a bare plugin entry is pinned to the downloaded exact version before restart, so a restart does not silently swap the package mid-session, and you opt into floating versions by writing @latest explicitly. If you want reproducibility, leave the pin alone. The project is MIT licensed, which permits commercial use and modification, but the licence covers the code in this repository; it does not cover the model providers the historian and dreamer call, and those have their own terms and their own costs. That is a factual boundary, not legal advice. The README is translated into a long list of languages, which suggests an active documentation effort, but translation breadth says nothing about whether the consolidation pass behaves well on your codebase.
Editorial conclusion
Adopt Magic Context if you run long-lived sessions on OpenCode, Pi or OMP and you are willing to pick and pay for a historian model, because the plugin will not summarise older history without a real provider/model-id in historian.opencode.model. Do not adopt it if you want a drop-in memory layer with no model dependency, or if you cannot disable the host's built-in compaction, since the README states the two will double-compress. Before you commit, verify three things: that the wizard actually wrote a valid model id into magic-context.jsonc, that compaction.auto and compaction.prune are both false in opencode.jsonc, and that the historian runs succeed on your first long session rather than surfacing the history comparting needs attention notice.
Community notes