I wanted to try Qwen 3.8 Flash Next, a 177B MoE model, on the same RTX 3060 used in Part 1. Its quantized weights occupy 76.3 GiB, and my machine has 12 GB of VRAM and 32 GB of system RAM.
The first launch froze my desktop. Getting it working required changing how the server loaded the weights.
I used the UD-IQ3_XXS quantization and GenerelSchwerz’s llama-moe-cache branch to test GPU expert caching with weights backed by NVMe storage.
This is Part 2 of a three-part series on running, benchmarking, and scaling local coding agents. Part 1 covers the local Qwen setup; Part 3 explores running a larger MoE model on the same desktop hardware.
In Part 1, I got Qwen 3.6 35B A3B NVFP4 running locally on an RTX 3060 with a 64k context window and wired it into Crush, Pi, and Oh My Pi. I wanted to know how that setup compared with the terminal coding agents I already had on subscriptions. Could it finish the same tasks, and would I want to merge the patches?
[Read More]This is Part 1 of a three-part series on running, benchmarking, and scaling local coding agents. In Part 2, we benchmark this setup across 640 public trials and 280 private trials on a production Go monorepo, including Claude Code, Codex, Antigravity, local Qwen, and two hosted models. In Part 3, we build and test the specialized llama-moe-cache fork to run 177B Qwen3.8-Flash-Next on desktop hardware.
I wanted a capable local reasoning model for coding agents on my workstation, but my GPU is a standard desktop NVIDIA GeForce RTX 3060 with 12GB VRAM. The weights would not all fit in VRAM, so I needed a setup that could offload them.
[Read More]I use big LLMs to draft blog posts and LinkedIn posts. They help with research and structure, but I still spend time rewriting them to sound like me. Every draft comes out with the same polished, slightly corporate voice, and even after I edit it by hand, something of that voice stays in the text. There is actually research confirming this: a 2026 study on post-editing found that even when humans edit LLM drafts, the result stays measurably closer to LLM style than to the author’s own writing.
[Read More]In [Part 1] I pulled apart two compromises of one codebase by hand – a fake font that ran on folder-open, and a babel.config.js that turned every build into a remote-access trojan. Both, it turns out, belong to a publicly-documented campaign: public reporting attributes that family to a DPRK-linked actor tracked as PolinRider (also Void Dokkaebi). I didn’t prove that myself – my analysis was static – but the shared Tron dead-drop, the commit-spoofing tool, and the 166.88.54.158 C2 line up with what Trend Micro and others have published.
I gave a talk recently about the state of software supply-chain attacks, and afterwards people kept coming back to the two compromises I’d pulled apart by hand, more than to any of the industry-wide numbers. This post is the written version of that part. Part 2 will pull back to the wider picture (XZ Utils, tj-actions, Trivy, and what actually helps); this one stays on the two incidents I looked at directly.
[Read More]Our GitHub Actions matrix containers build workflow was always building every container image in our Turborepo monorepo — even if only a few packages had actually changed. This not only resulted in increased build time but also inflated our operational cost. In this post, I’ll will outline how we tackled this issue and implementing a robust solution that leverages Turborepo’s dry-run capabilities and GitHub Actions caching to build Docker images only for the changed packages.
[Read More]Yesterday I encountered a nasty surprise after upgrading Hyprland to version 0.46.2—it crashed on startup, leaving me unable to log into my Wayland session. If you’re experiencing this problem, here’s a temporary workaround so you can keep working until a fix arrives.
Hyprland 0.46.2 appears to crash immediately upon launch, preventing you from getting into your usual tiling window manager environment.
After some further digging, I discovered my Hyprland crash was caused by the AUR hyprutils-git package. I had previously switched to hyprutils-git from the AUR because I was also using hyprpolkitagent-git. Because of this, the entire Hyprland ecosystem ended up depending on the hyprutils-git package, which broke compatibility with the stable release of Hyprland in the last few updates.
[Read More]Hyprland is not just a tiling window manager; it’s a gateway to a highly customized and efficient Linux environment. In this second part of our guide, let’s explore some advanced features for your Hyprland setup.
In the previous part, we’ve covered the basics of setting up and configuring Hyprland. We’ve done a lot of work, and it would be a shame to lose it. So, first, let’s start by saving our configurations using GNU Stow in a GitHub repository.
[Read More]Hyprland is a dynamic tiling window manager built for the modern Wayland display server protocol. This guide, we’ll walk you through the process of setting up Hyprland on your Linux system.
First and foremost, performance and reduced input lag. Wayland is a modern replacement for X11, and it has much cleaner architecture, better application separation, and improved HiDPI hardware support.
So, a tiling window manager, as opposed to a floating window manager, organizes your windows in a non-overlapping, grid-like pattern. It will give you a superhuman ability to fly through your windows and workspaces with hotkeys and improve your productivity.
[Read More]