OpenViking
github.com/volcengine/openviking- Category
- AI Agents
- Rank
- No. 1977Tools index
Previous survey · No. 1986 ·
- Type
- APP
- Use case
- Data, Retrieval & Knowledge · Agent Building
- GitHub
- 39.2k stars
- Latest release
- sdk/go/v0.0.4
- Date
About
Open-source context database for AI agents that stores memories, resources, and skills as one virtual filesystem under a viking:// protocol. Agents browse their own context with ls, tree, and find instead of querying a vector store, with content tiered into abstract, overview, and detail layers loaded on demand.
What it does
OpenViking is a self-hosted server that gives AI coding and chat agents one browsable store for what they know: imported documents and code, memories pulled out of past conversations, and reusable task instructions. Everything sits at folder-like addresses, so an agent, or you, can list, read, grep and edit it the way you would a directory. On import, a language model writes a one-line abstract and a longer overview for each processed folder, and search can be limited to a single subtree. Finished sessions are archived and their extracted memories saved as editable Markdown. The server is Python; the command-line client is Rust.
Why it's ranked here
Memory an operator can open and correct is the selling point, and the code has the structure to back it. The server wires more than twenty route groups, covering the file tree, search, sessions, skills, access control and a WebDAV mount, over a Rust file layer with pluggable storage backends. It ships Python, Go and TypeScript SDKs plus hook and MCP integrations for Claude Code, Codex, Cursor and others. The README reports memory accuracy of 80 to 83% for three agents, up from 24 to 57% natively, but those runs are the project's own and used its parent company's Doubao models.
What's good
The tiered summaries are the practical idea: an agent reads a one-sentence abstract, then an overview, and opens full content only when it needs to. The README reports 34 to 91% fewer input tokens in its own memory runs. Scoped search means a query about one project does not trawl every memory. Stored memories are plain Markdown you can inspect, edit and merge rather than opaque vectors. Setup has a built-in doctor command that checks provider configuration and connectivity, and the model layer accepts Volcengine, OpenAI, Kimi, GLM or a local Ollama. The parsing stack pins its code-grammar versions exactly to avoid upstream breakage.
Tradeoffs
The license is AGPL-3.0, whose network clause matters if you plan to offer it inside a hosted product. The package declares itself Alpha. Nothing works without both an embedding model and a vision-language model configured, and summarising on import costs model calls. The install is heavy: over fifty runtime dependencies, including a web crawler, a model-routing library, the OpenTelemetry stack and a dozen pinned code parsers, and the optional bot extra adds SDKs for Telegram, Slack, DingTalk, QQ and more. The headline benchmark numbers come from the vendor, on its own models, so treat them as a claim to reproduce.
How to use it well
Fit: teams running Claude Code, Codex, Cursor or OpenCode who want memory that persists across sessions and that a human can audit. Try the hosted Studio demo first, then install with pip, run the init and doctor steps, import one repository and scope searches to its folder before pointing a whole agent fleet at it. Rerun the bundled benchmark scripts with your own models before trusting the accuracy figures. Look elsewhere for a lightweight in-process vector lookup with no model budget, or if AGPL terms conflict with how you ship.
Technical notes+
pyproject.toml names the package openviking (license AGPL-3.0, classifier Development Status 3 Alpha, Python 3.10 to 3.14) and maps the ov and openviking scripts to a thin Rust CLI wrapper, with openviking-server pointing at a separate bootstrap. Cargo.toml is a workspace of three crates: ov_cli, ragfs and ragfs-python. crates/ragfs/src/lib.rs describes RAGFS as a Rust implementation of AGFS, a mount table where plugin filesystems (MemFS, KVFS, QueueFS) register through PluginRegistry and are consumed in-process via the Python binding. openviking/server/app.py builds a FastAPI app with 26 routers (filesystem, search, sessions, skills, acl, webdav, compile and others) and three built-in auth plugins, dev, api_key and trusted, failing startup on an unknown auth mode. openviking/retrieve/__init__.py exports HierarchicalRetriever and IntentAnalyzer. openviking/session/__init__.py always returns SessionCompressorV3 and logs that the memory version setting is deprecated and ignored. openviking/__init__.py lazily exposes sync and async HTTP clients only. docs/en/index.md is a frontmatter stub rendering a single component.
Observed
- License
- AGPL-3.0
- Declared maturity
- Development Status :: 3 - Alpha (package classifier)
- Languages
- Python server and library; Rust workspace for the CLI and filesystem layer
- Python support
- Requires 3.10 or newer; classifiers list 3.10 through 3.14
- Install
- pip install openviking; ships ov, openviking, openviking-server and vikingbot commands
- Interfaces
- CLI, HTTP API (FastAPI), Python/Go/TypeScript SDKs, MCP, WebDAV route
- Model requirements
- An embedding model and a VLM; providers include Volcengine, OpenAI, Kimi, GLM, local Ollama
- Server auth modes
- dev, api_key, trusted
- Tests
- pytest configured with a tests directory and coverage reporting in pyproject
Read from README.md, pyproject.toml, Cargo.toml, docs/en/index.md, openviking/__init__.py, openviking/server/app.py, openviking/retrieve/__init__.py, openviking/session/__init__.py, crates/ragfs/src/lib.rs.
Tags
Tech Stack
Comments (0)
No comments yet
Editorially curated, with community endorsements as a secondary signal. Corrections welcome.