Bundle
use-opencode-local-provider
Use the opencode local server (OpenCode Zen client channel) as a provider in dsh
- Source
- Payel-git-ol
- License
- MIT
- Updated
- Updated 2 days ago
Readme
# use-opencode-local-provider
A [dsh](https://github.com/deepseek-ai/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>`):
```bash
dsh plugin --profile <profile> add use-opencode-local-provider
```
Then add the plugin to `cordis.patch.yml`:
```yaml
- 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
```bash
npm install
node -e "import('./lib/index.js').then(m => console.log(Object.keys(m)))"
```Install
dsh plugin --profile web add github:Payel-git-ol/use-opencode-local-provider
Profile: web
With the hub plugin installed, ask your agent to install it by name — it resolves the same plan shown here.
dsh plugin --profile web add github:stvlynn/dsh.fish#path:packages/dsh-plugin-hub
install use-opencode-local-provider from the hub
- This source has no pinned commit, so a later push upstream changes what installs. Prefer pinning a commit.