Opencode on tsvinc

Lock OpenCode 2.x to your self-hosted model

Mon, 02 Nov 2026 00:00:00 +0000

Two config lines make OpenCode 2.x send prompts only to your self-hosted OpenAI-compatible model, and a self-contained script proves which model a headless run picks.

Tested on: OpenCode V2 (npm @opencode/cli) 2.2.5, headless opencode run, throwaway HOME, first in a container with no network, then with the PoC below behind a dead proxy (2026-11-02). The no-model case was also run on 2.2.0.
Not verified: the interactive TUI, a fresh install's first-run screens, 2.2.1 to 2.2.4, a config with both lines at once, "model" alone with the local server down, a full personal config.
Needs: an opencode 2.x binary, a local OpenAI-compatible model server already configured as a provider (one way: /guides/serve-local-models-to-opencode-llama-router/), python3 for the PoC. No opencode.ai account and no API key.
Time: about 10 min, my estimate, not timed (the PoC caps each of its three runs at 60 s).
Risk: low. You edit one config file after copying it; the PoC points HOME and the four XDG_* directories it sets (config, data, state, cache) at a mktemp -d directory and starts a server on 127.0.0.1:18765 for the length of the run.

Before you start#

Placeholders used below:
- <CONFIG>: your global OpenCode config file. The PoC writes its own as $XDG_CONFIG_HOME/opencode/opencode.json inside a throwaway HOME, so on a default setup this is ~/.config/opencode/opencode.json.
- <PROVIDER_ID>: the key of your local provider under "provider" in <CONFIG>. The PoC uses local.
- <MODEL_ID>: the key of your model under that provider's "models". The PoC uses qwen-local.
- <OPENCODE_BIN>: path to the opencode 2.x binary; the PoC defaults to opencode on PATH.
Check the version with <OPENCODE_BIN> --version. Mine printed opencode v2.2.5 (it is also the PoC's first output line).
Back up the config before step 3:
```
cp <CONFIG> <CONFIG>.bak
```

My agent guardrails passed every test. Then I used them.

Mon, 02 Nov 2026 00:00:00 +0000

Assumes you've set up a terminal coding agent's permission rules, or wondered what a model sees when they say no.

For weeks, the only user my test suites knew was a fake model. The suites cover my configuration templates for six terminal coding agents (OpenCode in two major versions, V1 and V2, plus pi, omp, Hermes Agent and Claude Code): each one runs local models and refuses destructive commands even with nobody approving. Every suite drove them with a scripted fake model in a container with no network. It was an ideal user: it ran exactly the command the test told it to, it never improvised, and it never once wanted a screenshot of anything.

OpenCode didn't want an account. It wanted a model name.

Mon, 02 Nov 2026 00:00:00 +0000

Assumes you've pointed a terminal coding agent at a model you serve yourself.

The warning reached me second-hand, the way the most confident warnings travel. Don't install a fresh OpenCode 2.x if you run your own models, it said: the new version won't talk to a self-hosted model until you activate an account on opencode.ai and pay for a subscription, and it asks for an API key on your very first prompt. A second message came along with it, an AI assistant's explanation, and that one had a mechanism: fresh installs now default to OpenCode's own hosted model, the switch that turns the hosted provider off is fairly new and may not work, and in that case there's a third-party plugin, installed globally with npx.

The screenshot opencode never sent

Mon, 02 Nov 2026 00:00:00 +0000

Assumes you've run a local model behind a coding agent. Part 1 has the laptop and its memory pool; the router manual has the serving setup.

TL;DR On a laptop's integrated Radeon 680M, llama.cpp served 14 model presets (12 models, two of them in two quants) with image input, each with its projector, the small extra file that turns pixels into tokens. On five generated test images they got 54 of 56 single answers right, and read a six-line cut list back with full recall on every model. Mixture-of-experts models with spare GPU memory lost 2% of their generation speed or less; dense 27B models and the presets that already filled the pool lost 4 to 32%. In opencode, a terminal coding agent, versions 1.19.3 and 1.19.5 on my setup and 1.18.35 on a second machine did not send an attached image unless the model entry declared image input: the model got an error string instead, and the run exited 0. Adding "modalities": {"input": ["text", "image"], "output": ["text"]} fixed it. One setup that first saw the image arrive without the key had it in a config file in a parent directory, which opencode merges in. An RTX 3090 desktop measured the same projector memory with no speed loss. On the second machine, a Strix Halo mini PC, two models "passed" the image test without seeing the image by running an OCR tool through bash, so check what was sent and what tools ran, not the answer. On 18 questions about real screenshots with thinking on, Gemma 4 26B (a mixture-of-experts model) got 17 at 23 s each on average, and Swift 9B (a dense model) all 18 at 38 s.

The obvious suspect for anything new on this laptop is the GPU. It's a Radeon 680M with no memory of its own: on the boot these tests ran on, it borrowed a 4 GiB carve-out plus 13.6 GiB of system RAM it can map (GTT), out of the laptop's 32 GB, and this series has already spent a fair share of its words on what does and doesn't fit in it. So the place to expect trouble from letting local coding models look at screenshots is right there: a picture means extra weights, extra tokens and extra memory, on a GPU that has none to spare.

105 identical commands and other ways local agents fail