Version 1.1.0 of Actioneer is out — my native GNOME client for GitHub Actions, written in Rust and GTK4. The headline changes are a redesigned workflow pane, live durations and 14 languages. Along the way I want to tell you about two bugs I found: one had been living in the snap build since its very first release, the other only shows up if you switch your system to Arabic.

One card instead of a nested list

The workflow → runs → jobs → steps accordion was already there — what is new is how it looks. Instead of a nested list it is now a single rounded card with one-pixel separators, a round status dot sized per level (26 pixels for a workflow, 13 for a step), a meta line under the run number carrying branch, actor, duration and time, and the run's buttons (re-run, re-run failed jobs, cancel, open on GitHub) moved into its header. An expanded workflow gained a progress bar with a live done-of-total counter.

The duration of anything currently running is now live: the counter ticks once a second instead of updating once per API poll. A small thing, but without it the interface looks frozen at exactly the moment you are watching it.

The log window changed separately. There was one before and there is one now, but the Logs button used to open a single job's log — the job the app picked for you. It now opens the whole run: the same window, with a sidebar where jobs are one click apart, a ticking counter on the running ones, and a Refresh that re-fetches the job list as well as the log. Logs you have already read stay in memory for as long as the window is open, so going back to a previous job costs nothing.

14 languages, none of which snap was showing

This release adds Italian and Japanese, bringing the count to 14. While I was there I went through every existing catalogue and closed the remaining untranslated strings, restoring dropped diacritics along the way: German umlauts, French and Spanish accents.

Then I installed the snap build to look at the Japanese. It was in English. In every language.

The app looks for its catalogues in $SNAP/usr/share/actioneer/po, and snapcraft.yaml had never copied them there: the Flatpak manifest has that line, the snap simply did not. Translations in the snap build had not worked for a single day, ever since the first release.

The fix is two lines — but noticing it took installing the snap and changing the language. No test catches this: a built package is only ever verified by the person who installed it.

Logs should not flip

Arabic and Urdu turn the interface right-to-left, as they should. The problem is that two places showing machine output turned with it: the job log and the crash report.

A log is not prose. Every line mixes Latin, digits and punctuation, and the bidi algorithm dutifully reorders the segments by rules written for text. The timestamp drifts to the end, the path breaks into pieces. It is unreadable. Both views are now pinned to LTR regardless of the interface language.

The log window title needed fixing in exactly the opposite direction. "{name} — Logs" started with the run name, and a run name is Latin, so bidi resolved the whole line as LTR and an Arabic reader met it from the wrong end. No code was needed at all: reordering the words inside the translation itself is enough to make the first strong character Arabic.

Where to get it

Actioneer is open source under the MIT license. Sources are on GitHub; you can install it from Flathub or the Snap Store.

After I unlocked the power limit on the graphics card, a local Qwen3.8-27B was giving me 31 tokens per second. Then unsloth re-released the same quant using a new method, I switched to the fresh one — 35. And I took that for the ceiling.

Then I did the arithmetic against memory bandwidth: the card was delivering 46% of what it could. Half of it was idling.

The obvious suspect is Vulkan instead of CUDA. I had already tried that, during those same two days of dead ends before the power unlock. There was no difference, so I closed the question. Turns out I shouldn't have.

Wrong turn one: the compiler didn't know my card

That measurement was broken. Every NVIDIA card has a version number for its instruction set — the compute capability, written as compute_90 or sm_90. You have to ask the compiler explicitly to build for a given version, and it simply doesn't know about versions newer than itself.

The system nvcc 12.4 goes up to compute_90 — that is Hopper, the server-grade H100s. And an RTX 5080 Laptop is compute_120, consumer Blackwell. The build was running through intermediate PTX translated on the fly, without native kernels. Claude Code and I had measured the fallback path and taken it for CUDA.

Wrong turn two: the installer that silently waited for Enter

There are no official llama.cpp builds with CUDA for Linux at all, only for Windows. So build it myself. I downloaded NVIDIA's 5 GB installer — and it silently hung, having opened a tiny X11 window asking me to press Enter. You need the --nox11 flag.

