Giving DeepSeek Harness a Memory: OpenViking Cuts Tokens by Up to 91% in Real-World Tests

The Amnesia Problem in LLMs — and How OpenViking Solves It

DeepSeek^Ad Harness (DSH) is a go-to AI coding tool for many developers, but it has one persistent pain point: every new session starts with a blank slate. For the same project, you have to re-explain the background, directory structure, and requirements from scratch every single time — an endless cycle of context rebuilding that kills productivity.

To tackle this, a Bilibili creator integrated a memory layer called OpenViking into DSH. This is an open-source context database project from ByteDance that has accumulated roughly 37,900 stars on GitHub. Once set up, the AI can retain memory across sessions for the same project — no more starting over.

The core concept is straightforward: organize everything the AI needs to remember into a filesystem. There are just three top-level directories — Agent, Resources, and User. You can navigate them directly from the command line using familiar commands like ls, tree, and find. Each directory carries a summary description, which is the key to how tokens are saved.

Three-Layer Loading: The Secret Behind the Token Savings

OpenViking's token-saving mechanism lies in layered content loading, rather than dumping all information into the context window at once.

• L0: A one-sentence summary, used first to determine whether this content is relevant to the current task;
• L1: An overview layer, used for task planning;
• L2: Full text, loaded only when a deep read is genuinely needed.

This progressive, coarse-to-fine retrieval avoids feeding the model large blocks of irrelevant content all at once. According to official benchmarks, input token reduction ranges from 34% to 91% — a wide range that depends on task type and retrieval hit rate.

Beyond cost savings, memory accuracy also improves. Official data shows that on Claude Code (referred to verbally as "Cloud Code" in the video), memory accuracy jumped from 57% to 80%. Worth noting: these are figures published by the project itself. The repository includes reproduction scripts, so readers who want to verify the numbers can do so independently.

The context window refers to the maximum text length a model can "see" in a single inference pass, measured in tokens. Tokens are not equivalent to characters — one Chinese character typically maps to 1–2 tokens, while an English word is roughly 1–1.5 tokens. Mainstream models have expanded their context windows from the early 4K limit to 128K or beyond, but a larger window doesn't mean unlimited free capacity. Commercial APIs typically charge per input token, and a fuller window also scatters the model's attention across long distances, leading to retrieval failures where information is technically present but effectively ignored. OpenViking's layered loading is essentially a manual retrieval and trimming layer outside the window — only relevant content snippets are placed inside it, keeping costs in check while maintaining high attention density on the information that actually matters.

Real-World Testing: One in Four Searches Comes Up Empty

The creator didn't stop at repeating official figures — they ran their own tests on their own machine. The results are worth paying attention to: out of 1,257 retrieval attempts, 40.3% returned zero results — meaning roughly one in four searches found nothing at all.

This number reveals an important reality: OpenViking is not a plug-and-play silver bullet. The zero-result rate depends heavily on how well you've organized your directory structure. The library in the test contained roughly 5,270 projects across three mount points (self-reported by the author, unmodified). In other words, retrieval hit rate requires active effort from the user — the tool only provides the mechanism.

The author's tone here is admirably restrained: no inflating of the official cost-reduction figures, and an honest acknowledgment of the high zero-result rate encountered in practice. That kind of unvarnished presentation is far more useful to readers than a polished sales pitch.

How to Connect It to DSH

Connecting OpenViking to DeepSeek Harness is supported through two official methods:

1. Plugin integration;
2. MCP (Model Context Protocol) integration.

Each approach suits different use cases. The repository link is provided in the video description. For developers already using DSH who are tired of the amnesia problem, this is a low-cost patch worth trying.

That said, it's important to be clear about its limits: OpenViking addresses cross-session memory persistence and context compression. What it can't fix — as the author openly states — is a poorly organized directory structure. That part is on you. The tool provides the skeleton; the user has to supply the flesh.

MCP (Model Context Protocol) is an open protocol introduced by Anthropic in late 2024, designed to create a standardized communication interface between AI models and external tools or data sources. Think of it as the "USB port" of the AI world — as long as both the tool and the host conform to the protocol, integration and switching require no custom adapter work on either side. Claude, Cursor, Windsurf, and other mainstream AI coding environments already support MCP, and the ecosystem is expanding rapidly. Compared to plugin-based integration, MCP's main advantage is stronger interoperability: a single OpenViking MCP service can theoretically be called by multiple MCP-compatible clients simultaneously, without maintaining a separate integration for each tool. For developers who switch between multiple AI coding environments, the long-term maintenance cost of the MCP approach is generally lower.

Summary

OpenViking abstracts AI memory into a command-line-navigable filesystem, paired with L0/L1/L2 progressive loading that delivers 34%–91% token reduction and meaningfully improved memory accuracy according to official data. In real-world use, however, a roughly 40% zero-result rate makes clear that the tool's effectiveness is highly dependent on how well the user organizes their directory structure. For DSH users, it's an open-source, reproducible, relatively low-barrier memory augmentation solution worth evaluating against your own project's needs.