OpenViking stores your agents’ context as a file system you can traverse with ls, tree, and find, rather than as embeddings in a vector database. After installing it in my Claude Code setup, I think the difference that matters isn’t which one retrieves better, but which one you can audit when something goes wrong.
OpenViking is an open-source context database for AI agents, maintained by Volcengine, ByteDance’s cloud arm. At the time of publishing this note it has 35,500 stars and 2,700 forks on GitHub, and the latest version is v0.4.10, released on July 16, 2026.
What is a context database and how does it differ from a vector one?
A vector database takes your context, converts it to embeddings, and returns you the nearest neighbors to a query. It works. It’s also opaque: you can’t inspect why one fragment showed up and not another, and you can’t traverse the store to see what it contains.
A context database inverts that relationship. OpenViking organizes memories, resources, and skills under a viking:// scheme, in directories. The agent traverses them with the same verbs it already uses on real files: ls, tree, find. Retrieval stops being a similarity score you have to accept and becomes a path you can read.
On top of that goes tiered loading, which is the part that seems really clever to me:
- L0 — abstract, around 100 tokens. Enough to decide if this branch is relevant.
- L1 — overview, around 2,000 tokens. Enough to plan.
- L2 — detail, the full original content, loaded only when the agent commits.
Directories have their own L0 and L1 layers before you get to a file. An agent can thus traverse a large context store while reading almost nothing from it, which is what it’s all about when your context window is the scarcest resource you have.
What exactly does it do inside Claude Code?
Here the design stops being theoretical. The plugin registers seven lifecycle hooks:
| Hook | What it does |
|---|---|
UserPromptSubmit |
Searches OpenViking and injects relevant context |
Stop |
Captures the new turn when Claude finishes responding |
SessionStart |
Brings file summaries back when resuming a session |
PreCompact |
Confirms pending data before the transcript is rewritten |
SessionEnd |
Final commit when closing the session |
SubagentStart / SubagentStop |
Maintains isolated memory for subagents |
The plugin’s README puts it bluntly: “Recall happens automatically before every prompt, capture happens automatically after every turn — no MCP tool calls required from the model.”
That sentence is why this deserves your attention. Most memory integrations expose tools and rely on the model remembering to call them. This moves memory into the harness lifecycle, where it happens whether the model thinks about it or not. The PreCompact hook is the detail that gives away someone who was paying attention: it confirms data just before Claude Code rewrites the transcript, which is exactly when naive integrations lose information.
MCP tools (search, read, store, forget) remain available at the /mcp endpoint of the server for when you want to get hands-on.
How do you install it?
First you need an OpenViking server running: all integrations connect to one, and the documentation describes only self-hosting. At the time of publishing this note there is no documented managed option.
pip install openviking --upgrade
openviking-server init
openviking-server doctor
openviking-server
Python 3.10 or higher. init guides you through choosing an embeddings and vision provider: Volcengine, OpenAI, Ollama, Kimi, GLM, or Codex OAuth. doctor is the step whose output is actually worth reading — that’s where a misconfigured provider shows up before it becomes a confusing failure down the line. The server listens on http://localhost:1933 by default; using it remotely requires an API key.
Next, the Claude Code plugin. There’s a one-liner installer, but I’d go through the marketplace: it’s explicit, and I found two different installer URLs between the documentation and the examples directory, a coin I’d rather not flip on someone else’s machine.
claude plugin marketplace add https://raw.githubusercontent.com/volcengine/OpenViking/main/.claude-plugin/marketplace.json
claude plugin install openviking-memory@openviking
Connection details go in ~/.openviking/ovcli.conf (url, api_key, and optionally account and user). Configuration resolves by priority: environment variables, then ovcli.conf, then ov.conf, then defaults. The variables worth knowing are OPENVIKING_URL, OPENVIKING_API_KEY, OPENVIKING_RECALL_LIMIT, and OPENVIKING_AUTO_CAPTURE.
To verify, inside Claude Code:
/pluginslistsopenviking-memoryas installed, with theopenvikingMCP connected/mcpshows the server URL with valid authentication/openviking-memory:ovprints the server status and statistics
If activation fails, set OPENVIKING_DEBUG=1 and check ~/.openviking/logs/cc-hooks.log.
If you’re building Claude Code from scratch, our terminal setup guide covers the ground this takes for granted.
Do the numbers hold up?
They’re self-reported, and were measured on v0.3.22 — a version earlier than what you’d install today. Read them as the project’s own account of its design working, not as independent validation.
On LoCoMo, a memory benchmark for long conversations, the project reports precision rising to 80–83% across three agent integrations, from a baseline of 24–57%, with input tokens dropping between 34.3% and 91.0% and query latency between 58.45% and 66.10%. On tau2-bench, task success improves 6.87 percentage points on the retail split and 11.87 on the airlines split.
The token reduction is the number I’d want to reproduce before believing it, because it’s what would justify the operational cost of keeping another server running. A floor of 34% is plausible just from tiered loading. A ceiling of 91% is doing a lot of work within that range.
Where does it fit in your stack?
Today there are more than fifteen integrations, and the list is the real signal: Claude Code, Codex, OpenCode, Cursor, TRAE, DeepSeek Harness, OpenClaw, Hermes, LangChain, and LangGraph. If you already run OpenClaw or Hermes, this is a memory layer that talks to both, instead of a patch per agent.
That breadth is also the strategic point. OpenViking isn’t trying to be a better vector database: it’s trying to be where your agents’ context lives, whatever harness you’re using this quarter. It’s a more ambitious position than it looks at first glance, and it’s the reason to evaluate it now and not after it becomes the default in three of the tools you use.
If you’ve been following the topic, we’ve already covered two different approaches to the same problem: claude-mem and AgentMemory. OpenViking differs from both in that it’s not a memory plugin for Claude Code: it’s a context store with a Claude Code plugin on top.Two warnings before trusting it with something important. It’s pre-1.0, at v0.4.10 with 90 open issues at the time of writing, so treat the storage format as something that can still shift beneath you. And the core is under AGPLv3 — the CLI (crates/ov_cli) and examples are Apache 2.0 — something worth looking into if you handle licenses at your company and plan to modify and expose it over the network.
Is It Worth Installing Today?
If you use Claude Code every day and you’re tired of re-explaining your codebase in each session, yes: the ten minutes are worth it, and the hooks mean you won’t have to remember it’s there. If you’re looking for a memory layer for a system in production that matters, evaluate it now and adopt it after 1.0.
What I wouldn’t do is ship it as just another RAG wrapper. The filesystem paradigm is a real bet on how agents should navigate context, and it’s being made by a team with the resources to back it.