92 Days of Writing OSS Alone, and I Received My First External Code Contribution — CodeRouter v2.9.4, and the Story of Fixing a KV Cache Corruption I Never Noticed

Synopsis — This is the 36th installment.

The first commit was on 2026-04-19. The work date for this article is 2026-07-19, which is the 92nd day since the first commit. The previous installment (Part 35) was v2.9.1 on 07-12.

• Parts 1–9 (v1.8 → v2.2): "It works" → "It doesn't break" → "It fixes itself when it breaks"

• Parts 10–21 (v2.3 → v2.6.0): Plugin SDK / Launcher / Handling upstream accidents with filters

• Parts 22–26 (v2.7.0 → v2.7.6): Auditing 26,656 lines with an AI review squad / Measuring empty response fallbacks / MTP support

• Parts 27–31 (v2.7.7 → v2.9.0): Moving external agents to the backend / Extracting agent_cli into a plugin

• Parts 32–35 (up to v2.9.1): Sub-agent E2E / Fixing grok empty responses / Self-implementing automatic model swapping in the launcher

• Part 36 (This article, v2.9.4): On the 92nd day, I received my first external code contribution

The underlying theme has always been "It should work on my desk → The actual hardware betrays me → I fix it." This time, for the first time, eyes other than my own are involved.

A notification arrived

There was an unfamiliar username in my GitHub notifications. A Pull Request from `firelzrd`. For 92 days, CodeRouter had been a repository where the only authors were myself and an automation bot. Then, a PR appeared from an external fork.

The title is `fix(translation): keep mid-conversation system messages in place`. Mr. firelzrd is the author of the Linux BORE CPU scheduler and is widely known in the custom kernel community. The change involved 2 files, +76 −18, and 1 commit. Before reading the content, the fact that someone from the outside had reached out to help with something I had been building alone hit me harder.

What was fixed was a hole I hadn't noticed myself

Since version 2.1.154, the Claude Code CLI has been inserting `role:"system"` messages (system-reminder) into `messages[]` in the middle of conversations. This behavior is a regression that has been reported multiple times in issues for vllm and the official claude-code. The translation layer of CodeRouter was hoisting these mid-conversation system messages to the top-level `system` field.

Here is the problem. The system-reminder changes its content every turn. Moving it to the beginning means the start of the prompt changes every time. Since the prefix cache in llama.cpp and LM Studio works by "recalculating only from the longest common prefix onwards," changing the beginning effectively causes everything to be reprocessed. According to the PR author's measurements (LM Studio + Qwen3.6-35B, Claude Code 2.1.211), only 11.8% of the prefix could be reused, and 242,419 characters were being recalculated every time. The author had already isolated the issue: if connected directly to the raw Anthropic API, the system message remains constant — the culprit was the conversion on the CodeRouter side.

The fix was clean. It branches based on position in `normalize_message_roles()`, hoisting the initial system message as before, while converting mid-conversation system messages that appear after a turn starts into `role:"user"` in place without moving them. As long as the beginning doesn't change, the cache is preserved.

I reviewed it, merged it, and left one piece of homework

I don't take code from the outside at face value. I followed my usual routine: I had one Opus instance read it thoroughly as if to break it, and ran tests in three states: base, after PR application, and after merge.

My findings were 1 Medium and 2 Low issues. The Medium issue was an edge case where converting a mid-conversation system message to a user message could break block handling when `tool_use` and `tool_result` are adjacent, which wasn't covered by tests. While it doesn't break the core fix under rare conditions, the lack of tests is a fact. So, I decided to leave it as homework.

For a first-time contributor's PR, branch protection requires approval to run workflows. I went through the flow of approval → CI green → merge for the first time with someone else's code. The merge commit is `91b2687`, and the total tests after merging were 1905 passed. Looking at the entire git history, this is the only author who is neither the owner nor a bot — this was the first time code arrived from an external person.

On the same day, what I was building on my side

Coincidentally, on the same day I was reviewing this PR, I was building Launcher device selection. It detects devices with `--list-devices`, lets the user choose via checkboxes with VRAM info, and generates `--device` and `--tensor-split` (automatically suggesting a ratio of 0.57, 0.43 for a 5090 + 3090 setup). I added it to both the GUI and Web interfaces, and extracted the common logic into a new module, `launcher_devices.py`. If nothing is selected, the generated command is byte-for-byte identical to the previous version.

The actual hardware showed a face not found in the official documentation. When I build for both CUDA and Vulkan on my Linux machine (RTX 5090 + RTX 3090), `--list-devices` returns 5 devices. CUDA0=5090, CUDA1=3090, Vulkan0=3090, Vulkan1=5090, and Vulkan2 is the iGPU Radeon — the same physical GPU is listed twice, and even the numbering correspondence is reversed. This is an observation from my own machine. On Mac (M3 Max), `BLAS: Accelerate` shows up as 0 MiB, so I excluded devices with 0 MiB. The launcher-related tests increased from 246 to 372.

Bench sweep (beta) and two consecutive CVEs

I also added bench sweep (beta). It's a mechanism that runs a list of configurations in the order of startup → readiness → external bench → shutdown. The measurement itself is delegated to my separate custom tool llmbench (`zephel01/swe-bench`), and the launcher just provides the framework to run them. It's still in beta.

A small note: cve-audit turned red in the CI immediately after merging. click 8.3.2's PYSEC-2026-2132 (fixed in 8.3.3) was detected by pip-audit (PyPA DB). When I upgraded click to 8.4.2, OSV-Scanner then picked up json-repair 0.59.10's GHSA-xf7x-x43h-rpqh (CVSS 7.5, fixed in 0.60.1) — this one was missed by pip-audit (not mirrored in PyPA). Thanks to having a multi-layered scan with pip-audit and OSV, one caught what the other missed. I raised the json-repair lower bound to `>=0.60.1`, and even after the fix, it was 1905 passed.

Summary

For 92 days, I've been writing this alone. I've talked about "hiring" reviewers (Episode 22), but they were all agents under my command. This time is different — someone completely from the outside fixed a hole I couldn't see with their code. And it was in the most subtle yet effective part of local LLMs — prompt cache reuse rate. What I will remember most about v2.9.4 is undoubtedly this one PR that arrived.

How would you record the day you received your first external code contribution to an OSS you're building alone? When welcoming an external contributor, how would you decide the temperature of the review — how much to have them fix and what to leave as homework? Please let me know in the comments.

CodeRouter is an MIT-licensed OSS: https://github.com/zephel01/CodeRouter
You can run it with `pip install coderouter-cli` / `uvx coderouter-cli serve`.

#CodeRouter #LocalLLM #llamacpp #LMStudio #OSS #IndieDev #ClaudeCode #KVCache #PromptCache #OSSContribution