And later it turned out the installer isn't needed either: the same components ship as separate archives, and 0.86 GB is enough instead of five gigabytes.

Wrong turn three: CUDA won't build against a new glibc

CUDA 12.8 does not build with glibc 2.43. The new glibc added the functions cospi, sinpi and rsqrt, while CUDA's own headers declare them too, with a different exception specification. I patched six declarations by hand (well, by Claude Code's hand) — the same fix, as I found out afterwards, is described in llama.cpp's own documentation.

Wrong turn four, the dangerous one: the benchmark that lied

Built it, measured it: CUDA gives +20% on generation. I was about to switch my working scripts over. Then I measured on a real prompt of 64 thousand tokens — CUDA came out 45% slower.

I caught that same reversal three times in one day: speculative decoding through MTP gave +25% on a short request and −12% on a long one, n-gram lookup +400% and −34%, the DFlash2 draft model +29% and −43%. On this workload any short benchmark inverts your conclusions at real length.

Wrong turn five: a conclusion I didn't like

The conclusion was this: CUDA has no fast path for a quantized KV cache, so we stay on Vulkan. I didn't like that conclusion and asked to dig once more.

Turns out the path is there, and the kernel is built by default. It is slow because of a specific bug — one that already has a report filed, on the same architecture and the same Linux kernel as mine, and an open fix.

What came out of it

Rebuilt: CUDA 13.3, the branch with the fix, native sm_120.

Minus 21% of the time on a real step. The context did not suffer for it — the same 196 thousand tokens.

The ceiling turned out to be a false one

The conclusion I ended up with: the ceiling turns out to be a false one every time. There is always a bit more room above it, you just have to knock.

A few days ago it was 20.8 tokens per second, and that was the limit: the card was running at 80 watts out of the 175 it is rated for. I unlocked the power — 31. Unsloth re-released the same quant using a new method, calibrated for agentic coding — the same model, just rebuilt — I switched to it, and got 35.

And CUDA added its share somewhere I wasn't expecting. Generation on a short request rose from 35 to 44 tokens per second, but on the real 64-thousand-token prompt the gain is modest: from 27.8 to 29.5. What did speed up is the prefill — processing the prompt itself before the answer — from 555 to 768 tokens per second, almost 40%.

And for coding that is worth more than a gain on generation. An agent reads a lot and writes little: 64 thousand tokens of prompt against roughly a thousand tokens of answer, so three quarters of the time goes to reading. That is where the 21% off the whole step comes from.

From 20.8 to 44 tokens per second, plus 38% on prompt processing — in a few days. On live work an agent step now fits into two minutes instead of two and a half. And that is something you can work with, rather than sit and wait for.

I thought 21 tokens per second was all my laptop's RTX 5080 could manage running Qwen3.8-27B. Turns out the card was working at 80 watts out of the 175 it is rated for.

I noticed by accident, while measuring why a local model was computing slower than its memory bandwidth said it should. Under full load the card sat at exactly 79.9 W and would not go above it under any conditions. And nvidia-smi reported the situation honestly all along: current limit 80, maximum 175.

Not even root could raise it:

$ sudo nvidia-smi -pl 175
Changing power management limit is not supported in current scope

Two days of dead ends

Built llama.cpp with CUDA instead of Vulkan — zero difference in generation. Tried multi-token prediction — worse on long context. Restarted nvidia-powerd, switched power profiles, went into the BIOS. Nothing.

The cause was not Linux

It was one missing command. OMEN Gaming Hub on Windows sends the firmware two WMI commands: the thermal profile and the power limit unlock. The hp-wmi driver in the kernel sends only the first. The second one, for my board, it does not send at all.

How it was found

Claude Code took it from there, and it did not work by guessing. It dumped the ACPI tables of my own laptop, disassembled them and read what exactly the firmware does in response to those commands. It found the precise packet layout, found that two field names are swapped in other people's implementations, and found that yet another method those projects call is addressed to the AMD integrated graphics, not to the NVIDIA card at all.

