dsh-llm-opencode-go

The built-in pi-ai adapter inside DeepSeek Harness leaves two practical gaps when talking to OpenCode Go. Go s client matrix requires a stable per-conversation session ID on every request for routing and prompt-cache reuse, and it rejects an unrouteable call with 400 MissingSessionID, something the shared adapter never stamped. The pinned pi-ai release ships a frozen model list, so a model Go releases today is invisible to the harness. dsh-llm-opencode-go promotes OpenCode Go to a first-class model-inference provider: a single route covers every model the Go subscription exposes, dispatching each call over the wire protocol that model actually speaks (openai-completions, openai-responses, or anthropic-messages) and injecting the session headers Go expects on every request.

The model catalog is a three-layer overlay. The base layer is the pinned pi-ai description set; the middle layer holds user-declared entries in settings.yaml that override or add individual model protocols, context windows, reasoning toggles, and input modalities; the top layer is a live refresh triggered on mount, on a configurable interval (default six hours), via the chat command /opencode-refresh, or through a button in the plugin card. A refresh pulls v1/models from the endpoint and enriches descriptions from models.dev, merges new IDs over the pinned set, and re-announces the route so the model picker reloads without a restart. IDs Go advertises but neither source describes are auto-registered with a vendor-prefix protocol guess and can be corrected by hand.

This plugin is aimed at developers who already orchestrate multi-model workflows inside DeepSeek Harness and hold an OpenCode Go subscription. Everything short of the API key lives in settings: endpoint, refresh cadence, per-model protocol, input-modality validation, and reasoning-level toggles. Input validation (for example, image support) fires before the request leaves the process, and reasoning levels can be switched off per model. The Settings to Plugins card handles key storage through the credentials service, endpoint editing, and catalog interrogation, with no build step, no manual route registration, and a developer experience consistent with the Harness-native providers.