dsh-jev-subagent-dispatch

dsh plugin --profile web add dsh-jev-subagent-dispatch

dsh-jev-subagent-dispatch

Cut LLM costs: routine tasks go to cheap subagent models; the main model keeps the hard parts.

Jev-guided subagent dispatch for DeepSeek Harness: the plugin asks Jev — TypeSafe's typed-decision model — a handful of atomic questions about the task, applies your routing policy, and appends a dispatch recommendation: which subagent model route should take the turn. The division of labor is deliberate — Jev guides, the main agent performs the handoff through the harness-native subagent tool; the plugin owns no delegation machinery of its own.

Jev does not write code and is not a chat LLM. It answers typed questions (choice / score / noul) with probabilities and a confidence, in one parallel pass, in tens of milliseconds. That makes it an ideal guide: the expensive main agent stops spending tokens deciding who should do the work.

[jev-subagent-dispatch] is to your agent what a team lead is to a developer: it reads the ticket for 200 ms and decides whether it goes to a junior — and it never lets a junior touch production.

The injection is advice, not enforcement: the main agent weighs it and can ignore it. Measure the recommendation's quality (see [Measuring impact](#measuring-impact)) before trusting it in daily work.

At a glance

The Subagent plugin has to be active. Delegation is not something this plugin can provide: DSH composes the subagent service, a child provider behind it, and the subagent tool separately, and this package deliberately takes no dependency on any of them — it re-checks at request time instead, and the card warns you when the plugin's absence is visible from settings. With it off, a verdict is still produced; there is simply nowhere to send it.

Its routes must name models your session allowlist permits. A route the allowlist forbids still classifies, so the verdict reads as healthy while dispatch is impossible. The card removes the trap: one select per role, offering exactly the allowlisted models.

Jev's task class · Role that takes it · Shipped route · Delegated

mechanical — renames, reformatting, comments, boilerplate · junior · openrouter/qwen3.8-flash · yes

bugfix · implementer · openrouter/deepseek-v4-flash · yes

research · researcher · openrouter/qwen3.8-flash · yes

review — a second opinion on work that already exists · reviewer · openrouter/qwen3.8-flash · yes

refactor, feature_work, meta_chat · — · — · no — absent from profiles.*.delegate.taskClass, so they never reach a route

Delegated is the shipped auto profile. The stricter careful profile delegates only mechanical, and the predicate's ceilings (effort, blast radius, per-question probabilities) can hold any class back regardless of its role.

Roles name the worker, classes name the work. routeFor maps a class to a role and routes maps a role to a model, so you can add a role, or point an existing one at a different model, without touching the rubric. junior exists because mechanical and bugfix are delegated together but are not one job — a rename has an unambiguous spec, a bug fix has to find the cause first — and it is the role to point at your cheapest model. reviewer ships on the same example gateway as the others, because which models exist is your composition's business and not this plugin's: the one thing the role asks of whoever configures it is that it points at a different model than your implementer — a second opinion from the model that wrote the change, or from its twin, is worth less. Every shipped route is a placeholder you replace with one select in the card; a route that is not composed fails loudly, naming the role.

Everything below is the detail behind those facts; the failure modes are in [Dispatch capability is a prerequisite](#dispatch-capability-is-a-prerequisite).

Dispatch capability is a prerequisite

For a dispatch plugin, calling Jev before knowing whether the agent can delegate at all would waste the call. DSH needs three pieces for delegation — the subagent service, a child provider behind it, and a delegation tool visible to the agent — and a depth limit of 0 disables delegation entirely. Installing this plugin implies none of that, so every routing request re-verifies capability at request time against the live host services (never a package dependency, never a boot-time snapshot):

• a delegation tool (subagent / subagent_fork) is visible to this agent;
• the subagent service is present and the provider behind the visible tool is registered;
• the agent has remaining delegation depth (session.header.delegationDepth against the effective depth limit — provider-managed limits always leave room locally);
• the session's model-selection policy (subagentModelSelectionPolicy projection): when model selection is off, the subagent tool takes no model argument and the recommendation names no model — the session's configured child default applies; when it is on, a configured route is named only if the session allowlist contains it, otherwise the message points the agent at list_subagent_models;
• which tool, and its provider: a fork is fixed-route no matter what the tool is called — the advice renders as "the fork inherits your model and context" for subagent_fork and for a custom-named tool with provider: fork alike. A model name is only ever advice the visible tool can follow.

Situation · Explicit /route request · Ordinary turn (auto)

Capability check passes · classify → inject recommendation · classify → inject recommendation

Capability check fails · inject a diagnostic naming wha

…(truncated)