[KongchangAI]
· 3 min read· 1,600 words

Open-Source Analysis of Live-Compact, the Real-Time Compression Plugin for DeepSeek Harness

Open-Source Analysis of Live-Compact, the Real-Time Compression Plugin for DeepSeek Harness

Open-source plugin Live-Compact uses 20K-token small slices to replace 80%-threshold big compression, cutting compression time to milliseconds.

A Bilibili creator open-sourced the DeepSeek Harness plugin DSH Live-Compact to address latency, drift, and frequent triggering from forced compression at the 80% context threshold. Its "compress as you go" approach cuts every 20,000 tokens without calling models or tools, processing only the current slice while preserving prior bytes for cache hits. Short-task cost fell from 1.5 to 1.15 yuan with no forced compression; long-task compression time dropped from 14 seconds to 74 milliseconds and context shrank about 40%. Shortcomings remain in excerpt file growth and non-code validation.

As Agent applications become increasingly widespread, context management is emerging as a key factor affecting both efficiency and cost. In a recent share, a Bilibili creator open-sourced a DeepSeek Harness plugin called DSH Live-Compact. The core idea is "compress as you go"—replacing the traditional one-shot large compression with high-frequency, lightweight small slices. The plugin has no complex tech stack, yet it attempts to solve a pain point that has long plagued users: the latency, drift, and frequent triggering brought by the "thunderous big compression."

Why existing compression mechanisms are a headache

Drawing on his own experience using multiple Harness implementations, the creator points out a common phenomenon: whether it's Claude, Codex, or Grok, each hardcodes a compression threshold, typically triggering forced compression when context usage reaches around 80%. This design works fine when model inference is fast, but once you switch to a locally deployed 27B model, a single compression of a 256K context can take several minutes—which the creator describes as "thunderous big compression."

If it's 20,000

Information drift after compression is equally tricky. Even if the model is smart enough, users have no way to judge whether the information discarded during compression was useful. Worse, the compressed context quickly fills up again: in long-task tests, the original Harness triggered compression around round 15, and after compressing down to 150K tokens, it was back up to over 500K by around round 20, soon facing another compression. The creator wanted to find a way to make compression appear less frequently as context grows.

Context window and compression threshold: A large language model's context window refers to the maximum number of tokens that can fit in a single request (e.g., 256K, 1M). Since GPU memory and compute costs grow with token count, model vendors and Harness implementations typically trigger compression when usage approaches the limit, summarizing historical conversation into shorter text. The 80% threshold is an engineering compromise—leaving headroom for the next few rounds of interaction to avoid requests overflowing outright. But once the threshold is hardcoded, compression timing becomes decoupled from the task rhythm: long tasks may hit the line at round 15, while short tasks never trigger compression at all.

The solution: cut once every 20,000 tokens

The Live-Compact rule can be summed up in one sentence: whenever 20,000 tokens are reached, make a cut according to preset conditions. This number is not arbitrary—it's a compromise the creator validated through practice—small enough to keep compression lightweight, yet not so frequent that it disrupts task execution.

The biggest difference from traditional approaches is that it doesn't call the model, doesn't call tools, and doesn't unpack the result. The creator specifically notes that some Bilibili users pointed out other plugins call the model to read a summary and then write another summary—which he considers completely unnecessary: "If the model can write the summary itself, why would I go read it again?" This approach is especially evident in code scenarios—code snippets have clear structure and can be replaced entirely by extraction rules instead of model generation, reducing compression time to milliseconds.

Cache hits are another key consideration. The plugin only processes the current slice; user messages before the cut point and the final answer remain untouched, and the original byte content is not modified, so subsequent requests can directly reuse the same prefix. The creator states that in testing, the cache hit rate is basically the same as the original Harness, without undermining DeepSeekAd's cost-saving characteristics.

It's the 99.89-something cache hit rate

Regarding the 650K figure, the creator explains that in a 1M-context scenario, the compression point is around 678K, leaving roughly 20K-plus of headroom for the existing forced compression mechanism to avoid mistakenly cutting important content.

KV Cache and prefix caching: In Transformer inference, the key-value pairs of processed tokens are cached (KV Cache), and subsequent requests with the same prefix can reuse them directly, avoiding redundant computation. APIs like DeepSeek bill cache hits and misses separately, with hits priced significantly lower. Therefore, if a compression mechanism modifies the original text before the cut point, it causes cache invalidation and higher costs. Live-Compact only processes the current slice and preserves the bytes before the cut point precisely to maintain the same prefix so the cache keeps hitting.

Test results: dual validation on short and long tasks

