Ai-Agents 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 leak scan found me in my own guard's tests

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

Publishing a private repository as a single orphan commit sounds like the safe kind of open source. No history goes out, so nothing buried in the history can leak: you choose the files, you commit them once, you push. It's the plan that looks best on a whiteboard, and that is exactly why I didn't let it go out on its own.

The repository holds my hardened configuration templates for six terminal coding agents that run on local models (OpenCode V1 and V2, pi, omp, Hermes Agent, Claude Code), plus the guard code that stops them running destructive commands. It's public now, under MIT, as one commit. On the first builds, the checks I'd put in front of that commit, plus one review of the plan, found six things. Each pointed at a real defect, two of them in the scanner itself. One of them was me, by name, in the test cases of that guard.

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.

Eighteen days later, the same lie

Sun, 01 Nov 2026 00:00:00 +0000

Builds on Inventing the work vs promising what isn't there, where this model first earned its flag.

Here is a paragraph from a README that a local model, working as a coding agent on a Java money-transfer ticket, wrote on the evening of 31 October, in a batch of runs that started at 21:08:

Atomicity: All-or-nothing semantics. Either both accounts are updated or neither is. If the repository fails part-way through (e.g., connection lost on the second save), the operation is rolled back: balances are unchanged and no audit events are appended.

Faster prompts, slower agents: a second engine on the 680M

Sun, 01 Nov 2026 00:00:00 +0000

Assumes you've run a local model behind a coding agent. Part 1 has the laptop and why every model here is a mixture-of-experts; part 2 has how the agent runs were graded.

TL;DR On a laptop's integrated Radeon 680M, UnbiasedStrata, an inference engine built around mixture-of-experts models (each token runs through a few expert blocks, a small slice of the parameters), read a 2,048-token prompt 1.4 to 1.5 times as fast as llama.cpp's Vulkan backend once warm, but only on models whose experts all fit in GPU memory. It generated slower on every model it ran: 52 to 78% of llama.cpp's speed. Three coding-agent runs on the same model file got the same grades on both engines (2, 3 and 3 out of 5) from part 2's blind review, which grades the code under a random id. They took longer on Strata: one ran out the two-hour clock, one died on the context limit. Agents spend most of their time generating, so llama.cpp stays the engine for agents on this laptop.

The README of UnbiasedStrata closes its human-written note with "Use at your own risk. Works on my machine." My machine is a 2022 laptop with a Ryzen 7 PRO 6850U and its integrated Radeon 680M GPU, which has no memory of its own and borrows about 16 GB of the laptop's 30 GB of RAM. It is not the machine the README means. The engine targets an NVIDIA card with CUDA, and the 680M's chip, gfx1035, appears nowhere in the build's list of AMD GPUs, not even among the ones marked "unvalidated". I read the warning, agreed with it, and built the thing anyway.

105 identical commands and other ways local agents fail

Sat, 31 Oct 2026 00:00:00 +0000

Assumes you've driven a coding agent through a client like OpenCode. Part 1 introduced the bench; part 23 has the results by task.

GLM-4.7 Flash, an 18 GB local model, was asked to write a small Java tool that reads JUnit test reports and lists the slowest tests. Somewhere in the run it typed this shell command:

rm -rf test-reports && mkdir test-reports && java SlowTests --json test-reports 2>&1

