This article is derived from the plugin's already-indexed fields (wiki / faq / compatibility_json / readme), not freshly generated by AI. Source field is noted at the end of each section.

Quick start

dsh-model-tier

— source: plugin_wiki.wiki_content

Install & verify

dsh plugin --profile web add dsh-model-tier

Run the command above in your DSH Web Profile. Then enable the plugin in the plugin list.

— source: plugins.install

Key points

• id: model-tier
• Host plane — mounted in the profile bundle (cordis.patch.yml), not the agent preset, so it applies to every session and subagent on the profile.
• Host Details document — remote_host_notes maintains per-host notes (environment activation, partitions/account, conventions) that the model reads before submitting jobs.
• Structured error codes (ERR_NOT_INIT / ERR_NOT_FOUND / ERR_VALIDATION / ERR_PATH / ERR_QUOTA / ERR_LOCK_TIMEOUT / ERR_IO) instead of opaque strings.
• Hypothesis state machine (proposed → testing → supported/refuted/inconclusive) and forward-only phase transitions (rewind requires config).

— source: plugin_wiki.readme_en (fallback readme_raw)

FAQ

What is the relationship between this plugin and Claude Code's Opus/Sonnet/Haiku strategy?

It's the DSH implementation of the same concept: automatically routing auxiliary requests (title/compression) and subtasks to the light tier within the same session, running the main conversation on the default tier, and upgrading complex tasks to the strong tier according to rules, corresponding to Claude Code's smallModel/--model-small and task complexity judgment.

Will all sessions be automatically tiered after installation?

No. The plugin only registers a virtual provider 'Intelligent Tiering' in the session model selector. It needs to be manually selected as 'Intelligent Tiering / Some Scheme' in each session to be enabled. Sessions not selected are completely unaffected (opt-in per session, no global routing).

Where is the config file stored? Do I need to restart after making changes?

Written to $DSH_HOME/model-tier.json (default ~/.dsh/model-tier.json). The routing engine caches by file mtime, changes take effect immediately, no need to restart profile or reopen session.

Is the LLM pre-classifier (routing.classify) required?

No. It's an optional enhancement: when enabled, before each user question or subtask dispatch, a small model will classify the task as light/default/strong, overriding the structural tier. By default it uses the light tier model for classification, failure/timeout/nonsense automatically falls back to the structural tier (does not block the main request).

Can thinking models be used for the classifier target?

Not recommended. Thinking models' reasoning content also consumes maxTokens quota (default 512, can be adjusted via maxTokens). Testing has shown cases where thinking consumed the entire quota, resulting in empty string output and unable to get classification words. README explicitly recommends selecting non-thinking models.

What is the relationship with dsh-science?

dsh-model-tier is a companion package to dsh-science. Installing dsh-science will automatically include dsh-model-tier as a dependency; but it is completely independent and can be used alone in any profile via dsh plugin add dsh-model-tier.

— source: plugin_wiki.faq_json

Compatibility

• DSH: 未声明
• Node: >=18
• Platforms: 跨平台

— source: plugin_wiki.compatibility_json

Pitfalls

Review the upstream repo before installing. This guide is auto-derived from indexed fields and may lag the latest release. If anything contradicts the official docs, treat the upstream source as authoritative.

— source: general rule