
openviking-context-database
Expert skill for using OpenViking, the open-source context database for AI Agents that manages memory, resources, and skills via a filesystem paradigm.
- Installs
- 1.3K
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/reason-machines/trending-skills --skill openviking-context-database- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads openviking-context-database automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
OpenViking Context Database
Skill by ara.so — Daily 2026 Skills collection.
OpenViking is an open-source context database for AI Agents that replaces fragmented vector stores with a unified filesystem paradigm. It manages agent memory, resources, and skills in a tiered L0/L1/L2 structure, enabling hierarchical context delivery, observable retrieval trajectories, and self-evolving session memory.
Installation
Python Package
pip install openviking --upgrade --force-reinstall
Optional Rust CLI
# Install via script
curl -fsSL https://raw.githubusercontent.com/volcengine/OpenViking/main/crates/ov_cli/install.sh | bash
# Or build from source (requires Rust toolchain)
cargo install --git https://github.com/volcengine/OpenViking ov_cli
Prerequisites
- Python 3.10+
- Go 1.22+ (for AGFS components)
- GCC 9+ or Clang 11+ (for core extensions)
Configuration
Create ~/.openviking/ov.conf:
{
"storage": {
"workspace": "/home/user/openviking_workspace"
},
"log": {
"level": "INFO",
"output": "stdout"
},
"embedding": {
"dense": {
"api_base": "https://api.openai.com/v1",
"api_key": "$OPENAI_API_KEY",
"provider": "openai",
"dimension": 1536,
"model": "text-embedding-3-large"
},
"max_concurrent": 10
},
"vlm": {
"api_base": "https://api.openai.com/v1",
"api_key": "$OPENAI_API_KEY",
"provider": "openai",
"model": "gpt-4o",
"max_concurrent": 100
}
}
Note: OpenViking reads
api_keyvalues as strings; use environment variable injection at startup rather than literal secrets.
Provider Options
| Role | Provider Value | Example Model |
|---|---|---|
| VLM | openai | gpt-4o |
| VLM | volcengine | doubao-seed-2-0-pro-260215 |
| VLM | litellm | claude-3-5-sonnet-20240620, ollama/llama3.1 |
| Embedding | openai | text-embedding-3-large |
| Embedding | volcengine | doubao-embedding-vision-250615 |
| Embedding | jina | jina-embeddings-v3 |
LiteLLM VLM Examples
{
"vlm": {
"provider": "litellm",
"model": "claude-3-5-sonnet-20240620",
"api_key": "$ANTHROPIC_API_KEY"
}
}
{
"vlm": {
"provider": "litellm",
"model": "ollama/llama3.1",
"api_base": "http://localhost:11434"
}
}
{
"vlm": {
"provider": "litellm",
"model": "deepseek-chat",
"api_key": "$DEEPSEEK_API_KEY"
}
}
Core Concepts
Filesystem Paradigm
OpenViking organizes agent context like a filesystem:
workspace/
├── memories/ # Long-term agent memories (L0 always loaded)
│ ├── user_prefs/
│ └── task_history/
├── resources/ # External knowledge, documents (L1 on demand)
│ ├── codebase/
│ └── docs/
└── skills/ # Reusable agent capabilities (L2 retrieved)
├── coding/
└── analysis/
Tiered Context Loading (L0/L1/L2)
- L0: Always loaded — core identity, persistent preferences
- L1: Loaded on demand — relevant resources fetched per task
- L2: Semantically retrieved — skills pulled by similarity search
This tiered approach minimizes token consumption while maximizing context relevance.
Python API Usage
Basic Setup
import os
from openviking import OpenViking
# Initialize with config file
ov = OpenViking(config_path="~/.openviking/ov.conf")
# Or initialize programmatically
ov = OpenViking(
workspace="/home/user/openviking_workspace",
vlm_provider="openai",
vlm_model="gpt-4o",
vlm_api_key=os.environ["OPENAI_API_KEY"],
embedding_provider="openai",
embedding_model="text-embedding-3-large",
embedding_api_key=os.environ["OPENAI_API_KEY"],
embedding_dimension=1536,
)
Managing a Context Namespace (Agent Brain)
# Create or open a namespace (like a filesystem root for one agent)
brain = ov.namespace("my_agent")
# Add a memory file
brain.write("memories/user_prefs.md", """
# User Preferences
- Language: Python
- Code style: PEP8
- Preferred framework: FastAPI
""")
# Add a resource document
brain.write("resources/api_docs/stripe.md", open("stripe_docs.md").read())
# Add a skill
brain.write("skills/coding/write_tests.md", """
# Skill: Write Unit Tests
When asked to write tests, use pytest with fixtures.
Always mock external API calls. Aim for 80%+ coverage.
""")
Querying Context
# Semantic search across the namespace
results = brain.search("how does the user prefer code to be formatted?")
for result in results:
print(result.path, result.score, result.content[:200])
# Directory-scoped retrieval (recursive)
skill_results = brain.search(
query="write unit tests for a FastAPI endpoint",
directory="skills/",
top_k=3,
)
# Direct path read (L0 always available)
prefs = brain.read("memories/user_prefs.md")
print(prefs.content)
Session Memory & Auto-Compression
# Start a session — OpenViking tracks turns and auto-compresses
session = brain.session("task_build_api")
# Add conversation turns
session.add_turn(role="user", content="Build me a REST API for todo items")
session.add_turn(role="assistant", content="I'll create a FastAPI app with CRUD operations...")
# After many turns, trigger compression to extract long-term memory
summary = session.compress()
# Compressed insights are automatically written to memories/
# End session — persists extracted memories
session.close()
Retrieval Trajectory (Observable RAG)
# Enable trajectory tracking to observe retrieval decisions
with brain.observe() as tracker:
results = brain.search("authentication best practices")
trajectory = tracker.trajectory()
for step in trajectory.steps:
print(f"[{step.level}] {step.path} → score={step.score:.3f}")
# Output:
# [L0] memories/user_prefs.md → score=0.82
# [L1] resources/security/auth.md → score=0.91
# [L2] skills/coding/jwt_auth.md → score=0.88
Common Patterns
Pattern 1: Agent with Persistent Memory
import os
from openviking import OpenViking
ov = OpenViking(config_path="~/.openviking/ov.conf")
brain = ov.namespace("coding_agent")
def agent_respond(user_message: str, conversation_history: list) -> str:
# Retrieve relevant context
context_results = brain.search(user_message, top_k=5)
context_text = "\n\n".join(r.content for r in context_results)
# Build prompt with retrieved context
system_prompt = f"""You are a coding assistant.
## Relevant Context
{context_text}
"""
# ... call your LLM here with system_prompt + conversation_history
response = call_llm(system_prompt, conversation_history, user_message)
# Store interaction for future memory
brain.session("current").add_turn("user", user_message)
brain.session("current").add_turn("assistant", response)
return response
Pattern 2: Hierarchical Skill Loading
# Register skills from a directory structure
import pathlib
skills_dir = pathlib.Path("./agent_skills")
for skill_file in skills_dir.rglob("*.md"):
relative = skill_file.relative_to(skills_dir)
brain.write(f"skills/{relative}", skill_file.read_text())
# At runtime, retrieve only relevant skills
def get_relevant_skills(task: str) -> list[str]:
results = brain.search(task, directory="skills/", top_k=3)
return [r.content for r in results]
task = "Refactor this class to use dependency injection"
skills = get_relevant_skills(task)
# Returns only DI-related skills, not all registered skills
Pattern 3: RAG over Codebase
import subprocess
import pathlib
brain = ov.namespace("codebase_agent")
# Index a codebase
def index_codebase(repo_path: str):
for f in pathlib.Path(repo_path).rglob("*.py"):
content = f.read_text(errors="ignore")
# Store with relative path as key
rel = f.relative_to(repo_path)
brain.write(f"resources/codebase/{rel}", content)
index_codebase("/home/user/myproject")
# Query with directory scoping
def find_relevant_code(query: str) -> list:
return brain.search(
query=query,
directory="resources/codebase/",
top_k=5,
)
hits = find_relevant_code("database connection pooling")
for h in hits:
print(h.path, "\n", h.content[:300])
Pattern 4: Multi-Agent Shared Context
# Agent 1 writes discoveries
agent1_brain = ov.namespace("researcher_agent")
agent1_brain.write("memories/findings/api_rate_limits.md", """
# API Rate Limits Discovered
- Stripe: 100 req/s in live mode
- SendGrid: 600 req/min
""")
# Agent 2 reads shared workspace findings
agent2_brain = ov.namespace("coder_agent")
# Cross-namespace read (if permitted)
shared = ov.namespace("shared_knowledge")
rate_limits = shared.read("memories/findings/api_rate_limits.md")
CLI Commands (ov_cli)
# Check version
ov --version
# List namespaces
ov namespace list
# Create a namespace
ov namespace create my_agent
# Write context file
ov write my_agent/memories/prefs.md --file ./prefs.md
# Read a file
ov read my_agent/memories/prefs.md
# Search context
ov search my_agent "how to handle authentication" --top-k 5
# Show retrieval trajectory for a query
ov search my_agent "database migrations" --trace
# Compress a session
ov session compress my_agent/task_build_api
# List files in namespace
ov ls my_agent/skills/
# Delete a context file
ov rm my_agent/resources/outdated_docs.md
# Export namespace to local directory
ov export my_agent ./exported_brain/
# Import from local directory
ov import ./exported_brain/ my_agent_restored
Troubleshooting
Config Not Found
# Verify config location
ls -la ~/.openviking/ov.conf
# OpenViking also checks OV_CONFIG env var
export OV_CONFIG=/path/to/custom/ov.conf
Embedding Dimension Mismatch
If you switch embedding models, the stored vector dimensions will conflict:
# Check current dimension setting vs stored index
# Solution: re-index after model change
brain.reindex(force=True)
Workspace Permission Errors
# Ensure workspace directory is writable
chmod -R 755 /home/user/openviking_workspace
# Check disk space (embedding indexes can be large)
df -h /home/user/openviking_workspace
LiteLLM Provider Not Detected
# Use explicit prefix for ambiguous models
{
"vlm": {
"provider": "litellm",
"model": "openrouter/anthropic/claude-3-5-sonnet", # full prefix required
"api_key": "$OPENROUTER_API_KEY",
"api_base": "https://openrouter.ai/api/v1"
}
}
High Token Usage
Enable tiered loading to reduce L1/L2 fetches:
# Scope searches tightly to avoid over-fetching
results = brain.search(
query=user_message,
directory="skills/relevant_domain/", # narrow scope
top_k=2, # fewer results
min_score=0.75, # quality threshold
)
Slow Indexing on Large Codebases
# Increase concurrency in config
{
"embedding": {
"max_concurrent": 20 # increase from default 10
},
"vlm": {
"max_concurrent": 50
}
}
# Or batch-write with async
import asyncio
async def index_async(files):
tasks = [brain.awrite(f"resources/{p}", c) for p, c in files]
await asyncio.gather(*tasks)
Environment Variables Reference
| Variable | Purpose |
|---|---|
OV_CONFIG | Path to ov.conf override |
OPENAI_API_KEY | OpenAI API key for VLM/embedding |
ANTHROPIC_API_KEY | Anthropic Claude via LiteLLM |
DEEPSEEK_API_KEY | DeepSeek via LiteLLM |
GEMINI_API_KEY | Google Gemini via LiteLLM |
OV_LOG_LEVEL | Override log level (DEBUG, INFO, WARN) |
OV_WORKSPACE | Override workspace path |
Resources
- Website: https://openviking.ai
- Docs: https://www.openviking.ai/docs
- GitHub: https://github.com/volcengine/OpenViking
- Issues: https://github.com/volcengine/OpenViking/issues
- Discord: https://discord.com/invite/eHvx8E9XF3
- LiteLLM Providers: https://docs.litellm.ai/docs/providers
FAQ
What does the openviking-context-database skill do?
Expert skill for using OpenViking, the open-source context database for AI Agents that manages memory, resources, and skills via a filesystem paradigm.
How do I install openviking-context-database?
Run npx skills add https://github.com/reason-machines/trending-skills --skill openviking-context-database in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/openviking-context-database/ (personal) or .claude/skills/openviking-context-database/ (project).
Which AI agents can use openviking-context-database?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is openviking-context-database safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains openviking-context-database?
It is published by reason-machines in reason-machines/trending-skills. It has 1,334 recorded installs.
More from reason-machines/trending-skills
openclaw-control-center
reason-machines/trending-skills
Local-first, security-first control center for OpenClaw agents — visibility dashboard with readonly defaults, token attribution, collaboration tracing, and safe write operations.
inkos-multi-agent-novel-writing
reason-machines/trending-skills
Multi-agent CLI system for autonomous novel writing, auditing, and revision with human review gates
claude-hud-statusline
reason-machines/trending-skills
A Claude Code plugin that displays a real-time HUD showing context usage, active tools, running agents, and todo progress in your terminal statusline.
understand-anything-knowledge-graph
reason-machines/trending-skills
Turn any codebase into an interactive knowledge graph using Claude Code skills — explore, search, and ask questions about any project visually.
agency-agents-ai-specialists
reason-machines/trending-skills
A collection of specialized AI agent personalities for Claude Code, Cursor, Aider, Windsurf, and other AI coding tools — covering engineering, design, marketing, sales, and more.
agent-browser-automation
reason-machines/trending-skills
Headless browser automation CLI for AI agents using native Rust binary with Chrome DevTools Protocol
Popular data & databases skills
supabase-postgres-best-practices
supabase/agent-skills
Postgres best practices maintained by Supabase, for Postgres running anywhere. Load this skill BEFORE writing or changing anything that lives in a Postgres database: creating or altering tables and columns (including choosing column types), schema design, migrations and declarative schema files, RLS policies and the tests that verify them, indexes, triggers, database functions, queues and scheduled jobs (pgcron, pgmq), vector/semantic search (pgvector), and restoring dumps (pgrestore) or importing data. Also load it when diagnosing slow queries, high CPU, timeouts, EXPLAIN plans, connection exhaustion, locking, bloat, or rows visible to the wrong user or tenant. This is not just a performance guide — schema, migration, security, and SQL authoring tasks need these rules too, even for a one-column change or a single query.
prisma-client-api
prisma/skills
Prisma Client API reference covering model queries, filters, operators, and client methods. Use when writing database queries, using CRUD operations, filtering data, or configuring Prisma Client. Triggers on "prisma query", "findMany", "create", "update", "delete", "$transaction".
prisma-database-setup
prisma/skills
Deprecated compatibility name for prisma-orm-setup. Use only when a user or existing integration explicitly invokes prisma-database-setup; otherwise select prisma-orm-setup.
prisma-cli
prisma/skills
Prisma ORM 7 CLI reference for existing Prisma 7 applications or explicitly selected Prisma 7 workflows. Covers prisma init, generate, migrate, db, dev, studio, and mcp. For setup, connection repair, or Prisma 8, use prisma-orm-setup; not the Prisma Platform CLI.
prisma-postgres
prisma/skills
Deprecated compatibility name for prisma-postgres-setup. Use only when a user or existing integration explicitly invokes prisma-postgres; otherwise select prisma-postgres-setup.
prisma-driver-adapter-implementation
prisma/skills
Required reference for Prisma ORM 7 SQL driver adapter work. Use when implementing or modifying adapters, adding database drivers, or touching SqlDriverAdapter, Transaction, savepoint, result mapping, or DriverAdapterError behavior. Covers current transaction lifecycle, optional savepoint hooks, original database-error preservation, and verification.