The interesting part, though, is that four attempts failed. The firmware accepted the unlock flags, confirmed them on read-back, and the power did not move by a single watt. What was missing was a third command both of us had considered optional: reading the fan count. An ordinary data query — what could it possibly change?

In the stock kernel driver that function is called hp_wmi_get_fan_count_userdefine_trigger. The word "trigger" in the name was the answer: the read has a side effect in the embedded controller. We put the call first in the sequence — and the limit came off.

What came out of it

Plus 50% generation speed on the same card and the same quant of the model.

That is a benchmark, though, and a benchmark is short. On real work — an agent writing code, prompts from 55 thousand tokens up — median generation rose from 17.2 to 24.4 tok/s, that is by 42%. And on the very longest prompts there is no gain at all: there the bottleneck is no longer watts but memory bandwidth, and the extra power has nowhere to go. The shorter the prompt, the bigger the win.

About temperature

Checked under sustained load: the temperature reaches a plateau of 87 °C and stays there. That is exactly the card's target temperature — it aims for it on its own and from there gives power back smoothly to hold it. Hardware thermal slowdown never engaged once. So this is not overclocking on the edge, it is the stock mode that the laptop's firmware simply would not let me turn on.

The irony

In kernel 7.1 all of this is already done, and for my exact board at that — the commit landed on 10 April. Set platform_profile to performance and the driver runs the whole sequence itself. But Ubuntu 26.04 ships kernel 7.0, and 7.1 will never arrive there: the next HWE kernel comes from an interim release, which means it will already be 7.2, and not before February. Fedora, for what it is worth, has had 7.1.8 since 11 August — in the current release and in the previous one.

While we wait, a kernel module of my own is running with a watchdog timer: if the temperature supervisor dies for any reason, the kernel drops the unlock by itself within five seconds. Verified the crudest way possible, with kill -9.

Ran three local models — Qwen3.6-35B-A3B, Muse-Glimmer-30B and Qwen3.8-27B — through one and the same spec: a markdown editor in Rust and GTK4. Judged them not by eye but with a harness: 13 machine gates, 27 contract tests and 14 functional UI checks driven through AT-SPI, with screenshots. Each model got up to 30 rounds, and between rounds it received a report of exactly what had failed.

Hardware — RTX 5080 Laptop with 16 GB, llama.cpp on Vulkan, OpenCode as the agent.

Results

Only one of the three passed acceptance.

The other two tripped over the same thing: the markdown rendering function is supposed to return HTML, and Qwen3.6-35B-A3B produced Pango markup while Muse-Glimmer-30B produced plain text with the markup characters stripped out.

Tests that confirm the mistake

The interesting part is not in the table. All three models wrote tests, as the spec required, and all three had their own tests passing. Here is a real test from Muse-Glimmer-30B:

let out = render_markdown("# Title\nSome text");
assert!(out.contains("Title"));
assert!(!out.contains('#'));

It is green. And the function returns bare text instead of HTML. The model wrote an oracle that confirms its own reading of the task — and the reading was wrong.

Hence the conclusion that justifies the whole exercise: telling a model to "work test-first" is not enough. The model authors both the code and the check for it, so the check has to come from something you did not write together with it. Qwen3.8-27B had its own version of the same act — for nine rounds it kept fn main() {} and wrote library code, never once running the application. The unit tests passed the entire time.

On reasoning effort

Qwen3.8-27B thinks at maximum by default — xhigh. Ran it again on medium, changing nothing else.

Same result — full acceptance, at half the price. And look at the last row: the number of responses barely moved. The whole difference is in how much the model thinks per step, not in the number of steps. xhigh does not find more solutions; it deliberates longer over the same ones.

On speed

20.5 tokens per second — and that is the ceiling of the laptop, not of the model. The card is locked at 80 W against the 175 W it is rated for: on Linux the hp-wmi driver never sends the firmware the unlock command that OMEN Gaming Hub sends on Windows. Built llama.cpp with CUDA instead of Vulkan — zero difference in generation, 20.97 against 20.84. The backend is not to blame; it is short on watts.

