OpenViking

An open-source project from Volcano Engine, ByteDance (volcengine/OpenViking).

Why it matters

Claude Code forgets the conversation when the session ends. Project docs and team rules get pasted in again every time, and the coding conventions you settled on last week have to be explained from scratch. The docs name the underlying problem directly: “Context Fragmentation: Memory in code, resources in vector databases, skills scattered everywhere — difficult to manage uniformly.”

OpenViking puts all three behind one virtual filesystem under viking://. Rather than querying a store that only returns matches, the agent walks its own context with ls, tree, and find, and every retrieval leaves a trajectory you can watch and debug.

What you can do

Representative tasks from the docs and the README:

• Ingest a repo or a page as a resource — ov add-resource https://github.com/volcengine/OpenViking pulls a GitHub repo or web page in for semantic processing
• Browse resources like files — ov ls and ov tree walk directories, ov find "what is openviking" asks in natural language, and ov grep scopes a search to one URI
• Turn sessions into memory — “After a session commits, OpenViking asynchronously extracts user preferences and agent experience into long-term memory,” landing under paths like viking://user/{user_id}/memories/preferences/coding_habits
• Share one memory across agents — Claude Code, Codex, Cursor, OpenCode, and TRAE pointed at the same server work from the same context
• See why a result came back — “Each query preserves its directory-browsing trajectory. When a result looks wrong, you can see exactly which path produced it.”

Grounded in docs.openviking.ai and the volcengine/OpenViking README.

Key features

• The viking:// filesystem

  “Memories, resources, and skills each get a viking:// URI. Agents locate and manipulate context deterministically, like a developer working with files.” Paths such as viking://resources/my_project/docs/api make it visible where a piece of context lives.

• Tiered L0 / L1 / L2 loading

  Every entry is processed on write into L0 (abstract, ~256 characters for vector search and filtering), L1 (overview, ~4,000 characters for reranking and navigation), and L2 (the full original data), then “loaded only as deep as the task requires.”

• Directory recursive retrieval

  “Vector search first locates the highest-scoring directory, then drills down layer by layer, so results arrive with their surrounding context intact.”

• The Claude Code plugin

  openviking-memory hooks four points: it searches OpenViking and injects relevant memories before every prompt, captures new conversation turns after each response, injects the profile and memory index on session start, and commits pending messages before compaction and on session end. Each subagent is assigned an isolated memory session.

• Auto-recall and auto-capture toggles

  OPENVIKING_AUTO_RECALL and OPENVIKING_AUTO_CAPTURE are enabled by default, and OPENVIKING_BYPASS_SESSION_PATTERNS turns the plugin off for selected sessions. /openviking-memory:ov shows server health, identity, recall and injection counts, and toggle states.

• Provider choice

  openviking-server init “supports Volcengine, OpenAI, Codex OAuth, Kimi, GLM, and local Ollama — for Ollama it can detect and install the runtime and pull models suited to your hardware.”

Setup

Install and configure the server first. Requires Python 3.10 or higher.

pip install openviking --upgrade
openviking-server init      # interactive wizard: providers, models, ov.conf
openviking-server doctor    # validate setup
openviking-server           # start

The Claude Code plugin has a one-line installer:

bash <(curl -fsSL https://raw.githubusercontent.com/volcengine/OpenViking/main/examples/memory-plugin-shared/install.sh)

Or add the marketplace yourself. The marketplace path needs Claude Code 2.0+; older versions fall back to hooks.

claude plugin marketplace add https://raw.githubusercontent.com/volcengine/OpenViking/main/.claude-plugin/marketplace.json
claude plugin install openviking-memory@openviking

Connection settings go in ~/.openviking/ovcli.conf as url and api_key; with no config file the plugin defaults to http://127.0.0.1:1933. In Claude Code, /plugins should list openviking-memory and /mcp should show the OpenViking entry.

Working with resources from the terminal:

ov status
ov add-resource https://github.com/volcengine/OpenViking --wait
ov tree viking://resources/volcengine -L 2
ov find "what is openviking"
ov grep "openviking" --uri viking://resources/volcengine/OpenViking/docs/en

To see it before installing anything, OpenViking Studio is a hosted playground that runs in the browser.

Notes

• Setup is not trivial — the plugin alone does nothing. Python 3.10+, a server process kept running, and an LLM plus embedding provider all come first
• OpenViking Helper (Beta) — a desktop console for macOS and Windows x64 that “detects OpenViking CLI, Claude Code, Codex, Cursor, Trae, and OpenCode, then configures supported plugin, MCP, Hook, and CLI integrations,” and parses sessions to show recall, prompt injection, capture, and commit events
• Read the benchmarks with their setup — on LoCoMo, Claude Code goes from 57.21% on its native memory to 80.32% with OpenViking, but that memory evaluation used Doubao 2.0 Pro as the VLM and Doubao-embedding-vision-251215 as the embedding model, so other combinations are not covered by those numbers
• Where data leaves the machine — the server is yours, but summarizing and embedding ingested content goes through the provider you configured. Choose a local provider such as Ollama to keep it in
• Commercial editions are separate — Managed SaaS on Volcano Engine and a self-managed edition exist, but “The open-source edition is not crippled… no feature gates, no account required, no activation key”
• License — AGPL-3.0. The repo “open-sources a subset of the core capabilities described in the VikingMem paper” (arXiv:2605.29640, accepted by VLDB 2026)