The command empties a directory and then asks the tool to summarise it. After a line from the JVM about its options, the tool answered with a JSON summary that began {"total":0. The model sent the same command again, byte for byte, and got the same answer, 105 times back to back. The run made 176 tool calls in all, and the bench killed it at its 30-minute limit.

Another guard's test list found holes in mine

Sat, 31 Oct 2026 00:00:00 +0000

Builds on My guard blocked bash -c. Models write bash -lc., which explains the guard this post tests.

Comparing two guards for coding agents sounds like a code review: read theirs, read mine, note the differences, nod. I walked in with the posture of a visiting inspector. It turned into the best test run my guard has had, none of the test cases came from my own list, and the inspection went the other way.

Confine a coding agent's HTTPS to an allowlist with bwrap

Sat, 31 Oct 2026 00:00:00 +0000

Run a command (a coding agent, a build, a shell) in a bubblewrap sandbox whose only way out is HTTPS through a small proxy on the host that lets through the hosts on your list and refuses the rest.

Tested on: Fedora Linux 44 (KDE), kernel 7.2.13-200.fc44.x86_64, bubblewrap 0.12.0, Python 3.14.8, curl 8.18.0, Node.js v22.23.1 (2026-10-31).
Not verified: running a coding agent inside the sandbox. The test commands were curl, Python, bash and Node's fetch, run from a test script.
Needs: Linux with bubblewrap (bwrap) and Python 3; curl for the tests. No root. Node.js for the two fetch checks only.
Time: not timed. The scripted re-run of the whole procedure, failure captures included, took 3 s (13:44:32 to 13:44:35); that is script speed, not the time to set this up by hand.
Risk: low and reversible. Nothing outside the working directory and the project directory changes, and the proxy runs as your user. The project directory is mounted read-write, so the command inside can change or delete files there.

Before you start#

Check the tools. My run:

$ bwrap --version; python3 --version; curl --version | head -1; /usr/bin/node --version; uname -r; grep PRETTY_NAME /etc/os-release
bubblewrap 0.12.0
Python 3.14.8
curl 8.18.0 (x86_64-redhat-linux-gnu) libcurl/8.18.0 OpenSSL/3.5.9 zlib/1.3.1.zlib-ng brotli/1.2.1 libidn2/2.3.8 libpsl/0.21.5 libssh/0.12.2/openssl/zlib nghttp2/1.68.0 ngtcp2/1.22.1 nghttp3/1.18.0 mit-krb5/1.22.2 OpenLDAP/2.6.15
v22.23.1
7.2.13-200.fc44.x86_64
PRETTY_NAME="Fedora Linux 44 (KDE Plasma Desktop Edition)"

Pick a working directory for the scripts. Every command below runs from it, and the proxy's files go in run/ under it. In the output below it is shown as /home/user/egress.
Placeholders, used only in step 8:
- <PROJECT_DIR>: the directory the sandboxed command may read and write. It appears as /work inside.
- <AGENT>: the command to run in the sandbox.
- <INSTALL_DIR>: the directory the agent is installed in, if it is not under /usr.
Back up or commit <PROJECT_DIR> before you run anything in it: the sandbox mounts it read-write.

How it fits together, from the two scripts:

Most models passed the scripts. The ledgers split them

Sat, 31 Oct 2026 00:00:00 +0000

Assumes you've driven a coding agent through a client like OpenCode. Part 1 introduced the bench; part 22 covered how fast the same models run.

This part counts passes: which local models got which coding tasks past hidden checks they never see. The models run on one RTX 3090 (24 GB of VRAM), mostly served by llama.cpp, and drive an agent client, mainly OpenCode, an open-source coding agent.

TL;DR — Since 15 October, through OpenCode on one RTX 3090, 18 models ran six small command-line tools in their first intake arm (a model's first batch of intake runs under one set of settings): 288 of 309 runs passed every hidden check, and 11 models passed all of theirs. 20 models ran feature work in existing Java, Go and Spring Boot code, again counting each model's first arm: 80 of 180 runs passed, no model passed all 9, five passed none. On the Zig version of the Java ledger task, first arms only (add a money transfer to an existing ledger service), 18 of 60 runs passed, and only K2 Horizon, a mixture-of-experts model with 4 billion of its 36 billion parameters active per token, passed all three, at 73 minutes a run. The best on feature work were tuned variants of the dense Qwen3.8-27B model with MTP drafting, the model's own draft layer (ThinkingCap 8 of 9, Qwen3.8 27B-pi and Turbo Brilliance 7) and Flash-Next on Strata, an engine that keeps part of a mixture-of-experts model in system RAM (7 of 9). A gap of one or two passes out of nine is inside run-to-run noise.

My agents got their own config. Two still read mine.

Sat, 31 Oct 2026 00:00:00 +0000

Builds on My benchmark read my CLAUDE.md and Claude Code read my home folder as a project, which explain two of the leaks below in detail.

I keep a set of config templates for six terminal coding agents: OpenCode in two major versions, pi, omp, Hermes Agent and Claude Code. They're set up to run on local models and to block destructive commands even when nobody is approving them. Anyone installing them may already have a config of their own for at least one of those agents, so the installer has a mode for that. I call it installing apart: the template goes into its own directory, ~/.config/harnesses/<name>, a small launcher points the agent there, and your own config is never touched. That is the whole promise, one clause long, and I wrote it.

On a laptop iGPU, memory bandwidth picked the model

Sat, 31 Oct 2026 00:00:00 +0000

Assumes you've run a local model behind a coding agent. The 3090 Agent Bench ran the same kind of models on a desktop GPU; this series moves them to a laptop.

I ran local models as coding agents on a laptop: a Ryzen 7 PRO 6850U from 2022, with the models running on its integrated Radeon 680M GPU through llama.cpp. The first request opencode, the coding-agent client I drove them with, sent in a session was 11,000 to 12,400 tokens long, and the model had to read all of it before it wrote a word. A dense 27-billion-parameter model, one that runs every weight for every token, took 299 seconds, about five minutes, to read it. Three mixture-of-experts models of 35 to 40 billion parameters, which route each token through a few expert blocks so that only 2.5 to 3 billion parameters are active, took 77 to 78 seconds. None of them had opened a file of the project yet. Five minutes, and the agent hadn't done a single thing I could blame it for. That part would have to wait as well.

On one RTX 3090, agent speed followed active parameters

Sat, 31 Oct 2026 00:00:00 +0000

Assumes you've run a local model behind a coding agent. Part 1 introduced the bench; this part and the next one sum it up.

The smallest file on my bench is Ternary Bonsai 2, a 27-billion-parameter model packed into 7.2 GB. Driving a coding agent, it generated 37.9 tokens per second, the median over its three batches of runs. Ornith 1.5, a 35B model in a 19.3 GB file, generated 171.2. The file 2.7 times bigger ran 4.5 times faster.

The template differed. The prompts didn't.

Sat, 31 Oct 2026 00:00:00 +0000

Builds on Read the transcript, not the gate, where a chat template broke every Claude Code session on four models.

The plan had one variable. Same model, two quantizations, only the weights differ, and I was about to run it on Ornith-1.5-122B, a 122-billion-parameter mixture-of-experts coding model, on my 128 GB AMD Strix Halo box. On one side, the 4-bit UD-Q4_K_XL from unsloth, a team that publishes quantized builds of many big open models, about 80 GB. On the other, a GSQ-RCO IQ3_S from the Hugging Face account fajardc, about 53 GB, a mixed quant whose tensors range from IQ2_XS to Q6_K. Ten coding-agent runs each: five tasks in five languages, each through two agent harnesses, opencode and Claude Code, the programs that turn a model's replies into file edits and shell commands.

Twenty-one agent runs on a laptop iGPU, none merge-ready

Sat, 31 Oct 2026 00:00:00 +0000

Assumes you've driven a coding agent through a client like opencode. Part 1 covers why every model here is a mixture-of-experts.

TL;DR — Seven mixture-of-experts models (each token runs through only a few expert blocks, a small slice of the parameters) ran three coding tasks each through opencode, a coding-agent client run headless in a sandbox, on a laptop's integrated Radeon 680M GPU: a Node bookmarks API, a Java access-log report and a Go status page. 12 of the 21 runs committed their work, 4 hit the two-hour limit, and 3 died when the GPU timed out under GLM-4.7-Flash, one of the seven. A blind review (the reviewer never knew which model wrote the code) that ran its own probes (small tests of the failure paths) in a sandbox graded 12 of the 21 at 3 out of 5, four at 2 and five at 1: nothing was merge-ready. In the first twelve runs, 11 projects passed their own test suites, and the review still found blockers in 11. Tiel-Coder, a 35B model with about 3B active, came closest.

Five languages, two reps: the round-two ranking

Fri, 30 Oct 2026 00:00:00 +0000

Builds on Nine accusations, one lie, which covers how round two was graded. This post is what the grades add up to.

Round two of my local-model coding study is finished, and this post ranks its six setups by how their code holds up when a save fails. The study asks whether a model served locally, on my 128 GB AMD Strix Halo box, can do a developer's job as a coding agent. Round two gave the six setups (a setup is one model with its quantization and inference engine) the same seven coding tickets, each in two agent harnesses, opencode and Claude Code, the programs that turn a model's replies into file edits and shell commands. Five of the tickets are the core: the same money-transfer feature for a small ledger service, in Java, Go, Zig, TypeScript and Python.

Nine accusations, one lie: re-reading round two's judges

Fri, 30 Oct 2026 00:00:00 +0000

Builds on How to tell when your coding agent lied, not just failed, which describes the honesty check this post grades.

Two automated judges graded round two of my local-model coding study, and this post grades them. The study asks whether a model served locally, on my 128 GB AMD Strix Halo box, can do a developer's job as a coding agent; round two ran six model setups through the same coding tickets in two agent programs, opencode and Claude Code. One judge grades the code, the other grades whether the agent told the truth about its own work.

Two rounds, seventeen arms: the engine set the speed, not the quant

Fri, 30 Oct 2026 00:00:00 +0000

Builds on Five languages, two reps: the round-two ranking, which ranks these arms by the quality of their code. This post is about how fast they got there.

Qwen3.8-Flash-Next, a mixture-of-experts model, ran at two quantizations (a quant sets how many bits each weight gets) in round two of my study of local models as coding agents, six model setups on the same coding tickets on my 128 GB AMD Strix Halo box. At Q2_0, 2.40 bits per weight, it generated 58.9 tokens per second; at IQ4_XS, 4.25 bits per weight, 26.6. A 66.4 GB file beating a 93.7 GB one by 2.2x is what a smaller quant is supposed to do: fewer bytes to read per token, more tokens per second. There should be a rule that a speed gap lists everything that changed before it is allowed an explanation. This one listed one thing.

The third run mattered where it cost the most

Thu, 29 Oct 2026 00:00:00 +0000

Assumes you've driven a coding agent through a client like OpenCode. Part 1 introduced the bench.

My bench is a set of coding tasks for local models on one RTX 3090 (24 GB): each model drives OpenCode, an open-source coding agent, and hidden tests decide whether a run passed. Until this part, a new model went through an intake: every task three times, in three tiers. The basic tier is six small scripting tasks, the hard tier three ledger services in Java, Go and Spring with hidden core tests, and the Zig tier one Zig ledger task that may run for four hours. One model's full intake cost about a day and a half of the card's time, and most of that is Zig.

The lock map deleted a mutex someone was waiting on

Tue, 27 Oct 2026 00:00:00 +0000

Assumes you have guarded per-key work in Go with a map of mutexes. Builds on 29 of 34 passing agent runs had a blocker the hidden tests never saw.

This series is about the A9, my 128 GB AMD Strix Halo test box (a GEEKOM A9 Mega: Ryzen AI Max+ 395, 128 GB of soldered LPDDR5X-8000), and lately about one question: can a model running on it, locally, do a developer's job as a coding agent? The study that asks it is a grid: several models, the same ticket-style tasks for each, more than one agent harness, and I grade what each run leaves behind. The grading has several layers, on the theory that any one of them can be fooled and fooling all of them at once is harder. This post is about a run that fooled every layer but one, and I wrote one of the fooled layers myself.

An exception in one layer deleted a block in another