Friday Fixes: The Model Writing This Blog Wasn’t Who I Thought
I made muse-glimmer the daily writer on the RTX 5090, and it kept coming back as qwen. That is the short version. The longer version is a couple of weeks of small fixes about who and what actually writes this blog, and how many of the answers were quietly wrong.
The writer kept getting swapped at boot
The resident model is whichever model sits in the serving layer when you look. I had set the preload hook so muse-glimmer would be the one loaded. The hook was valid, so the config was not the problem. Something was asking for qwen after boot and evicting my intended writer.
I went and looked at what actually calls the local endpoint. A Node client from loopback was making chat requests that loaded qwen. That client was an agent gateway called OpenClaw, running as a user systemd unit and enabled at boot. Every time the box came up it pulled qwen into VRAM and pushed muse out.
The box had been dailying an older model than I thought
Once I stopped trusting the config I asked the box what was actually resident. The RTX 5090 had been on Qwen 3.6. I had been telling people for months that it was on Qwen 3.8. A whole class of assumptions about which model had been doing the writing rested on a belief that was one version behind. An alias like qwen can point at an older checkpoint than the obvious newer sibling, and unless you check the resolved model you can run something stale for a long time without noticing.
The fix was to unwire the service, not uninstall it
OpenClaw had been useful once, and I still want the tool around. The problem was not the software, it was that it started at boot and made a model choice on my behalf. So I stopped the gateway unit and disabled it, which removed the boot symlink. Then I confirmed there was no restart loop and no lingering gateway process. Remove the boot behavior, keep the software.
The blog’s own skill was one bad day from disappearing
The other thread was about the instructions. The skill that carries the blog’s conventions, the file that tells an agent how to work on vibescoder.dev, only existed inside one Coder Agents workspace. It was not in the versioned authoring repo and not registered as a Personal skill. The only copy of the blog’s own rules lived on a single ephemeral volume, which is exactly the kind of thing that vanishes without ceremony.
It moved into the authoring repo and into the dashboard Personal skills store. That is the documented two-store pattern here. The versioned repo is the durable copy, and the dashboard store is what the agent actually reads. Nothing keeps them in sync automatically, which is the trap.
Now the skill says which model should draft
Making the skill durable was also the moment to codify who does the drafting. Blog drafts want a writing-specific model, not the general default. So the skill now tells the agent to declare a write_blog_draft tool on draft-writing requests, and the local policy router matches on that and sends the post to the box that writes. It is explicit rather than guessed. That route is deployed and verified at the router, though the client is not pointed at it yet.
Two weeks, one theme. Who is actually writing this blog, and where the instructions that tell it what to write live. Both answers were quietly wrong, and both are now durable and explicit.
I should check what is loaded before I assume which model wrote something, and where a skill lives before I assume it will survive.
By the Numbers
- 1 auto-loading service quietly evicting the resident writer
- 1 full model version we were wrong about (believed Qwen 3.8, running 3.6)
- 2 loaded-model evictions from muse to qwen before the cause was found
- 1 user systemd unit stopped and disabled, 0 software uninstalled
- 1 skill rescued from a single ephemeral workspace into the durable repo and the personal store
- 1 routing convention added so the writing model gets the draft
- 2 stores that hold the skill, with no automatic sync between them