nzbfast is a Usenet downloader built around a single pass: every byte gets decoded, verified and extracted while it downloads. There's no assembly pass afterwards, nothing left to verify or unpack once it's done. The moment the progress bar fills, the file is finished and provably intact.
macOS · Windows · Linux · Docker: one self-contained executable, repair and unpack tools built in.

Why it's fast
This is architecture, not micro-optimisation, and every bit of it is measured in the benchmark log with commands you can re-run.
Several article requests stay in flight on each connection, so a round-trip never leaves the socket idle and TCP never lets its congestion window decay between articles. Across four sites we measured +12% to +270% over serial, and a line saturates at 8 connections rather than 30–50.
Articles are SIMD-decoded in place and written once, straight to their final offsets, then PAR2-verified out of the same decode buffers. For store-mode RAR posts the contents are extracted during the download, so the volumes never exist as files: disk written comes to content × 1.0.
An article counts as "missing" only once every configured backbone has turned it down. Block-exact accounting calls the job COMPLETE, REPAIRABLE or IMPOSSIBLE before wasting bytes, pulls just the exact-fit minimum of recovery blocks, and drops hopeless downloads within seconds.
The pipeline
Other clients write the archive volumes, read them back to verify, read them a second time to extract, then write the output, roughly 2× the writes and 2× the reads. Here's what nzbfast does instead:
socket ──TLS──▶ rapidyenc SIMD decode (in place - 4.95 GB/s per core)
│
├─▶ pwrite at final offset (plain posts)
│ └─ or: RAR-map translate ─▶ pwrite straight into the
│ extracted file (store-mode posts - the rar
│ volumes never touch disk)
├─▶ PAR2 block hasher - every block MD5-verified from the
│ decode buffer; verification finishes with the download
└─▶ availability ledger - block-exact health, live
Headline features
The full list (every knob, every integration) is on the features page.
Benchmarks
Same machine, same six providers, runs interleaved back-to-back. What's timed is when a usable, extracted file exists, the only metric that really matters. Every competitor was tuned to its own documented best, right down to switching SABnzbd's pipelining on, which it ships without.
190.6 GB NZB → a single 167.9 GB mkv, M1 Ultra on 10 GbE, 6 providers × 8 connections. The same job also finishes inside a 1 GB memory budget. Full tables, all seven scenarios, and the legs we don't win (plus how to reproduce them) are on the benchmarks page.
Fits your stack
It carries the full SABnzbd-compatible API, so you add nzbfast as a "SABnzbd" download client and it just works: grabs, categories, priorities, retries, post-processing scripts on the SAB_* contract, history. The Newznab facade goes one further and lets the *arrs search your local index as if it were an indexer.
The daemon speaks NZBGet's JSON-RPC as well, so the popular phone remotes drive nzbfast without any changes. The dashboard itself also has a proper phone layout for when you're away from the big screen.
One click pulls your servers in from an existing SABnzbd or NZBGet install, and it'll read sabnzbd.ini directly if that's what it finds. Watch folders, filtered RSS feeds, smart folders with TV filing and cleanup rules all come along too.
Unzip, double-click the launcher, answer three questions (or let it find your existing SABnzbd config) and the dashboard opens. Your first download lands inside two minutes.