Skip to content
dsh.fish
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 3 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

  • This source has no pinned commit, so a later push upstream changes what installs. Prefer pinning a commit.
Source