Multi-token prediction (MTP) gives +25–37% on short prompts, but on a 59,000-token prompt it came out 12% slower: the draft acceptance rate falls from 70% to 35–47%, and the extra pass stops paying for itself. No good for coding.

Conclusions

Of the three, Qwen3.8-27B is the one to use for coding, and by a clear margin: the only model to reach acceptance, it wrote twice as many tests as the runner-up, and along the way it found a defect in my own verification harness. Run it on medium rather than xhigh — twice as fast for the same result.

A caveat: one run per model and one task, so this is not statistics. Qwen3.6-35B-A3B stalled on its own at round 11; Muse-Glimmer-30B I stopped at round 22, after thirteen rounds without movement.

And the main thing the experiment showed: the difference between "the model wrote code" and "the code works" can only be measured by something the model did not write.

Ran an interesting experiment today. The same spec file as before, for a markdown editor in Rust and GTK. Two different approaches.

1. The whole task done by Opus 5 through Claude Code. To keep the comparison clean, Claude Code spawned a separate subagent with a fresh context.
2. The task done by Opus 5 paired with a locally running Qwen3.6-35B-A3B. Here Opus 5 acts as the orchestrator and the brains, while all the code writing is delegated to Qwen. The orchestrator is a separate subagent with a clean context too, so that both approaches start from the same place.

The spec lists the criteria the app has to meet — interfaces, features, tests — plus validation by external scripts that check whether the thing actually works.

First, I was curious whether two models working together could handle the task at all. Second, I wanted to find out whether there would be any difference in token spend. The results are rather interesting.

Results

Both handled it.

By the formal criterion it is a draw. On tokens the pairing is 1.77× cheaper on output and 2.08× cheaper on cache reads, and that is a real saving: the local model costs nothing against my Claude limits.

But half the cost bought me barely more than a third of the code. The pairing did exactly what I ordered stage by stage — the mandatory core, and not a step further. Opus, entirely unprompted, went on to finish twelve more items the spec marks as optional: syntax highlighting, split view, themes, session restore, watching the file for external changes, HTML export, single-instance mode.

The saving is in limits, not in speed: on the clock the pairing is twice as slow.

One more observation, more about me than about the models. My validation scripts turned out to be weaker than I thought. They check that a window opened, that there are controls, and that clicking them does not crash the app. The main scenario — type some text and save it — is not covered at all. In the paired run Qwen produced code that sailed straight through the scripts, yet edits in the editor never reached the document model: Save wrote an empty file. The orchestrator caught that by reading the code, not by running the scripts, and sent it back to be fixed.

Conclusions

Delegating to a local model is worth it if you need exactly what you specified, and you are willing to slice the task into stages yourself and check every one of them. It saves almost half of your limits.

The orchestrator does have to work from a fresh context. I had a third run where I drove Qwen straight from a long working session — it ate three times more, purely on re-reading the accumulated history on every turn. That swallowed the entire gain.

But you pay for the saving with initiative. The pairing closes the list of requirements; it does not make a product. If you want the latter, not delegating is cheaper.

It's amazing to see how much progress models and llama.cpp have made in just a few months. Before this, I tested the Qwen3.6-27B model. It wouldn't fit in my 16 GB of VRAM, ran quite slowly, and generated at 12–18 tokens per second.

It took about 20 hours to complete my test task: building a Markdown editor in Rust with GTK on Linux.

It was an interesting experiment, but practically useless. Way too slow.

And in the meantime, the Qwen3.6-35B-A3B model was released. It uses a MoE architecture: 35B total parameters, but only ~3B are activated per token (8 routed experts + 1 shared expert out of 256). This makes the model compute much more efficiently while retaining quality on par with much larger models in the same class. llama.cpp has added support for this architecture, along with numerous performance improvements and MTP (Multi-Token Prediction) — an additional "head" trained to predict multiple tokens ahead, alongside the main model. MTP delivers a ~1.4–2.2x generation speedup without sacrificing accuracy, though for MoE models the boost is usually more modest (~1.15–1.25x).

