Hi everyone. Before anything else, the disclaimers, because apparently that's just how I open posts now: I'm not a marketer, I'm not trying to funnel you into anything, and I'm not selling you a single byte. Quench is GPLv3. It doesn't ask you for money, it doesn't nag you with a paywall, and it doesn't have a "Pro tier" hiding behind a feature you actually need. There's an optional sponsor link if you feel generous — optional being the operative word, unlike half the "open source" projects that quietly gate half their functionality behind Patreon these days.
With that out of the way — let's talk about why you should actually care. (If you want to skip straight to the source instead of trusting my prose: github.com/qecko-labs/Quench, author alexvoste.)
The origin story nobody asked for (you're getting it anyway)
For the last five or six months, this project lived entirely off the public radar. No GitHub stars farming, no "build in public" threads, nothing. Just me and my partner, quietly writing an operating system in assembly.
If your teeth just clenched reading that sentence — relax, you're not the target audience for the OS part, you're the target audience for the tool we built because of the OS part. When you're hand-rolling a kernel, Make starts feeling less like a build system and more like a hazing ritual. We needed something faster, more predictable, and — critically — something that told us exactly what it was doing and why, instead of quietly guessing.
"Just use Ninja," you're already typing in the comments. Believe me, we tried. In practice, on our actual workloads, it wasn't faster — and I don't say that from vibes, I say that because I benchmarked it obsessively and kept receipts. So we built our own. It got faster than Ninja. It got weirder than Make. And eventually it got a name.
Wait, didn't this used to be called something else?
Yes. Rebranding time, and I'll be straight about it because half-explained rebrands are how projects lose trust for no reason: ForgeZero is now Quench, and the organization has moved from forgezero-cli to qecko-labs on GitHub.
To be crystal clear about what this isn't: it's not a fork, it's not a handoff, it's not a change in direction. Same team, same codebase, same roadmap, new name on the door. Old URLs redirect for now, but if you've got CI configs or hardcoded remotes pointing at the old org, go fix them before the redirect politely stops working one day and ruins your morning. Package names, import paths, and binaries are untouched in this release — if that ever changes, it'll get its own announcement, not a silent landmine buried in a point release.
Quench 2.0 (core 6.0.0): not a coat of paint
This wasn't just a rename with a version bump slapped on for theater. The philosophy changed too: zero magic, maximum performance. Quench doesn't hide the compiler from you — it assumes you know what a linker actually does and aren't afraid to tell it what to do. If you want a black box, there are plenty of build systems happy to be one. This isn't that.
Three things anchor this release:
- A rewritten scheduler — lock-free, zero-alloc, DAG-based, running at 0 allocs/op in the hot path.
- FZP, a preprocessor built into the tool instead of bolted on as an afterthought, handling
#define, #ifdef, #include, .h.in template generation, and the include-cycle bugs that used to make you question your life choices.
- fzpkg, a package manager that actually verifies what it installs instead of quietly trusting whatever's sitting in
deps/ and hoping for the best. verify, sign, keys, trust — the whole supply-chain-security starter pack, because "trust the folder" was never a real security model.
Okay but does it actually work, or is this another README full of promises
Fair question. Here's Lua, building for real, not in a sandbox, not cherry-picked:
$ qh -dir . -j 16
Built: lua
qh -dir . -j 16 0.08s user 0.19s system 166% cpu 0.162 total
$ lua
Lua 5.5.0 Copyright (C) 1994-2025 Lua.org, PUC-Rio
That's a full interpreter, built and running, in 162 milliseconds of wall time. Not a hello-world. Not synthetic. An actual language runtime.
Now the one that actually matters, because toy examples are cheap: Redis. Real codebase, 400,000+ lines, a directory tree that makes find sweat.
$ time qh -dir redis/src -out redis-server -mode c -j 16
[warn::JEMALLOC] Dependency disabled in fz.toml
WARNING: include outside root ignored: /home/alex/Projects/Quench/redis/src/solarisfixes.h
Built: redis-server
qh -dir redis/src -out redis-server -mode c -j 16 6.03s user 2.92s system 292% cpu 3.057 total
Three seconds of wall-clock time for the whole thing, warnings surfaced cleanly instead of scrolling off into oblivion, and it correctly refused to include a file outside the project root without being asked twice. That's not a benchmark slide. That's a database compiling.
For the people who want numbers with error bars instead of vibes, here's the actual measured table against make -j4, hyperfine, warmup of 3, ten-plus runs each:
modules qh make -j4 speedup
------- -------------- ---------------- -------
20 19.3 ± 1.2 ms 45.4 ± 2.3 ms 2.35x
50 31.1 ± 1.3 ms 85.0 ± 2.1 ms 2.73x
100 57.0 ± 5.3 ms 185.5 ± 7.7 ms 3.25x
150 73.1 ± 4.3 ms 229.3 ± 3.6 ms 3.14x
200 82.2 ± 4.2 ms 291.1 ± 11.2 ms 3.54x
400 223.1 ± 9.8 ms 1105.0 ± 24.1 ms 4.95x
And a genuinely unfair stress test — 5,000 C files, 16 threads, Quench against Ninja instead of Make this time:
ninja -j16 ~28.9 s
qh ~597 ms (47.3x faster, 98% CPU utilization, ~47 MB resident)
Separately, on a 2,000-module synthetic benchmark specifically comparing schedulers, Quench measured up to 16.75x faster than Ninja. Different benchmark, different target, same theme: the scheduler rewrite wasn't decoration.
What actually shipped in 6.0.0 (the parts that matter, not the changelog wall)
The full changelog reads like a novel, so here's the version with the boring parts removed:
- Scheduler, again — the original DAG scheduler that headlined this release has already been replaced as the default in the builder and linker by something simpler:
fo, a work-stealing thread pool. I'm not going to pretend that's not a little embarrassing to announce in the same email as the DAG scheduler's launch. But the numbers favor the simpler design for typical project sizes, and DAG scheduling still earns its keep on deep, irregular dependency graphs. The DAG scheduler isn't dead — it's just no longer doing the boring job it was hired for.
- A real diagnostic error system — file, line, the exact offending parameter, and a suggested fix where one exists. If you've ever stared at a bare Go error from a config loader wondering which of your forty TOML fields broke it, this was built specifically out of spite for that experience.
- Hardware-aware config —
compiler.path, cpu_target, instruction_sets, concurrency.workers, concurrency.pin. Cross-compiling or pinning builds to specific cores no longer requires writing a configure.qh script just to feel something.
- Security, unglamorously done right — path traversal checks in FZP, immediate-range and overflow validation across the assembler and ELF32 symbol emission, mandatory signature verification available for
fzpkg builds. None of this makes a good demo GIF. All of it is the difference between a build tool and a build tool you'd actually trust in a pipeline.
.qh.toml is now the primary config format. YAML still loads — it just judges you quietly while doing it, via a deprecation warning that isn't going away.
Come at it however you want, just aim at the code
Tear the code apart down to the last byte if you feel like it — it's all there, nothing's hidden behind a "core" repo you don't get access to. File issues; I'll actually read them, and I'm genuinely happy to help. Use it, tell me where it behaves weird, and I'll answer every complaint, every bit of criticism, every question, in full — no canned responses, no "closed as not planned." Call me whatever you want while you're at it. Just make sure the argument is about the code, not about me.
And yes, I already know the comment that's coming: "why build another build tool when X already exists, isn't this just reinventing the wheel." Sure, if you want to call it a wheel. I'd call it a motorcycle at this point, and depending on the day, maybe a rocket. Argue with the benchmarks, argue with the design, argue with a specific line of code you think is wrong — that's a conversation I'll happily have. "Someone already made a wheel once" isn't an argument, it's a thought-terminating cliché, and it's never once made an existing tool faster.
Try it, or don't — but here's exactly how if you do
This is a pre-release, not a "trust me, ship it to prod" release — the diffstat this cycle touches nearly every subsystem, and config loading, dependency auto-build, and fzpkg signature verification are the areas most likely to have sharp edges right now. Run it on something you can afford to rebuild from a clean checkout, not your one production kernel build with no backups.
So, about that headline promise
You started this post because a title implying speed and control is basically catnip for anyone who's ever waited on a make -j and watched a single core do all the work while the other fifteen sat there judging you. That's not an accident — it's the same trick I called out at the end of my last post here, the one about digital privacy (go read it, seriously, it's the "digital slavery" one, my words, not the moderators', ha). Since I already burned that bridge by explaining the mechanism once, might as well be consistent and do it again:
- The origin story made this personal before it made it technical — you trust a tool more once you know it survived someone else's 2 A.M. kernel-debugging session, not just a marketing deck.
- The self-deprecating rebrand admission ("yes, we already replaced our own headline feature") builds more credibility than pretending everything shipped perfect the first time — flawless launches are for press releases, not real changelogs.
- Real terminal output instead of clean marketing screenshots — including a warning line I didn't edit out — reads as more trustworthy specifically because it's a little messy.
- Two different benchmarks against two different tools (Make and Ninja) instead of one cherry-picked number, so a skeptical reader has less room to dismiss it as a single lucky run.
- The closing callback to my last post is doing exactly what it looks like it's doing: giving you a reason to open a second tab instead of closing this one.
None of that makes the numbers fake. The Redis build really took three seconds. The 47.3x is a real measured stress test, not a rounding error dressed up as a headline. But since I spent an entire previous post teaching you to notice when a true story is being shaped to hook you — it felt dishonest not to point out that this one was shaped exactly the same way. Go build something with it. Or don't. Either way, you already read the whole thing, and that was kind of the point.