dsh-our-free-model: a plugin that wires free model gateways into DeepSeek Harness

What the plugin registers when the host starts

The package is a DeepSeek Harness plugin, and the manifest declares it as private, which is consistent with how it is installed: from a local path, not from a public registry.

dsh plugin --profile web add /绝对路径/dsh-our-free-model

Its entry point is `index.js`, with a separate `./client` export for the web interface and a pattern export for locale files. Underneath it there is an `adapter/` directory that `index.js` imports on its first line, a `src/` directory for the plugin logic, a `feed/` directory that appears to hold the announcement content, a `vendor/` directory holding a bundled third party component with its own NOTICE and LICENSE, and a `worker/` directory.

The manifest declares peer dependencies on the host's own packages, including `@deepseek-ai/cordis` and `@deepseek-ai/dsh-commands`, and requires Node 22.19 or newer. The `dsh` block in the manifest points at a patch file, `cordis.patch.yml`, and marks the client platform as web with immediate loading.

One design decision is worth singling out because it explains a lot of the code. The README states that the plugin treats `llm` as a hard dependency but does not require a web server, so it works in compositions with no web UI at all, such as a terminal client. The dashboard is mounted on a separate fiber and only registers its routes once the web server is ready. That ordering is the kind of detail that normally causes silent breakage when a plugin loads before its host, and here it is handled explicitly.

Three version numbers for one plugin

The manifest says the package version is 2.0.0. The most recent release tag is v1.4.6, published 2026-10-05, with v1.4.5 earlier the same morning and v1.4.4 the day before.

Now look at the manual installation instructions in the README. They tell you to add a dependency entry pinning a specific version, and they state that this number follows the repository manifest and is currently 1.5.0. The instruction explicitly warns not to reuse an older value and not to write it as a link.

So there are three numbers in play at once: 2.0.0 in the manifest, 1.4.6 as the newest tagged release, and 1.5.0 as the value the install instructions tell you to type. The third is not a release anyone can download, since no 1.5.0 tag exists in the release list.

This is the kind of inconsistency that only matters when you follow the manual path, because the automated path reads the manifest. But the manual path is the documented one for desktop installations, and the instructions go to some length about why it has to be manual, including a profile gate that refuses to start the application if the profile tree contains symlinks or directory junctions other than the ones the host itself generates. The error it raises is about offline dependency migration not being available.

The two other manual steps are a file copy into `node_modules` with an explicit list of what has to be present, the adapter directory included, and an append to the host's bundle list. The README also warns against registering the plugin in the patch file as well, because both registrations produce a duplicate loader entry error.

The free lane and the channel that wants your GitHub star

The headline claim is that installing the plugin gives you access to frontier models with no account, no sign-up and no API key. That claim is true for a specific lane and false for the plugin as a whole.

The free lane draws from two public gateways. The README names the OpenCode Zen gateway as the source for one set of models and Kilo AI's public gateway for a free pool that includes an automatic routing entry. It states that both are connected to directly with no third party relay in between, and it links to the disclaimer section describing who handles requests and where data goes.

Then there is the channel called EAC, which works differently. The README says it unlocks automatically in the DeepSeek Harness desktop application, that models appear with an EAC prefix, that credentials are sealed and guarded by a host fingerprint gate, and that the server verifies GitHub authorization before allowing a conversation through. That authorization is described as logging in and starring the repository. In the command line and other hosts, the channel does not exist at all.

Finally, version 2.0 absorbed a separate project called dsh-codearts-auth, which brings thirteen account channels: CodeArts, CodeBuddy and WorkBuddy, LobsterAI, Qoder in two regional variants, TRAE, Cline, Loomy, Raccoon, MiniMax, ZCode and Gemini. Each has its own login flow, account pool, daily credit claiming, model blacklist and a local OpenAI gateway listening on a loopback port. The README notes that OpenCode account access has been discontinued while the anonymous free models remain.

So the accurate summary is: one lane needs nothing, one lane needs a GitHub login and a star, and thirteen lanes need accounts with daily credit collection. If you only want the first, the plugin is heavier than it needs to be.

Probing which models your network can actually reach

The most interesting engineering in the repository is not the gateway calls, it is the availability logic, and the README describes it in unusual detail.

