dsh-opencode-live-models

dsh-opencode-live-models

English | 中文

DeepSeek Harness (DSH) ships with a pi-ai model catalog that can lag behind OpenCode Go. This plugin updates it at runtime.

Install

Desktop — open Plugins in the sidebar, click Add plugin, paste the spec, then choose Enable now and restart DSH:

github:Luca4Don3/dsh-opencode-live-models

CLI — add both installs and selects the bundle; restart DSH to compose it:

dsh plugin --profile desktop add github:Luca4Don3/dsh-opencode-live-models

The github: spec downloads over HTTPS from codeload.github.com; an npm mirror does not proxy it, so the host needs reachable GitHub access.

Requires DSH 0.1.5-rc.1 or newer, and 0.3.0 or newer of this plugin.

0.3.0 drops the bundled model descriptors. A model the installed catalog does not carry is now offered only while Pi's catalog is reachable, so a first boot with no network lists one model less than 0.2.1 did: space-bunny-free. See How it works.

0.1.1 is kept for the record — do not install it. Two defects are fixed in 0.1.2: a roster that arrives before the adapter registers can pass the size guard and hide installed models, and unloading leaves the overlay installed, so the picker keeps showing models the plugin is no longer maintaining. Upgrading in place is enough; existing installs do not need to be removed first.

How it works

• Loads model descriptors from Pi's catalog. Nothing is bundled: the overlay is whatever Pi currently publishes, so an id added, renamed or retired upstream needs no release here. The installed catalog remains available if the fetch fails.
• Checks the OpenCode Go model list for retired installed models and reports model IDs that lack descriptors.

Pi's own entries are exempt from that check. A model Pi still publishes while OCG has retired it stays in the picker until Pi drops it — following Pi's cadence is this plugin's contract, and treating a gateway gap as a retirement would retire exactly the ids Pi is ahead on.

The plugin updates pi-ai's opencode-go model list. Requests continue through the installed pi-ai transport and authentication.

Both feeds are fetched in parallel and neither is trusted to shrink the catalog: a response that is empty, malformed, or implausibly smaller than the last good one is refused rather than applied, so a bad fetch cannot quietly empty the picker.

Mounting does not wait for them. The installed catalog is already a correct catalog — the one you would have had without this plugin — so it is published the moment the plugin loads; the network refresh runs behind that and publishes again only if it changes something. On a first boot with no network at all, that floor plus the on-disk cache is everything the plugin has to offer, which is the deliberate cost of bundling nothing.

The accepted catalog is also written to disk and read back on the next start, so an outage does not cost you the models only Pi carries. It goes to the profile directory when DSH exposes one, otherwise to ~/.dsh. Cached entries are re-validated on the way in, a cache older than a week is ignored, and one that cannot be written or read is simply skipped. Pi serves an ETag, so an unchanged catalog costs a conditional request rather than a full body.

Reading the log. On a 304 the plugin keeps both the catalog and the ETag and does not rewrite the file, so the cache's mtime staying put is the expected result, not a failure. catalog updated marks a change in the visible catalog and nothing else — restoring the cache at start can produce it too, and its absence says nothing about whether the refresh worked. A first catalog published count is not a fixed number either.

What to check after a controlled restart: the overlay was installed, a catalog published appeared, and no pi.dev catalog refresh failed did — but wait for the first refresh to finish before looking for that warning. The two requests run in parallel with an 8s timeout each, and the failure is only recorded once both settle, so the absence of a warning right after catalog published means nothing yet. Allow the timeout window before concluding anything.

Test

npm test

Runs probe.mjs against fixtures committed in test/fixtures/, captured from the live endpoints — no network or setup needed after a fresh clone.

Probe

Two of the three fixtures are the endpoints' own response bodies, verbatim:

curl -sS https://opencode.ai/zen/go/v1/models \
  -o test/fixtures/ocg-models.json
curl -sS 'https://pi.dev/api/models/providers/opencode-go?types=chat' \
  -o test/fixtures/pi-dev-opencode-go.json

The third is the catalog the installed pi-ai ships, which lives inside the desktop client rather than on disk: app.asar → node_modules/@earendil-works/pi-ai/dist/providers/data/opencode-go.json. docs/catalog-injection.md has a working reader for that archive. Record the pi-ai version it came from in both the filename (opencode-go-.json) and CATALOG_SOURCE in probe.mjs — the assertions that cite it are statements about a catalog that exists only inside one release, and a fixture that silently stops matching the client is how this suite once passed against something nobody was shipping.

Then run the suite. Most counts are derived from the fixtures rather than written down, so a genuine upstream change should leave it green. What must not change silently is the set of models the drift report names — if that differs, the answer to "which live models have no descriptor" moved with it, so read docs/protocol-probing.md before editing any assertion that names a model.

To try fixtures without committing them:

OCG_FIXTURES=/path/to/fixtures npm test

Limitations

• Models without descriptors do not appear in the picker.
• The two endpoints, the five-minute poll interval and the cache age are fixed in the source. The gateway base URLs are fixed on purpose — a remote catalog decides which models exist, never where a request goes — so pointing this at a different gateway means editing lib/index.js.
• The plugin uses llm-pi-ai internals. If a DSH update changes them, it logs a warning and leaves the installed catalog in place.

License

MIT