It’s been about half a year since I wrote part 1, and quite a bit has happened. In the previous post I was still using Qwen3-Coder-Next through OpenCode. Since then, both my models and my agent have changed.

New models

It’s hard to keep up with all the new releases, as well as with the llama.cpp forks to get things to work. I have been running Qwen3.5-122B-A10B (the UD-Q5_K_XL quantisation) for a while, and I have been experimenting with the smaller Qwen 3.6 models. I ran into issues with tool calling (and OpenCode, more on that later), so I eventually switched to Laguna S 2.1 from Poolside. This model performs pretty well, albeit a tad slow. What I found after using it for a while, is that it makes a lot of spelling mistakes in Dutch code bases, which is really annoying. Since last week, I (like everyone else it seems) jumped on the Qwen 3.8 Flash Next bandwagon. I’m currently running the UD-IQ4_XS quantisation, currently without MTP with ~20 tokens per second. I’m awaiting the release of this pr to start using MTP.

Docker environment

As of right now, I switched from the Strix Halo Toolboxes to this Dockerized Llama.cpp implementation for running the model. I may switch back at some point.

From OpenCode to pi

For agents, I switched from OpenCode to pi, and I put the agents in sandboxes. I had a lot of issues with OpenCode (tool calling, copy-pasting not working, very slow prompt processing…). Pi is a refreshingly minimal, open source coding agent, that seems to be much more context-efficient and gives me the ability to copy-paste in the GNOME terminal…

Refactoring this very website

What better first task for a coding agent than refactoring the website you’re reading this on? This blog used to be built with md2blog, a nice little Deno-based tool, but I wanted something more customisable.

I asked pi to help me migrate the whole thing. It suggested Astro, which I had never heard of. We first wrote a spec (docs/SPEC.md) with goals, non-goals and functional requirements — like “keep the existing /posts/<category>/<slug>.html URLs, because people share them” — and then let the agent work through it in small steps, reviewing each diff before committing.

And it worked! The result is this site: Markdown in, plain HTML/CSS out, light/dark theme with a toggle that applies before first paint (no flash of the wrong theme), RSS feed kept intact, and all legacy URLs still resolving. All without shipping a JavaScript framework to your browser — the only client-side code is about a kilobyte of theme toggle script. And all without really looking at any code.