So today I decided to feed my test task to this model. First, I had Claude Code run several tests to find the optimal settings for it.

Saying I'm surprised is an understatement. First, the entire model fits comfortably in VRAM. Second, I'm getting a 256K context window, which I've never been able to use with other models (even smaller ones struggled with this).

Prompt processing is running at roughly 260–400 tokens per second. Generation speed on an empty context was nearly 100 tok/s, dropping to 62–65 tok/s as the context filled up. Still, it's damn fast.

With the 27B model, it took about 10 hours just to reach a state where the app would run, even with a buggy and broken UI. Today, the 35B model got there in 50 minutes!

Energized by the speed, I started telling the model what to fix. In just 4 hours, I got a fully working application with all the flaws and even minor details corrected.

Looking forward to running this model on my real projects now. Who knows, maybe the dream of a capable local coding model isn't so far out of reach after all.

Over the past few months I've tried out a lot of different local models. I have my own kind of benchmark for them — a file with a detailed spec for a notes editor for Linux written in Rust. Syntax highlighting (not hard, it's available out of the box in the system component) and a preview panel that should render formatted text. Overall, it's pretty similar to my Swifty Notes app, but in Rust.

So, Qwen3.6-27B is so far the only model that's made it to the finish line. It worked for 3 days (not around the clock, only when I was at the computer and could guide it). Occasionally the model had issues with tool calls. Sometimes it couldn't edit a file and would just stop — I had to ask it to try again. Overall I'd give this part a 4 out of 5.

The most important thing is that the model didn't go in circles. Rust is a great choice here: if there's an error, the project simply won't compile. Combined with the fact that the spec requires writing tests first and then the code (Test Driven Development), a lot of issues get caught and fixed at the earliest stages. And here the model performed pretty well. It fixed errors fairly quickly, followed the instructions from the spec, and consulted documentation if it suddenly used a nonexistent API or just needed to check what was available. A solid 4 out of 5 here.

The model size is 17.5 GB. I downloaded it through LM Studio but ran it via llama.cpp — surprisingly, the performance there is significantly better, even though LM Studio supposedly uses llama.cpp under the hood. Maybe more recent versions of llama.cpp are just better optimized.

The model doesn't fit entirely into VRAM (I have 16 GB), so it ran partially on the CPU, which heavily impacted speed. This whole thing was eating 15.94 GB of VRAM and another ~12 GB of RAM at peak (when the context was nearly full). I set the context size to 64k — at first that was plenty, but towards the end, as the codebase grew, the model would compact the context fairly often. Still, overall it handled a task of this size.

I'd give the speed a 2 out of 5.

When the model reported that everything was done, I launched the app and saw raw HTML text in the preview panel instead of a rendered view. I had to ask the model to fix it, and after another hour and a half or two I got an acceptable result. That said, it's worth mentioning that this kind of thing happens all the time even with flagship models — large tasks rarely work on the first try and usually require revisions and clarifications.

Bottom line: Claude Code would've done this task in 20–30 minutes, and I'd probably spend another 20–30 minutes finishing things up. Let's round up to 1 hour. With Qwen3.6-27B it took about 20 hours of continuous work in total, roughly 3 full working days. Of course, most of that time you're just sitting there watching the model work. Generation speed on the preliminary tests Claude helped me run was 12–18 tokens per second on my hardware.

The speed difference is huge. The result is acceptable. A lot of the required functionality just doesn't work, but I blame the context size for that — it's hard for models to hold that much code in memory.

Still, I'm happy with the result. It gives me hope that programming with local models on regular hardware is feasible. A year ago even cloud models were making similar mistakes, and local models of this size were simply not suitable for programming at all. Maybe in another year progress will get us to the point where subscriptions won't be needed for small projects. And I really like the trend that open-source free models have already caught up with the flagships from OpenAI and Anthropic.