DeepSeek Harness has been in developer preview long enough for the plugin ecosystem around it to develop a shape. This is a snapshot of that shape, based on the listings tracked in this directory and their repository signals. It is not a market report and it does not rank winners: the useful question for a reader is whether a category is stable enough to depend on, and which failure mode a plugin is actually solving.
Growth is real, and uneven
The plugin population keeps expanding, and the distribution is steep. A small number of repositories attract most of the attention, while a long tail of genuinely useful single-purpose plugins receives almost none. That distribution is normal, and it is exactly why discovery matters more than ranking: the thirtieth search plugin may be a better fit for your setup than the first.
What has changed since the early preview is not the count — it is that several categories now ship contracts rather than demos. A vision plugin that returns coordinates and region labels is an API you can parse. A context plugin that logs compaction events is a measurement tool. A search plugin that hardens fetch is stating a security posture. Those contracts are what make a plugin infrastructure instead of a weekend project.
Four categories matured
Four areas now have plugins that behave like infrastructure rather than experiments:
- Vision. Structured evidence output, tiled OCR for long captures, and pixel tooling for regression checks. The open question is schema convergence: three JSON shapes still make three prompts.
- Context inspection. Composition breakdowns and compaction event logs turned context tuning into measurement. The remaining gap is budget control — seeing the window is not the same as stopping a runaway session.
- Memory. Approval gates, bounded retrieval and audit surfaces replaced opaque accumulation. Version pinning still matters while snapshot formats settle.
- Search. Zero-key providers made browsing a default rather than a paid upgrade. The cost shows up later as rate limits and as unguarded fetch paths.
Three categories are still volatile
Interface plugins remain the most fragile, because they hook rendering paths that change most between preview releases. Agent orchestration plugins are maturing fast but still surprise people with unbounded loops. Model routing plugins carry the quiet risk of changing answer quality without saying so.
The practical advice for all three is the same: keep them in an isolated profile, pin after upgrade, and refuse any plugin that cannot state a stop condition or a permission surface.
Verification adoption is climbing
More listings now declare a dshTarget and a license than did a quarter ago, and more repositories carry the dsh-plugin topic, which is the mechanism that makes any of this discoverable. The remaining gap is install specification accuracy: a meaningful share of listings still show a command that does not match the published package name.
On this directory, verification levels stay in the honest L1–L3 band. That is intentional. L4 and L5 imply sandbox load or run tests; until those exist as artefacts, the labels would be marketing. Automated security scans help triage repositories without running them — they do not replace reading the permission surface of anything you install for real work.
What still needs fixing
Three problems worth naming, because directories can help with all of them.
- Compatibility declarations lag releases. A plugin that works but does not say so is treated as broken. Authors who pin a range get more trust than authors who stay silent.
- Install specs drift from reality. A wrong command wastes the trust a listing earned. Prefer
github:owner/repo#shawhile the preview line moves, and re-check after every harness bump. - Security posture is undocumented. Permission surfaces are usually discoverable from source but rarely stated, which pushes every user through the same review.
A fourth issue is quieter: duplication. Several listings register the same capability name. After a multi-plugin install, check the registered tools — a later install can silently override an earlier one.
How to read this snapshot as a buyer
Do not use star counts as a quality proxy; they measure attention. Use three signals instead: whether the install command resolves, whether the plugin declares a target or documents its breakage plan, and whether the failure mode it claims to fix matches yours. A high-star UI skin and a low-star context dashboard solve different problems; only one of them is on your critical path.
If you are starting from zero: install context inspection first, then search or vision if the model lacks that capability, then memory only after you can see what the window is doing. Orchestration last — and only with a budget.
What is coming
Expect the interface churn to continue while the runtime is in preview, more convergence on structured evidence formats for tool output, and the first serious attempts at cost and routing transparency in the model category. The directory will keep tracking all three, and will keep refusing to publish a single “safety score” until the inputs can support one.