English | 简体中文

sieve / dsh-sieve

LLM agent context engineering and token efficiency plugins for DeepSeek Harness (DSH)

sieve filters tool output, prunes older context and progressively discloses skills to reduce redundant input tokens in AI coding agents, improve context window utilization and provide observable usage data for LLM inference cost optimization. Originals are archived before rewriting and can be retrieved on demand.

Over 30% less request payload in offline replay, measured in characters: a 36.28% aggregate reduction across 100 public agent trajectories. See offline replay results.

Historical live model results: 21.2% lower main model input token usage across 80 paired runs on deepseek-flash, with cache hit rate moving from 93.4% to 92.9%. This experiment used the now-removed session-model judge path; the current Jev / Laya configuration has not been remeasured. See live model results and the cache FAQ.

Built around context engineering and token efficiency, sieve manages the context delivered to the model within the agent loop, reducing repeated input across multi-step tool use.

[!IMPORTANT] sieve works only with a judge model configured: Jev (hosted, needs an API key) or Laya (local, macOS on Apple Silicon). sieve never uses the session's model in its place. With neither configured, the plugin loads but changes no context. See judge models.

Why sieve

In an agent loop the main model rereads its whole context at every step. What makes requests large is rarely the user's input. It is:

• Tool output: build logs, test reports and command output run to thousands or tens of thousands of characters, and the next step usually needs a small part of it;
• Stale context: tool results that a later read superseded, or that stopped mattering long ago, are sent again at every step;
• Skill catalogs: dozens or hundreds of skill descriptions are injected at session start, most of them unrelated to the task.

All of this is billed as input tokens, fills the context window and dilutes the model's attention. sieve adds a judgment kernel on DSH's public extension points that admits, forgets and progressively discloses these three kinds of content, so the main model sees a shorter, more focused context at every step.

The hard part is deciding what can go. Fixed rules have to keep any output format they have not seen; asking the main model to decide costs its tokens and a full round of reasoning. sieve hands this step to a dedicated judge model that answers structured yes/no and single-choice questions with probabilities, and the kernel rewrites or keeps the original by threshold. In offline replay, the median latency of one Jev judgment was about 0.3 seconds.

Core capabilities and use cases

For AI coding agents running on DeepSeek Harness, especially tasks with verbose test logs, frequent tool calls, long sessions or large skill catalogs.

Quick start

1. Install the plugin (the web profile also gets the panel):

   dsh plugin --profile web add dsh-sieve@0.2.0 dsh-sieve-web@0.2.0
   

2. Configure a judge model, one of:

   • Jev: paste a TypeSafe or OpenRouter API key on the Sieve page of the DSH Web sidebar, or set the TYPESAFE_API_KEY environment variable;
   • Laya: start the Laya server on this machine and set judge.type to laya in the profile, see Using Laya.

3. Restart dsh web and reload the page, then enter /sieve status in a session and check that the "判断模型" (judge model) line does not say "未配置" (not configured).

For other ways to install (GitHub Release, building from source) see Installation.

Architecture

flowchart LR
    subgraph Loop["DSH Agent Loop"]
        T[Tool execution] -->|post-execute| A
        P[agent/pre-step] --> F
        S[Skill catalog injection] --> D
    end

    subgraph Sieve["dsh-sieve"]
        A["tool.admission<br/>tool.admission.test-log"]
        F[context.forget]
        D[skills.disclosure]
        K(("Judgment kernel<br/>Judge Engine"))
        A <--> K
        F <--> K
        D <--> K
    end

    K <-->|"System One / local HTTP"| J[("Judge model<br/>Jev · Laya")]
    A & F -->|originals| SP[(spill archive)]
    K -->|decision records| L[(ctx.storage ledger)]
    L --> W["/sieve command · Web panel"]

    A & F & D -->|reduced context| M[Main model request]

Judge models (Jev / Laya)

What rules can handle, deterministic rules handle. What they cannot settle goes to the judge model. A decision point turns the content into structured questions (yes/no, single choice); the judge model answers each with a probability or an option, and the kernel rewrites or keeps the original by threshold.

flowchart LR
    D[Decision point] --> R{Judge model configured?}
    R -->|no| N[Change nothing<br/>rules do not run either]
    R -->|yes| Q[Structured questions<br/>redacted]
    Q --> JV["Jev<br/>System One protocol"]
    Q --> LY["Laya<br/>local sidecar"]
    JV & LY -->|probabilities / options| P{Threshold}
    P -->|passes| AP[Rewrite context]
    P -->|fails / timeout / error| KP[Keep original]

No session model. Judgments go only to Jev or Laya. sieve never hands a judgment to the session's main model and has no setting for it; a profile from an older version with judge.type: llm, judge.type: off, judge.provider or routes fails to load.

No judge model, no changes. The default judge.type: auto looks for a Jev key before each decision. Without one, all four decisions let everything through: nothing is folded, forgotten or filtered, and nothing is recorded; /sieve status and the web panel say no judge model is configured. A saved key takes effect from the next decision, without a restart.

Judgments stay out of the conversation. A judge call is a side request: it is not written to the session log, does not enter the main model's context and does not change the main model's request prefix. What goes to the judge is redacted first: only content that is certainly a credential is replaced, namely credential-shaped tokens, assignments w