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

key	default	description
opencodeBin	opencode	path to the opencode binary
serverHost	127.0.0.1	host of the opencode serve instance
serverPort	17655	port of the opencode serve instance
bridgeHost	127.0.0.1	bind host of the local OpenAI-compatible API
bridgePort	17656	port of the local OpenAI-compatible API
providerId	opencode-local	route name in the llm-pi-ai settings
providerName	OpenCode Local	display name in the dsh UI
apiKeyEnv	OPENCODE_API_KEY	env var name dsh uses as the provider's key (the bridge ignores it; pi-ai still requires a credential)
models	full OpenCode Zen catalog	model ids exposed to dsh
directory	process.cwd()	working directory of opencode sessions
streamTimeoutMs	600000	max wait for the model to finish (incl. multi-step tool runs)
permissionReply	once	auto-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)))"