Documentation menu / searchSearch documentation →

Start here

Quick startConnect through MCPOpenCode native memoryOpenCode memory controllerMemory API & local models

Use the service

Memory & compactionMemory lifecycle controllerLocal agents & swarmsCLI referenceHTTP reference

Run a node

ConfigurationOperations & backupsLocal memory & ARM

Evidence

Performance & device targetsFull retrieval reportBenchmark methodologyEvaluation policyMemory benchmark notes

Build with us

Architecture & schemaTechnology & learning mapRepository maintenanceContributingSecurityWebsite & deploymentSearch & agent discoveryPrivate product measurementEngineering references

Project

Cleanup & release planRoadmapLocal AI memory: when instantKV fitsFeaturesChangelog

History

Verification history

Proposals

Distributed memory proposal

Project / single-node · source MVP

Roadmap

Source MVP status, local-model evaluation, phone integration and optional retrieval plans.

The source MVP is implemented and unreleased. The next milestone is a usable release with proven local-agent task continuation. The cleanup and release plan defines the work order and acceptance gates.

Current source

  • Structured remember, recall, search, browse and forget.
  • Topic/tag/time indexes and bounded BM25 search with English stemming.
  • Atomic record/index changes, revision conditions, quotas and expiry.
  • Atomic checkpoint/latest-pointer commits and bounded restore.
  • Embedded Rust core, authenticated HTTP, CLI and scoped MCP tools.
  • Local profile, shared/private namespace setup, backup and restart tests.
  • Optional source-only Python controller for reviewed proposals, corrections, conflicts, provenance, live profiles and content-free forgetting.

Memory contract · Checkpoint contract · Verification history

Next milestones

OrderWorkAcceptance
1Clear onboarding and harness setupOne working source path; Codex, Claude Code and OpenCode setup examples; generated site and links pass
2Real local-agent continuationActual model saves, resets, restores and continues; complete traces and failure cases
3Storage and upgrade hardeningDisk-full/commit faults, single-writer diagnostics, binary compatibility and restore drills
4Memory MVP releaseMatching tested binaries, checksums, fresh-install and upgrade tests on named platforms
5Retrieval improvementsHeld-out task gains after the frozen campaign, with measured resource costs

For each supported harness, the release check must start from a clean config, connect MCP, save one fact, stop, restart and recall that fact. Run the shared server case with two concurrent adapters. Keep commands and expected results in Connect an agent and failure steps in Operating one node.

Retired-session cleanup, migration tools and observability need separate implementation work. Native phone support and physical ARM-board measurements remain pending. Performance and device targets. Use the private measurement guide to track release downloads and recent GitHub traffic. Actual source installations and active local users remain unknown without an explicit opt-in signal.

Evaluation status

The committed 4 October reports contain full LongMemEval-S and LoCoMo retrieval. Full native LongMemEval-S QA scored 85.20% (426/500) using GPT-6 Luna as reader and judge. This is a model variant, not official leaderboard parity. Competitor QA remains incomplete. LongMemEval-V2, AMA-Bench, BEAM and 100K–10M+ record tests remain incomplete in the published evidence.

Keep the engine frozen during the finite campaign. Preserve failed and interrupted runs. Real local-agent tests and storage smoke experiments do not substitute for full suites. Full results · Evaluation policy.

Memory product tasks

The controller follows this implementation contract. It adds an optional local integration while keeping the Rust engine frozen. M1-M4 are implemented in source. Validation records the combined real-node workflow and limits. Use the controller. The OpenCode integration also passed a six-session model trial.

IDTaskCompletion checkDependency
M1Completed: deterministic lifecycle and HTTP adapterFive focused lifecycle/HTTP scenarios and combined real-node restart workflow passCurrent API
M2Completed in source: optional extraction and interactive agentSix fake-model/transport/harness scenarios pass; installed-model quality remains M5M1 interface
M3Completed: CLI and operator guideSaved-preview retry, inspection, correction, profile/context, permissions and forgetting pass through the real CLIM1 interface, M2 extraction
M4Completed: integration and product reviewCombined workflow, repository checks and site checks pass; changes committedM1-M3
M5Completed: connected-model product trialSix fresh OpenCode sessions save, recall, correct and forget one synthetic preference; traces, presentation friction and cost recordedM4 and a connected provider
M6Partly complete: normal agent integration; long-term use pendingOpenCode lifecycle adapter installed and connected; safe archival/compaction, explicit restoration after forget and sustained use beyond per-slot limits remain openM5 feedback
M7Broader memory qualityEvaluate temporal facts, ambiguous entities and paraphrases on separate development cases before proposing semantic retrieval or graph reasoningM5-M6

M1-M5 cover implementation and one small product trial. M6-M7 remain broader product gates. Model calls stay in the optional agent runtime; storage and lifecycle validation remain model-free.

Later proposals

Portable export/import comes before multi-device synchronization. Phone bindings need lifecycle, sandbox, backup and energy tests on named devices. Optional embeddings must earn their model, index and runtime costs. Distributed consolidation and managed hosting remain proposals without a delivery date.