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 an opencode serve session 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)))"