Models are not hardcoded. The model set, context lengths and capabilities are re-pulled from upstream on every refresh, and the plugin keeps no static snapshot. On top of that, the plugin probes each model and classifies the outcome. A model the upstream list declares but the gateway refuses to route is removed from the dropdown entirely, kept only in the settings page with the refusal reason and the probe timestamp. Models blocked by regional policy stay visible but move into a separate region-limited group.

Crucially, the failure taxonomy separates model problems from infrastructure problems. A 5xx from the gateway, a 429 rate limit, a timeout or a dropped connection are all treated as inconclusive, and the model stays selectable. Only an explicit rejection counts as evidence against the model. If every model in a round is refused, the plugin keeps them all rather than presenting an empty picker.

There is a specific detail about stream detection that suggests the author has been fighting a real gateway bug. The README says that under load the gateway can return a complete sequence of server-sent event frames with a JSON content type. Rather than trusting the header, the plugin sniffs the response body shape, re-injects the bytes it consumed while sniffing, and neither fails the round nor marks a working model unavailable because the header lied.

Thinking budget is handled the same way. The plugin maps three levels to output token budgets of 2,048, 8,192 and the model maximum, and it says explicitly that this is enforced through hard output limits rather than by sending a reasoning effort parameter, with the reasoning explained in its own section. For models where thinking cannot be turned off, all three levels double, because thinking and answer text share the same output allowance. The settings page shows the actual limit sent for each model card.

A measured first token latency of up to 221 seconds

Release v1.4.6 contains an admission that is more useful than any feature list. Its notes say that measurements together with server logs show the signing lane, the keepalive mechanism and the concurrency gate all working correctly, and that first token waits of 34 to 221 seconds come from queueing in the relay upstream's shared account pool.

Read that as a property of the free and cooperative channels rather than a bug in the plugin. A shared pool of accounts serving many users will queue, and the queue is outside the plugin's control. A user who installs this expecting responsive free access to a frontier model is going to encounter waits measured in minutes, and the project's own release notes are where you would find that out.

The same release notes describe an upgrade failure that is a good illustration of the trust chain problem. Version 1.4.5's manifest was invalidated because a repository rename produced a one byte drift in four files, which broke one-click upgrade for anyone on the older version. The fix was to re-sign the 1.4.5 manifest. That is what happens when an in-app upgrade verifies a manifest hash before replacing files: any change to the bytes, including a rename in the repository path, invalidates it.

The upgrade path itself is described as a sequence with a rollback at every step: download, SHA-256 verification, backup, atomic replacement, read-back verification, then hot reload, with automatic restoration of the previous version if any step fails. That is a careful design, and the 1.4.5 incident shows both why the verification exists and how brittle a byte-exact manifest can be.

Managed installs disable the parts that write to disk

When the plugin is installed by a bundle or integration pack rather than by the user, the rules change, and the reason is a good one.

The README says the installer sets a distribution flag to managed, and that in-app upgrades, the announcement feed and hot reload are then all switched off. Two writers operating on the same directory will corrupt it, and only the model lane keeps working. Acceptance for that arrangement is covered by an offline test script, and directory readiness records including a manifest version, provenance, license and integrity live under a catalog directory.

The announcement system is worth a note on its own, because it is a remote content channel by design. The maintainer edits JSON in the repository, and every installed instance receives it within one polling cycle. Bodies render as HTML under a whitelist, an urgent level triggers a full screen popup, and system notifications are optional. That is a fast way to ship notices to every install, and it is also a channel through which the repository owner can push content into your application. The whitelist on the HTML is the mitigation, and the design is at least honest about what it is for.

The repository also carries two self-made static cards recording trending list positions, with a note that the images are hosted in the repository and the ranks were verified on a stated date. They are screenshots of somebody else's leaderboard, not live badges, which means they will be wrong the moment they are written and cannot be checked without opening the linked list.

Editorial conclusion

This plugin is an interesting read because it solves a problem the host application deliberately leaves open: provider registration. What it does not do is remove the trade-offs of using free gateways, it just measures them and puts them in a dropdown. The model list is refreshed from upstream rather than pinned, so what you get tomorrow can differ from what you get today, and reachability is measured from your own exit IP, which means the same plugin shows different models in different places. The account channels add thirteen login flows where the free lane adds none. Read the channel list before you install, decide whether the EAC arrangement is something you want to participate in, and check the version you are actually installing against the release tags rather than the number in the README.

Frequently asked questions

Official sources

1. Ebony-Vinyl/dsh-our-free-model on GitHub
2. Issues
3. License: MIT
4. README
5. Releases