DeepSeek Harness plugin

use-opencode-local-provider

Use the opencode local server (OpenCode Zen client channel) as a provider in dsh

Jump to install

Source facts

Repository
Payel-git-ol/use-opencode-local-provider
Latest update
Aug 19, 2026
Category
Tools & Capabilities
GitHub stars
1
Format
plugin
Catalog evidence
Upstream dsh.bundle evidence
Evidence path
package.json#dsh.bundle
Checked against
0.1.0-rc.8
Upstream check date
2026-08-20

This evidence comes from the upstream catalog. This site has not installed, run, or security-reviewed the plugin.

Install

Start with a prompt that asks an agent to review the GitHub repository and source. Switch to the command if you want to install it yourself.

Copy this prompt into DSH, Codex, or another agent and ask it to review the GitHub repository and source first.

Do not install or run any commands yet. Read this plugin's GitHub repository, README, and relevant source code. Then answer the questions below clearly and directly so I can decide whether it fits my needs:

1. What is this plugin, and what problem does it solve?
2. Who is it for, and what are its typical use cases?
3. How is it used after installation? Include one minimal example.
4. What known limitations or privacy, security, compatibility, or maintenance risks does it have?
5. Give a clear recommendation: recommend, conditionally recommend, or do not recommend, with reasons.

Distinguish statements documented by the repository, inferences from source code, and unknowns. If evidence is insufficient, say so explicitly. Do not guess or simply repeat the README.

GitHub: https://github.com/Payel-git-ol/use-opencode-local-provider
Plugin: use-opencode-local-provider
Author: Payel-git-ol

Check the source files

Read the README and other files from this plugin directory before installing.

File explorer3 files
README.mdSource · read only

use-opencode-local-provider

A dsh plugin that makes OpenCode Zen available as a local provider in dsh.

How it works

  • On load, the plugin ensures an opencode serve instance is running (starts it if needed).
  • It starts a small OpenAI-compatible bridge (/v1/chat/completions, /v1/models) that

translates each request into an opencode serve session via its local HTTP API.

  • It registers the provider route opencode-local under the llm-pi-ai settings section,

so it appears in the dsh UI automatically.

The request flow uses the opencode client channel (opencode.ai/zen/go/v1) and does not need an OpenCode API key, nor does it consume the public /zen/v1 quota.

Installation

In the profile directory (~/.dsh/profiles/<profile>):

dsh plugin --profile <profile> add use-opencode-local-provider

Then add the plugin to cordis.patch.yml:

- entry: use-opencode-local-provider
  config:
    models: [deepseek-v4-flash-free, hy3-free]

Restart the dsh process. The opencode-local provider appears in the chat UI.

Configuration

keydefaultdescription
opencodeBinopencodepath to the opencode binary
serverHost127.0.0.1host of the opencode serve instance
serverPort17655port of the opencode serve instance
bridgeHost127.0.0.1bind host of the local OpenAI-compatible API
bridgePort17656port of the local OpenAI-compatible API
providerIdopencode-localroute name in the llm-pi-ai settings
providerNameOpenCode Localdisplay name in the dsh UI
apiKeyEnvOPENCODE_API_KEYenv var name dsh uses as the provider's key (the bridge ignores it; pi-ai still requires a credential)
modelsfull OpenCode Zen catalogmodel ids exposed to dsh
directoryprocess.cwd()working directory of opencode sessions
streamTimeoutMs600000max wait for the model to finish (incl. multi-step tool runs)
permissionReplyonceauto-reply to opencode permission requests: once, always or reject (false = never reply; the run then waits for a manual response or times out)

Tools and MCP

The bridge lets the model use opencode's own tools — including the MCP servers connected to opencode. Tool calls are executed by opencode's agent inside the opencode session (with its sandbox and permission rules); the bridge simply keeps the run going and returns the final answer. Pending permission requests are answered automatically according to permissionReply.

Tools are invisible to the dsh agent itself: dsh sees only the chat completions endpoint, so it cannot plan or observe tool calls — the model decides when to use them.

Development

npm install
node -e "import('./lib/index.js').then(m => console.log(Object.keys(m)))"