安装
在 DeepSeek Harness 里通过 dsh-market 安装
dsh plugin --profile web add dshmarket
或使用命令行
dsh plugin --profile web add @creait/dsh-gen-limit
装任何插件都等于在你的机器上跑第三方代码,权限和你本人一样大——能读你的文件、用你的凭据、访问网络。请先审阅源码,并尽量锁定 commit(github:owner/repo#sha)。
README
该插件的 README 只有英文版本。
Per provider/model concurrency limits for DeepSeek Harness, with a settings card.
Some backends fall over — or bill hard — when several sessions generate against them at once. A self-hosted GPU serving one model has a real ceiling; a metered API has a financial one. dsh has no per-model concurrency control, so a single agent that fans out subagents can saturate either.
This caps how many sessions may generate concurrently on a given provider/model. Work past the cap waits in a FIFO queue rather than failing: a fan-out of eight researchers against a limit of three is a pacing problem, and bouncing five of them does not make the brief smaller, it just spends the retry budget re-asking.
How it enforces
The count — llm/stream waterfall. Every streaming model call is capped by
the number of distinct sessions actually generating. A session reentering
the loop is not counted twice, and a session parked waiting on a subagent holds
no stream — the child is what counts. This is where the limit is enforced, and
it is enforced the same way no matter how a session started: a subagent from a
tool call, a child the workflow engine started directly, or a plain
conversation.
The pacing — tools/pre-execute. When an agent calls a subagent spawn tool
(subagent, subagent_fork) and the target provider/model is already full, the
spawn joins the same queue and is admitted as soon as there is room, so a
fan-out is paced instead of piling more sessions onto a saturated backend.
This gate deliberately holds no slot of its own. Reserving one per admitted
spawn is the obvious design and it double-counts: the child then takes a second
slot the instant it generates, so every live child costs two. There is no clean
seam to hand a reservation over either — subagent/start carries no
back-reference to the spawn that caused it, and it also fires for children the
workflow engine starts without any tool call. So a child is counted exactly
once, where it can be counted consistently.
What a wait costs. queueTimeoutMs bounds how long a request waits (0
waits indefinitely) and maxQueued bounds how many may wait at once — an
unbounded queue in front of a slow backend is a memory leak that presents as a
hang. Only a request that exhausts its wait fails, and it fails with the code
GEN_CAPACITY_EXCEEDED; for a spawn that means the tool call is denied.
Reaching that point means the backend has been saturated for a sustained
period, not that a request was unlucky with timing.
The consequence — transport timeouts. Waiting for a slot means a stream may
legitimately go quiet for a long time, so the limiter also makes sure the socket
agrees. llm-pi-ai lets a provider declare streamIdleTimeoutMs, but the SSE
stream rides Node's built-in fetch, whose bodyTimeout defaults to five
minutes and which nothing in the harness configures — so any value above
300000ms is unreachable. Raising it just moves the kill from the harness
watchdog (TIMEOUT) to undici (TypeError: terminated, classified TRANSPORT,
equally retryable), and each retry restarts the step from scratch and discards
everything it had generated.
So transport.js reads the timeout the provider already declares and
installs a dispatcher that applies it to that provider's origin, plus a
30-second margin so the harness watchdog stays the one that reports a dead
stream. There is nothing new to configure, and no other origin is affected — MCP
servers, web fetches and the update check keep Node's defaults. A provider that
declares no streamIdleTimeoutMs, or one under five minutes, is left alone.
Install
dsh plugin --profile web add @creait/dsh-gen-limit
The package ships its own cordis.patch.yml, so it inserts its roster row on
its own — no manual profile edit. Add it to dsh.profile.bundles to activate
the browser half.
Configure
Limits live in the dsh-gen-limit settings namespace, one row per
provider/model. max: -1 means unlimited, and any pair without a row defaults
to unlimited — the plugin is inert until you give it a limit.
Seed them from the row in your profile patch — provider and model are
whatever ids your own routes publish:
- id: gen-limit
config:
limits:
- { provider: local-gpu, model: deepseek-v4-flash, max: 2 }
- { provider: anthropic, model: claude-opus-4, max: 1 }
queueTimeoutMs: 120000 # how long a request waits for a slot; 0 = forever
maxQueued: 64 # how many may wait at once
Or edit it in the GUI: Settings → Plugins → Plugin config → Generation
Concurrency (the shipped web UI labels those 设置面板 → 插件 → 插件配置).
The card lists the live providers and models from the same llm service the
conversation uses, so the rows are pickable rather than typed from memory.
Routes
The card talks to three plugin-owned loopback routes rather than the settings RPC — the harness settings wire only exposes namespaces on its own allowlist, which a plugin cannot widen:
| Route | Purpose |
|---|---|
/api/dsh-gen-limit/config |
read/write the limit rows |
/api/dsh-gen-limit/catalog |
live provider/model list |
/api/dsh-gen-limit/stats |
what is generating right now |
What breaks this
llm/stream and tools/pre-execute are pre-1.0 internal seams with no
compatibility guarantee. peerDependencies pins the versions this was
built against; a harness upgrade can move them.
The transport half rests on the seam Node leaves for proxies: built-in fetch
takes no per-call timeout options and reads its dispatcher from a global that
undici's setGlobalDispatcher writes. Verified on Node 25.8.1 with undici
8.10.0 — a 3s bodyTimeout installed this way killed a built-in fetch body at
3.5s, where the default had taken 301s. It is a convention, not a contract; a
runtime that stopped honouring it would put the five-minute ceiling back, which
is where things stood before this existed.
The settings nav glyph is a deliberate reach past the API. settings.section
has no icon option — the shell picks the glyph from a hardcoded section-id map
(ui-settings-general navIcon) and falls back to the gear for ids it does not
know, ours included. So the client half repaints its own row: it finds the nav
cell by label and swaps the gear's path geometry for the official
IconBranchOutline16 path, mutating the attribute rather than replacing the
node so React re-renders over it without restoring the gear. It fails safe — if
the shell's markup moves, nothing matches and the row keeps the gear.