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 serveinstance is running (starts it if needed). - It starts a small OpenAI-compatible bridge (
/v1/chat/completions,/v1/models) that
translates each request into anopencode servesession via its local HTTP API. - It registers the provider route
opencode-localunder thellm-pi-aisettings 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-providerThen 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)))"