Should You Use OpenViking? A Three-Minute Test for Agent Wranglers

No quiz needed. The AI looks at your project first (read-only, if it can see one), then asks you questions one at a time, and ends with a fit score and an edition verdict.

Help me decide whether I (or the project in front of you) should adopt OpenViking, and which way to run it. Judge independently from the facts; if I don't need it, say so.

Step 1: if you can read the current project, start with a read-only pass. Do not install anything or modify any file; for configuration, look only at environment variable names and never print a secret's value.
- Agent instruction files: AGENTS.md, CLAUDE.md, .cursor/rules and similar. Note their length and, if git log is available, how often they change.
- Home-grown memory or retrieval: vector stores (chromadb, faiss, pgvector, qdrant, milvus…), embedding calls, LangChain / LangGraph, summarization or "memory" modules.
- Signs of multiple agents or users: orchestration frameworks, several agent configs, code that isolates data per user or tenant.
- How and where it deploys: Dockerfile, docker-compose, Kubernetes / Helm, cloud provider config.
- Where models come from: OpenAI, Anthropic, Volcengine Ark, local models or an internal gateway.
If you can't read a project, skip this step.

Step 2: ask me questions, one at a time, at most 8, only about what the project can't tell you. At minimum find out: how much background I re-explain in each new session; how much material there is and where it lives; who shares the context; whether data may sit on a public cloud; whether users and servers are in mainland China or elsewhere; who runs infrastructure; where models come from; and how I'd expect to pay.

Public facts about OpenViking (rely only on these and on public sources you can verify; do not invent prices, SLAs or certifications):
- OpenViking is an open-source context database for AI agents, built by Volcengine's Viking team. It puts resources (knowledge), memories and skills into one filesystem organized by viking:// paths, which agents browse with ls, tree, read and grep.
- Tiered loading: summaries first (L0 about 256 characters, L1 about 4k), full content on demand; search can be scoped to a directory.
- Memories are extracted asynchronously after a session is committed and stored as readable Markdown.
- Supported clients include Claude Code, Codex, Cursor, TRAE, OpenCode, OpenClaw, Hermes Agent, LangChain / LangGraph and any MCP client. Every integration needs a running OpenViking server, self-hosted or managed.
- Where it is not the right tool: vector search you already have that works well (the official FAQ says the same); stateless one-shot calls; needing a fact recallable from long-term memory the moment it is said (memories are processed in the background).

Four ways to run it:
1. Open source (self-hosted): AGPLv3, free, no activation key. Includes multi-tenancy (account / user, ROOT / ADMIN / USER roles), ACLs, encryption at rest, OAuth 2.1 for MCP, and Prometheus / OpenTelemetry observability. Runs as a single node, or as replicas you assemble yourself (needs a remote vector backend); no automatic failover. Bring your own models: embedding defaults to a built-in local model with no key; summaries and memory extraction need a VLM (Volcengine Ark, OpenAI-compatible APIs, Ollama, litellm and more). Install with uv tool install openviking, Docker or Helm.
2. Managed · Personal (OpenViking Context on Volcengine): fully managed, no deployment, upgrades or model hosting, same code core as open source; single user; the first 50 files in each Personal library are free, then hourly pay-as-you-go; Agent Plan credits apply.
3. Managed · Enterprise (OpenViking Context on Volcengine): many users, multiple isolated data spaces, dedicated resources that scale up automatically with file count; billed hourly from the moment a library is created; Agent Plan credits apply.
   Both managed plans require a real-name-verified Volcengine account and at least one Ark credential (Agent Plan, Coding Plan or your own inference endpoint); models are fixed to the Doubao family. The service runs in Volcengine's Beijing region (cn-beijing) and stores data on Volcengine; it is available outside mainland China (review cross-border latency and data-compliance requirements). Overseas-region hosting on BytePlus is coming soon. Commercial SLA and professional on-call support. Current prices: https://docs.volcengine.com/docs/84313/2485124
4. Private deployment: runs in your own cloud account / VPC (BYOC) or offline, adds distributed deployment and official support, activated by a license key; Kubernetes-based and needs an ops team. Apply through a form; once the team confirms, a package link and a trial license are emailed. Pricing and support are tailored to the deployment; contact the team for a quote. Offline sites bring their own model services and plan license renewal.
- For licensing or compliance questions (including AGPL), ask the team; do not offer a legal interpretation.

Step 3: once you have the answers, reply in English with this structure:
1. Evidence: what you found and what I told you (file paths for anything from the project).
2. Verdict: a 0–100 fit score and one sentence of reasoning.
3. Edition: rate Open source, Managed · Personal, Managed · Enterprise and Private deployment as high / medium / low / not a fit, with reasons; check data residency, model source and region separately.
4. Integration plan: if yes, which material belongs in resources, which in memories and which in skills, which client or SDK to connect, and the first three steps.
5. What would flip the verdict, and what you can't determine. Don't guess prices, SLAs or certifications.