Magic Context: self-managing memory for OpenCode, Pi and OMP agents

The problem Magic Context targets: amnesia between agent sessions

A coding agent that starts every task with an empty context window behaves like a contractor hired for one bug and dismissed the moment it ships. The README makes this comparison directly and then names the failure mode it is built around: agents forget decisions, constraints and conventions that were established earlier in the same project, and mid-task they hit compaction pauses that interrupt work and drop information.

The intended user is someone running a persistent session per project rather than a fresh one per task. The README's phrasing is "one session, for life", and the repository topics include agent-memory, context-engineering and context-management, so the audience is people already working inside agent harnesses and feeling the cost of context loss. It is not a general-purpose vector database, and it is not a library you call from your own application code. It is a plugin that sits inside OpenCode, Pi or OMP and changes how those harnesses handle history.

Capture, consolidate, recall: the three-stage memory loop

The README describes three stages. Capture happens as a component it calls the historian compresses your history; durable knowledge such as decisions, constraints and conventions is lifted into project memory. Consolidate is periodic and runs "overnight", with dreamer agents verifying memories against the codebase, curating duplicates and stale entries, and promoting what recurs. Recall surfaces memories automatically each turn, and the agent can search across memories, past conversations and git history on demand.

The repository layout backs up the claim that this is not a thin wrapper. There is a Rust workspace under crates/ with members mc-core, mc-store, mc-module and mc-tokenizer, and the Cargo.toml comment describes it as "the harness-agnostic MC module (CK-in / CK-out) that runs under the subc daemon". That comment also states the Rust crates are path-dependencies on sibling repositories (commons/ and subconscious/) that are "not yet published". So the storage and tokenizer work lives in Rust, while the harness integration is distributed as TypeScript packages: @cortexkit/magic-context for the CLI, @cortexkit/opencode-magic-context for OpenCode, and @cortexkit/pi-magic-context for Pi.

One design decision is worth flagging as a trade-off rather than a feature. The README says the host's built-in compaction would "interfere with its cache-aware deferred operations and double-compress", which is why the setup wizard disables it. That means Magic Context is not additive to your existing context handling; it replaces it. If the plugin fails, you have removed the harness's own fallback.

Installing Magic Context and running the setup wizard

The README gives three installation paths. On macOS and Linux there is a shell installer; on Windows a PowerShell equivalent; and on any OS you can invoke the CLI directly through npx. The wizard is interactive: according to the README it detects your models, configures everything, adds the plugin, disables built-in compaction, helps you pick models for the historian, dreamer and sidekick, and resolves conflicts with other context-management plugins.

npx @cortexkit/magic-context@latest setup

You can target a single harness instead of letting detection decide. The README documents --harness opencode, --harness pi and --harness omp. If you cannot run the wizard at all, the manual OpenCode path is to edit opencode.jsonc so the plugin is loaded and built-in compaction is switched off:

{
  "plugin": ["@cortexkit/opencode-magic-context@latest"],
  "compaction": { "auto": false, "prune": false }
}

The README notes that a bare plugin entry gets pinned to the downloaded exact version before restart, so OpenCode does not remove the active package mid-session; writing @latest explicitly keeps it unpinned. Then create magic-context.jsonc with a historian model. The README lists historian.opencode.model as required and warns that without a real provider/model-id 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".

{
  "$schema": "https://raw.githubusercontent.com/cortexkit/magic-context/master/assets/magic-context.schema.json",
  "historian": {
    "opencode": { "model": "provider/model-id" }
  }
}

Dreamer and sidekick blocks are optional; omit them and periodic consolidation and /ctx-aug stay off. The README does not document what a successful first run looks like beyond the absence of that failure notice.

Where Magic Context is the wrong tool

The clearest limitation is the required model configuration. There is no default historian model that works out of the box; the README's placeholder is literally provider/model-id, and the failure mode is quiet. The plugin loads, so nothing looks broken, but summarization never happens and you only learn about it from a notice after repeated failures. If you cannot point the historian at a model you are willing to spend tokens on, the memory layer does not function.

The second limitation is that the project is mid-restructure. The Cargo.toml states the CortexKit cache-stability and storage crates are sibling path-dependencies that are "not yet published", with a note to "pin a published version at first release". Building the Rust side from this repository therefore assumes the sibling directories exist on disk. The repository also carries pnpm-lock.yaml and bun.lock side by side, and package.json declares [email protected] as the package manager with a bun >=1.4.0 engine constraint, so the JavaScript toolchain is bun-first rather than npm-first despite the npx entry point.

Third, the README is silent on rollback. There is no documented uninstall command, no procedure for re-enabling built-in compaction, and no statement about what happens to accumulated memories if you remove the plugin. For a component that deliberately disables a host safety mechanism, that omission matters more than it would elsewhere.

How it compares to Mem0 and to harness-native context handling

Mem0 appears in the search phrases people use around this project, and the difference in approach is structural. Mem0 is a memory service you integrate into an application: your code decides when to add memories and when to query them. Magic Context is the inverse. It installs as a plugin inside the agent harness, hooks the historian into the compression path, and surfaces memories automatically every turn. You do not write the capture or recall calls; the harness does, on your behalf. That is convenient when your workflow is already OpenCode, Pi or OMP, and useless when it is not, because the integration is the product.

The comparison against harness-native handling is sharper. OpenCode's own compaction summarises and prunes within a session; Magic Context disables that and substitutes its own deferred operations, which the README describes as cache-aware. The promised benefit is that your agent never stops to manage context and never forgets. The cost is a single point of failure in the context path, plus a dependency on the historian model being reachable. If you want the smallest possible change to a working agent setup, native compaction is the lower-risk choice.

Maintenance, releases and what the MIT licence means here

The repository is not archived, and the last push was on 2026-09-10. Releases are frequent: v0.41.4 on 2026-09-06, v0.41.3 on 2026-09-04, and a dashboard release, dashboard-v0.15.0, on 2026-09-05. The dashboard is versioned separately from the plugin, so two release streams need tracking if you use both.

Upgrade cost is concentrated in the plugin entry. The README explains that a bare plugin entry is pinned to the downloaded exact version before restart to prevent OpenCode from removing the active package mid-session, and that you must write @latest explicitly to keep it unpinned. That is a small but real operational detail: an unpinned plugin means the version can change between restarts, and Magic Context ships patch releases days apart.

The licence is MIT, stated in the README badge and present as a LICENSE file at the repository root. MIT permits commercial use and modification with the copyright notice retained. This is not legal advice; if you redistribute the plugin inside a product, read the LICENSE file and the licences of the sibling CortexKit crates it depends on, since the Cargo.toml comment says those are separate repositories.

Editorial conclusion

Adopt Magic Context if you run long-lived OpenCode, Pi or OMP sessions on a single project and want history kept as durable memory instead of discarded at compaction. Do not adopt it if you cannot supply a valid provider/model-id for the historian, or if you need documented rollback and uninstall steps before touching a working setup. Verify two things first: that historian.opencode.model resolves in your configuration, and that disabling built-in compaction in opencode.jsonc is acceptable for your harness.

Frequently asked questions

Official sources

1. cortexkit/magic-context on GitHub
2. License: MIT
3. Project website
4. README
5. Releases