OpenViking
A browsable context database that unifies agent memory, resources, and skills.
Per-dimension scores and reasoning
Evidence shows security policy and dependency list, but least privilege design not explicit. User confirmation exists in interactive init but not comprehensive. Data flow transparency good with retrieval trajectory documentation. Sensitive data handling not detailed. Dependency security has policy but no vulnerability scan evidence. External effects like network requests not clearly restricted. Rollback not mentioned. Source attribution has author info but unverified.
Self-consistency good, docs align with code structure. Dependency availability unverified but many dependencies listed. Failure messages not detailed.
Target audience clear (AI agent developers), scenarios diverse. Capability boundaries described but not detailed. Trigger precision not explicit. Environment fit supports multiple platforms.
Information architecture clear with docs and examples. Install notes detailed. Naming stability not explicit. Examples and FAQ present. Known limitations not explicit. License clear (AGPL-3.0). Versioning changelog not provided. Maintenance responsibility has community and contributing guide.
Output usability good with CLI and API. Marginal value high with unique features. Cost benefit supported by benchmark data.
Claim traceability moderate, benchmark results reported but not independently verified. Cross-source corroboration limited. Fact-inference separation not explicit.
- Publisher identity unverified, proceed with caution.
- Many dependencies, check supply chain security.
- Benchmark results not independently verified.
What does this agent do, and when should you use it?
OpenViking is an open-source context database for AI agents that exposes memories, resources, and skills through a virtual filesystem using the viking:// protocol. On write, it organizes content into L0 abstracts, L1 overviews, and L2 source details for progressive loading. It runs as an openviking-server service and is operated with the ov CLI for resource ingestion, filesystem browsing, semantic search, and text search. Documented integrations include Claude Code, Codex, OpenClaw, Cursor, MCP clients, and LangChain/LangGraph; committed sessions can asynchronously yield long-term memory.
After openviking-server is running, ov add-resource writes URL-based resources into the context store. OpenViking processes stored material into L0, L1, and L2 layers and exposes it under locations such as viking://resources/ and user directories. Agents or operators can browse with ov ls and ov tree, run semantic retrieval with ov find, and search text with ov grep against a URI. Retrieval first identifies a high-scoring directory, then drills down through its layers while preserving the browsing trajectory. When a session commits, the system asynchronously extracts user preferences and agent experience into long-term memory.
- A developer using Codex or Claude Code wants preferences, project resources, and skills recalled across coding sessions.
- An engineering team imports repositories, documentation, and web pages, then navigates their context with viking:// paths and ov find.
- An application using an MCP client needs a retrievable store for resources, memories, and skills.
- A LangChain or LangGraph team wants session-derived long-term memory in a multi-turn agent workflow.
- An agent developer needs to inspect the directory-browsing path that produced an unexpected retrieval result.
What are this agent's strengths and limitations?
- It represents resources, user memories, and skills in one viking:// filesystem, with familiar ls, tree, and find-style operations.
- Its L0/L1/L2 write-time processing supports checking summaries or overviews before loading full source content.
- Recursive directory retrieval retains surrounding context and a trajectory that can be inspected for debugging.
- The documented delivery paths span a self-hosted service, CLI, MCP clients, several agent integrations, and multiple providers.
- It requires Python 3.10+ plus model/provider configuration; provider connectivity is explicitly checked by doctor.
- Newly added resources require semantic processing, so ingestion is not necessarily immediately searchable unless --wait is used.
- The project describes itself as early-stage; the OpenViking Helper is beta and its listed desktop builds are limited to macOS and Windows x64.
- Licensing differs by component: the main project is AGPLv3, while ov_cli and examples are Apache 2.0, requiring component-level license review.
How do you install or deploy this agent?
Requires Python 3.10 or higher and a configured model/provider. Run:
pip install openviking --upgrade
openviking-server init
openviking-server doctor
openviking-serverinit writes ~/.openviking/ov.conf and guides provider setup. The documented options are Volcengine, OpenAI, Codex OAuth, Kimi, GLM, and local Ollama.
How do you use this agent?
With the server running, run:
ov status
ov add-resource https://github.com/volcengine/OpenViking
ov ls viking://resources/
ov tree viking://resources/volcengine -L 2
ov find "what is openviking"
ov grep "openviking" --uri viking://resources/volcengine/OpenViking/docs/enSemantic processing takes time after ingestion; use --wait with add-resource when you need to wait for it.
How does this agent compare with similar options?
The README benchmarks OpenViking against the native memory of OpenClaw, Hermes, and Claude Code. It reports roughly 80–83% LoCoMo accuracy with OpenViking, alongside lower input-token use and query latency; this makes it most relevant when a separate, browsable context layer is preferable to relying only on host-agent memory.