DSH Hub

raullenchai/rapid-mlx-dsh-provider

dsh-provider

BundleWorkflow21 GitHub stars· updated 2026-08-19

Native Rapid-MLX provider for DeepSeek Harness (dsh) — dsh reads model facts from the server instead of your settings.yaml.

Install

npx @deepseek-ai/dsh plugin --profile web add @raullenchai/dsh-provider

Restart `dsh web` after install. Bundle APIs can change during the developer preview.

README badge

dsh-provider DSH Hub badge
[![DSH Hub](https://dshhub.dev/badge/rapid-mlx-dsh-provider.svg)](https://dshhub.dev/plugins/rapid-mlx-dsh-provider)

Paste this into your README. The star count updates with every catalog sync.

From the README

Excerpt from raullenchai/rapid-mlx-dsh-provider, cleaned of badges and images.

@raullenchai/dsh-provider

A native Rapid-MLX provider for DeepSeek Harness — so dsh gets its model facts from the server instead of from whatever you typed into settings.yaml.

Status: published to npm as @raullenchai/dsh-provider. The end-to-end dsh run in Verified was on an M3 Ultra against dsh 0.1.0-rc.7; dsh 0.1.0-rc.8 is API-compatible — the LlmAdapter contract is byte-identical and the only changes are additive — and the adapter is re-verified against rc.8 at the protocol and unit-test level. DSH is still a developer preview that moves fast, so treat this as tracking a moving target, not a frozen compatibility promise.

What it does for you

DSH can already talk to a local Rapid-MLX server through its generic openai-completions provider. That route works — but it knows nothing about your model beyond what you hand-wrote:

# what the generic route makes you maintain, by hand, per model
llm-pi-ai:
  providers:
    rapid-mlx:
      baseURL: http://localhost:8000/v1
      defaultContextWindow: 262144      # you looked this up. is it still right?
      models:
        - id: qwen3.6-35b-8bit
          contextWindow: 262144
          reasoningEfforts: {off: none, low: low, medium: medium, high: high}

Rapid-MLX's /v1/models already publishes all of that and more. This adapter reads it, so:

1. Nothing to hand-write, and nothing to re-write when you switch models. Swap what rapid-mlx serve is running and dsh follows. No re-running setup, no stale numbers.

2. The reasoning control tells the truth. Rapid-MLX reports whether a model actually has a reasoning parser. A model that can't reason no longer shows an off/low/medium/high selector that does nothing.

3. Compaction is timed with the capacity that actually fits this Mac, not a number that drifted. This is the one that quietly costs you. dsh-compaction-basic asks the provider for the route's capacity and compacts at thresholdRatio × capacity (0.8 by default). The provider prefers the server's max_model_len — Rapid-MLX's memory-fitted ceiling (what fits in unified memory: weights + KV cache), in the vLLM/SGLang-standard field — over the native context_window, and falls back to context_window on an older server that doesn't report it. So compaction is timed to what the machine can actually hold, not the model's advertised window (which it may not have room for) and not a hand-written number copied from another model.

Install

Needs Node ≥ 22.15 (dsh imports Node's Zstd stream API without declaring it) and a running Rapid-MLX server.

# From npm:
dsh plugin --profile web add @raullenchai/dsh-provider

# …or straight from source — the package ships plain JS with no build step:
dsh plugin --profile web add github:raullenchai/rapid-mlx-dsh-provider

export RAPID_MLX_BASE_URL=http://localhost:8000/v1     # optional; this is the default
dsh web

Then point the agent at the route:

# $DSH_HOME/settings.yaml
agent-default-model:
  provider: rapid-mlx
  model: qwen3.6-35b-8bit

Verified: that command installs and activates as a profile layer against dsh 0.1.0-rc.7. To hack on it locally instead, see Local development.

Model management (v0.2.0)

Related plugins