dsh-limit-break

dsh plugin --profile web add dsh-limit-break

dsh-limit-break

Four small tools for DeepSeek Harness that came out of a

self-benchmark: two things an agent is normally told it cannot do, made cheap enough to just do.

Tool · What it does

memory_recall · Ranked search over a JSON fact store that outlives the session. Omit query to list everything.

memory_save · Write or overwrite one fact: { id, statement, value?, unit?, details?, tags?, source? }.

resilient_fetch · Fetch with a four-rung ladder and a report of which rung answered.

memory_stats · Where the store is, how many facts, how big.

Zero npm dependencies. No import-time side effects. Everything fails soft — a broken store or a dead

network returns an error object, never an exception that could take the host down.

Recall quality. memory_recall is measured, not vibed: tools/recall-bench.mjs runs 20

hand-labelled questions against the live store and prints hit@1 / hit@3 / MRR. At 1.5.0 the ranking

skips English stopwords, stems, matches whole words (with a prefix fallback, so ray finds

raytracer), splits dotted ids into segments, weights each query token by inverse document

frequency, and rewards a whole-phrase hit: hit@1 0.75 → 0.95, MRR 0.867 → 0.975 on the same 20

questions and the same 20 facts. The one remaining miss is a genuinely ambiguous question that

matches two benchmark facts.

Runtime requirement: curl. Rung 1 of the fetch ladder is plain fetch and needs nothing; rungs

2–4 (IPv6 → IPv4 → sibling hostname) shell out to curl, so it has to be on PATH. Windows 10+,

macOS and mainstream Linux all ship it. Without it the ladder degrades to rung 1 and says so in the

report instead of pretending it climbed.

Why these four

Memory. A session starts from zero. A store on disk plus a read at the start is enough to beat

that. Measured with two brand-new agents, zero context, the same five questions: **5/5 with the

store, 0/5 without** — and the control did not hallucinate, it answered "I don't have that" five

times.

Network. The reflex "this host is unreachable" is wrong more often than it is right. Measured on

one network, same edge IP, 75 seconds apart: api.wikimedia.org → 200 in 0.43 s,

en.wikipedia.org → connection reset in 1.21 s, api.wikimedia.org again → 200 in 0.39 s. The

block was keyed on the TLS hostname, not the address. So the ladder tries, in order: plain fetch →

IPv6 → IPv4 → a sibling hostname of the same service whose certificate still verifies

(*/wiki/Title → api.wikimedia.org/core/v1/wikipedia/<lang>/page/<Title>).

It does not disable certificate verification and does not route through a proxy that would

impersonate the origin. Those are MITM, not workarounds.

The ladder learns. A fallback rung that worked is written back as network.route.<host> and the

next call to that host starts there; if a plain fetch starts working again the route is deleted (host

self-heals). Measured on en.wikipedia.org/wiki/Monte_Carlo_method, 12 s per-rung timeout: cold

12.1 s (rung 1 burned the timeout, rung 4 answered) → warm 1.08 s / 1.14 s, one attempt

instead of two — 11.2× faster. Numbers come from tools/fetch-route-bench.mjs.

Install

dsh plugin --profile <profile> add dsh-limit-break

Then restart that profile. In the desktop app, install it from Settings → Plugins instead — the

desktop profile is owned by the app's plugin manager.

The package declares dsh.bundle and ships cordis.patch.yml, so dsh plugin add mounts it with no

manual editing. If you are mounting it by hand, add to profiles/<profile>/cordis.patch.yml:

- insert:
    - id: limit-break
      name: dsh-limit-break

A hand-mounted entry still needs the package on the profile's dependency list — a bare insert for a

package the profile does not declare is silently ignored.

The store

$DSH_HOME/memory/facts.json, schema:

{ "schema_version": 1,
  "facts": [ { "id": "", "topic": "", "statement": "", "value": "", "unit": "",
               "details": "", "source": "", "timestamp": "", "tags": [] } ] }

Plain JSON on purpose: anything that can read a file can use it, with or without this plugin.

Writes are tmp-file + rename, and a save takes a .facts.lock (created O_EXCL, stolen after

15 s if its writer died) around the whole read-modify-write, so two sessions saving at the same

moment both keep their facts. tools/concurrency-selftest.mjs states the numbers: 16–17 of 48

saves lost before the lock, 0 after.

Disable / remove

• Hot: set disabled: true on the entry in cordis.patch.yml — Cordis recomposes in about a second.
• Cold: dsh plugin remove dsh-limit-break, then restart.
• The store is not deleted by either. It lives in $DSH_HOME/memory/ and is safe to keep.

Known limits

Measured, not guessed — each line is something a session actually hit.

• Tools are visible only to sessions opened after the mount. A session created before the

plugin mounted keeps its tool snapshot; new tools do not appear until a new session. Not fixable

from the plugin side (the tool list is materialised per session).

• Concurrent saves serialise, and wait at most 8 s. A second session saving at the same moment

waits for the lock instead of losing its fact; if the holder is wedged, the save returns

{ ok: false, code: "memory.locked" } rather than hanging. Read paths take no lock, so a save

still cannot stop a reader from seeing the previous snapshot.

• The fetch ladder is hostname-level. It does not defeat IP-level blocks, TLS interception,

or a proxy that terminates the connection; it does not skip certificate verification.

• A remembered route is a bet with a 14-day expiry. The ladder trusts network.route.<host> for

two weeks and drops it as

…(truncated)