Acontext vs OpenViking
Skill memory layer for agents: auto-captures learnings from runs into plain Markdown skill files you can read, edit, git and share across frameworks — memory without an opaque store. — versus — Volcengine's context database: memories, resources and skills as one `viking://` filesystem agents ls, tree and grep — L0/L1/L2 tiers, traceable retrieval, sessions distilled into memory.
Shared premise — agent memory should be inspectable artifacts, not an opaque store. acontext keeps it as plain Markdown skill files in git; OpenViking runs a server with semantic tiering and vector-guided directory retrieval. acontext for git-native simplicity, OpenViking for scale and traceable recall.
| Acontext | OpenViking | |
|---|---|---|
| Stars | 3.7k | 32k |
| Forks | 334 | 2.4k |
| Language | JavaScript | Python |
| License | Apache-2.0 | AGPL-3.0 |
| Last activity | 1 months ago | yesterday |
| Topics | memory, skills | memory, rag, skills |
| Curated connections | 8 | 5 |
Acontext — the curator's take
The "memory should be legible" bet: instead of embeddings in a vector store, learnings from agent runs become Markdown skill files you can read, diff, git and mount into any framework — debuggable memory users can inspect and correct, the exact thing opaque memory layers get wrong. It can also adopt and evolve skills you wrote or downloaded. Trade-off: no semantic recall over thousands of entries; it lives or dies on distilling runs into a curated, manageable skill set. Want scale-out retrieval memory instead? That's memmachine or hindsight territory.
OpenViking — the curator's take
Use it when opaque vector recall has burned you: every query keeps the directory-browsing trajectory that produced it, so a wrong answer is debuggable, and the L0/L1/L2 tiers let an agent judge relevance before paying for full content. It pays off most for long-lived agents with heavy reference material — repos, docs, per-user preferences — and there are documented hooks for Claude Code, Codex, Cursor, OpenCode, LangChain/LangGraph and plain MCP clients. Costs: it's a server plus semantic pre-processing on every write, so ingest is slow and not free; AGPLv3 rules it out of many closed products; and there's an obvious managed-SaaS path on Volcano Engine behind it. Wrong tool if you just want an in-process vector index.