The creator selected 150 short-task code problems from open-source benchmarks (covering Python, Go, Java, Rust, and other languages) and 20 long-task code problems for comparative testing.

For short tasks, both the original and plugin versions passed all problems. In terms of cache hit volume, the plugin version is noticeably lower because it continuously makes small slices; the miss volume is correspondingly reduced, and cost dropped from 1.5 yuan to 1.15 yuan. As for context peak, the original reached a maximum of 670, having already gone through one compression of about 12.8 seconds, while the plugin version was 589, never triggering forced compression throughout—it made 145 cuts, with cumulative compression time of only 2.2 seconds. On total task duration, the two were 8,500 seconds and 6,000 seconds respectively. The creator cautiously notes this may be fluctuation from a single test, but logically, continuously maintaining clean context helps the model produce more concise results.

What's that tool called

For long-task testing, the 20 longest problems from WebUniversal were selected, all complex scenarios requiring multiple tool calls and dozens of rounds of interaction. The original Harness compressed only once, taking 14 seconds; the plugin version made 20 cuts, with compression time of 74 milliseconds—a gap of two orders of magnitude. With a 27B model, this difference would be even more pronounced. In terms of context, the original averaged 360K at the end of tasks, with ending context already at 430K, which by this pace would soon require another compression; the plugin version averaged 210K, about 40% less than the original, with ending context at 320K, about 25% less. Cache hit rates for both remained above 99%, and the plugin version still maintained a high level on the last problem.

The creator draws a broader point from this: solving model efficiency shouldn't rely on the model alone—the Harness matters just as much. "If we're going to pursue efficiency, let's do this thing thoroughly."

Token accounting and cost basis: Figures in the article such as "1.5 yuan down to 1.15 yuan" and "context 670 vs. 589" all use tokens as the unit. Cache hit volume refers to the number of tokens in a request that reuse the KV Cache, while miss volume must be recomputed and billed. Context peak reflects the history length carried in a single request, directly determining GPU memory usage and latency. Understanding these metrics helps clarify: the plugin version's cost reduction is not because tasks became simpler, but because small slices make each request carry shorter history and reuse cache more fully.

Unfinished parts and open ideas

Live-Compact currently has one obvious flaw: due to continuous slicing, compressed excerpts are stored in a separate viewing directory rather than directly replacing the corresponding passages in the conversation log as the original does. After 145 cuts across 150 short tasks, the excerpt files totaled about 2.6 MB and only grow, never shrink. The creator admits this isn't a major problem, but long-term growth still needs to be addressed, leaving it for the community to figure out.

I think after testing

Another unsolved challenge is the coexistence of the model's "thunderous big thinking" with Harness forced compression. After research, the creator found no solution that simultaneously maintains cache hit rate, and ultimately decided not to modify the original compression mechanism, only to delay its triggering.

The limitations of test set coverage are also honestly stated: the creator only has code test sets; rules for everyday conversation, finance, e-commerce, scientific research, and other scenarios have been written but lack corresponding data for validation. Since the files are open-sourced, users can adjust rules for their own scenarios. The creator positions himself as a "path-clearing operator"—blazing a trail for others to follow if they find it suitable.

Editor's observations

The value of Live-Compact lies not in technical complexity but in a shift of perspective: rather than optimizing a single big compression, make compression disappear into everyday operations. This approach aligns with the pursuit of token efficiency in model post-training, and echoes an easily overlooked fact in Agent engineering—the Harness design may influence final cost and experience no less than the model itself. Of course, the continuous growth of excerpt files, the lack of validation in non-code scenarios, and the failure to replace the forced compression mechanism are all steps this plugin must climb before maturity.

One-line Summary

Open-source plugin Live-Compact replaces 80%-threshold big compression with small slices every 20,000 tokens, reducing compression time to milliseconds.

Paragraph Summary

A Bilibili creator open-sourced the DeepSeek Harness plugin DSH Live-Compact, addressing the latency, information drift, and frequent triggering caused by existing Harness implementations triggering forced compression at the 80% context threshold. It proposes a "compress as you go" approach: cut once every 20,000 tokens according to preset rules, without calling models or tools, processing only the current slice while preserving original text before the cut point to maintain cache hits. In short-task tests, cost dropped from 1.5 yuan to 1.15 yuan with no forced compression triggered; in long tasks, compression time dropped from 14 seconds to 74 milliseconds, with context reduced by about 40% versus the original. The plugin still has shortcomings such as continuously growing excerpt files and lack of validation in non-code scenarios, and the creator argues that Harness-layer optimization is as important as model efficiency.

#DeepSeek Harness#Live-Compact#context compression#KV cache#Agent engineering#token efficiency
Share:

Related articles