TechFuel HQ

LM Studio vs Ollama on an RTX 5080: Measured (2026)

LK Wood IV — Wed, 26 Aug 2026 15:20:00 -0500

Depending on which search result you trust, LM Studio is 46% faster than Ollama, 10-20% slower, or exactly the same speed. The Reddit thread that ranks first for this query carries “3-4x faster” claims for Ollama, while a Stack Exchange question a few results down asks why Ollama’s models run faster inside LM Studio. Those claims cannot all be true on the same computer, so I put both apps on mine: one RTX 5080, the same GGUF files loaded by both. Hard-linked, sha256-verified, the same bytes on disk. Five runs per cell, at stock settings and again with settings matched.

The apps are within 14% of each other everywhere. One wrong setting is worth 240%.

The verdict, by use case

You want	Run	Why, measured
A background service, API, scripting, Docker	Ollama	5-11% faster dense decode, 78-132 MB idle RAM, headless by design
A GUI, model browser, per-model tuning	LM Studio	The interface is the product; decode within 5-11% of Ollama
Fastest gpt-oss 20B on 16 GB	LM Studio + upstream GGUF	242.8 vs 213.7 t/s, engine and conversion differences both in play
Long prompts, RAG, big context ingestion	LM Studio	Prefill 5-14% faster on every model tested
Both at once	Fine	Ran simultaneously on ports 11434/1234, 7,000 MiB total VRAM with two 3Bs

Neither app deserves a speed-based religion. Here is what one controlled rig actually measures.

What people claim vs what I measured

The top of this search results page disagrees with itself. The r/LocalLLaMA thread that ranks first carries claims of Ollama being “3-4x” faster; a Medium post and Codiste both say Ollama wins by 10-20%; atomic.chat says LM Studio generates 46% faster; tech-insider.org titles its piece “Zero Performance Difference [Tested]”, then prints Qwen 2.5 14B Q4_K_M at 25-30 tokens/sec on an RTX 4090, attributed to community benchmarks. Every one of those pages is linked in the Sources block. My RTX 5080 measures that exact model and quant at 97-102 t/s in both apps. Three to four times their 4090 figure. A different machine and unknown settings on their side, granted, and that is precisely the problem — this argument runs on numbers nobody measured under stated conditions.

With settings matched (context 4096, full GPU offload, temperature 0, seed 42, one serving slot, medians of five fresh-prompt runs):

Model	App	Decode	Prefill (~450 tok)	GPU mem (MiB)
Llama 3.2 3B	Ollama 0.32.15	350.5 t/s	17,862 t/s	3,760
Llama 3.2 3B	LM Studio 0.4.21	316.0 t/s	20,337 t/s	3,808
Qwen 2.5 14B	Ollama 0.32.15	102.2 t/s	5,038 t/s	10,356
Qwen 2.5 14B	LM Studio 0.4.21	97.6 t/s	5,567 t/s	10,405
gpt-oss 20B²	Ollama 0.32.15	213.7 t/s	9,187 t/s	13,570
gpt-oss 20B²	LM Studio 0.4.21	242.8 t/s	9,618 t/s	12,533

² Different conversions of the same model, because they have to be: Ollama ships its own gpt-oss blob and LM Studio runs the ggml-org upstream MXFP4 file. More on that below.

Ollama decodes faster on dense models, by 10.9% on the 3B and 4.7% on the 14B. LM Studio prefills faster on everything I tested and wins the MoE outright. Each side wins one event, which is the same shape my Ollama vs llama.cpp bench found six days earlier, and none of it justifies “3-4x” folklore. The per-run decode arrays, VRAM, RAM, LM Studio TTFT medians, and load times are in the same-GPU compare dataset, CC BY 4.0.

Same engine underneath, same process name

The process tables captured with every run show the same thing on both sides: the model being served by a llama-server.exe process — Ollama’s from its install directory, LM Studio’s from its backend extension directory. Both apps are packaging around llama.cpp’s server, which is why the dense-model numbers land within 11% of each other and why “which app is faster” is mostly a question about versions and defaults.

The versions matter more than the wrapper. Ollama 0.32.15 runs its vendored llama.cpp at commit 9d77fa172; LM Studio 0.4.21 downloaded its llama.cpp runtime 2.29.1 on first launch. The installer shipped 2.28.2 engines, still on disk next to the newer one. The app updated itself before I ran anything. Worth knowing if you pin versions for reproducibility. Six days and fourteen patch-version increments separate my two captures of Ollama on this rig, and its 3B decode moved from 319 t/s (0.32.1, August 20) to 351 (0.32.15, August 26). Some of that is engine updates. Some may be capture-window conditions, since the earlier run predates the quiet-window discipline described in the method. By the time I finished writing, Ollama had already promoted 0.33.0. Any LM-Studio-vs-Ollama benchmark without version numbers is a screenshot of a moving target.

The defaults are the real story

The plan for this piece treated “defaults as installed” and “settings normalized” as separate test conditions on the expectation that packaging differences would show up in the numbers, and the dense models shrugged at every bit of it: Qwen 2.5 14B ran 98.2 t/s at LM Studio’s stock settings and 97.6 normalized while the 3B moved about 1%. When the model fits comfortably, stock settings are fine. Stop tuning.

Two defaults are not fine, and both fail silently.

LM Studio’s automatic GPU offload quietly benched gpt-oss at 186 t/s — 23% below the 243 the same app hits with settings tuned. Stock, LM Studio loads models at 8,192 context across 4 parallel slots with GPU offload on “auto”, and my first normalized pass changed all three at once. So I re-ran the stock configuration changing only the offload slider, nothing else. Result: 244.9 t/s, the entire gap, from one setting. Context length and slot count contributed nothing measurable. On a 16 GB card, auto had chosen to hold part of the MoE’s weights on the CPU, and no warning appears anywhere. Setting GPU offload to max was worth 31% on this card.

Ollama’s context slider is a 3.4x foot-gun. Ollama’s documented default for a 16 GB card is a 4,096-token context, and at that default the 3B decodes at 351 t/s, 100% GPU-resident. This machine’s Ollama had its app-settings context slider at 256k from earlier use, a value Ollama clamps to this model’s 131,072-token maximum. Still far past what fits. With nothing else changed, the same 2 GB model loaded an 18 GB footprint, split 22%/78% across CPU and GPU, and decoded at 102 t/s. A 3.4x slowdown from one setting, and ollama ps is the only place that shows you why. I would bet money this explains a large share of the “Ollama was crawling for me” posts in that Reddit thread; it is also presumably invisible to anyone benchmarking only fresh installs.

If one number from this page survives in your memory, make it this pair. The gap between these two apps is at most 14%. The gap between a good and a bad memory setting is 240%.

Memory: VRAM is a tie, RAM is not

Wherever both apps loaded the identical file, GPU memory matched within 50 MiB — 3,760 vs 3,808 on the 3B, 10,356 vs 10,405 on the 14B. Same bytes, same engine, same memory. The gpt-oss row differs by 1,037 MiB because the conversions differ; Ollama’s fork has allocated about a gigabyte more than upstream in every capture I have run, on either engine.

System RAM is where the apps genuinely part ways. Idle with no model, the Ollama service tree held 78-132 MB across my checks; LM Studio’s GUI and server held 709-928 MB across the quiet-window observations (one transitional reading hit 3.1 GB mid-unload and is excluded as a non-idle state; it is in the raw JSON). Loaded, LM Studio’s runtime keeps the memory-mapped model file hot in its working set. With gpt-oss resident, its process tree reported about 13 GB of RAM alongside the 12.5 GB of VRAM, where Ollama’s runner released its mapping and sat near 2.1 GB. Mapped file pages are evictable cache, so this is not a hard requirement, but on a machine with 16-32 GB of RAM running other work, Ollama is the lighter tenant: five to six times lighter loaded, five to twelve times lighter idle. tech-insider.org’s “5x Memory Gap” headline has the right direction and, at idle, roughly the right magnitude; the spread depends mostly on what the Electron GUI is doing.

Load times were closer than I expected: 2.3-2.8s for the 3B on both apps, 5.5s vs 7.7s on the 14B, 8.1s vs 8.4s on gpt-oss, warm caches throughout.

The portability catch travels

My llama.cpp piece found that Ollama’s gpt-oss:20b blob declares architecture gptoss, which upstream llama.cpp rejects. LM Studio reproduces the refusal verbatim: importing the blob works, the file indexes, and loading it dies with unknown model architecture: 'gptoss' from its 2.29.1 runtime. So the one model Ollama co-launched still cannot leave Ollama, now confirmed against two external consumers of the file.

Everything else travels beautifully. lms import took Ollama’s Llama 3.2 and Qwen 2.5 blobs by path, and with the hard-link option both apps share one physical copy of the weights. I verified it: each blob shows a link count of three (Ollama’s store, my staging copy, LM Studio’s models directory all naming the same bytes), and the files hash identically to Ollama’s own blob digests. The listings ship with the raw evidence. In the other direction, Ollama imports any GGUF with a one-line Modelfile (FROM /path/to/file.gguf and ollama create), though it copies rather than links. Running both apps against one model library costs you nothing but the gpt-oss exception.

Which one belongs on your machine

Run Ollama when the model is infrastructure: a service that starts at boot, feeds Docker containers, answers on 11434 from whatever stack you build on it, and stays out of RAM when idle. The local-LLM tutorials on this site ride on it for exactly that reason, and its dense-decode edge is real if modest.

Run LM Studio when the model is an appliance: you want to browse Hugging Face quants visually, flip a sampling parameter without editing a Modelfile, watch token streams in a chat pane, and still get an OpenAI-compatible server on 1234 when an app needs one. Its per-model load settings are the granular control Ollama hides behind environment variables, the same control that makes the auto-offload default worth checking before you benchmark anything.

Run both when the fits above split your week. They coexist on one card, share model files one direction cleanly, and the second app costs you a few hundred megabytes of idle RAM. Measured with both 3Bs resident: 7,000 MiB of total GPU memory including the desktop’s ~1.1 GB baseline, and sequential requests answered at 298 and 230 t/s. That is lower than the solo medians, though those coexistence runs capped generation at 64 tokens, so they are not directly comparable to the 256-token table above. My VRAM calculator and speed calculator both apply unchanged to either app, because underneath they are the same engine. That is the finding of this whole exercise. Pick by workflow. Fix your settings. The by-GPU model guide covers what fits in your VRAM either way.

Method and limits

Both apps measured 2026-08-26 on the same box, an RTX 5080 16 GB on driver 610.88 under Windows 11. Ollama 0.32.15, upgraded from 0.32.1 the same morning — the newest release at bench time, with 0.33.0 promoted while this was being written and not tested here. LM Studio 0.4.21, installed fresh that morning, runtime self-updated to llama.cpp-cuda12 2.29.1. Models: Llama 3.2 3B Q4_K_M (blob dde5aa3fc5ff…), Qwen 2.5 14B Q4_K_M (blob 2049f5674b1e…), gpt-oss 20B MXFP4 — Ollama’s blob e7b273f96360… on its side, ggml-org’s upstream file on LM Studio’s side, whose sha256 27cd6c432c76… matches the hash Hugging Face publishes. Rates come from each app’s own counters (Ollama’s eval fields; LM Studio’s /api/v0 stats), cross-checked by wall-clock recomputation. Decode figures are medians of five runs, long-prefill figures medians of three (a fourth warmup run is discarded), every run carrying a unique prompt nonce to defeat prompt caches. The gpt-oss offload finding was re-verified with a single-variable run — stock configuration, only the offload slider moved — recorded with the rest of the raw JSON. LM Studio’s prefill rate is derived from time-to-first-token minus one decoded token, because its API does not split prompt evaluation out the way Ollama’s does; the long-prefill TTFTs live in the raw JSON captures if you want to re-derive. One app under test at a time, the other fully killed, except in the coexistence check.

What I did not test: Mac and MLX (where the loudest “LM Studio is faster” claims come from, and where nothing on this page applies), AMD cards, multi-GPU, LM Studio’s chat UI as opposed to its server, concurrent multi-request serving, and NVFP4 quantization — no NVFP4 conversion of this model set existed to test. Mid-capture I caught a background indexing job on my own machine depressing 3B decode by 15%; it was suspended and every published number re-measured on a quiet system, which is one more reason to distrust any benchmark that does not say what else the box was doing. All raw JSON captures live in the repo, and the dataset page is the citable record. These numbers carry version stamps because they moved 3-10% in two weeks on one of the apps alone; date everything, including mine.

The Self-Hosted SSO Tax: A Verified Tracker (2026)

LK Wood IV — Wed, 26 Aug 2026 14:45:00 -0500

On August 9, 2026, PLANKA shipped version 2.2.0 and removed OIDC single sign-on from its free Community edition, which meant anyone who updated a working board found every SSO-based user on it deactivated, admins included. Three days after the announcement, the thread on GitHub was closed and locked, sitting at 86 thumbs-down. That thread is why this page exists.

The practice has a name. sso.tax, whose entries go back to 2018, tracks SaaS vendors that treat single sign-on as a luxury add-on, and its fork ssotax.org carries the same torch. Both lists measure per-user cloud pricing, which is the right lens for SaaS and the wrong one for software you run yourself. Neither covers what hit self-hosters this year: an app that runs on your hardware, under an open license or close to one, where the login method is still the feature behind the paywall.

Nobody was keeping the list for self-hosted software. So I built it. I verified every row on this page against the vendor’s own pricing pages and repositories on August 25, 2026, and each row links its receipt. A row I could not verify that day did not ship.

What is the self-hosted SSO tax?

The SSO tax is the practice of charging extra for single sign-on. In SaaS it shows up as an enterprise tier priced far above the plan you wanted. In self-hosted software it shows up as an open-core split, where the code is free to run while SAML or OIDC login sits in a paid edition, behind a license key, or inside a subscription that can cost more per month than the hardware under it. Same tax, new venue.

Why it stings more at home than in the office is worth spelling out. Once you run five or six services, an identity provider such as Keycloak or Authentik is what turns them into one system. One account per person. One password policy, one place to enforce two-factor, one switch to cut a user off everywhere. An app that paywalls SSO opts out of that system unless you pay, and the price is usually set for companies, not for a family of four. That gap is the tax.

What counts, and what does not

A tracker like this earns links only if its rules are stated before its accusations. Here are mine.

Class A, retroactive removal. A feature that shipped in the free edition moves behind a paywall, and existing free users lose it on update. The community calls this a rug-pull. It is the most serious class because it converts deployed users into hostages of their own upgrade path, people who picked the app in good faith on the feature set it shipped with and now get to choose between paying up and rebuilding somewhere else. PLANKA’s OIDC removal is the 2026 example.

Class B, gated from day one. SSO was never free in the self-hosted edition. This is a defensible business model and most rows below sit in this class. It still belongs on the tracker, because you should price it in before you adopt the app, and because the free alternatives column exists.

Class C, the quote wall. No published price at all. You cannot know the tax without talking to sales. The original sso.tax maintains a separate list for these vendors, and the same pattern appears in self-hosted pricing.

Three things deliberately do not count. Paid support or hosting around a fully free feature is the fair way to fund open source, and the free-side table below names projects doing exactly that. Gating in a vendor’s hosted cloud while the self-hosted build stays free is a SaaS matter, already covered by sso.tax. And a free evaluation edition does not make a feature free. Mattermost’s “Entry” edition includes SAML, and Mattermost’s own pricing page describes it as a limited-use edition of Enterprise Advanced for technical evaluation.

One more fairness rule. Where a vendor grandfathers old versions, the row says so. PLANKA does not disable anything remotely, and older releases keep working. That matters, and a tracker that hides it is a rant.

SAML, OIDC, LDAP: not the same thing

Every row below names the exact protocol, because “SSO” without a protocol name is how wrong accusations happen.

SAML 2.0. The XML-based enterprise standard. Common in corporate identity systems, heavier to implement, and the single most frequently paywalled protocol on this page.
OIDC (OpenID Connect). The modern JSON/OAuth2-based standard. What Keycloak, Authelia, and Authentik speak natively, and what most homelab setups want.
LDAP / Active Directory. Not SSO at all. A directory the app checks credentials against. Users still type a password into each app, and there is no single session. Several vendors sell “LDAP sync” as a separate paid feature.
Social login. OAuth2 against Google, GitHub, or similar. Convenient, and not the same as bringing your own identity provider.
Forward-auth. A reverse proxy asks an authenticator before passing traffic. Guards the front door without the app’s cooperation. More on its limits below.

The tracker: self-hosted apps that charge for SSO

Every row verified against the linked source on 2026-08-25. Prices are the vendor’s published numbers on that date, in the currency they publish. “Moved” means the feature left a free edition on the stated date. “Gated” means it was paid from the start as far as the vendor’s current material shows, with no claim about earlier history.

App	What is paid	Cheapest tier with it (2026-08-25)	Class	Free route that remains	Receipt
PLANKA (kanban)	OIDC SSO, removed from Community in v2.2.0 (2026-08-09); updating deactivates SSO-only users	Pro, self-hosted €36/mo (€432/yr)	Moved (Aug 2026)	Password login; TOTP 2FA now free; stay on ≤2.1.1 unsupported; Vikunja has free OIDC	Issue #1754 · pricing
Mattermost (team chat)	SAML and OpenID Connect for production use sit on paid plans (the SAML docs list “Entry” too — an evaluation-only edition, see the free-route cell)	Professional and up, quote-based (“prepaid annual subscriptions”)	Gated + quote wall	Free “Entry” edition includes SAML but is “a limited-use edition … for technical evaluation” per the pricing page; Zulip ships SAML/OIDC free	SAML docs · pricing
Grafana (dashboards)	SAML — “Available in Grafana Enterprise and Grafana Cloud”	Enterprise, quote-based	Gated + quote wall	Generic OAuth stays in the OSS build — its docs carry no edition banner, unlike SAML’s	SAML docs · OAuth docs
Metabase (BI)	SAML — “only available on Pro and Enterprise plans (both self-hosted and on Metabase Cloud)”	Pro, $575/mo	Gated	Open-source edition, without SSO	SAML docs · pricing
Teleport (infra access)	SSO via OIDC, SAML, or Active Directory — Enterprise versions only, per vendor FAQ	Enterprise, quote-based	Gated + quote wall	Community edition (the FAQ does not enumerate its auth methods)	FAQ
Passbolt (passwords)	SSO (Microsoft, Google, OpenID) and LDAP provisioning at Pro; AD FS at Enterprise	Pro, $4.90/user/mo billed annually, 10-user minimum	Gated	Community edition, without SSO/LDAP; Vaultwarden documents free OIDC	Pricing
Bitwarden (passwords)	“Passwordless SSO integration” at Enterprise; Teams lacks it	Enterprise, $6/user/mo billed annually	Gated	Vaultwarden, unofficial, free OIDC	Business pricing
n8n (automation)	“SSO, SAML and LDAP” at Business tier	Business, €667/mo billed annually	Gated	Free self-hosted Community build, email login	Pricing
Plane (project mgmt)	SAML and OIDC implementations — the pricing table marks both Enterprise Grid only	Enterprise Grid, quote-based	Gated + quote wall	CE self-host auth is passwords and magic links; Vikunja has free OIDC	Pricing · self-host docs
OpenProject (project mgmt)	SSO providers (CAS, SAML, OpenID Connect, Kerberos, Okta), reserved for paid Enterprise plans	Enterprise plans, from €10.95/user/mo billed annually with 25-seat minimums	Gated	Community edition (password logins)	Pricing table
Seafile (file sync)	SAML 2.0 / ADFS, manual-labeled “(Pro)”	Pro edition (per-user pricing not published on checked pages)	Gated	CE keeps OAuth, Shibboleth, and remote-user; Nextcloud has an official free SSO app	Manual · SSO overview

Two notes on reading it. The seat minimums matter more than the per-user price, because SSO on Passbolt starts at 10 paid seats — $49 a month at its listed rate even if only three people ever log in — and OpenProject’s plans carry 25-seat minimums on top of the per-user number. And a quote wall is itself data. Five of eleven rows publish no number at all.

The table is honest about what it does not know. Portainer folklore says Business Edition gates OAuth, and Portainer’s current documentation shows OAuth providers with no edition restriction, so there is no Portainer row. The same discipline removed a Rocket.Chat row from a draft of this page: their plan matrix lists basic SAML, LDAP, and custom OAuth in Community, so what they charge for is advanced identity sync, not SSO itself — that story sits in the retreats section below. Absence from this table is not an endorsement. It means I could not verify an SSO paywall from the primary source on build day.

What happened with Planka SSO

The case that made this page worth building deserves the neutral version.

On August 7, 2026, the PLANKA team posted issue #1754, announcing that OIDC/SSO would leave the Community edition with the next release. Their words were direct. “SSO was always meant to be a Pro/enterprise feature on our side.” They also cited support load, over 100 SSO setup requests a month by their count. Version 2.2.0 shipped on August 9. The thread was closed and locked on August 10, at 86 thumbs-down out of 96 reactions.

The mechanics are the sharp edge. Updating to 2.2.0 deactivates every SSO-based user, because those accounts have no password. An admin has to set passwords and reactivate them one by one. If the admin account itself was SSO-based, that person is locked out unless they create a new admin through the documented script first. The team’s own warning says to plan the migration before updating.

The fair-side ledger, stated plainly. Nothing is disabled remotely, and 2.1.1 keeps working for as long as you accept running without updates. The same release moved TOTP two-factor along with auto-logout and trusted devices from Pro into Community, so account security in the free tier went up while identity federation went out. Pro costs €36 a month self-hosted, which is priced for teams, and their stated line is that account security stays free while enterprise identity is paid.

If you run PLANKA with SSO today, the realistic options are four. Pay for Pro. Convert users to password logins plus the newly free TOTP. Freeze on 2.1.1 and accept the security trade of no updates. Or migrate boards to Vikunja, which speaks OIDC free. I have not tested a PLANKA-to-Vikunja migration, so check Vikunja’s importers against your data before committing to that path.

Self-hosted apps where SSO stays free

The counterexamples are the strongest argument that free SSO is viable. Same verification date, same receipt discipline.

App	Free identity support (verified 2026-08-25)	Receipt
Zulip (team chat)	Email, LDAP/AD, SAML, OIDC, social (Google, GitHub, GitLab, Discord, Apple), JWT — no plan restrictions in the auth docs	Auth methods
BookStack (wiki)	OIDC “as a primary method of authentication,” SAML 2.0 and LDAP alongside	OIDC docs
Paperless-ngx (documents)	OIDC and social auth via django-allauth since v2.5.0, plus remote-user	Advanced usage
Vikunja (kanban/tasks)	OIDC against “Authentik, Keycloak or similar”	OpenID docs
Vaultwarden (passwords)	OIDC SSO with per-provider guides; a master password is still required	Wiki
Nextcloud (files+)	Official “SSO & SAML” app maintained by Nextcloud GmbH, installable from the app store	App store

Zulip is the row I would show a vendor. A team chat server competing in the same category as Mattermost above ships SAML and OIDC free in every self-hosted deployment, LDAP too. It can be done.

We run several of these ourselves. Our Paperless-ngx setup guide and Nextcloud AIO walkthrough cover two of the six, and the self-hosted starter list puts them in context.

Your escape hatches

Run your own identity provider. Keycloak speaks OIDC free, and so do Authelia and Authentik. Our Authelia vs Authentik comparison picks between the two for a homelab, with the Authentik setup tutorial as the follow-through. Every app in the free-side table plugs into any of them.

Forward-auth for the rest, with honesty about its limits. Authelia or Authentik in front of your reverse proxy will challenge visitors before any backend sees traffic. For a single-user homelab that is often all the SSO you need. What it cannot do is put per-user identity inside an app whose native SSO is paywalled. The app still sees its own local accounts. One login at the door, separate accounts behind it. That is the honest limit, and any guide promising otherwise is selling something.

Pick apps by the auth column before you deploy. The cheapest time to avoid the SSO tax is before your data lives in the app. That is the real use of this tracker, and it pairs with our break-even calculator when the alternative is paying for the hosted product instead.

Three events, 2021 through 2026, belong in the same memory even though none is an SSO paywall. Different classes, labeled as such.

Project	What happened	Class	Receipt
Rocket.Chat (team chat)	Advanced identity sync (role mapping, extended attribute sync, background sync) moved to paid plans in a late-September 2021 release; the announcement kept “all the basic functionalities of LDAP, SAML, Social Logins and Custom OAuth” in Community, and the current plan matrix still lists them there	Advanced-tier migration	2021 announcement · plan matrix
MinIO (object storage)	Admin features stripped from the community web console between the 2025-04-22 and 2025-05-24 releases; management moved to the `mc` CLI or the paid AIStor product	Feature removal	Discussion #21316 · Blocks & Files
Cal.com (scheduling)	Announced on April 14, 2026 that the production codebase was going closed source, citing AI-assisted vulnerability discovery; a version of the codebase released to the community as Cal.diy under MIT	License retreat	Cal.com blog

Four dated incidents on this page span 2021 through 2026. The common thread is that the sharp edge sits in the migration path, wherever the announcement lands. Watch changelogs, and treat identity features as the canary.

The maintainer’s side

This page is not an argument that maintainers owe anyone free SSO, because building and then supporting SAML against every corporate identity provider that ever shipped a quirky metadata file is genuinely expensive work that someone has to fund. PLANKA’s hundred-requests-a-month figure is their own number, and I believe the shape of it. Enterprise identity is the classic open-core line because the buyers are enterprises, and a project that funds development by charging them is behaving better than one that quietly abandons its free edition.

Paying is sometimes the right call. If a team of 30 depends on OpenProject with Okta, €10.95 per user per month is a rounding error against migration cost. What this tracker exists to catch is narrower — removals from deployed free editions and upgrade paths that deactivate users, plus security features priced behind quote walls. Those are choices, and the first table records who made them.

How this page is maintained

Each row carries the date it was verified and a link to the source that backs it. When an app changes its tiers, the row gets re-verified against that same source and the update log at the bottom of this page records the change. New incidents get a dated row when a primary source exists, and the lastmod stamp above reflects the latest pass.

Corrections are welcome, including from maintainers. If a row misstates your pricing or your history, use the contact route on our about page and it will be checked against your source and fixed. The table data is available under CC BY 4.0, the same license as our measured datasets. Cite the page, take the table.

Critical Process Died? Check the Drive First (2026)

LK Wood IV — Wed, 26 Aug 2026 00:00:00 -0500

By LK Wood IV · 2026-08-26 · ~10 min read · St. Louis County, MO

Some retailer links below are Amazon affiliate links; if you buy through them TechFuel HQ may earn a small commission at no extra cost to you. As an Amazon Associate I earn from qualifying purchases. Commissions never influence what gets recommended — see our disclosure.

Two minutes. That’s what the most useful test for CRITICAL_PROCESS_DIED costs, and most of the guides I’ve read bury it beneath the same sfc /scannow, DISM, and “reset your PC” ritual. The stop code (0x000000EF) means a process Windows refuses to run without has terminated. Those processes, and everything they depend on, live on your system drive, so the drive’s own health report is the cheapest evidence you can collect. Collect it first. A bad result rewrites the entire plan; a clean one costs you nothing.

The other thing the generic checklists skip: your situation changes the order. A PC that crashes once a day but reaches the desktop, a PC stuck in a boot loop, and a PC that blue-screens at the logo every single time are three different problems wearing the same stop code. Start by picking your lane.

What CRITICAL_PROCESS_DIED means

Windows designates a short list of processes as critical. If one of them terminates, the OS declares its own integrity suspect and stops on purpose. Microsoft’s bug-check reference for 0xEF names the built-in set: csrss.exe, wininit.exe, logonui.exe, smss.exe, services.exe, conhost.exe, and winlogon.exe. These handle sessions, logins, and services. Windows cannot limp along without them, so it doesn’t try.

That framing explains why this code is so unhelpfully broad. Anything that kills or corrupts one protected process fires the same blue screen: a system file damaged on disk, an update that shipped a bad component, a driver or antivirus interfering with a process it shouldn’t touch, a drive returning garbage when the process’s code is read, or RAM corrupting it after it loaded. The code names the victim, never the killer. The rest of this page identifies the killer cheaply, in an order that doesn’t destroy evidence.

Step 1: Which of the three situations are you in?

CRITICAL_PROCESS_DIED: pick your lane before you touch anything

Same stop code, three different problems. The fix order below depends on which of these describes your machine — and one lane carries real data risk.

A

You can still reach the desktop

It crashes, reboots, and lets you back in. You have the easiest lane: run the drive check now (Step 3), then work the software half (Step 4).

B

Boot loop — it starts, blue-screens, repeats

Sometimes it offers “Preparing Automatic Repair.” Your path runs through the recovery environment (Step 5): uninstall the last update, reach Safe Mode, run the drive check from there.

C

Instant blue screen at the logo, every time

Safe Mode fails too. Highest data risk in this lane — secure files first (Step 2), then test the drive outside Windows (Steps 5–7).

Different code on your screen? Each one routes differently — the stop-code map on our restart-loop hub matches each blue screen to its own fix path. techfuelhq.com

One more routing check before you commit to this page. If your blue screens alternate between codes, the pattern outranks any single code: in this cluster’s triage, a machine that also throws DPC_WATCHDOG_VIOLATION moves storage up the list, one mixing in KERNEL_SECURITY_CHECK_FAILURE moves RAM up, and a machine that sometimes restarts with no blue screen at all belongs in the PC keeps restarting flow, which covers power-side causes this page won’t.

Step 2: If your files matter, secure them before any repair

Skip this step only if everything on the machine is backed up or expendable.

Every mainstream fix for 0xEF writes to the system drive. chkdsk /r remaps sectors, sfc and DISM rewrite system files, and a reset reinstalls Windows on top of whatever is there. On a healthy drive that’s fine. On a failing drive it’s the worst possible order: heavy writes push a marginal drive further along, and a reinstall destroys the crash evidence while planting your fresh OS on the same dying hardware. The safe sequence is the reverse. Copy or image first, repair second.

So, before the repair steps:

Lane A (desktop works): copy your irreplaceable files to an external drive or cloud storage now, while the machine is up. Ten minutes, zero risk.
Lane B (boot loop): reach Safe Mode via the recovery environment (Step 5) and copy files out from there.
Lane C (no boot at all): pull the drive and read it from another PC over a USB adapter or enclosure, or boot a Linux live USB and copy files off without touching Windows. If the drive is already making mechanical noises (clicking, grinding), stop powering it entirely and read our hard drive clicking triage; every additional spin-up of a failing mechanical drive costs you data.

The one command to withhold until your files are safe: chkdsk C: /r. It’s on every list, and on a drive with pending sectors it forces reads and remaps across failing media, sometimes for hours. Run it after the copy, or after the SMART check clears the drive, never as move one.

Step 3: Check the drive first — the two-minute test the checklists bury

Here’s the wedge, and the reason this page is ordered unlike the ones you’ve already read. I order checks by what they cost against what they can tell you, and nothing else on this list comes close: the drive check is free, takes about two minutes, and a bad result invalidates every software fix below it. sfc repairing files that a dying drive keeps re-corrupting is a treadmill — the exact loop the long-running community threads describe, where the error clears for a day and returns.

Install CrystalDiskInfo (free, from Crystal Dew World), open it, and select your system drive (the one holding C:). Read three things:

The health banner. Good in blue is a pass. Caution or Bad on the boot drive, with this stop code, is your answer until proven otherwise.
SATA SSDs and hard drives: the raw values for 05 (Reallocated Sectors Count), C5 (Current Pending Sector Count), and C6 (Uncorrectable Sector Count). Zeros are a pass. Non-zero and climbing between checks means the drive is actively failing. Recheck in an hour and compare.
NVMe SSDs: Percentage Used (at or past 100% the drive has consumed its rated write endurance), Available Spare (falling toward its threshold), and Media and Data Integrity Errors (should be 0).

Three outcomes:

Clean drive → storage drops far down the suspect list. Continue to Step 4 and fix it in software with a clear conscience.
Warnings on the system drive → stop repairing. Go to Step 7: rescue what’s on it, then replace it. Any hour spent on DISM at this point is an hour the drive spends getting worse.
Clean, but the machine also intermittently loses sight of the drive (BIOS sometimes misses it, Explorer drops it, cold boots fail but restarts work). That’s a detection fault SMART can’t score. Work the connector, cable, and M.2 checks in SSD not showing up; a drive that drops off the bus mid-session kills critical processes just as dead as a corrupt one.

I lead with this check on any blue-screening machine I touch, whatever the code turns out to be. It’s the highest information-per-minute test I know of in Windows troubleshooting. For 0xEF specifically, the community’s post-mortems back the ordering: the long-running r/techsupport thread in the sources ends at a dying system SSD behind recurring crashes under load, and BleepingComputer’s forum regulars open at the hardware layer too, starting with one-stick RAM isolation. That’s their experience, and experience isn’t telemetry; I have no cause-frequency data for this code, and I’ve seen none published. But when the free two-minute test and the expensive failure mode point at the same component, you run that test first.

SMART has one honest limit, and the same r/techsupport thread is the proof. The drive that caused those recurring crashes still reported healthy — no pending sectors, no uncorrectable errors, just a quiet health-percentage slide from 99 to 95 over a few months — and cloning to a new SSD is what ended the crashes. So read a clean report as a screen rather than an acquittal. It moves storage down the list; disk errors in Event Viewer (Step 4) or a drive that intermittently vanishes move it right back up, whatever the banner says.

Step 4: The software half, cheapest fixes first

Drive’s clean? Then it’s a software problem until proven otherwise, and the software checks also run cheapest-first.

Undo whatever changed. If the crashes started inside a week of a Windows update, remove it: Settings → Windows Update → Update history → Uninstall updates, newest quality update first. If a driver updated right before the trouble (GPU, storage, antivirus), open Device Manager, right-click the device → Properties → Driver → Roll Back Driver. A crash with a birthday usually has a parent, and removal is faster than repair.

Read the crash instead of guessing. Two built-in tools, five minutes:

Reliability Monitor (press Start, type reliability) draws a day-by-day timeline. Look at what landed on the machine (updates, driver installs, app installs) immediately before the first red X. That timestamp correlation is the most useful piece of software evidence I know how to collect.
Event Viewer → Windows Logs → System, sorted around the crash time. Repeated disk/storage errors (source disk, stornvme, volmgr) before each crash reopen the storage question no matter what SMART said. A service failing over and over names a software culprit.
Want the exact victim? A free minidump reader (WhoCrashed or BlueScreenView) pointed at C:\Windows\Minidump shows what was on the stack when the system stopped. For 0xEF a single dump often just confirms a critical process died. The pattern across several dumps is what talks, and if a third-party .sys file keeps appearing, that driver is your suspect.

Then repair system files, in this order:

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

Run both from an elevated Terminal, DISM first, because it repairs the component store that sfc pulls its replacement files from. Reboot after. These two fix damaged Windows system files, a real 0xEF cause, and that is the whole list. They cannot fix a third-party driver, a filter driver from a misbehaving antivirus suite (uninstall it properly with the vendor’s removal tool if the timeline implicates it), or hardware.

If crashes continue past this point with a clean drive, you’re into Step 6 territory: memory.

Step 5: Locked out — the boot-loop path through WinRE

Lanes B and C run the same fixes without a desktop. Before you start, grab your BitLocker recovery key from another device (aka.ms/myrecoverykey, signed into your Microsoft account), because recovery tools can demand it. Windows opens the door itself. Microsoft’s documented trigger is two consecutive failed attempts to start Windows, and the standard field method exploits exactly that: hold the power button to kill the machine the moment the Windows logo appears, twice, then boot a third time into “Preparing Automatic Repair” → Advanced options.

From Troubleshoot → Advanced options, in this order:

Startup Repair. Let it run once. It fixes a specific class of boot-path damage and takes minutes.
Uninstall Updates → latest quality update. The cheapest targeted move when the loop began right after Patch Tuesday.
Startup Settings → restart → 4 (Safe Mode) or 5 (with networking). Reaching Safe Mode is the big prize: it loads a minimal driver set, and from there you can run the Step 3 drive check, copy files out, roll back drivers, and uninstall recently added software. A machine stable in Safe Mode but crashing normally is pointing at a third-party driver or service.
System Restore, if you have restore points, returns Windows’ own files and registry to a pre-crash state without touching your documents.
Command Prompt, for the offline file repair: sfc /scannow /offbootdir=C:\ /offwindir=C:\Windows. One catch. WinRE sometimes letters your Windows volume differently, so run diskpart → list volume first and substitute the letter that actually carries Windows.

The one tile I would leave alone for now is Reset this PC. A reset is the reinstall-first play. It forfeits your files-first sequencing (Lane C readers may not have copied anything out), and if the underlying cause is the drive, you’ll watch the fresh install fail the same way in a week. Reset is a fine last software step once the drive has been cleared and the files are safe.

If even WinRE won’t load and Lane C is fully dark: reseat the drive and its cable (or the M.2 screw and slot), try the other SATA port, and test the drive in another machine per Step 2’s rescue path. At that point you are diagnosing hardware, not Windows.

Step 6: RAM and the rest of the ladder

Memory is the other part that kills critical processes — a protected process corrupted in RAM dies just like one fed bad data from disk. The tests are free; the parts aren’t.

Run MemTest86 from a USB stick overnight (or mdsched.exe, the built-in Windows Memory Diagnostic, for a faster first pass). Any red errors condemn the configuration, not necessarily one stick.
Reseat, then isolate. With two or more sticks, reseat them, then test one at a time. The one-stick pass is the same move BleepingComputer’s regulars open with on this code, and it separates a bad module from a bad slot.
Running XMP or EXPO? Set memory back to default JEDEC speed and retest. An unstable memory overclock corrupts data identically to a failing stick, and this cluster’s RAM-first sibling covers that fork in depth: KERNEL_SECURITY_CHECK_FAILURE.
Power sits at the bottom of the ladder. If the machine also hard-restarts with no blue screen, shuts off under load, or needs several tries to cold-boot, the storage and RAM symptoms may both be downstream of an unstable supply. Cross-check PSU failure symptoms and the instant-black-cut diagnosis in computer randomly turns off.

Run the free tests before buying anything. Replacement parts are painfully expensive right now (the RAM & SSD price tracker has current numbers), which makes a guessed-wrong purchase a three-figure mistake. Evidence first, wallet second.

Step 7: If the drive is the verdict — rescue, then replace

You’re here because the evidence corroborated the drive: SMART warnings on the boot drive (reallocated, pending, or uncorrectable sectors; NVMe media errors; Percentage Used pegged), disk errors marching through Event Viewer before each crash, or the strongest tell of all — the error came back after a clean reinstall.

The order is fixed. Data off first, then replace. Copy files out per Step 2’s lanes (Safe Mode if Windows still opens; USB enclosure on another PC if it doesn’t). If the drive holds something irreplaceable and is deteriorating fast, weigh a professional recovery service before more DIY power-on hours.

Then swap it. A current-generation 1TB NVMe SSD is the straightforward replacement for a desktop or laptop with an M.2 slot — check your board’s manual first, and a SATA-only machine needs a 2.5-inch SATA SSD instead. Our homelab NVMe picks hold up equally well as desktop boot drives. I would not reuse a drive with climbing reallocated sectors for anything — not as a game drive, not as scratch space. Its next failure has your data on it.

Fresh drive, clean Windows install, restore your files, and 0xEF should be history. If it isn’t, the drive was only a casualty. Return to Step 6, because RAM or power was corrupting the drive’s traffic all along.

Keeping it from coming back

A machine that has thrown 0xEF once earns two habits. Recheck CrystalDiskInfo in a month; sector counts that moved again settle any lingering doubt about a drive that squeaked by. And keep the pattern rule in reach: a rebuilt machine that starts throwing different stop codes has only reshuffled the problem, and the changing-codes signature points at memory or power. Start at the stop-code map rather than six separate code pages.

Two cases sit outside this page. Domain-managed and BitLocker-locked corporate machines belong to your IT department, which holds keys and imaging tools you don’t. And one more exists: a 0xEF can come from third-party software whose service was configured with the restart-the-computer recovery option Microsoft documents for developers; the fix there is removing that software. Everything else above is reproducible on any Windows 10 or 11 PC with a USB stick and a screwdriver.

Sources

Stop-code identity and the critical-process list: Microsoft’s Bug Check 0xEF: CRITICAL_PROCESS_DIED reference — a critical system process terminated; built-in critical processes include csrss.exe, wininit.exe, logonui.exe, smss.exe, services.exe, conhost.exe, and winlogon.exe; a developer-created service with its recovery option set to restart the computer can also trigger the check.
Recovery-environment entry behavior (WinRE starts automatically after two consecutive failed attempts to start Windows): Microsoft’s Windows Recovery Environment documentation. Menu labels in Steps 4-5 follow current Windows 11 builds — see the wording note below. BitLocker recovery keys: aka.ms/myrecoverykey.
Repair-command syntax: Microsoft’s sfc command reference (including the offline /offbootdir and /offwindir forms) and DISM image-repair documentation (/Online /Cleanup-Image /RestoreHealth).
Community corroboration for the failing-drive association with recurring 0xEF (experience reports, not telemetry — read in full before citing): the r/techsupport thread whose top answer traced recurring crashes to a dying system SSD that still showed healthy SMART, and BleepingComputer’s Stop Code: Critical Process Died (0xEF) forum thread, where staff open with hardware isolation (one RAM stick, drive health).
Tools: drive health via CrystalDiskInfo SMART/NVMe readouts — the NVMe fields (Percentage Used, Available Spare, Media and Data Integrity Errors) are defined in the NVM Express Base Specification’s SMART/Health log; minidump reading via WhoCrashed (Resplendence) and BlueScreenView (NirSoft) against C:\Windows\Minidump; memory via MemTest86 (PassMark) and Windows Memory Diagnostic (mdsched.exe).
Windows 10 end of standard support (October 14, 2025) and consumer Extended Security Updates: Microsoft’s Windows 10 end-of-support guidance.

Written against current Windows 11 and Windows 10 builds; menu wording drifts across updates. Corrections: hello@techfuelhq.com.

Home Assistant + llama.cpp: Fully Local LLM Voice, Measured (2026)

LK Wood IV — Wed, 26 Aug 2026 00:00:00 -0500

By LK Wood IV · 2026-08-26 · ~14 min read · St. Louis County, MO

144 milliseconds. That is how long a warm “turn on the kitchen lights” took to come back as a correct, executable tool call from a 4B model on my RTX 5080, measured at the same OpenAI-compatible endpoint Home Assistant’s new llama.cpp integration drives. The full pipeline adds speech-to-text on the front and Piper on the back. I measured those separately too. The honest headline is not the speed, though. On the same 24 spoken commands, the models people recommend for this job range from 71% to 96% correct, and the failure record includes a 3B model that answered a kitchen-scoped command by generating turn-offs for the entire house — front-door lock included — until the server’s parser rejected the response. In Home Assistant’s tool mapping, turning off a lock opens the door.

Home Assistant 2026.8 shipped a native llama.cpp integration on August 5. The release post describes it in one sentence: “Use a local llama.cpp server, or any OpenAI-compatible endpoint, as a conversation agent in Home Assistant.” The docs tell you which buttons to press. What they leave out (and what I could not find published anywhere) is which model to put behind it, what hardware that model needs, how many milliseconds each stage of the pipeline costs, and how often the model actuates the right device. This guide is those numbers.

What I measured, and what I did not

Every latency and accuracy figure on this page is first-party, from one bench: my Ryzen 7 7800X3D / RTX 5080 (16GB) machine, running llama.cpp build 10507 (llama-server) on Windows, driver 610.88. The integration is a thin OpenAI-API client, so I benchmarked the exact request path it drives. Each request carried the same system prompt Home Assistant 2026.8.3 assembles (its default instructions, its device-control and area prompts, and a fixed 20-entity, 9-area “bench home” serialized the way async_get_exposed_entities does it) and the same Assist tools (HassTurnOn, HassTurnOff, HassLightSet, HassClimateSetTemperature, HassSetPosition, HassStopMoving, GetLiveContext), mirrored from the 2026.8.3 intent-tools source. Temperature 0, seed 42, five warm repetitions per cell, medians reported. The summary CSV is published, and so are the full receipts: the corpus and scorer plus every raw per-request record.

What I did not do is run Home Assistant itself on this bench. My HA-side steps below follow the official integration docs and the 2026.8.3 source rather than a click-through on this machine, and I say so here instead of pretending otherwise. Two consequences are worth knowing. First, my “command time” is the model-server leg only; Wyoming transport and Home Assistant’s own intent execution add a little on top. Second, my accuracy corpus was typed text at the API, and my Whisper timings used Piper-synthesized speech as input. That audio is clean and close-mic, which makes the STT accuracy numbers a ceiling rather than a promise about your echoey kitchen. Latency transfers. Perfect transcription rates don’t.

The architecture, corrected

Most early coverage of this integration calls it “built-in llama.cpp.” It is not, and the real design is better. The integration is a client. You run llama.cpp’s llama-server (or llama-cpp-python, or vLLM) anywhere on your network, and Home Assistant connects to its OpenAI-compatible endpoint, default http://localhost:8080/v1. The integration page lists it plainly, and the config flow asks for a URL, an optional API key, and then which model the server offers.

That client design is exactly what a homelab wants. Your Home Assistant box stays a low-power N100 or a HAOS VM on Proxmox, and the model runs wherever the compute already lives. A gaming PC. A workstation. The same host, if it has the memory. You can register several agents against different servers and models, each with its own instructions.

Voice needs two more pieces, both older and both solid. Whisper handles speech-to-text and Piper handles text-to-speech, wired in over the Wyoming protocol as add-ons or standalone containers. One subtlety the docs never connect. Home Assistant’s low-power STT default, Speech-to-Phrase, is a closed recognizer that matches against known sentence patterns, which is why it runs “under one second” on a Pi. An LLM agent exists precisely so you can say things no template anticipated, so it needs open-ended Whisper STT. Choosing an LLM brain silently commits you to the heavier STT path. That is where the hardware question lives.

Hardware tiers, honestly

I sell nothing here. A voice brain does not need an RTX 5080. This bench has one, so that is the GPU I can measure, but the tiers below are what the numbers support.

Tier	What runs where	What to expect
Pi 4/5, HA Green	Default Assist agent + Speech-to-Phrase. No LLM.	Sub-second closed commands, per HA’s own docs. Free-form language is beyond this tier.
N100 mini PC	HA + Whisper `tiny/base-int8` locally; LLM server on another box	The right HA host either way. I did not bench an N100; HA’s own docs bracket it — ~8s STT on a Pi 4, under a second on a NUC — and my 7800X3D CPU column below is its upper bound.
Desktop CPU, no GPU	Everything on one box, `-ngl 0`	Works for a 3-4B brain, with seconds-not-milliseconds cold starts. I tried to measure this tier and my numbers failed their own sanity check; the honesty note under the latency tables explains why they aren’t printed.
Used 8-12GB GPU	Everything on one box	Between my CPU notes and the 5080 column. A 3060 12GB fits the 7B with room. That is interpolation rather than measurement; I did not bench one.
16GB GPU (this bench)	14B at 96% accuracy, or 20B	Warm commands in the 126-585 ms range across the ladder. The whole pipeline lands under a second.

For sizing a specific model against a specific card, the VRAM calculator does the arithmetic. My measured VRAM residency per model is in the results table.

Step 1: Run llama-server where the compute is

Grab a llama.cpp release for your platform (CUDA build for NVIDIA), or use the official containers. Tool calling — the thing that lets the model actuate anything — runs through the Jinja chat-template engine. On the build I tested (10507) the server’s own --help reports --jinja as default-enabled, and I pass it explicitly anyway; older builds shipped it off, so if your agent chats but nothing actuates, --no-jinja or an ancient build is the first thing to rule out.

Windows or Linux binary:

llama-server -hf unsloth/Qwen3-4B-Instruct-2507-GGUF:Q4_K_M --host 0.0.0.0 --port 8080 -ngl 99 -c 8192 --jinja --api-key changeme

Docker with an NVIDIA GPU:

docker run --gpus all -p 8080:8080 -v /path/to/models:/models ghcr.io/ggml-org/llama.cpp:server-cuda -m /models/Qwen3-4B-Instruct-2507-Q4_K_M.gguf --host 0.0.0.0 --port 8080 --n-gpu-layers 99 -c 8192 --jinja --api-key changeme

Notes from running this, not from the README:

-hf user/repo:QUANT downloads straight from Hugging Face and defaults to Q4_K_M. It saved me the download-and-point dance for every model in this guide.
-ngl 99 offloads all layers to the GPU, and -ngl 0 forces CPU. -c 8192 gives the ~1,500-2,500-token Home Assistant prompt room to grow with your entity count.
If you already run Ollama, llama-server can load most of Ollama’s blobs directly from ~/.ollama/models/blobs/. That is how I benched Qwen2.5. The exception that cost me an evening was gpt-oss — Ollama’s blob for it carries its own architecture tag and will not load in llama-server, so you need the upstream GGUF conversion. I hit the same wall building the Ollama vs llama.cpp comparison.
Set --api-key on anything listening beyond localhost. llama-server itself warns at startup that it ships with CORS open and no key.

Sanity-check with curl http://SERVER_IP:8080/health before touching Home Assistant. It answers {"status":"ok"} once the model is loaded.

Step 2: Connect Home Assistant

On Home Assistant 2026.8 or newer (I verified against 2026.8.3, the latest release as I write this), go to Settings → Devices & services → Add integration → llama.cpp. The flow asks for the base URL — your server’s http://SERVER_IP:8080/v1 — plus the optional API key, then queries the server and prompts you to select the model. From the integration’s entry you add a conversation agent subentry, which holds the two settings that matter.

Control Home Assistant grants the agent the Assist API. Without it you get a chatbot that can’t touch a switch.
Instructions is the system prompt, templated. The default plus the Assist API’s own guidance is what I benchmarked. Resist stuffing it until you’ve read the latency section, because every token you add here is prefill the model re-reads on a cold start.

The agent only sees entities you expose, under Settings → Voice assistants → Expose. Expose deliberately. My bench home is 20 entities and its serialized state costs ~1,500-2,500 tokens of prompt depending on the model’s tokenizer. A 300-entity house pushes the prompt up with it, along with the cold-start prefill and the model’s targeting difficulty.

Then build the voice side in Settings → Voice assistants. Create an Assist pipeline, pick your llama.cpp agent as the conversation agent, Whisper for STT, Piper for TTS. Whisper and Piper install as add-ons on HAOS (defaults model: auto, and Piper’s en_US-lessac-medium voice — the exact voice in my TTS table), or as containers on any Docker host, including your GPU box:

docker run -d -p 10300:10300 -v whisper-data:/data rhasspy/wyoming-whisper --model small-int8 --language en

There is a GPU build of faster-whisper (lscr.io/linuxserver/faster-whisper:gpu) if you want STT on the CUDA box too; my STT table below shows what that buys. Point Home Assistant’s Wyoming integration at port 10300 and the pipeline picks it up. Wake word (openWakeWord/microWakeWord on a satellite or the Voice Preview Edition puck) is the one stage I have no hardware to measure, so I leave it to HA’s docs.

Model choice: the accuracy table I went looking for and had to build

Speed was never the interesting question. Every model below answers a warm command in under a second on a GPU. The question is whether the tool call that comes back does the right thing. I ran a fixed corpus of 24 typed commands against each model at temperature 0 — simple on/off, area-scoped commands (“turn off all the lights in the office”), parameters (brightness, color, thermostat), locks and covers, state queries, and five deliberately hard cases covering ambiguity, multi-area targeting, an implicit request, a command for a device that doesn’t exist, and a timer request when no timer tool is offered. Scoring is mechanical. Correct tool, correct target, correct parameters, against a published acceptance set. The corpus and scorer live in the bench receipts along with every raw response, so you can recompute any cell of this table.

Model (Q4_K_M unless noted)	Correct / 24	Accuracy
Qwen2.5-14B-Instruct	23	95.8%
gpt-oss-20b (MXFP4)	22	91.7%
Qwen2.5-7B-Instruct	21	87.5%
Qwen3-4B-Instruct-2507	20	83.3%
Llama-3.2-3B-Instruct	17	70.8%

The failures are more instructive than the percentages, because they are not random. Each model has a signature way of being wrong.

Llama-3.2-3B floods, guesses, and crashes. Three of its 24 responses were rejected outright by llama-server’s tool-call parser — the model generated malformed tool output the server refused to hand back, which a Home Assistant user experiences as a failed interaction. The server log shows what it was trying to do on the kitchen-scoped “turn everything off” command: an enumeration of HassTurnOff calls marching far beyond the kitchen through the whole bench home, the Front Door Lock among them, until the parse died. Home Assistant maps turn-off on a lock to opening it; the only thing between that response and an open front door was a parser error. Asked the ambiguous “turn off the lights,” it silently guessed one room instead of asking which. It turned on the nonexistent disco ball. And its answer to “Who wrote The Hobbit?” was a GetLiveContext call with name: "The Hobbit" — it looked the novel up as if it were a device in the house (rejection number three). Fast, cheap, and the one model here I would not connect to real locks.
Qwen3-4B drops the scope. Its area commands came back domain-correct but house-wide. “Turn off all the lights in the office” produced HassTurnOff {domain: [light]} with no area, which would darken the whole house. Its instinct on ambiguity is investigation (GetLiveContext) rather than actuation, which is at least safe.
Qwen2.5-7B under-reaches. It targeted the entity literally named “Office Lights” and left the desk lamp on. Technically responsive, functionally half a command. On the ambiguous prompt it enumerated and switched off lights in five rooms instead of asking which one. On the disco ball it checked live context before telling me no such device exists — reasonable behavior that still scored as a miss under the strict no-tool answer key, where the 4B and 14B simply said so without calling anything.
Qwen2.5-14B just… behaves. Its one miss in 24: asked what’s playing in the living room, it answered (correctly) straight from the entity snapshot in its prompt instead of calling GetLiveContext as its instructions demand. Right answer, wrong route. On a real install, where that snapshot goes stale between commands, the habit can bite. It nearly had a second miss, but that one was mine — told to turn everything off in the kitchen, it also switched off the kitchen speaker, which my original answer key had forgotten existed. The model was more thorough than my gold labels. I corrected the key (corpus v1.0.1) and scored it as the pass it was.
gpt-oss-20b omits. It turned off the kitchen lights but forgot the dining room on the two-area command, and went off to inspect the thermostat instead of acting on “I’m cold.” Nothing dangerous, since its misses are omissions rather than overreach, but you feel its reasoning pass in the latency table below.

Home Assistant’s own prompt tells the model to ask for an area when a device-type command is ambiguous, and to prefer name-plus-domain targeting. The source is right here. The spread above is how differently five models follow the same instructions.

Two scoped notes. This is one fixed corpus at temperature 0 on one bench home, a reproducible comparison rather than a universal ranking, and the integration’s own default temperature is 0.7, which can only make behavior less deterministic. Also, a fine-tuned home-control model like Home-LLM exists precisely to attack this problem class; it predates the native integration and I did not bench it here.

Latency results

Command completion time is the number that matters for actuation: request sent to complete tool call back. First-token time flatters voice pipelines; a tool call is only actionable when it is finished. “Cold” is the first request after the server loads, which prefills the entire system prompt. “Warm” is the median of five repeats, where llama-server’s prompt cache means only your new sentence gets processed. That cache is the single most important performance fact in this whole stack. The same request that costs a second cold on the 14B costs 371 ms warm.

LLM leg, RTX 5080 (all layers offloaded):

Model	Load	Cold command	Warm command	Decode tok/s	Server VRAM
Llama-3.2-3B	2.8 s	284 ms	126 ms	287	3,168 MiB
Qwen3-4B-2507	2.6 s	326 ms	144 ms	232	3,873 MiB
Qwen2.5-7B	4.9 s	557 ms	291 ms	128	5,033 MiB
Qwen2.5-14B	26.0 s	1.02 s	371 ms	86	10,076 MiB
gpt-oss-20b	19.6 s	1.08 s	585 ms	212	11,601 MiB

Server VRAM is nvidia-smi total-used delta, before load versus after generation, on a card with an ~865 MiB desktop baseline. Every row above came from a verified-quiet capture window, with the baseline recorded per run in the receipts. This box runs other inference workloads, and two earlier contaminated captures were discarded rather than published.

CPU only: the numbers I am not publishing. I ran the same bench script with -ngl 0 on the 7800X3D and got decode rates near 1 token per second on a 3B. Absurd for this CPU, and I know exactly why. This bench box is temporarily on a single stick of DDR5 (a dead stick is out for RMA), and during the CPU window other inference workloads on the machine were sharing that one memory channel. CPU decode is memory-bandwidth-bound, so those runs measured my bus contention instead of the tier. Numbers measured badly are worse than no numbers, so the CPU rows stay out of the table until I can capture them on a quiet, dual-channel box; the dataset will grow the rows when they’re real. What holds regardless of my bad window: CPU prefill of a ~2,100-token Home Assistant prompt is a cold-start cost measured in seconds rather than milliseconds, warm commands ride the prompt cache exactly as on the GPU, and Home Assistant’s own docs put open-ended Whisper — the other CPU-hungry stage — at ~8 seconds on a Pi 4 versus under a second on a NUC. A resident server plus a 3-4B model is the only CPU-only configuration I would attempt, and I would set expectations in seconds.

STT (faster-whisper, beam 1, on the 24 synthesized commands, ~2-3s of audio each):

Model	Device	Median	Verbatim match
tiny-int8	RTX 5080	46 ms	83.3%
tiny-int8	CPU (7800X3D)	253 ms	83.3%
base-int8	RTX 5080	69 ms	79.2%
base-int8	CPU (7800X3D)	475 ms	79.2%
small-int8	RTX 5080	99 ms	87.5%
small-int8	CPU (7800X3D)	1,401 ms	87.5%

Two honest readings of that match column. First, the method-section reminder: the input audio is synthetically clean, so these are ceilings with a good mic, not field guarantees. Second, verbatim match is a harsh metric that cuts both ways. Several “misses” were harmless formatting (“Set the bedroom lights to 30%.” for “30 percent”, “10 minutes” for “ten minutes”), which the downstream LLM reads fine. The misses that matter are the garbled entity names: base-int8 heard “turn off the desk lamp” as “Turn off the disc lip,” and even small-int8 turned the disco ball into a “disco bowl.” A garbled name is a dead command no matter how good the model behind it is. (Base scoring below tiny here is a 24-sample quirk rather than a finding.)

TTS (Piper, en_US-lessac-medium, the add-on’s default voice): a non-problem, and I can now say so with numbers. On the 7800X3D’s CPU, Piper synthesized the short acknowledgment “Turned on the kitchen lights.” in 93 ms, a 2.9-second sentence in 101 ms, and a deliberately long 8.9-second status answer in 315 ms — a real-time factor of 0.03-0.07. The voice model loads once, in 1.5 s. Piper is the one pipeline component where the Raspberry-Pi-class advice in HA’s docs simply extends upward: their voice page calls it “optimized for the Raspberry Pi 4”, and a desktop CPU has an order of magnitude to spare.

Adding it up. A warm GPU pipeline — Whisper small on the card (99 ms), the 4B brain (144 ms), a short Piper acknowledgment (93 ms) — comes to roughly a third of a second of measured compute between end-of-speech and start-of-spoken-reply, before Wyoming transport and Home Assistant’s own execution overhead. That is inside the territory where an assistant feels instant. One honest asterisk. Like every OpenAI-style agent loop, the integration feeds the tool result back through the model to phrase the spoken confirmation (the loop is visible in its conversation-entity source), so the acknowledgment costs a second warm round trip. The actuation itself doesn’t wait for it. The lights are on before the voice says so.

Tuning notes from the bench

Keep the server resident. Everything above says cold starts are the tax. If the server is on a box that sleeps, or something else evicts your VRAM, every “first command of the evening” pays load plus full prefill. This is also my argument against giant system prompts and exposing 300 entities.
--jinja, again. It is the difference between tool calls and vibes. If your agent chats but nothing actuates, check this first.
Watch the token budget. The integration defaults to a 3,000-token response cap; temperature 0.7 and top-p 1.0 live in the same file. My bench capped at 512, and the 3B’s whole-house flood ran that cap out mid-JSON before the parser rejected it. If you see failed responses in the logs, the model rather than the budget is usually the problem.
Qwen3 pickers, use the Instruct variant. Qwen’s hybrid “thinking” builds spend tokens reasoning before every answer. I did not bench one, and for voice I would not; the 2507 Instruct line I benched answers directly. gpt-oss shows what reasoning costs even when it works: for the same warm command it generated 112 tokens where the 14B needed 30, which is most of why it sits at 585 ms warm even though its 212 tok/s decode is two and a half times the 14B’s.
Streaming is a chat feature. The integration exposes a streaming toggle, and it helps perceived latency when the model reads you a paragraph. A tool call is atomic. Nothing actuates until the JSON is complete.

Why local, briefly

Because the audio of your kitchen never leaves your LAN, because it works when your ISP doesn’t, and because the per-query price is your electricity. I will not pretend the cloud assistants aren’t slicker at barge-in and follow-ups. They are, today. What you get here is a voice interface whose brain, vocabulary, and failure modes are yours to choose, measure, and fix. The accuracy table is exactly that. Pick the brain whose mistakes you can live with, and wire it to locks only when the answer is “none of them.”

Sources

Home Assistant 2026.8 release post (llama.cpp integration announcement): https://www.home-assistant.io/blog/2026/08/05/release-20268/
llama.cpp integration docs: https://www.home-assistant.io/integrations/llama_cpp/
HA 2026.8.3 source — Assist tools + prompts: https://github.com/home-assistant/core/blob/2026.8.3/homeassistant/components/intent/llm.py · exposed-entity serialization + GetLiveContext: https://github.com/home-assistant/core/blob/2026.8.3/homeassistant/components/homeassistant/llm.py · the integration (defaults in const.py): https://github.com/home-assistant/core/tree/2026.8.3/homeassistant/components/llama_cpp
Local voice pipeline + hardware guidance: https://www.home-assistant.io/voice_control/voice_remote_local_assistant/
Whisper / Piper add-on defaults: https://github.com/home-assistant/addons/tree/master/whisper · https://github.com/home-assistant/addons/tree/master/piper
wyoming-faster-whisper container: https://github.com/rhasspy/wyoming-faster-whisper · GPU build: https://docs.linuxserver.io/images/docker-faster-whisper/
llama.cpp docker images: https://github.com/ggml-org/llama.cpp/blob/master/docs/docker.md
llama-server flag reference (-hf, --jinja default): https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md
Bench dataset (CSV, CC BY 4.0): /data/ha-voice-brain-bench-2026-08.csv — method ha-voice-brain-v1, corpus v1.0.1, captured 2026-08-25/26. Full receipts (corpus, scorer, raw per-request records, rescore output): /data/ha-voice-bench/README.md.

Memory Management BSOD? Don't Buy RAM Yet (2026)

LK Wood IV — Wed, 26 Aug 2026 00:00:00 -0500

By LK Wood IV · 2026-08-26 · ~11 min read · St. Louis County, MO

One retailer link below is an Amazon affiliate link; if you buy through it TechFuel HQ may earn a small commission at no extra cost to you. As an Amazon Associate I earn from qualifying purchases. Commissions never influence what gets recommended — see our disclosure.

MEMORY_MANAGEMENT (stop code 0x0000001A) is the blue screen that sends people shopping. The name points straight at your RAM, the forum replies say “run memtest,” and in 2026 — with kit prices multiplied by the memory crunch — a replacement is a three-figure purchase you want to be sure about before you make it. Microsoft’s reference page for the bug check is blunter and more useful: it says a severe memory management error occurred - meaning Windows caught its own memory bookkeeping corrupted. Bad RAM does that. So does a memory overclock the sticks were never guaranteed to hold, a driver writing where it shouldn’t, and a failing drive feeding corrupt paging data back into memory.

That list is the whole reason for this guide’s order. Test first. RAM is a suspect — one of four. The free tests lead. The ten-minute test beats the overnight one, and the purchase waits until a test has condemned a stick.

The new-RAM question, answered first

The question people attach to this stop code, in these exact words in the forum threads about it, is do I need to buy new RAM? Fair question. Here’s the honest answer.

Not yet. Probably not at all. The diagnosis is free either way.

Nobody publishes cause-frequency telemetry for stop codes, this site included, so instead of a percentage claim you get an ordering built from what each test costs you to run and what a wrong guess costs you to buy. The ranking is by price. A BIOS toggle costs ten minutes. An overnight MemTest86 run costs a night; a SMART check, two minutes. A mistaken RAM purchase in this market costs real money. In our own daily DDR5 price capture, the cheapest qualifying 32GB (2x16GB) DDR5-6000 offer at a named direct US retailer was $469.59 on August 24, 2026 (a listing the index flags for looser timings than its line label; the cheapest non-RGB line sat at $479.99) - about five times the ~$80-100 this class sold for in mid-2025, per the tracked history in the DDR5 buying guide. The price-crisis explainer covers why. At those prices, you run every free test before you spend a dollar.

Step 1. Read the signature - when does it hit?

The same stop code behaves differently depending on what’s causing it, and the pattern of when it appears is the cheapest diagnostic you own. Each signature below starts you at a different step.

Match your crash pattern, start at that step

One stop code, several causes. The timing of the crashes routes you to the cheapest test that fits your machine — ordered by cost of test, not by a frequency claim.

New build, new sticks, XMP/EXPO just enabled, or a fresh BIOS update The memory profile is the prime suspect — the rated speed was never guaranteed. Step 2 (JEDEC test) first.

Only under load — games, rendering, big compiles — fine at idle Marginal memory stability that holds until heat and bandwidth stress it. Step 2 if you run a profile, then Step 3.

Nothing changed, crashes getting gradually more frequent The slow-degradation pattern — a stick or a drive going bad over weeks. Step 3 (MemTest86), then Step 4 (SMART).

At boot, during disk-heavy work, or sfc keeps finding new corruption Paging data coming back corrupt from the drive is in play. Step 4 (drive health) before any RAM spend.

Laptop or stock OEM desktop — no profile, nothing changed Skip Step 2; there's no overclock to revert. Step 3 to test the memory, then Steps 4-5.

Seeing different stop codes each time, or restarts with no blue screen at all? That's a whole-system problem — use the stop-code decoder in PC keeps restarting instead. techfuelhq.com

A different code on each crash, or hard restarts with no blue screen, means this page is too narrow for you - work the whole-system flow in PC keeps restarting instead. And if your machine is a laptop or an unmodified OEM desktop, skip straight past the next section: there is no XMP/EXPO profile to revert, so your path is Step 3 onward.

Step 2. The ten-minute test that beats an overnight one

This fork is for machines where a memory profile is enabled or the hardware recently changed - a self-built desktop running XMP (Intel) or EXPO (AMD), new sticks in an old board, a BIOS update that reset or “upgraded” memory settings.

XMP and EXPO are overclock profiles. The DDR5-6000 on the box is a factory-validated overclock, not the module’s default; out of the box, DDR5 runs at a JEDEC standard speed, typically 4800 or 5600. Whether the advertised profile holds depends on the sticks, the board, and your specific CPU’s memory controller together. When that combination can’t quite sustain the profile, it corrupts data in exactly the way 0x1A reports - and the sticks themselves are healthy. PassMark’s MemTest86 documentation says the same thing from the other direction: some memory errors only appear when BIOS timings are set aggressively, and their suggested check is to retest at standard non-XMP timings.

So run the cheap experiment before the long one:

Enter BIOS and disable XMP/EXPO (set the memory profile to Auto/Default). Memory drops to JEDEC speed.
Use the PC normally for a day - include whatever load used to trigger the crash.
Crashes stop? The profile was unstable. Your options, in order of effort — run at JEDEC permanently (the real-world cost is smaller than it sounds - the DDR5 buying guide carries the measured JEDEC-versus-rated numbers, mostly low single digits with one 12% outlier), try a milder profile, or tune voltages by hand if you know the platform.
Crashes continue? Good news, oddly: you’ve ruled out the profile for free. Leave it disabled and go to Step 3.

Two configurations earn a specific warning here. Populating all four DDR5 slots drops the speed a board can hold stable below the kit’s rated profile - the buying guide’s four-DIMM section covers how far and why. And a new AM5 build that has never been stable is the textbook case of an EXPO profile the board never validated — on a week-old machine, check this before anything else.

Step 3. Test the sticks so the result means something

The field’s standard advice is “run memtest.” The part nobody explains is how to read what comes back, so results get misread in both directions - people replace healthy kits, and people trust a quick pass that proved nothing.

Run the real test. MemTest86 boots from a USB stick, outside Windows, which matters because the test gets the hardware to itself instead of sharing it with the very memory manager whose crash you’re chasing. Set it running when you go to bed. A badly failing stick usually errors fast; marginal instability can take hours, and PassMark notes the first pass is shorter than the ones after it. Windows’ built-in Memory Diagnostic (mdsched.exe) is the tool Microsoft’s own 0x1A reference suggests, and it’s a reasonable quick screen — but it finishes in minutes, and minutes of testing is weak evidence against a fault that needs a warm, loaded system to show itself. Treat its “no errors” as nothing found yet, never as proof the RAM is good.

Read the result like this.

Any error counts. PassMark’s troubleshooting doc is direct about this: in the vast majority of cases, reported errors are valid. There is no acceptable-errors threshold. One error is a fail.
A fail names a system first. Their same doc notes errors can also come from the CPU, its caches, or the motherboard - and from aggressive BIOS timings, which is why the JEDEC retest in Step 2 comes first. A kit that errors at XMP and passes at JEDEC is an unstable overclock rather than dead hardware.
Isolate to name the module. Two or more sticks, still erroring at JEDEC? Power down, pull all but one stick, test it alone in the same slot, then swap. The stick that errors alone is your answer; confirm the good stick passes in the same slot so you’ve also ruled out the slot itself.

Then let the crash tell you what it saw. Each 0x1A blue screen writes a minidump, and the first bug-check parameter carries a subcode saying which structure was corrupted. Open the latest dump from C:\Windows\Minidump in WinDbg (from the Microsoft Store) and run !analyze -v - the four parameters print at the top, and the PAGE_FAULT walkthrough covers the mechanics of reading dumps in more detail. For 0x1A, Microsoft’s subcode table turns the hex into a lead:

Parameter 1	What Microsoft’s table says it means	Where it points
`0x403`	Page table and page frame numbers out of sync; probably a hardware error, especially when two parameters differ by a single bit	A one-bit difference is the classic failing-stick signature - Step 3
`0x41790` / `0x41792`	A page table page, or a PTE, has been corrupted	Memory corruption with no named culprit - Steps 2-3
`0x3f`	An in-page operation failed a CRC check, with a page-file offset in the parameters	Corrupt data came back from the drive - Step 4
`0x1233` / `0x4477`	A driver mapped or wrote memory illegally	Software - Step 5, starting from the named driver

Use it as a compass. A subcode won’t close the case alone, but it stops you testing blind - 0x3f in particular moves the investigation to storage before you’ve spent anything on memory.

Step 4. The storage crossover nobody checks

Windows extends memory onto the drive — the page file holds data that was paged out and will be pulled back in, so a drive developing bad sectors can hand Windows corrupt memory, and the in-page CRC subcode above is Microsoft documenting precisely that path. The result wears a memory error’s name while the fault sits in storage. SMART settles it.

The check costs two minutes, which is why it belongs before any purchase.

Run CrystalDiskInfo and read the drive that holds your page file (almost always C:). Caution status, reallocated sectors, media errors, or a climbing percent-used figure on an NVMe drive all move the diagnosis to storage.
A drive that’s also slow, disappearing from Explorer, or dropping out entirely gets the SSD not showing up treatment - and back up before anything else, because a failing drive’s remaining life is a budget you spend carefully.
Storage-flavored blue screens tend to travel together: if you’re also seeing DPC_WATCHDOG_VIOLATION, that code’s storage-first guide is the companion to this section.

One pattern is worth naming. sfc /scannow that finds and repairs corruption, then finds new corruption a few days later, is not sfc being thorough. Something is corrupting files between runs, and this whole page is the list of suspects.

Step 5. Drivers and Windows - the honestly-bounded half

The software half is real, and it’s deliberately late in this order because its tests cost more time than a BIOS toggle and prove less than a memory test. Work it when the hardware half is clean, or immediately when a crash names a driver.

A named .sys on the blue screen or in the minidump goes first. Graphics drivers get a clean reinstall - the GPU driver crash guide covers DDU properly. Anything else: identify the driver, update it, or roll it back.
Timing matches a Windows or driver update? Roll it back (Settings → Windows Update → Update history → Uninstall updates) and see whether the crashes leave with it.
System files: sfc /scannow, then DISM /Online /Cleanup-Image /RestoreHealth, from an admin Terminal. These repair the damage corruption already did; they do nothing about what caused it.
The stubborn case - crashes continue, dump names nothing, hardware tests clean - is Driver Verifier territory, and the KERNEL_SECURITY_CHECK_FAILURE guide has the full walkthrough including the safe-mode escape hatch it requires. That code is 0x1A’s closest sibling: same corruption family, different tripwire.

What this half cannot do is fix electricity. A reinstall rebuilds every file and resets every driver, and an unstable profile or dying stick corrupts the new install on schedule. A 0x1A that comes back after a clean reinstall has told you, at the cost of your afternoon, that it was hardware all along — the free tests above would have said so first.

If a stick really is dead - replacement, priced honestly

You’re here because a stick failed MemTest86 alone, at JEDEC speed, in a known-good slot. That’s a corroborated verdict, and it’s the point where spending money stops being a guess.

Here is the 2026 reality from this site’s own tracking. I run a daily DDR5 price capture against named direct US retailers; in the August 24, 2026 capture the cheapest qualifying 32GB (2x16GB) DDR5-6000 offer was $469.59 (a kit the index flags as looser-timed than its line’s CL30 label; the cheapest non-RGB line sat at $479.99, and that line’s true CL30 kits at $619.99) - versus the ~$80-100 the same class sold for in mid-2025. The crisis explainer covers why prices tripled to quadrupled and when relief might come. Three rules keep the purchase from becoming a second problem:

Replace the kit, not the stick, when you run paired modules. Mixing a new stick into a surviving half-kit means unmatched silicon negotiating shared timings - the exact recipe for the marginal instability you just spent a week diagnosing. Kits are sold, binned, and validated together.
Don’t panic-buy four sticks. Two sticks of the capacity you need beats four sticks of half that; the four-DIMM ceiling applies double during a price crunch, when 2x32GB money is tempting to split into cheaper 4x16GB mistakes.
Size it once, deliberately. If you’re replacing anyway, the how much RAM do you need breakdown is the five-minute read that stops both under- and over-buying. When you’ve settled on a spec, a matched 32GB DDR5-6000 kit is the mainstream pick - check current prices against the index’s direct-retailer observations before you commit.

Keeping it stable

The fix that lasts is the boring one. Run the profile your specific combination proved it can hold - which sometimes means JEDEC, and that’s fine; the measured gap between JEDEC and a rated profile in typical desktop work is small enough that stability wins the trade. Two sticks, matched, in the slots your board’s manual names. Retest with MemTest86 after any BIOS update that touches memory settings, because “updated defaults” have re-enabled more than one profile that a machine had banished for cause.

And keep the one habit that makes every future blue screen cheaper: when it crashes, read the stop code and the subcode before touching anything. The stop-code decoder maps each code to its own guide - this page is the 0x1A entry in that family, 0x139 and 0x50 are its siblings, and the difference between them is exactly which test you run first.

Sources

Stop code identity and subcodes: Microsoft’s Bug Check 0x1A MEMORY_MANAGEMENT reference (retrieved 2026-08-25) - the severe-memory-management-error definition, the parameter-1 subcode table including the probable-hardware-error and in-page CRC entries, and its suggestion to run Windows Memory Diagnostic. The multi-cause framing and test ordering here follow that document’s own subcode taxonomy, corroborated across Microsoft Q&A, Reddit r/techsupport and r/overclocking, Tom’s Hardware, and LinusTechTips forum threads on this code.
Memory testing doctrine: PassMark’s MemTest86 troubleshooting documentation (retrieved 2026-08-25) - errors are valid in the vast majority of cases, not all errors are the RAM itself (CPU/cache/motherboard are possible), single-stick isolation as the method for naming a failing module, and retesting at standard non-XMP timings when BIOS settings are aggressive. Windows Memory Diagnostic (mdsched.exe), WinDbg’s !analyze -v, and CrystalDiskInfo SMART reading are standard documented tools.
Pricing: TechFuelHQ’s own DDR5 RAM price index - dated, per-capacity observations at named direct US retailers with the method and rejection log published; figures above are the 2026-08-24 capture. Market context in the RAM & SSD price crisis explainer.

Windows 10/11 instructions, current for 2026 builds. Settings paths may sit one step elsewhere on older versions. Report problems to hello@techfuelhq.com.

Why Hard Drives Got So Expensive in 2026 (and What to Do About It)

LK Wood IV — Wed, 26 Aug 2026 00:00:00 -0500

By LK Wood IV · 2026-08-26 · ~12 min read · St. Louis County, MO

$489.11. That is what Best Buy asked for a WD Red Pro 8TB on August 25, 2026 — the same listing, same retailer, that had listed at $402.99 two days earlier. A 21 percent jump in 48 hours, on a drive camelcamelcamel tracked as low as $189.99 in July 2024.

Multiply that shock across every NAS builder, backup hoarder, and Plex admin refreshing a cart this year and you get the anger filling an r/homelab thread titled “Hard drive prices have doubled over one year. WTF is going on” (340+ comments when I pulled the SERP on August 25), plus fresh siblings in r/selfhosted and r/DataHoarder. The threads argue from screenshots. This page argues from a dated, downloadable price series I run myself, plus the primary statements from the two biggest makers of the drives you can buy.

TL;DR · The 2026 hard drive squeeze

What happened: retail HDD prices rose 20-50% by early 2026 and kept going. ComputerBase's tracker had them up 129% vs September 2025 by mid-August. Our own three same-day captures put new 8TB drives at $41-61 per TB, 1.7-2.6x the tracked 2024 low for the same Red Pro SKU.
Why: AI data centers bought the supply. WD says it is sold out through calendar 2026; Seagate calls nearline capacity fully allocated. Neither is expanding production.
When it ends: nothing citable points to consumer relief before 2027, and contracts already run into 2027-2028.
What to do: buy what the build needs and skip the stockpile. If a build is blocked on a drive, buy the low end of the measured range now; if you can wait a year, wait. The per-case calls are below.

What an 8TB NAS drive costs right now, measured

I run a price capture against Google Shopping for twelve named 8TB drive lines — NAS, surveillance, enterprise, desktop — and publish every qualifying observation with its date in the HDD price index. The rules are strict on purpose. A listing only counts if it comes from a named direct US retailer (no marketplace storefronts), states the exact line and the 8TB capacity in its title, is a single new internal drive (no multi-packs, no external enclosures), and is not recertified or white-label. Most listings fail. On day one, 672 of 673 did.

Here is what qualified in the day’s final capture on August 25, 2026 — the one published in the index’s downloadable CSV:

Drive	Price	$/TB	Retailer
Seagate IronWolf 8TB	$329.99	$41.25	Best Buy, Newegg
WD Gold 8TB	$369.99	$46.25	Central Computers
Seagate Exos 7E10 8TB	$379.99	$47.50	Adorama
WD Red Pro 8TB	$379.99	$47.50	Newegg

Four lines out of twelve. Every row carries verification_status: discovery_only; I have not phoned a warehouse to confirm stock, and the index says so rather than hiding it. One open flag carried from the index: the Exos 7E10 row’s listing title reads SAS while the tracked part is the SATA variant, ST8000NM017B. Unresolved. That row stays discovery-only until a retailer page settles it.

Two things in that table deserve their own paragraphs.

The WD Red Pro swing is real and I can show the receipts. One Best Buy listing, same product cluster and same seller across captures: $457.04 on August 22, down to $402.99 on August 23, up to $489.11 on August 25 (on August 24 the same cluster surfaced under Newegg instead, a seller flip the index does not treat as comparable). That is a 21 percent range inside four days on a single SKU at a single retailer. Anyone quoting you “the” price of a drive this month from one screenshot is off by up to a fifth before they finish typing.

Single snapshots lie even harder within a day. I ran three captures on August 25. The first saw the Red Pro at Best Buy for $489.11 and no first-party IronWolf anywhere; the third, twelve minutes later, saw the IronWolf at two direct retailers and the Red Pro at Newegg for $379.99, which is $109 under the Best Buy ask on the same Google product listing. Same afternoon, same method, different slices of Google Shopping’s inventory. This churn is exactly why the index refuses to publish a headline median until six of the twelve tracked lines qualify on the same day — a gate that has stayed closed since the pilot began on August 12 — and why the honest unit of evidence here is a dated series, not a screenshot.

The marketplace premium showed up the same day. Across the day’s captures, marketplace storefronts on Newegg asked $469.99 and $513.99 for the same IronWolf 8TB that Newegg itself and Best Buy listed at $329.99 — 42 to 56 percent over the direct price. The index rejects those rows. Your cart should too.

Step 1: what kind of buyer are you?

There is no one answer to “should I buy a hard drive right now.” There is an answer per situation, and the honest way to order them is by what a wrong call costs you, so that is the order used here.

Building a NAS you need this year. Buy, and buy the boring low end of the measured range. In the day’s captures that means the cheapest qualifying line, IronWolf 8TB at $41.25/TB, over the premium lines that ran $46-61. The NAS drive buying guide carries the actual picks and the CMR-vs-SMR rules; the Seagate line comparison settles IronWolf vs Pro vs Exos. Waiting costs you a year of not having the machine, and nothing citable says next spring is cheaper.

Expanding an existing pool. Size the real need first with the NAS storage calculator. RAID and filesystem overhead mean the terabytes you must buy are not the terabytes you get. Then buy only the expansion and skip the “while I’m at it” spare. At $41-61/TB, speculative spares are the most expensive comfort object in the hobby.

Backup-only. You need capacity once, not performance, and this is where used and recertified enterprise drives earn their keep if you accept the trade; more on that two sections down. A backup target with redundancy plus an offsite copy tolerates a cheaper drive; the restic offsite backup guide covers the pipeline half.

Media hoarding at scale. You feel this market hardest, because $/TB is your whole cost model and on the tracked Red Pro SKU it doubled, from a $189.99 Amazon low in July 2024 to $379.99 listings now. Shop by $/TB across 8-16TB rather than assuming bigger is cheaper. Our July pull found the 12TB Red Plus pricier per TB than the 8TB. Recertified big-capacity CMR is the standing value play, eyes open.

No urgent need. Do nothing. Prices this distorted make “upgrade because it’s Tuesday” a luxury purchase. Check the index monthly; it exists so you can see a real trend instead of guessing from forum sentiment.

Why are hard drives so expensive in 2026?

Because the people who make them sold out. Literally, and they said so in public.

On Western Digital’s second-quarter earnings call, as reported by heise in February 2026, CEO Irving Tan told analysts the company is “pretty much sold out for calendar year 2026,” with “firm purchase orders with our top seven customers through calendar year 2026” and, per the same report, long-term agreements with three major customers extending through 2027 and 2028. Seagate’s CEO Dave Mosley said the same thing in his own words: nearline capacity “fully allocated through calendar year 2026,” with order-taking for the first half of 2027 expected “in the coming months.” Per heise’s report, nearline — the high-capacity 3.5-inch class that cloud and AI buyers take — is 87 percent of Seagate’s hard drive sales, and the company is not expanding production capacity to chase the spike.

Sit with that combination for a second. The two biggest hard drive makers have pre-sold their output to a handful of hyperscale customers, years forward, at contract prices. Nobody cut a factory’s output this time. The factories are running; their output just has someone else’s name on it.

Retail gets the remainder, and the remainder got expensive fast. Tom’s Hardware measured an average 46 percent rise across popular high-capacity drives between September 2025 and mid-January 2026, with the 24TB BarraCuda crossing $500. heise put the broader retail rise at 20-50 percent by mid-February. By ComputerBase’s August 15, 2026 storage-price check — a German price-comparison basket that deliberately excludes eBay and marketplace scalpers — hard drives stood 129 percent above September 2025, a new record for the series and still climbing month over month. German retail is not US retail, but it is the cleanest continuously-published basket anyone maintains, and our own US spot observations sit at 1.7x to 2.6x the tracked 2024 low, depending on the line.

Why did it hit hard drives later than RAM?

The RAM and SSD half of this story broke first and broke harder: memory makers reallocated wafer capacity toward AI data-center memory, and consumer DDR5 and NVMe prices roughly tripled through 2025 into 2026. That page carries the mechanism and the numbers; the two-sentence version is that your DIMM lost a bidding war to a server.

Hard drives lagged for a structural reason. DRAM and NAND trade close to spot: when wafers moved, consumer prices moved within weeks. Nearline hard drives sell overwhelmingly on long-term contracts, so the AI demand surge spent 2025 quietly consuming contract capacity before retail felt anything. ComputerBase’s single instrument shows the sequencing plainly: by August 2026 its RAM basket was up 345 percent from September 2025 while hard drives were up 129. The same shock, arriving through a slower pipe. The HDD story only broke into mainstream coverage in mid-January 2026, months after the RAM side’s climb began. If you extrapolate one from the other, the drive squeeze is the one with room left to run, which is also what the sold-out-through-2026 statements imply.

New vs recertified vs SSD: the $/TB math

New drives are the numbers in the table above: $41-61/TB across August 25’s captures, or 1.7x to 2.6x the $23.75/TB July-2024 Amazon low camelcamelcamel tracked for the Red Pro SKU. Enterprise buyers fare differently. Forbes’ Tom Coughlin puts a 30TB enterprise HDD at $668 in Q1 2026, about $22/TB and up 35 percent from Q2 2025. A 30TB drive is cheaper per terabyte by construction, so part of that gap is capacity tier; the rest is who holds allocation. You are not on that list.

Recertified drives are the traditional escape hatch, and they still undercut new: our NAS guide’s July 3, 2026 pull found a recertified 16TB IronWolf Pro at $31.25/TB, about 22 percent under the same model new. But recert is a different product (seller warranty instead of manufacturer warranty, unknown prior duty), and its supply is drying up for the same reason new supply did. Recertified stock comes from returns, overstock, decommissioned fleets (none of it a steady pipeline), and How-To Geek reported prices climbing back in October 2025 as data centers ran drives longer and returns got pressed back into service instead of hitting the recert channel. The index tracks new drives only and rejects recertified listings by rule, precisely so the two markets never blur into one number.

SSDs do not rescue you. The same AI demand hit flash at least as hard: ComputerBase’s August check had SSDs up 126 percent from September 2025, and Coughlin’s Q1 2026 enterprise comparison put QLC SSD capacity at 22.6 times the cost of equivalent HDD capacity. At retail, a 2TB NVMe ran $300-480 by mid-2026, which is $150-240/TB against our measured $41-61. Buy SSDs for speed. Bulk terabytes still belong to spinning rust, even angry-priced spinning rust.

When will hard drive prices drop?

Everything in this section is a projection and labeled as one; here is what the projections rest on.

The supply side has told you its calendar. WD: sold out through calendar 2026, some agreements into 2027 and 2028. Seagate: fully allocated through 2026, order books for early 2027 opening “in the coming months” — a phrase from the February 2026 report that describes demand stretching into next year rather than easing. Neither company announced meaningful capacity expansion; Seagate explicitly said it is not expanding nearline production. Meanwhile the retail trackers were still printing record highs in mid-August 2026.

So the floor of any honest forecast is: no relief while current supply is contractually spoken for, which is at minimum the rest of 2026. Whether 2027 brings actual consumer relief depends on AI storage demand cooling or new capacity arriving, and no source cited here commits to either. I am not going to invent a quarter. What I will commit to is the falsifiable version: the index publishes dated observations on a fixed method, so when the turn comes it will be visible in a CSV instead of argued from vibes. As of August 25, 2026, it has not come.

The reliability question the prices force

At $24/TB, a dead drive was an annoyance. At $47-61/TB it is a budget event, and it changes two decisions.

First, brand risk is now money. A peer-reviewed study of 443,156 Backblaze data-center drives by Christoph Siemroth of the University of Essex and Yeomyung Park covered 1.66 million drive-years from 2013 through mid-2025, and it found HGST drives failing at about 41 percent of Seagate’s rate with WD near 52 percent, while Toshiba landed slightly worse than Seagate, holding age, capacity, form factor, and temperature constant. Blocks & Files’ writeup quotes the authors’ conclusion plainly: “HGST HDDs are the most reliable, whereas Toshiba is the least reliable, closely followed by Seagate.” Those are enterprise-fleet statistics rather than a verdict on the specific NAS drive in your cart, and the authors flag the usual censoring caveats. But when the price of replacing a failure doubles, a measured factor-of-two difference in failure rate stops being trivia.

Second, redundancy math shifted. RAID parity and a 3-2-1 backup pipeline used to be cheap insurance; now the insurance premium doubled along with the asset. That argues for buying the reliability question down with data rather than paying $60/TB for a badge; workload ratings and warranty terms per line are in the IronWolf vs Pro vs Exos comparison.

How I track this

The numbers on this page that nobody else publishes come from a collector I run against Google Shopping’s US listings for twelve named 8TB drive lines. Every capture stores the complete raw API response, every accepted offer, and every rejected offer with machine-readable reasons; the qualifying observations publish as a dated CSV under CC BY 4.0 on the HDD price index page, method and change log included. Three captures ran for this article on August 25, 2026; their full evidence sits in the site’s repository alongside the dailies that preceded them.

The index’s headline metric (median cheapest $/TB across lines) stays unpublished until six of twelve tracked lines qualify on one day, and that gate has not opened yet. The observations you saw above are exactly what they claim to be: dated, rule-filtered spot prices from direct retailers, nothing more. When a competitor, a Reddit thread, and an AI answer all quote different hard drive prices this year, the difference is usually the date and the seller class. Ours are stamped with both.

If the price move matters to your build budget beyond drives, the RAM and SSD crisis page covers the other half of the 2026 storage bill, and DAS vs NAS settles whether you need a drive array at all before you price one.

Best Local LLM for Coding in 2026: Tested on a 16GB RTX 5080

LK Wood IV — Tue, 25 Aug 2026 21:20:00 -0500

52 GB.

That is the Q4_K_M download size of qwen3-coder-next, the model the top Reddit answer and a front-page tech-site article both point you at when you search for the best local coding LLM. My GPU has 16 GB. So, probably, does yours. The 5080, the 4080, the 5070 Ti, the 4060 Ti 16GB are the cards people actually buy, and most of the pages ranking “local” coding models never check whether their picks load on any of them.

So I checked. Then I went further. Every model that plausibly fits a 16GB card went through the same eight coding tasks (bugfix, feature-from-spec, test-writing, refactoring, explaining legacy code, SQL and regex, and a two-turn agentic tool-calling exercise) on my own RTX 5080, twice each at temperature 0, scored mechanically by executed checkers rather than by me nodding at the output. The prompts are published as a versioned JSON file so you can rerun the whole thing tonight. Per-rep results are a CSV. Tokens per second, VRAM figures, and load times live in the same open dataset that already tracks this card.

Scope, stated plainly: one retail RTX 5080, ollama 0.32.1, driver 610.88, August 2026. “Best” below means best in these tests on this card.

Picks as of August 2026, by VRAM tier

Your VRAM	Pick	Why	First-party?
16 GB	gpt-oss:20b	Only model to pass 8/8 tasks; fully resident at 178-190 tok/s	Tested here
16 GB, quality ceiling	Qwen3-Coder 30B (offloaded)	6/8 + best tool-calling; 74% GPU-resident, speed hangs on free system RAM	Tested here
12 GB	qwen2.5-coder:14b	9GB file fits; 5/8, solid for non-agentic work	Task results tested here; no 12GB card owned
8 GB	qwen2.5-coder:7b	4.7GB file fits; 4/8; completion and chat	Task results tested here; no 8GB card owned
24 GB+	Qwen3-Coder 30B fully resident	Cited below; I don’t own the card	No

Dated on purpose. Local-model rankings rot in weeks — the current dense mid-size Qwen went 3.5 to 3.6 to 3.8 within months — so this table carries its date and the changelog records revisions. If the date reads stale, assume the picks are too.

What the top-ranking lists get wrong

Before testing anything, I fit-checked the recommendations that currently rank for this search against the registries they install from. Three verifiable problems, receipts linked.

A top-ranking 16GB guide recommends a model that does not exist. The page (updated 2026-05-15, archived snapshot) recommends “Llama 3.3 14B Q5_K_M (10.1 GB),” with benchmark scores and a December-2025 release story attached. Meta’s own model catalog carries Llama 3.3 at exactly one size, 70B. The same page recommends a “Qwen3-Coder 32B”; the family ships at 30B and 480B.
The community’s favorites often need 3-4x your VRAM. qwen3-coder-next, genuinely excellent by every account, is a 52GB download at Q4_K_M. DeepSeek V4-Flash, a fixture of “self-hosted coding” lists, is 291 billion parameters. Kimi K2.7 Code’s ollama entry is a cloud-routed tag, not local weights at all.
Speed claims travel without their hardware. The most-quoted number for Qwen3-Coder 30B, 220 tok/s, comes from a guide whose own tier chart puts the model in a “24GB sweet spot” and never names the GPU it ran. On a 16GB card the same model cannot fully load. The measured number is below.

No accusation about how any of those pages got written. The errors speak for themselves, and they are the reason this page exists: every number on it comes from one named card, by a method you can rerun.

How I tested

Same rig as the throughput dataset: retail RTX 5080 (16,303 MiB), Ryzen 7 7800X3D, 32GB RAM, Windows 11, ollama 0.32.1, driver 610.88. Models pinned by digest in the raw logs, because tags move.

Eight tasks, each scored by a machine.

Bugfix. A binary search returning the wrong boundary; the fix must pass 8 cases.
Implement from spec. parse_duration("1h30m15s"), with ten ValueError traps.
Write tests. Given a working LRU cache, write a check() strong enough to pass the real implementation and also kill a planted mutant that evicts the wrong entry.
Refactor. Collapse triple copy-paste into a helper. Behavior must stay identical across five input sets, and a helper function must exist.
Explain legacy code. An unlabeled Luhn implementation; name it.
SQL. A join with an aggregate and a HAVING filter, executed on seeded SQLite and compared row-for-row, with boundary rows planted on purpose.
Regex. A semver matcher against 17 match/no-match cases via re.fullmatch.
Agentic tool-calling. Two function schemas, one two-step request. A pass requires correct structured tool calls, the thing an agentic coding tool (aider, opencode, Continue) consumes. Prose descriptions of what the model “would” do score zero.

Identical prompts, temperature 0, seed 42, 8k context, two repetitions. A task counts only when both reps pass; one-of-two is reported as flaky, never rounded up. Two scoring defects I found and fixed during the build are worth naming, because benchmark pages never admit these. My reference LRU crashed on a capacity-0 probe, which punished exactly the models thorough enough to test that edge. My refactor checker initially rejected helpers nested inside the function, which is a perfectly good refactor. Both fixtures were fixed and every affected task re-run for every model. The eval is versioned. So are its mistakes.

What this is not: SWE-bench. Eight tasks cannot rank frontier coding ability — Aider’s leaderboard exists for that. They are built to separate “autocompletes plausibly” from “follows the spec, checks the edges, and drives tools” at exactly the size class a 16GB card forces on you.

The 16GB tier, measured

Model	Bugfix	Spec	Tests	Refactor	Explain	SQL	Regex	Tools	Stable
gpt-oss:20b	pass	pass	pass	pass	pass	pass	pass	pass	8/8
Qwen3-Coder 30B	fail	pass	1 of 2	pass	pass	pass	pass	pass	6/8
devstral:24b¹	pass	fail	pass	pass	pass	pass	fail	pass	6/8
qwen2.5-coder:14b	pass	fail	fail	pass	pass	pass	pass	fail	5/8
qwen2.5-coder:7b	pass	fail	fail	pass	pass	pass	fail	fail	4/8

¹ devstral ran at 4k context; the exception is explained two sections down.

gpt-oss:20b swept it. Eight for eight, both repetitions. That includes the only perfect two-turn tool-calling run, and a capacity-0 edge-case test on the test-writing task strict enough to break my original checker. It is also the fastest real option at this tier. The 13.4GB MXFP4 build stays fully GPU-resident, decodes at 178-190 tok/s across two dated captures in the dataset’s controlled runs, and held ~152-156 tok/s while doing actual eval work with a checker pipeline running beside it. The eval settled something the throughput table couldn’t. The MoE speed champion from the MXFP4 analysis is also the best-behaved coding model at this size.

Qwen3-Coder 30B is the interesting one. The community is right that it is strong. Best-in-eval tool-calling (both calls, correct arguments, single turn), clean SQL, clean regex, clean spec work. Two honest dents. It failed the plainest task on the sheet, the binary-search boundary fix, in all four scored repetitions across two runs. Its test-writing was flaky. And it does not fit: ollama’s 19GB Q4_K_M ran 74% GPU-resident at 8k context, and the dataset’s controlled cells put it at 62 tok/s at 4k context and 52 at 16k — brisk for a spilling 19GB model (the MoE only activates ~3B parameters per token), still a third of gpt-oss’s rate. Treat even that number as conditional. The same model measured anywhere from 0.7 to 83 tok/s across three host-memory states, which is the next section’s story.

devstral is the specialist showing its age. Mistral’s dedicated agentic coder (still the newest dedicated one on ollama, at over a year old) wrote the best tests of any model here and tool-called cleanly. Its SWE tuning shows. It also failed spec-following and regex, and its 14GB file plus KV cache would not stay resident at 8k context on this card.

The qwen2.5-coder pair is what “coder model” meant in 2024, measured in 2026. Both aced the bugfix, the refactor, the SQL task, and code explanation. Both failed the same three modern requirements. Strict spec-following: each accepted "15s1h" as a valid duration, ignoring the stated unit order. Test-writing: the 14B’s recency test asserts the wrong eviction victim, so the test itself misunderstands LRU. And structured tool-calling, where both produced prose descriptions instead of tool calls. Fine completion engines. Not agents.

System RAM quietly gates offloaded models

Nobody’s tier list mentions this, and it cost me half a benchmarking night. When a model spills past VRAM, its speed is hostage to free system RAM. Same card, same model, same night: Qwen3-Coder 30B decoded at 83 tok/s with ~20GB of system RAM free, and at under 1 tok/s while a pair of runaway indexing jobs had the machine down to 1.2GB free and paging. The dense devstral collapsed the same way at 8k context (0.8 tok/s) with far less spilled. If you run a spilling model, budget real RAM headroom for the spilled layers, or stay resident and keep the speed. The VRAM calculator tells you which side of that line a model lands on, and the VRAM tier guide owns the fit math in depth.

12 GB and 8 GB: what transfers and what does not

A VRAM-capped 5080 is not an 8GB card. Restricting my GPU would fake the memory ceiling while keeping 5080 bandwidth and compute, so I did not do it, and no number here pretends otherwise. What I can honestly hand you:

Task results transfer. qwen2.5-coder:14b at Q4_K_M is a 9GB file that fits a 12GB card with context room. Its pass/fail rows above are properties of the weights, not of my GPU. Same for qwen2.5-coder:7b (4.7GB) on 8GB cards.
Speed numbers do not transfer. My tokens per second came from a 960 GB/s card. For the budget tier, the RTX 5060 walkthrough has first-party numbers from that class of card. Beyond it, demand a GPU name next to any tok/s figure you read.
The quality cliff lives in the quant. A 12GB card running the 14B at Q4_K_M gets exactly the model I tested. Squeezing a larger model in via Q2/Q3 quants gets you a different, worse model, whatever the tier. The quant mechanics piece shows why.

24 GB and up, cited rather than tested

I don’t own a 24GB card, so this section is fit math and labeled third-party positioning. No borrowed benchmarks.

Qwen3-Coder 30B fully resident is the obvious 24GB move. The same 19GB file that spills here loads whole there, and its task profile above is second-best on this page even with the handicap.
Qwen3.8-27B, the current dense mid-size Qwen (mid-August 2026): Unsloth’s UD-Q4_K_M GGUF is 16.5GB. The weights alone match this card’s entire memory, the classic one-gigabyte-too-far case. On 24GB it fits with room. Untested here.
Laguna XS 2.1 (Poolside’s 33B) quantizes to roughly 19-20GB. Same story as the 30B, without the MoE discount on offload.
qwen3-coder-next (52GB) and gpt-oss:120b (65GB) are 48-64GB-class machines’ problems. The VRAM tier guide covers that end.

Agentic coding: which models drive tools

The task that split the field cleanest is the one the field argues about most. Given two function schemas and “create the directory, then write the file,” scored on structured tool calls only:

gpt-oss:20b made the correct create-directory call, took the tool result back, and followed with a correct write-file call carrying the exact content. Both reps. This is the loop an agentic coding tool runs all day.
Qwen3-Coder 30B emitted both calls with correct arguments in a single turn. Also correct, arguably more efficient. One nuance for tinkerers: ollama parses this model’s tool-call format at the engine level, so you get structured calls even though its chat template never mentions tools.
devstral delivered a clean create-then-write across two turns.
qwen2.5-coder 7B and 14B described what they would do, in prose, both reps, tools unused. If your workflow is aider-style automation, that is a disqualifier no HumanEval score will warn you about.

When the cloud is honestly better

If your daily work is large multi-file refactors across an unfamiliar codebase, a frontier hosted model is still better than anything on this page, and no amount of local-AI enthusiasm changes it. The local case is different and real. Unlimited volume at zero marginal cost, with code that never leaves the machine and keeps working offline. And, as of this eval, genuinely competent spec-following and tool-driving at the 16-20B class. The break-even calculator does the cost half of that argument with your numbers instead of mine.

Running the winner

ollama pull gpt-oss:20b and it fits with room to think at 8k context. The practical notes from living with it during this eval: it spends tokens on reasoning before answering (the 4096-token output budget here exists because a 2048 cap cut off one of its correct answers mid-fence), it held 178-190 tok/s across the dataset’s two captures at 4k and 16k context alike, and it pairs with Ollama or llama.cpp equally well. llama.cpp squeezes out a bit more decode if you want it. For the offloaded 30B path instead, budget a ~15GB whole-GPU footprint, expect roughly 62 tok/s at 4k context and 52 at 16k on this card when system RAM is free, and read the dataset’s offload note before trusting any single number for a spilling model — including mine.

Method, limits, changelog

One card, one runner, one driver, eight tasks, two reps. Enough to rank what fits a 16GB card for coding work. Nowhere near enough to rank frontier models. Quantization was Q4_K_M-class throughout (MXFP4 for gpt-oss). NVFP4, the Blackwell-only 4-bit path, shows mixed community results and ollama does not expose it, so it stays cited rather than quoted. Task outcomes are near-deterministic at temperature 0 but not guaranteed identical across driver or runtime versions, which is why every rep sits in the published CSV with its model digest and runtime version attached.

2026-08-26 — v1. Five models, eval v1, throughput dataset v1.1.0.

Corrections to measured rows land in the dataset changelog; pick revisions land here, dated. The next scheduled look is the next model-meta shift. Lately that has been monthly.

Jellyfin Remote Access: Pick the Right Path for Your Situation (2026)

LK Wood IV — Tue, 25 Aug 2026 00:00:00 -0500

By LK Wood IV · 2026-08-25 · ~12 min read · St. Louis County, MO

Jellyfin does not have a relay. That single architecture fact generates the question this page answers. When a Plex user hits play from a hotel, Plex’s own infrastructure brokers the connection; when Plex put that convenience behind a paywall in 2025, the migration wave toward Jellyfin began, and every migrant hit the same wall about a week in. Jellyfin gives you a checkbox that says Allow remote connections to this server and leaves the actual path from the outside world to your basement entirely to you.

The r/jellyfin community answers this question so often that a post sitting at 279-plus upvotes as of late August 2026 is literally titled “I’m kinda tired of the constant remote access questions” — 250-plus comments of people relitigating the same four options. Listing the options was never the hard part. Matching one to your situation is. So this guide routes first and explains second.

TL;DR · Route yourself before reading anything else

Your situation	Use this
Just you, on your own phone and laptop	Tailscale (Path 1)
You + household, every device can install apps	Tailscale, apps on each device (Path 1)
Family elsewhere, watching on smart TVs	Reverse proxy + your own domain (Path 2)
Family elsewhere on TVs, but your ISP uses CGNAT	VPS relay: Pangolin or WireGuard bounce (Path 3)
Non-technical viewers who will not install anything	Reverse proxy - a URL in a browser is the only universal client (Path 2 or 3)
Hotel room / a TV you do not own	Travel streaming stick with Tailscale, or laptop + HDMI (device table below)
Roku in another house	Reverse proxy or VPS relay - no Tailscale client exists for Roku
Tempted by Cloudflare Tunnel because it is free	Read Path 4 first - video streaming sits against Cloudflare's CDN terms

Why “just use Tailscale” keeps failing people

Tailscale is the default answer in every thread, and for the person asking, it is usually right. It is also the answer I give for a solo setup, so this is not a takedown. The failures cluster in one place: the devices you do not control.

Tailscale reaches a device by running a client on it. The client coverage is better than most people assume in 2026 - there is an Android TV app in the Play Store, an Amazon Appstore app for Fire TV (most devices after 2018, though Tailscale states it does not support the Fire TV Stick 4K Select), and an Apple TV app. But Tailscale’s supported-platform list ends there for TVs. No Roku. No LG webOS. No Samsung Tizen. Jellyfin ships official apps for all three, so the missing piece is the network path. Your mother-in-law’s Roku can run Jellyfin; it cannot run your VPN.

The second failure is human. A tailnet wants an account relationship with every participant: you either share devices to their Tailscale account or manage logins for them. For a household that tolerates you, fine. For the relative who calls when the TV “stopped working,” each moving part you added is a future phone call. The 100-plus-comment version of this complaint is “I’m eyeing Jellyfin (currently use Plex w/ a Lifetime pass)”, a holder of the old Plex deal asking whether Jellyfin can match that remote simplicity for non-technical family - and the honest answer is: only if you build the path that needs nothing installed, which is Path 2.

So run Tailscale when you control the endpoints, and something with a plain HTTPS URL when you do not.

Path 1: Tailscale (or another mesh VPN)

This is the path for you, your own devices, and a household that installs apps. It costs $0. The free Personal plan covers up to 6 users with unlimited devices, which is most homes.

The mechanics are in our Tailscale homelab guide — client on the server, client on each viewer, then the Jellyfin apps talk to http://<tailscale-ip>:8096 from anywhere. The Jellyfin Docker guide covers the server side in Step 6. Traffic stays WireGuard-encrypted end to end, nothing is exposed to the internet, and CGNAT does not matter because every connection is outbound.

Two honest caveats. Battery and cellular behavior on phones is solved, but every viewer’s device must keep its VPN toggled on, and the failure mode when it silently is not - “your server is down” - lands on you. And if you would rather self-host the coordination server too, that is Headscale, with the same client math.

Do not confuse this path with Tailscale Funnel, which publishes a tailnet service to the open internet through Tailscale’s relays. Tailscale documents Funnel traffic as subject to non-configurable bandwidth limits - a constraint that rules it out for pushing video at your family every evening.

Path 2: Reverse proxy + your own domain

This is the path for family on TVs and for viewers who install nothing, because any client with a browser or a Jellyfin app that accepts a URL can reach it. It needs a public IPv4 address and ports 80/443 forwarded on your router. The only recurring cost is an ordinary domain registration, since the proxy automates a free Let’s Encrypt TLS certificate.

This is the path I validated end to end while writing this guide, on a bare Windows box with no Docker, because the claim “a reverse proxy in front of Jellyfin is fiddly” deserved a test. It is not fiddly anymore. The sequence, timed:

Jellyfin 10.11.11 portable zip unpacked to a folder and started: about three minutes from download to a listening server on port 8096. No installer, no admin rights.
The setup wizard’s Set up Remote Access screen shows one checkbox — Allow remote connections to this server — already checked by default. I verified the shipped network config afterward through the API: remote access on, UPnP off, HTTPS off, Known Proxies empty. Jellyfin never opens your router for you and never brings its own TLS - both are deliberately your job, and both are exactly what the proxy provides.
Caddy as the proxy, one binary, and the entire working config is this:

media.yourdomain.com {
 reverse_proxy 127.0.0.1:8096
}

That is the whole file. With a real domain pointed at your IP, Caddy obtains and renews the Let’s Encrypt certificate on its own. Against my local instance I watched the three things that historically break proxied Jellyfin all come back clean: the web client served, logins authenticated, and the websocket upgrade returned 101 Switching Protocols with zero websocket-specific configuration. That last one matters because Jellyfin’s reverse-proxy docs warn that not every proxy passes websockets by default - nginx wants explicit upgrade headers, and the equivalent toggle is the classic missed step in Nginx Proxy Manager. Caddy is also what Jellyfin’s own docs recommend first, “for its ease of use.” On the same evidence, I concur. (Choosing between Caddy, NPM, and Traefik is its own comparison.)

One Windows-specific wrinkle from the test worth passing on: Caddy’s self-signed local mode pauses on an interactive certificate-trust prompt. Irrelevant for the real deployment - public certificates involve no local trust store - but if you dry-run with local_certs first, expect that prompt.

Two settings finish the job properly. Add the proxy’s IP to Known Proxies in Jellyfin’s networking settings, or every viewer shows up in your logs as the proxy’s address instead of their own - the docs flag this, and the fresh-install default I captured (empty list) means it is always on you to set. And leave Jellyfin itself listening on plain 8096 bound to localhost or the LAN; the proxy is the only thing that should face the world. Never forward 8096 directly - that is unencrypted HTTP with your login page on it, and it is the port-forward horror story the community warnings are actually about.

What kills this path is not skill. It is CGNAT - if your ISP does not give you a real public IPv4, no amount of port forwarding helps, and dynamic-DNS tricks change nothing. Check before you buy a domain. If your router’s WAN address falls in the 100.64.x-100.127.x range (RFC 6598 shared address space), or the “what is my IP” number differs from the router’s WAN number, you are CGNATed and you want Path 3.

Path 3: VPS relay - the CGNAT escape hatch

This fits everything Path 2 fits, for the case where the ISP will not give you a public IP or you refuse to open home ports. The going figure in the community threads is about $5/month for a small VPS.

The idea is to rent the public IP you do not have. A minimal VPS gets the public endpoint; your home server connects outward to it; visitor traffic enters the VPS and rides that outbound tunnel home. Three implementations, in ascending order of hand-holding:

WireGuard bounce - the DIY version. WireGuard on both ends, forwarding rules on the VPS. Full control, most assembly; our WireGuard on Proxmox guide covers the VPN half.
FRP (fast reverse proxy) - the same shape with a purpose-built tool, popular in the budget threads.
Pangolin - the project that broke out in 2026, and the reason this section is not just “run WireGuard.” It is a WireGuard-based, identity-aware tunneled reverse proxy: dashboard, per-app authentication, Let’s Encrypt handling, all self-hosted. Its own requirements state the deal plainly: a Linux server with a public IP, a domain, and ports 80/443 (TCP) plus 51820/21820 (UDP). At 22.5k GitHub stars it has become the default answer to “self-hosted Cloudflare Tunnel alternative,” and there is a managed free tier (5 users, 5 sites) if you want to try the model before renting anything.

The trade nobody advertises: every stream now transits the VPS, so your remote picture quality is capped by the VPS provider’s bandwidth and your home upload, whichever is worse. Budget VPS bandwidth caps are real; check the fine print against your bitrates before moving the family movie night onto one.

Path 4: Cloudflare Tunnel - free, easy, and built on someone else’s tolerance

Cloudflare Tunnel deserves its reputation for polish: outbound-only connector, free HTTPS URL, CGNAT-proof, no client software for viewers. For a wiki or a dashboard I recommend it without hesitation - the full comparison against Tailscale covers where it shines.

For Jellyfin specifically, read the terms before you build on it. Cloudflare’s service-specific terms, as published on 2026-08-25, state that unless you are an Enterprise customer, “Cloudflare offers specific Paid Services (e.g., the Developer Platform, Images, and Stream) that you must use in order to serve video and other large files via the CDN,” and that Cloudflare “reserves the right to disable or limit your access to or use of the CDN” if you serve “video or a disproportionate percentage of pictures, audio files, or other large files” without them.

Streaming your library through a free tunnel is exactly that. The record supports two observations at once. Enforcement against small personal servers is rare in practice — the community is full of people doing it quietly — and no threshold is published anywhere, so any “under X TB you’re fine” claim you read is folklore, not policy. Both things are true, and together they mean the availability of your family’s media server depends on a policy Cloudflare applies at its own discretion. That is a fine risk for an experiment and a bad foundation for the thing your household relies on. There is also a mechanical constraint that bites before the policy does: the 100 MB request-body cap on free plans breaks large uploads through the same hostname.

If the tunnel’s shape is what you want - outbound-only, no exposed home ports, URL for everyone - Pangolin in Path 3 is that shape with the policy risk replaced by a small VPS bill.

The device truth table

The rows are where remote-access plans actually die. “Works” here means the normal Jellyfin app experience over that path.

Device	Jellyfin app	Tailscale (Path 1)	Proxy/relay URL (Paths 2-3)	Reality check
Android / Google TV	Official	✅ Play Store client	✅	Best-covered TV platform: both paths work
Fire TV	Official (Android TV app)	✅ Amazon Appstore, most post-2018 devices; not the 4K Select stick	✅	The travel-stick platform of choice
Apple TV	Swiftfin / Infuse	✅ App Store client	✅	Tailscale’s only non-Android TV client
Roku	Official	❌ no client exists	✅	The single strongest argument for Path 2/3
LG webOS	Official	❌ no client	✅	Same story as Roku
Samsung Tizen	Official	❌ no client	✅	Same story as Roku
Xbox	Official	❌ no client	✅	Console app, URL-based access only
Phones / tablets / laptops	Official	✅	✅	Everything works; these were never the problem
Hotel / dorm TV	none of yours	via a stick you bring	✅ if the TV has a browser (rough)	See below

The hotel row earns its own paragraph, because a 90-plus-comment thread on it converged on answers that surprise people. Casting from your phone mostly fails in hotels: hotel Wi-Fi typically runs AP isolation, so your phone and a Chromecast cannot see each other even on the same network. The frequent travelers in that thread bring a streaming stick with Tailscale and Jellyfin already signed in, plug it into the room TV’s HDMI, and give the stick the hotel Wi-Fi — the tunnel is outbound, so captive portals and CGNAT do not matter. The road warriors in that thread report usable HDMI inputs in the large majority of rooms, with the occasional welded-on “hospitality mode” remote as the exception. The zero-cleverness fallback is a laptop and an HDMI cable. A GL.iNet-class travel router running the VPN for the whole room is the deluxe version of the same idea.

If you run Path 2 or 3, the hotel problem mostly dissolves. Your domain works in any browser, including the TV’s, and in any Jellyfin app on hardware you bring.

The security baseline, whichever path you picked

Paths 1 and 3-via-Pangolin put authentication in front of Jellyfin; Path 2 puts Jellyfin’s own login on the internet. Either way:

Password quality is the whole game on a public login page. Long, unique, per user, no shared “family” account with a weak password. Jellyfin’s account system is the only thing between a scanner and your library on Path 2.
Update the server. Jellyfin 10.11.11 is current as I write this; security fixes ride ordinary releases, and a version pinned in 2024 and forgotten is how exposed services rot. The setup guide covers the container-update flow.
Set Known Proxies (Path 2/3), or your access logs record the proxy talking to itself while real client addresses vanish - which also breaks any fail2ban-style banning you add at the proxy layer later.
Do not log full request URLs at the proxy. Jellyfin’s docs note it sometimes passes api_key in the URL; a proxy logging full paths writes credentials into its own logfiles.
Quick Connect ships enabled on a fresh 10.11.11 install - the code-based login on the sign-in page, verified on the test instance below. It is convenient for TV logins on your own tailnet; on a fully public instance, it is one more auth path you should consciously decide to keep or disable.

What I tested, and what I did not

The reverse-proxy path above is first-hand: Jellyfin 10.11.11 portable on Windows, Caddy 2.11.4 in front, wizard walked, defaults pulled from the live API, Quick Connect state read off the fresh install, websocket upgrade verified through the proxy, on 2026-08-25. The public-DNS leg ran against a local certificate authority rather than a routable domain, because I was not going to open ports on the network I ran the test from - the Let’s Encrypt half of Caddy’s job is its most automated part, but it is the one piece of Path 2 this test takes from documentation rather than observation. Tailscale’s TV-client coverage comes from Tailscale’s own install docs rather than a rack of TVs, and the hotel tactics come from the travel thread’s consensus, attributed as such; I have not road-tested them. I have not run Pangolin beyond its documentation and requirements - it is on the bench list, and if that test changes the Path 3 advice, this page moves with it.

Sources

Windows VM Won't Boot After the Proxmox 9 Upgrade? Read the Error Before You Reinstall (2026)

LK Wood IV — Tue, 25 Aug 2026 00:00:00 -0500

By LK Wood IV · Published 2026-08-25 · ~9 min read · St. Louis County, MO

The host reboot after a Proxmox VE 8-to-9 upgrade has a particular quiet moment. The console comes back. The containers go green. The Debian guests come up. And the one Windows VM lands on a blue recovery screen instead of a login: “Your PC/Device needs to be repaired… 0xc0000001. An unexpected error has occurred.”

Nothing inside Windows changed. That is the tell.

A guest that booted fine before the upgrade and refuses after it is reporting a change in the layer underneath — firmware type, disk controller, boot entries, or the host kernel itself. Which layer depends on what the failure looks like, and the failure tells you if you read it before touching anything. Reinstalling Windows, the move half the panic threads reach for, is the one response that cannot be right: it destroys a healthy guest to address a host-side change, and in the worst case reinstalls onto the exact configuration that triggers the bug.

I maintain the upgrade guide this page pairs with, and I want to be straight about sourcing: I have not reproduced this failure on a lab host. Every fix below instead names the community thread or vendor document that confirmed it, chiefly the Proxmox forum thread where the 0xc0000001 signature was worked to a confirmed fix, and the r/Proxmox reports that match it. Where a step was tried in those threads and did not work, I say that too. That list of dead ends is half the value here.

What the failure looks like

Four screens, four different problems. Match yours before running a single command.

The signature fork

The screen the VM stops on names the broken layer. Every fix in the ladder below belongs to exactly one of these forks — running fixes from the wrong fork is how a one-reboot problem becomes a weekend.

FORK A · HOST KERNEL

Blue recovery screen: 0xc0000001 “An unexpected error has occurred”

Reported on SeaBIOS + MBR guests the moment the host moved to kernel 7.0. Same VM boots fine on the previous 6.17 kernel.

→ Steps 1–2, permanent fix in Step 5

FORK B · EFI BOOT ENTRY

Drops to the UEFI boot menu or shell — picking the disk manually boots fine

The OS is intact; the auto-boot chain is not. Reported on OVMF guests after 9.2 point updates, worst with boot disks on IDE.

→ Step 3

FORK C · DISK CONTROLLER

BSOD: INACCESSIBLE BOOT DEVICE

The boot disk's bus type changed and Windows has no driver bound for it — usually self-inflicted mid-troubleshoot, or after a restore that changed the controller.

→ Step 4

FORK D · GUEST TYPE FLAGS

Instant reboot loop — no error screen at all

Reported on a UEFI Windows 11 guest on kernel 7.0.14: the VM resets before Windows draws anything. Fixed in-thread by correcting ostype from win10 to win11.

→ 30-second checks below

techfuelhq.com · signatures per forum.proxmox.com thread 183958 + r/Proxmox reports, mid-2026

One honest caveat on ordering. Nobody has failure-rate telemetry for this, me included, so the ladder below is ordered by cost of the test, cheapest and most reversible first. Anyone who tells you which of these causes is “most common” is guessing.

The 30-second configuration checks

Before changing anything, pull the VM’s config on the host and read five lines:

qm config <vmid>

bios: is ovmf or seabios (absent means SeaBIOS, the default). This decides which fork you are in. A UEFI Windows install needs ovmf; if this line says otherwise, something rewrote your config (a restore, a migration script, a manual edit).
efidisk0: must exist on every OVMF VM. An OVMF guest with no EFI disk has nowhere to store boot entries, and boot-entry loss is exactly the Fork B symptom.
machine: shows whether your virtual hardware moved. Windows VMs get their QEMU machine version pinned at creation (pc-q35-8.1, say) precisely because, in the words of the Proxmox reference documentation, “Windows is sensitive to changes in the virtual hardware.” If yours shows a pinned version, the upgrade did not move it. If it shows latest or a bare q35, the upgrade silently jumped your virtual hardware to QEMU 11’s newest revision.
scsihw: and the boot disk’s bus (scsi0: / sata0: / ide0:) matter for Step 4, so note what they are. If Windows last booted from a scsi0 disk and the disk now hangs off ide0, that mismatch is your Fork C.
ostype: should be win11 for the Windows 11 / Server 2022 / Server 2025 generation and win10 for Windows 10 / Server 2016 / 2019 — the qm.conf reference defines win11 as “Microsoft Windows 11/2022/2025” and win10 as “10/2016/2019”, and Server 2022 on the win10 setting is a common leftover. The forum thread’s reboot-loop case (Fork D) was resolved by exactly this one-line correction on a UEFI Windows 11 guest, so check it before deeper surgery.

Five lines, under a minute, and you have usually already picked your fork.

Why Proxmox 9 breaks Windows VMs and leaves Linux guests alone

The 8-to-9 upgrade is not one change. Landing on the current 9.2 means Debian 13.5, QEMU 11.0, and the Linux 7.0 kernel all arrive at once, and each is a layer a guest boots through.

The kernel is the loud one right now. Within days of kernel 7.0 reaching 9.2 hosts, the Proxmox forum thread above collected Windows Server guests failing with 0xc0000001 across three hosts with different storage back-ends — all SeaBIOS, all MBR boot disks, all fine again the moment the host booted the previous 6.17.13 kernel. The thread’s participants converged on a kernel regression affecting SeaBIOS/MBR guests specifically; no OVMF guest shows up among the failures, and one commenter reported his OVMF guests running fine on the same PVE version. As of this writing there is no Proxmox staff reply in that thread, so treat the diagnosis as strong community evidence rather than an official statement. The fix pattern it produced, though, was confirmed by two separate users in the linked discussion, which is more than most boot-failure folklore ever gets.

QEMU 11 is the quiet one. Windows VMs carry a pinned machine version for stability, so most survive the QEMU jump untouched. The r/Proxmox comments on the same failure confirm the corollary: rolling the machine version back (pc-q35-8.0) did not fix the 0xc0000001 failure. Machine versions matter at the margins. Guests set to latest get a large hardware jump, and QEMU’s own policy now removes machine versions from upstream after six years, so a config pinned to something ancient will eventually stop starting at all. Worth reading once and then not obsessing over.

And Windows itself is simply the fussy tenant. It refuses to boot from a disk bus it was not prepared for (the documented INACCESSIBLE BOOT DEVICE failure in Step 4), its Boot Configuration Data store assumes the firmware handoff never changes shape, and a BitLocker-protected guest treats TPM changes as a reason to demand its recovery key. Linux guests and containers re-enumerate most of this on every boot and move on. That asymmetry (host change, Windows-only casualty) is the entire diagnostic frame of this page.

The fix ladder, least invasive first

Each step says what it does, when it is the right one, and how to undo it.

Step 1: update the host before you change the VM

The bug you hit may already be fixed. One commenter in the boot-menu thread reports a similar failure (his word — similar, not identical) that cleared up with a later Proxmox kernel or qemu-server update. Check and apply point updates on the host, reboot, and re-test the VM before touching its config.

apt update && apt dist-upgrade

When it is the one. Always first. It costs a host reboot and nothing else, and every later step benefits from being on current packages. How to revert. Nothing to revert.

Step 2: boot the previous kernel — the confirmed 0xc0000001 fix

This is Fork A’s move, and it doubles as its diagnostic. Proxmox keeps the previous kernel installed; proxmox-boot-tool can select it, and the selection works on both systemd-boot and GRUB hosts:

proxmox-boot-tool kernel list
proxmox-boot-tool kernel pin 6.17.13-13-pve --next-boot
reboot

--next-boot applies for one boot only. If the Windows VM comes up normally on 6.17 (as it did for the reporters in the forum thread, whose guests failed on kernel 7.0.6-2 and booted on 6.17.13-13), you have confirmed the kernel fork in one reboot with zero permanent changes. Then make it stick until you are ready for Step 5:

proxmox-boot-tool kernel pin 6.17.13-13-pve

The cost is real, and I want it on the page: a pinned host is not running the kernel line that receives current fixes. You are trading an unbootable guest for a slightly stale host, which is the right trade this week and the wrong one forever. Record the pin somewhere you will see it, re-test on each new point release, and proxmox-boot-tool kernel unpin the day the current kernel boots your guests again. If you run GPU passthrough, you may already know this dance. Kernel pinning is the same escape hatch the passthrough community reaches for when a new kernel breaks VFIO.

Step 3: repair the UEFI boot path — when manual boot works

Fork B has the friendliest tell in the whole taxonomy: press Esc at the VM’s firmware splash, pick the Windows disk by hand, and it boots perfectly. The OS is fine. Only the automatic handoff is broken. Three sub-fixes, in cost order:

Boot order first. VM → Options → Boot Order. After upgrades and restores this list can end up pointing at the wrong device or de-selecting the boot disk entirely. Fix, cold-boot (full stop/start, not a guest reboot), done.

Get the boot disk off IDE. In the r/Proxmox thread where two of four Server 2022 guests dropped to the boot menu after a 9.2.9 update, the affected disks hung off IDE, and a commenter identified the mechanism as the BCD not supporting IDE EFI boot chaining, which is exactly why manual selection worked while auto-boot failed. Moving the boot disk to SCSI resolved it, with one caveat the reporter hit honestly — Windows needed a Safe Mode boot to bind the storage driver on first start after the move. Do it in Step 4’s driver-safe order rather than a blind detach/re-attach.

Rebuild the EFI vars and TPM state. This is the heavier variant, reported working across a fleet. Detach and delete the VM’s EFI disk and TPM state, re-add both fresh, and — the detail that made it stick — reset the TPM to factory keys before the first boot. The thread’s reporter found a plain rebuild did not stick (Windows booted once, then the failure returned on the next reboot); the commenter who recovered roughly two dozen VMs adds the factory-key reset before first boot as the step that makes it hold. Nobody in-thread tested the two variants side by side. Before you touch either disk, have your BitLocker recovery key in hand. Clearing the TPM is on Microsoft’s own list of events that put a BitLocker device into recovery, so expect the recovery prompt at next boot — and without the key that screen is a lockout.

When it is the one. The manual-selection tell, or an OVMF guest whose efidisk0 is missing or damaged. How to revert. Boot order and controller moves reverse in the GUI; a deleted EFI/TPM disk does not come back, which is why the recovery key comes first.

Step 4: swap the disk controller without losing boot

Fork C is the one you can give yourself mid-troubleshoot, and the shape of it is worth thirty seconds. When the boot disk arrives on a bus Windows has not booted from before, Windows can fail before it is up — the standard explanation is that boot-critical storage drivers are only armed once Windows has actually used them. Whatever the exact mechanism, Proxmox’s driver documentation states the outcome flatly: installing the VirtIO drivers and switching the boot disk in one step “will result in a blue screen, claiming an ‘INACCESSIBLE BOOT DEVICE’.”

So the swap is a two-boot procedure, per that same document:

Load the virtio-win ISO in the VM’s CD drive and attach a small temporary disk (1 GB) on the VirtIO SCSI bus.
Boot Windows, install the drivers, and wait until the temp disk shows up in Disk Management. That appearance is the proof the driver is genuinely bound.
Shut down. Remove the temporary disk, then detach the boot disk and re-attach it on the target bus (SCSI on the VirtIO SCSI single controller is what Proxmox’s Windows best-practices guide has you pick).
Fix Options → Boot Order to point back at the boot disk, boot, and take the ISO out once you are up.

If you are already stuck on the blue screen because the bus changed underneath you, put the disk back on the old bus first. That is the one-minute undo (detach, re-attach on the previous bus type, restore boot order), and Windows boots because the old driver is still the one it trusts. Then do the procedure above properly. And a warning from the founding thread worth repeating: controller shuffling was tried against Fork A’s 0xc0000001 and did nothing — VirtIO SCSI single versus VirtIO SCSI, iothread on or off, none of it moved that failure. Controller surgery fixes controller problems. It does not fix kernel problems.

Step 5: convert SeaBIOS/MBR to UEFI — the permanent Fork A fix

The kernel pin in Step 2 avoids the wedge; this removes it. The wedge condition is SeaBIOS firmware booting an MBR disk, so the reporter converted his Windows guests to UEFI/GPT and ran them on kernel 7.0 without issue — “everything runs now fine,” in his words in the r/Proxmox comments after migrating his whole fleet — and a second user in the same discussion, after converting his Server 2025 guest the same way, closed with “everything is ok.”

Inside Windows, validate before you commit. mbr2gpt refuses ineligible layouts (more than three primary partitions, extended/logical partitions present), and per Microsoft’s documentation BitLocker protection must be suspended first:

mbr2gpt /validate /allowFullOS
mbr2gpt /convert /allowFullOS

The conversion rewrites the partition table in place, creates the EFI system partition, and migrates the BCD. Data stays, but there is no un-convert command, so this is a tested-backup-first operation. Then shut down and flip the Proxmox side to match, because a GPT disk under SeaBIOS boots nothing:

Hardware → Add → EFI Disk.
Options (or Hardware → BIOS) → change SeaBIOS to OVMF (UEFI).
Re-check Boot Order, cold-start, and expect one trip through the firmware menu if the fresh EFI vars need the Windows Boot Manager entry selected once.

When it is the one. Fork A guests you want back on the current kernel line, done one VM at a time in a maintenance window. I would not run it on a domain controller before its backup restore had been tested. The tool is fine; “no undo command” plus “untested backup” is the combination you only get burned by once. How to revert. You do not; you restore.

Step 6: restore the pre-upgrade backup

If you took the tested backup the upgrade guide insists on, the calm exit was available the whole time. Restore the guest as it was, pin the kernel if the restored VM still hits Fork A, and schedule the UEFI conversion for a quieter week. A restore also cleanly unwinds a troubleshooting session that changed five things: restored config, restored disk, known state.

If you did not take one, let this be the page that converts you. Every fork above is survivable with a backup and console access; several are miserable without. The 3-2-1 setup takes an evening.

What not to do

Do not reinstall Windows. Wrong layer. The guest is healthy; the platform moved. In the kernel-regression case a fresh install onto SeaBIOS/MBR can hit the same wall on first boot.
Do not detach and re-attach disks “to see if it helps.” Every detach can drop the disk from the boot order, stacking a Fork B problem on top of whatever you had. Config changes here should be single, deliberate, and written down.
Do not upgrade the rest of the cluster while node one’s Windows guests are down. The failure travels with the kernel, and so does your blast radius. Diagnose on one node; pin or fix before the next node moves.
Do not run fixes from the wrong fork. The reporter’s threads already burned the hours for you: against 0xc0000001, controller swaps did nothing, iothread toggles did nothing, machine-version rollback to pc-q35-8.0 did nothing, and a QEMU 10-vs-11 switch did nothing. The kernel pin worked. The UEFI conversion worked. Match the signature, run its fix.

Prevent it on the next node

Everything above compresses into three pre-upgrade lines for whatever you upgrade next:

qm config every Windows guest and record bios / machine / boot bus / ostype. Thirty seconds per VM, and it turns any post-upgrade surprise into a diff instead of a mystery.
Convert SeaBIOS/MBR Windows guests to UEFI before the host jumps to kernel 7.0, on your schedule instead of during an outage.
Take the tested backup. Then run the full pre-flight checklist (pve8to9, NIC pinning, console access) and upgrade knowing the escape hatches on this page exist but expecting not to need them.

The upgrade itself is routine. The preparation is the whole job — and for Windows guests specifically, the preparation now includes knowing which firmware they boot with.

Sources

Proxmox forum — “Windows Server 2025 fails to boot after PVE 9.2 / Linux 7.0 Kernel upgrade” (the 0xc0000001 thread; kernel versions, controller/iothread and QEMU 10-vs-11 non-fixes, the ostype win10→win11 boot-loop fix): https://forum.proxmox.com/threads/windows-server-2025-fails-to-boot-after-pve-9-2-linux-7-0-kernel-upgrade.183958/
r/Proxmox — the same failure’s discussion thread (three hosts, SeaBIOS/MBR/VirtIO SCSI, broken 7.0.6-2-pve vs working 6.17.13-13-pve; machine-version-rollback non-fix; both UEFI-conversion confirmations): https://www.reddit.com/r/Proxmox/comments/1trztwg/
r/Proxmox — Server 2022 guests dropping to the boot menu after 9.2.9, manual disk selection working; IDE/EFI boot chaining diagnosis, EFI+TPM rebuild fix, the similar-failure-fixed-by-update report: https://www.reddit.com/r/Proxmox/comments/1vgbstt/
Proxmox wiki — Paravirtualized Block Drivers for Windows (the temporary-disk procedure and the INACCESSIBLE BOOT DEVICE warning, quoted verbatim): https://pve.proxmox.com/wiki/Paravirtualized_Block_Drivers_for_Windows
Proxmox wiki — Windows 10 guest best practices (SCSI bus on the VirtIO SCSI single controller for Windows guests): https://pve.proxmox.com/wiki/Windows_10_guest_best_practices
Proxmox wiki — Host Bootloader (proxmox-boot-tool kernel list / pin / –next-boot / unpin): https://pve.proxmox.com/wiki/Host_Bootloader
Proxmox VE reference documentation — QEMU/KVM Virtual Machines (Windows machine-version pinning, machine-version removal policy): https://pve.proxmox.com/pve-docs/chapter-qm.html; ostype value definitions (win10 = 10/2016/2019, win11 = 11/2022/2025): https://pve.proxmox.com/pve-docs/qm.conf.5.html
Microsoft Learn — MBR2GPT (validate/convert syntax, /allowFullOS, disk prerequisites, BitLocker suspension, UEFI firmware requirement): https://learn.microsoft.com/en-us/windows/deployment/mbr-to-gpt
Microsoft Learn — BitLocker recovery overview (“Turning off, disabling, deactivating, or clearing the TPM” as a recovery trigger): https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/recovery-overview
Proxmox VE roadmap — 9.2 release contents (Debian 13.5, kernel 7.0, QEMU 11.0), verified 2026-08-25: https://pve.proxmox.com/wiki/Roadmap

Ollama vs llama.cpp vs LM Studio: Same-GPU Compare Dataset

LK Wood IV — Thu, 20 Aug 2026 01:10:00 -0500

By LK Wood IV · Published 2026-08-20 · Updated 2026-08-26 · ~4 min read · St. Louis County, MO

The short version

This page holds two captures on the same retail RTX 5080. On 2026-08-20 I ran Ollama against bare llama.cpp; on 2026-08-26 I ran Ollama against LM Studio, same GGUF bytes on both sides via hard links. Across both captures the pattern holds: every one of these tools is llama.cpp underneath, decode differences on dense models stay inside 11%, and the settings each app ships with move throughput far more than the app choice does.

Downloads: llm-server-compare-2026-08.csv (Ollama vs llama.cpp) and llm-server-compare-2026-08-26-lmstudio.csv (Ollama vs LM Studio, both conditions). CC BY 4.0, per-run decode arrays included.

Capture 2: Ollama 0.32.15 vs LM Studio 0.4.21 (2026-08-26)

Settings normalized on both sides: context 4096, full GPU offload, temperature 0, seed 42, one serving slot, per-run prompt nonces throughout. Decode figures are medians of five runs; long-prefill figures, measured at ~450 prompt tokens, are medians of three with a warmup discarded. The decision-layer writeup is the LM Studio comparison article.

Model	App	Decode	Prefill (long)	GPU mem (MiB)	Load
Llama 3.2 3B	Ollama 0.32.15	350.5 t/s	17,862 t/s	3,760	2.3s
Llama 3.2 3B	LM Studio 0.4.21	316.0 t/s	20,337 t/s	3,808	2.8s
Qwen 2.5 14B	Ollama 0.32.15	102.2 t/s	5,038 t/s	10,356	5.5s
Qwen 2.5 14B	LM Studio 0.4.21	97.6 t/s	5,567 t/s	10,405	7.7s
gpt-oss 20B	Ollama 0.32.15 (own fork)	213.7 t/s	9,187 t/s	13,570	8.1s
gpt-oss 20B	LM Studio 0.4.21 (upstream MXFP4)	242.8 t/s	9,618 t/s	12,533	8.4s

At stock as-installed settings the dense rows barely move, but two defaults bite: LM Studio’s automatic GPU offload held gpt-oss to 186.3 t/s, 23% below its own tuned figure — and a single-variable re-run (stock config, only the offload slider moved to max) recovered the whole gap at 244.9 t/s. Ollama’s app-level context slider set to 256k (clamped to this model’s 131,072 maximum) dropped Llama 3.2 3B from 351 to 102 t/s with the KV cache spilled to CPU. Both are recorded as their own rows in the CSV and raw JSON. Idle app overhead: the Ollama service tree held 78-132 MB of RAM; LM Studio’s GUI plus server held 709-928 MB across quiet-window observations (one 3.1 GB transitional reading mid-unload excluded, kept in the raw JSON). Ollama’s engine is its vendored llama.cpp at commit 9d77fa172; LM Studio’s is its packaged llama.cpp runtime 2.29.1 (CUDA 12) — and both run the model in a llama-server process.

Ollama alone gained 3-10% decode over its own 08-20 numbers here (319→351 on the 3B; 195.8→213.5 on gpt-oss, defaults condition) across six days and fourteen patch-version increments — with the caveat that the 08-20 capture predates this page’s quiet-window discipline, so part of that spread may be ambient. Either way, single-digit decode gaps between these tools do not survive a version bump.

Capture 1: Ollama 0.32.1 vs llama.cpp b10507 (2026-08-20)

Model	Server	Decode	Prefill (long)	GPU mem (MiB)	Load
Llama 3.2 3B	Ollama 0.32.1	319 t/s	17,444 t/s	4,343	3.2s
Llama 3.2 3B	llama.cpp b10507	338 t/s	16,809 t/s	4,339	2.5s
Qwen 2.5 14B	Ollama 0.32.1	99.4 t/s	5,004 t/s	10,941	5.6s
Qwen 2.5 14B	llama.cpp b10507	101.4 t/s	4,697 t/s	10,942	8.1s
gpt-oss 20B	Ollama 0.32.1	195.8 t/s	—	14,152	8.6s
gpt-oss 20B	llama.cpp (upstream GGUF)	222-238 t/s²	—	13,037	19.8s

² Prompt-dependent on this MoE: a fixed prompt held 232-242 t/s (median 238.5); varied prompts were bimodal with a ~176 slow path (median 235.3), and the published 222 median includes a cold first run. Ollama’s fork ran a flat 195.7-196.3 under the same nonce scheme. Load times are cold-start to first ready response: llama-server was faster on the 3B, Ollama faster on both larger models.

The desktop baseline was 1,642 MiB of GPU memory before any model loaded (nvidia-smi reports MiB; the CSV column is vram_total_mib_median). These figures run 2-7% above our RTX 5080 throughput dataset for the same models because that capture used 500-1,650-token prompts; both pages state their regime.

Method

I kept one server resident at a time, with a fresh process per model and ollama stop plus process-tree kills between configurations. Every request carried a unique nonce prefix, llama-server additionally ran with prompt caching disabled, and generation was pinned to temperature 0, seed 42, 256 tokens (64 on the long-prefill pass), context 4096, full offload. Rates are each server’s own counters; a wall-clock recomputation agreed within 2% on every run (one cold-start exception at 3.6%, disclosed above), and llama-bench served as a third instrument on the 3B (pp512 19,589 ± 2,071 t/s, tg256 367.1 ± 0.7 t/s, raw engine loop). The capture scripts are available on request via hello@techfuelhq.com.

The limits, named. One GPU, one box, three models per capture, and a short-prompt prefill column retained only to document its own overhead artifact. Token counts for identical text differ slightly between tools because each applies its own chat template handling. The decision-layer writeups are Ollama vs llama.cpp and Ollama vs LM Studio; this page is the citable record for both.

Ollama vs llama.cpp on an RTX 5080: Measured (2026)

LK Wood IV — Thu, 20 Aug 2026 01:00:00 -0500

The argument shows up in every local-AI thread: Ollama is “just a wrapper” and real performance lives in bare llama.cpp. Nobody arguing it ever posts numbers from the same machine. So I ran both servers on the same RTX 5080, loading the same GGUF bytes, with generation pinned to temperature 0, seed 42, and fresh prompts every run.

The answer surprised me, because I went in expecting to confirm the forum consensus and instead measured something smaller, stranger, and more useful. The wrapper costs almost nothing, and each side wins one event.

Decode goes to llama.cpp. Prefill goes to Ollama. Nobody wins big.

The measured table

Ollama 0.32.1 versus llama.cpp b10507 (llama-server), full GPU offload, 4096 context, 256-token generations, decode medians of five runs. Prefill measured at real prompt length (~420 tokens), median of three fresh runs with a discarded warmup. The short version of why the prompt length matters is below.

Model	Server	Decode	Prefill	GPU mem (MiB)
Llama 3.2 3B	Ollama	319 t/s	17,444 t/s	4,343
Llama 3.2 3B	llama.cpp	338 t/s	16,809 t/s	4,339
Qwen 2.5 14B	Ollama	99.4 t/s	5,004 t/s	10,941
Qwen 2.5 14B	llama.cpp	101.4 t/s	4,697 t/s	10,942
gpt-oss 20B	Ollama	195.8 t/s	—	14,152
gpt-oss 20B	llama.cpp²	222-238 t/s	—	13,037

² Upstream GGUF (the Ollama blob refuses to load; see the portability catch below). gpt-oss is a mixture-of-experts model and its decode rate on upstream llama.cpp is prompt-dependent: a fixed prompt held a tight 232-242 t/s (median 238.5), while varied prompts were bimodal, mostly ~230-243 with a ~176 slow path — honest range 175-243, varied-prompt median 235.3. The published 222 median also carries a cold first run at 186. Ollama’s fork ran a flat 195.7-196.3 under the same nonce scheme. The gpt-oss prefill cells are dashed because the long-prompt pass was not run on this model.

Desktop baseline was 1,642 MiB of GPU memory; subtract it for the models’ own footprints. Wall-clock recomputation agreed with each server’s self-reported rates within 2% on every run but one — the first gpt-oss run on llama-server landed 3.6% off, a cold-start artifact. Wherever both servers loaded the same file, VRAM matched within 7 MiB. Same weights, same memory. The gpt-oss row is the exception, and it is carrying two different conversions of the model, not a wrapper difference. These figures also run 2-7% above our earlier RTX 5080 throughput dataset for the same models, because that capture used 500-1,650-token prompts where this one uses short ones; both pages state their regime.

llama.cpp decodes 2-6% faster on the dense models, more on the MoE below. Ollama prefills 4-7% faster at real prompt sizes. Neither gap changes what a model feels like to use, and neither survives a driver update, an engine release, or a quantization change as the deciding factor in a purchase or a migration.

The overhead ladder

One more instrument makes the picture honest. llama.cpp ships llama-bench, which times the raw engine loop with no server in front of it. On Llama 3.2 3B:

Instrument	What it measures	Decode
llama-bench	bare engine loop	367 t/s
llama-server	+ HTTP serving, sampling pipeline	338 t/s
Ollama	+ model management, its serving stack	319 t/s

Each layer costs single-digit percent, and that is the entire “wrapper tax”: 13% from the bare engine loop to the most convenient tool in the stack, most of it spent on serving machinery that any usable setup needs anyway, whichever side of the argument you started on. Forum threads promise dramatic slowdowns. None reproduced here.

That is the whole controversy, measured.

How my first measurement lied to me

The first pass of this bench used a short, ~40-token prompt, and it showed Ollama’s prefill rates landing 32-55% above llama-server’s — a gap that turned out to be an artifact, because at tiny prompt sizes “prefill tokens per second” is dominated by fixed per-request overhead rather than compute, which means it measures which server shuffles a request faster rather than which one ingests your context faster, and re-measured at ~420 prompt tokens, llama-server’s prefill jumped from ~5,300 to ~16,800 t/s on the 3B while the gap collapsed to single digits. The flags people credit for prefill speed did nothing here either: flash attention on or off, micro-batch 512 or 2048, all within noise at real prompt length on this card. Flags were not the story. Prompt length was.

So treat one-line-prompt prefill numbers as request plumbing, not throughput.

The portability catch

Ollama stores weights as standard GGUF blobs, and ollama show <model> --modelfile prints the path. Point llama-server at it and both tools share one copy of the weights. That worked perfectly for Llama 3.2 3B and Qwen 2.5 14B.

It failed for gpt-oss:20b, and the failure is worth knowing about. llama.cpp refused the blob with unknown model architecture: 'gptoss', and the server died on the spot. Ollama’s conversion tags the architecture with its own name, while upstream llama.cpp expects gpt-oss — so the one model Ollama co-launched is the one whose Ollama download you cannot carry to the upstream engine, so its download does not travel. The fix is downloading the upstream GGUF separately, at the cost of a second ~12GB copy on disk. The upstream copy then decoded 13-22% faster than Ollama’s fork on most prompts and allocated 1.1GB less GPU memory at the same context, so the annoyance bought something real, about 1.09 GiB of it.

Which one should you run?

Run Ollama when you want model management to be someone else’s problem: pulls, updates, memory eviction, an OpenAI-style API on 11434, and every tutorial on the internet assuming you have it. If the real question is a GUI desktop app rather than a second server engine, that is a different comparison — I benched it separately in Ollama vs LM Studio on the same card. Our RTX 5080 throughput dataset and the RTX 5060 local LLM guide both ride on it for exactly that reason.

Run llama-server when you want the newest engine the day it ships, exact control over batching, context, and sampling, or the last few percent of decode speed. For these models the engines share llama.cpp lineage; Ollama’s README lists llama.cpp among its supported backends, and the gpt-oss arch tag shows it also ships its own engine paths. You are choosing how much of the engine’s surface to touch. Throughput is the wrong reason to switch in either direction — 2-6% is less than the gain from one quantization step or one driver update.

Method and limits

Both servers ran the same sha256-identical GGUF blobs from Ollama’s own store (except the gpt-oss case above), one server resident at a time, fresh process per model, with ollama stop and process-tree kills between runs. Every request used a unique prompt nonce; llama-server additionally got cache_prompt: false. Generation pinned to temperature 0, seed 42, 256 tokens (64 for the long-prefill pass), context 4096 on both. Rates come from each server’s own timing counters, cross-checked by wall-clock recomputation (within 2% throughout) and by llama-bench as a third instrument.

The limits, named. One GPU, one box, three models, servers on default flags. Token counts for identical prompt text differed slightly between servers (433 vs 407 on the long prompt) because Ollama applies its chat template to /api/generate while llama-server’s /completion takes the prompt raw — rates are per-token, so the comparison holds, but byte-identical inputs produce slightly different token streams. Ollama’s engine is a vendored llama.cpp build, so some of the decode gap is simply engine version lag, and it will move with every release on both sides. Date everything; this page says 2026-08-20.

MCP Server Resource Benchmark: RAM, Startup, Tools Dataset

LK Wood IV — Thu, 20 Aug 2026 00:48:00 -0500

By LK Wood IV · Published 2026-08-20 · ~3 min read · St. Louis County, MO

The short version

I benchmarked eleven of the most-recommended MCP servers for what they cost to keep resident. The answer: 178-422MB of RAM each (median 188MB), ready in 0.5-1.9 seconds warm, with tool counts from 1 to 26. A realistic concurrent five-server stack totals 961.6MB, and two independent measurement paths confirmed that figure to the decimal. Tool count barely predicts weight. The runtime and framework dominate.

Download: mcp-server-bench-2026-08.csv. CC BY 4.0, per-iteration arrays included.

The measured table

Server	Version	Ready	RSS	Tools
GitHub (legacy npm)	0.6.2	547ms	178MB	26
Playwright	1.63.0-alpha-2026-08-05	618ms	227MB	24
Time (Python)	1.29.0¹	619ms	181MB	2
Sequential-thinking	0.2.0	666ms	186MB	1
Memory	0.6.3	667ms	187MB	9
Filesystem	0.2.0	692ms	188MB	14
Git (Python)	1.29.0¹	699ms	185MB	12
Fetch (Python)	1.29.0¹	717ms	220MB	1
Context7	4.0.2	815ms	214MB	2
Desktop Commander	0.2.47	1,705ms	275MB	26
Qdrant (Python, 3.12 pin)	1.29.0¹	1,881ms	422MB	2

¹ The four Python servers self-report 1.29.0 via serverInfo. That is a framework version string rather than each package’s own release number.

Controls on the same box: bare Node resident loop 52.1MB, bare Python loop 15.2MB. Five-server concurrent stack components: memory 189.8, filesystem 187.1, fetch 221.7, git 184.5, GitHub 178.5. Total: 961.6MB.

Method

Each iteration spawns the server fresh (npx or uvx, warm package cache after one discarded warmup), completes the MCP initialize handshake over stdio, requests tools/list, then samples RSS across the full descendant process tree. I report medians of five iterations, three for the two servers benched later the same evening, marked in the CSV. The bench script lives in our repo at ops/bench/mcp/mcp_bench.py. For the decision layer, meaning which servers earn their memory and which to skip, read the companion article.

Known limitations, named: one Windows 11 machine, warm caches, stdio transport only, readiness and listing timed rather than per-tool-call latency under load. The GitHub entry is the legacy npm package; GitHub’s current first-party server ships as a Go binary and hosted remote. Version 1.0.0 of this dataset; changes will be logged in the update history above.

Unraid vs TrueNAS vs OMV vs Proxmox: NAS OS Pick (2026)

LK Wood IV — Thu, 20 Aug 2026 00:30:00 -0500

Every NAS thread ends in the same four names, and one of them does not belong. I spent an evening verifying the current state of all four against their own release notes, pricing pages, and documentation, because so much of the standing advice on this comparison describes products that no longer exist, and the details that changed are exactly the ones that decide the purchase: TrueNAS SCALE is gone as a name, TrueNAS CORE is discontinued as a product, Unraid’s “subscription” is not one, and Proxmox, the name that starts half the arguments, does not serve a single network share out of the box and never claimed it could.

Here is the decision, then the evidence.

The short version

Two are free. One is worth paying for. One is a hypervisor wearing a costume.

Mixed drives you already own, apps with minimum friction, money available: Unraid. Uniform drives, integrity as the priority, 8GB of RAM to spare: TrueNAS Community Edition. A weak or small box, Debian comfort, zero budget: openmediavault. And if virtual machines are the actual point of the server, run Proxmox — with a NAS on top of it, not instead of one.

The August 2026 state of play

	Unraid	TrueNAS CE	openmediavault	Proxmox VE
Version	7.3.2 (Jul 2026)	25.10.6 (Aug 2026)	8.5.6-1 (Aug 2026)	9.2 (May 2026)
Cost	$49 / $109 / $249 once	Free	Free	Free²
Storage	mixed-size parity array	ZFS only	mdadm + 16 mountable filesystems	for VM disks, not shares
RAM floor¹	none published	8GB	1GiB	1GB (2GB + guests)
Apps	Community Apps (Docker)	TrueNAS Apps (Docker)	omv-extras plugins	VMs + LXC only

¹ Official documentation figures; Unraid’s getting-started docs publish no RAM number (only a 4GB USB stick requirement) and its forum moderators suggest 4GB as the practical minimum. ² Subscriptions run €120 (repo access only, no tickets) to €1,100 (unlimited tickets) per socket per year; the free package repo is officially labeled not recommended for production.

What the old comparisons get wrong

The rename nobody indexed. TrueNAS SCALE became TrueNAS Community Edition with 25.04 “Fangtooth” in April 2025, and the FreeBSD-based CORE line is formally finished. The software status page says it is no longer under active development, with 13.0-U6.8 and 13.3-U1.2 as the final builds. Any comparison still weighing “CORE vs SCALE” is a museum piece.

Unraid’s pricing produces the loudest arguments and the most misinformation. The licenses are perpetual. The $36 a year on the Starter and Unleashed tiers is optional and only gates new feature releases; your installed version keeps working and keeps receiving security patches within its minor version. Lime Technology shipped 7.2.8 with a WebGUI CVE fix three weeks after 7.3.2 was already current. Call it a subscription and its forum will correct you, with citations.

RAIDZ expansion stopped being a differentiator. TrueNAS shipped it in 24.10 in October 2024, sponsored by iXsystems, and Unraid’s ZFS pools gained the same one-drive-at-a-time growth in 7.2.0 a year later. The classic “ZFS can’t grow one disk at a time” objection is two years stale against TrueNAS and ten months stale against Unraid.

openmediavault deserves both its reputation and its asterisk. It is the lightest real NAS OS here, it is genuinely free, and the third-party omv-extras mergerfs and SnapRAID plugins recreate Unraid’s mixed-drive economics without the license fee. The asterisk is structural: the GitHub contributor graph shows 8,303 commits by the lead developer against 24 by the next contributor. One maintainer carries the core. OMV 7 also quietly went end-of-life in June 2026, so a fresh install today should start at OMV 8.

The category error

Proxmox VE describes itself as a server management platform for enterprise virtualization. Its storage documentation lists NFS and SMB only as backends it mounts from somewhere else, to hold VM disks and backups. There is no interface anywhere in it for creating a share, and its community answers the recurring question without hedging: “not a NAS software like TrueNAS,” in its own words. That settles it.

So why is it in every NAS thread? Because homelabbers correctly run it as the base layer and put the NAS on top — a TrueNAS or OMV virtual machine with disks passed through, a fileserver LXC, or bare Samba on the underlying Debian. All of those work. None of them makes Proxmox a NAS OS; they make it a hypervisor hosting one, which is a different decision with different failure modes. If that is your situation, the real question is which storage backend to run under Proxmox, and we compare exactly that separately.

Picking by your actual constraint

Your drives are a mixed bag. Unraid’s parity array takes different sizes in one protected pool, and openmediavault reaches the same shape via the third-party omv-extras mergerfs and SnapRAID plugins. TrueNAS will let you mix sizes but charges you for it: ZFS caps every disk in a vdev at the smallest member’s capacity.

Your RAM is tight. TrueNAS officially wants 8GB plus 1GB per drive past eight. OMV officially runs in 1GiB. On a repurposed thin client or an N100 with soldered memory, that spread decides the argument by itself.

You want apps without ceremony. Unraid’s Community Apps store is, in my judgment, the smoothest catalog in home NAS. TrueNAS moved its apps backend from Kubernetes to plain Docker in 24.10, which simplified life, though its forums carry real migration scars from that transition, and the forum threads from the 25.04 virtualization overhaul read the same way. OMV needs the omv-extras compose plugin before Docker exists at all.

Your data is the point and nothing else is. TrueNAS. It is not close, because the whole platform is organized around one job: ZFS end-to-end with checksumming, snapshots, and replication, maintained by a company whose paying enterprise customers keep the storage layer honest whether or not the home users complain loudly enough.

Budget rules everything. OMV and TrueNAS are free. Unraid’s $49 Starter covers six attached devices, which fits most first builds; count your drives before assuming the $109 tier. Run your drive plan through the RAID capacity calculator first — parity overhead changes the real cost per usable terabyte more than the license does.

Whatever wins, put it on hardware that idles politely. A NAS runs 24/7, so the idle-power economics compound annually, and the budget NAS builds and old-PC conversion guide both start from that premise.

Method and limits

Everything above was verified on 2026-08-20 against official release notes, pricing pages, and documentation, with community claims labeled as community claims; the source list below carries the URLs. Two honesty notes from the verification run: the openmediavault docs site blocks automated fetchers, so its facts were checked against the project’s own docs source repository (identical content), and a small number of forum items were verified through search-index snippets rather than full page loads. What this page is not: a hands-on bench of the four installers side by side. I have not run these four concurrently on matched hardware, so you will find no throughput or power numbers here — when we measure that, it will publish as a dataset with the raw files, like our other measured work. Versions move fast in this space; if the table above and a vendor page ever disagree, the vendor page has moved and this page’s lastmod tells you by how much.

Best MCP Servers for a Homelab: 11 Measured (2026)

LK Wood IV — Wed, 19 Aug 2026 23:58:00 -0500

All four “favorite MCP servers” roundups I could find share one gap. None publishes a single number. No memory footprint, no startup time, no latency. Enumerate and vibe is the format. So I wrote a small benchmark, pointed it at eleven of the most-recommended MCP servers, and measured what they actually cost to keep resident on a homelab box.

The headline: each server holds 178-422MB of RAM, and the popular advice to “just connect everything” costs about 1GB for five servers, because I measured 961.6MB for a real concurrent stack, two independent measurement paths agreed on it to the decimal, and that is a gigabyte gone before a single model or container starts, spent on tooling I touch a few times a day. Nobody mentions this. RAM is the quiet bill.

The measured table

Fresh spawn per iteration, warm package cache, five iterations per server (three for GitHub and Qdrant, benched later the same evening — the iterations column in the CSV says which), medians reported. RSS covers the full process tree, because npx and uvx both spawn children, and measuring only the parent undercounts 18x. Raw data ships as CSV with a versioned dataset page, CC BY 4.0.

Server	Version	Ready	RSS	Tools
GitHub (legacy npm)	0.6.2	547ms	178MB	26
Playwright	1.63.0-alpha-2026-08-05	618ms	227MB	24
Time (Python)	1.29.0¹	619ms	181MB	2
Sequential-thinking	0.2.0	666ms	186MB	1
Memory	0.6.3	667ms	187MB	9
Filesystem	0.2.0	692ms	188MB	14
Git (Python)	1.29.0¹	699ms	185MB	12
Fetch (Python)	1.29.0¹	717ms	220MB	1
Context7	4.0.2	815ms	214MB	2
Desktop Commander	0.2.47	1,705ms	275MB	26
Qdrant (Python, 3.12 pin)	1.29.0¹	1,881ms	422MB	2

¹ The four Python servers self-report the version string 1.29.0 via serverInfo, a framework string rather than each package’s own release number.

Controls matter here. A bare Node process idles at 52MB and bare Python at 15MB on the same box, so the gap between those floors and the table is frameworks plus dependencies. Your tool code is nearly free. Tool count barely predicts weight. The 26-tool GitHub server is the lightest thing I measured, while the 1-tool sequential-thinking server still costs 186MB. The framework is the payload.

Two findings surprised me. Python servers land as heavy as Node ones, since uvx resolves an environment and spawns its own interpreter chain; fetch holds 220MB for a single tool. And the whole startup-cost worry is mostly noise for homelab use. Everything except Desktop Commander and Qdrant is ready in under a second warm, and a persistent client like Claude Code spawns servers once per session anyway.

The tiers, with the criteria stated

I ranked on four things I can defend: measured cost, utility per megabyte, install friction, and whether the server works standalone or needs a service running behind it.

Tier 1, connect these first

Filesystem (188MB, 14 tools), Fetch (220MB, 1 tool), and Git (185MB, 12 tools). These are the hands and eyes of any local AI setup. They read and edit real files, pull real web pages, and work actual repository history. Every workflow I run daily leans on at least two of the three, so their megabytes never idle.

Tier 2, worth it when the use exists

GitHub (178MB, 26 tools) earns a slot if your work lives in issues and PRs. The npm package I measured is the legacy implementation; GitHub’s current first-party server ships as a Go binary and a hosted remote endpoint, so treat 178MB as the worst case. Playwright (227MB, 24 tools) puts an agent behind a real browser, and the 227MB is just the idle server, so budget for the browser on top. Memory (187MB, 9 tools) gives an agent a persistent knowledge graph across sessions, which pays off once you have sessions worth remembering. Desktop Commander (275MB, 26 tools) is the heaviest Node server, and at 1.7s only Qdrant starts slower. It earns that by being a full terminal-and-editor surface. Run it where you would trust an agent with a shell, and nowhere else.

Tier 3, think twice

Sequential-thinking is the worst utility-per-megabyte in the table. It holds 186MB for one tool that restates a reasoning pattern current models handle natively. Context7 (214MB, 2 tools) pulls current library docs into context, which helps coding agents and duplicates a client that already fetches the web. Qdrant is the heaviest measured at 422MB, and bare uvx failed to install it outright on this machine — the resolver picked a pydantic-core it had to source-build, which dies without a Rust toolchain. Pin it with uvx --python 3.12 mcp-server-qdrant and it starts fine, then holds its FastEmbed embedding model (all-MiniLM-L6-v2 by default) inside that 422MB. Run it if you already run Qdrant for something else.

The service-bound layer I did not measure

The service-bound servers the homelab press centers on need their platform running to mean anything. Proxmox MCP is the consensus pick, covered by three of the four roundups I checked, with one author counting 200+ exposed tools. Kubernetes MCP and Docker Desktop’s MCP Toolkit round out that set. This bench box runs neither Docker nor Proxmox, so those numbers would have been theater, and I left them out. The pattern from the measured set almost certainly transfers. Expect the runtime floor plus dependencies, call it 200-400MB per server, and measure on your own box before trusting anyone’s table, including mine.

Configs beyond Cursor

Three of the four roundups I read assume Cursor, and the fourth stays client-agnostic. Two clients they skip matter in a homelab. Claude Code wires a server in one line.

claude mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem C:/lab

LM Studio and Claude Desktop take the same JSON shape in mcp.json.

{
 "mcpServers": {
 "filesystem": {
 "command": "npx",
 "args": ["-y", "@modelcontextprotocol/server-filesystem", "C:/lab"]
 }
 }
}

Swap npx -y <package> for uvx <package> on the Python servers, and remember the Qdrant interpreter pin from the table above.

What to run this on

The RAM math is friendly. A five-server stack costs about 1GB resident, so any N100-class mini PC with 16GB handles the tooling layer without noticing. The real constraint is whatever model or services run beside it. If the same box also hosts a local LLM, size memory for the model first. Our RTX 5080 throughput dataset and the local LLM on an RTX 5060 guide carry the VRAM numbers. Mine are measured on this bench. The 5060 guide’s come from published benchmarks for those cards. With DDR5 prices where they are, over-provisioning system RAM is the cheapest insurance in the build.

Method, including the traps

The bench script (ops/bench/mcp/mcp_bench.py in our repo) spawns each server fresh, speaks MCP JSON-RPC over stdio with an initialize handshake followed by a tools/list call, and samples RSS across the full descendant process tree 0.4s after the listing returns. Five iterations per server, three for the two late additions. One discarded warmup spawn keeps npm and uv package caches warm, because the documented condition is a configured homelab, and never a first install. Run-to-run ready-time spread stayed under 7% for eight of eleven servers; the Python time and fetch servers carried first-iteration outliers up to 17%, visible in the published arrays. RSS spread stayed within 8MB worst case.

The instrument hit traps, so yours does not have to. Measuring only the spawned npx parent reports 10.3MB while the full process tree holds 189.3MB — an 18x undercount, recorded in the evidence set. Sum the tree. My first Git-server runs timed out because I pointed the repository flag at a plain directory, and the server waits silently. The Qdrant failure looked like a hang until stderr showed the build dying: “Failed to build pydantic-core==2.33.2 … Rust not found, installing into a temporary directory”. Bare uvx had resolved a pinned pydantic-core and fallen back to a source build; the 3.12 interpreter pin sidesteps it. For the five-stack figure the components were memory 189.8, filesystem 187.1, fetch 221.7, git 184.5, and GitHub 178.5, totaling 961.6MB by psutil; an independent PowerShell WorkingSet64 walk over the same process trees returned 961.6MB, exact agreement.

Limitations, named. One Windows 11 machine. Warm caches. Stdio transport only. I measured readiness and listing, and never per-tool-call latency under load. The GitHub entry is the legacy npm package rather than the current Go binary. Linux numbers will differ, likely lower on the Node floor, and that comparison is a natural v2 alongside the service-bound servers once this lab runs Docker.

RTX 5080 LLM Power Efficiency: Measured Watts and Joules per Token

LK Wood IV — Wed, 19 Aug 2026 00:00:00 -0500

By LK Wood IV · Published 2026-08-19 · ~5 min read · St. Louis County, MO

The short version

The RTX 5080 throughput dataset answers “how fast” — this companion answers “at what electrical cost.” Same retail card, same ollama stack: I logged board power at 1Hz with nvidia-smi while driving fixed-length generations through four models from 3B to 20.9B parameters, then divided each run’s decode rate by the watts that produced it. The result is the number almost nobody publishes for consumer cards: joules per token, and from it, real dollars per million tokens at the current EIA US residential electricity average of $0.184/kWh.

Two findings up front. First, the sparse-MoE gpt-oss 20B beats the dense 7B on tokens per joule (0.665 vs 0.53) and doubles the dense 14B (0.317) — active-parameter count and quantization set the electric bill, not total size. Second, the quiet budget-killer: this card measures 52–71W at idle in my system — not the 8–15W reference figure reviews quote — which at 24/7 duty is $85–115/year before a single token is generated.

The numbers (capture 2026-08-19, stock 448W power limit)

Model	Quant	Decode tok/s (med)	Board W (med, loaded)	Tokens/joule	Wh per 1M tokens	$ per 1M tokens
Llama 3.2 3B	Q4_K_M	318.3	265.2	1.20	231	$0.043
Qwen 2.5 7B	Q4_K_M	182.2	343.6	0.53	524	$0.096
Qwen 2.5 14B	Q4_K_M	98.8	311.6	0.32	876	$0.161
gpt-oss 20B	MXFP4 (MoE)	194.4	292.4	0.67	418	$0.077

Loaded-basis medians: telemetry samples counted only at GPU utilization ≥ 50%. Decode rates are ollama’s own eval counters (fresh prompt every iteration — cached-prompt runs report prefill artifacts, not decode). Full column set including clocks, temperature, VRAM, and per-run min/max is in the CSV.

What the data says

Sparsity beats size. gpt-oss 20B is the second-most efficient model on the card despite carrying the most total parameters — 0.67 tokens/joule against the dense 7B’s 0.53 and the dense 14B’s 0.32. It is a mixture-of-experts design that activates only a fraction of its weights per token, shipped in MXFP4, so it decodes at 194 tok/s while drawing less power than the 7B. If your workload fits its quality profile, the 20B is both the smartest and the second-cheapest model per token in this ladder — the dense-model intuition that “bigger costs more electricity per token” fails here.

Board power barely moves; efficiency moves 4x. Across a 7x spread in total parameters, loaded board power stays inside a narrow 265–344W band — the card runs at 59–77% of its 448W limit no matter what I feed it, and never once touched the cap. The 7B is the thirstiest of the four (343.6W): it generates fast enough to keep the memory bus saturated while still lighting up plenty of compute. What actually separates the models is the numerator — tokens delivered per second — which is why tokens-per-joule spans 0.32 to 1.20 while watts span barely 30%.

The marginal token is nearly free; the idle hours are not. Even the least efficient row costs $0.161 of electricity per million tokens — a full novel’s worth of output for under two cents at the May-2026 EIA residential average. Set against the idle finding below (52–71W around the clock ≈ $85–115/year), the budget conclusion for a home inference node inverts the usual framing: model choice barely matters to the bill; what the box does during the other 23 hours dominates it. Temperatures never passed 52°C at a 30% fan median, and the 448W cap was never reached — which also means a power-limit sweep should cost little throughput, and that is exactly the queued v1.1.

The idle-power finding

Every 24/7 cost model I have seen for this card starts from single-digit idle watts. Mine doesn’t idle there: across repeated captures this week the card sat between 52W and 71W at the Windows desktop, pinned in P0 with graphics clocks near 2.9GHz — multi-monitor output holds the high P-state, an animated wallpaper added ~6W and 2% utilization on its own, and the cleanest state I could produce (wallpaper closed, no model resident) still read 53.7W. This is a known behavior class, not a defect, but it is the number an always-on node actually pays: at $0.184/kWh, 52–71W around the clock is 456–622 kWh ≈ $85–115/year of pure idle. If your 5080 box mostly waits for occasional inference, the idle line, not the inference line, dominates the bill — check your own card with nvidia-smi --query-gpu=power.draw --format=csv before trusting any spec-sheet idle figure, mine included.

Method, exactly

Card: ASUS ROG Astral RTX 5080 OC (the same physical card as the throughput dataset and the Astral bench dataset), stock 448W power limit, driver-default clocks.
Host: Ryzen 7 7800X3D, 64GB DDR5-6000, Windows 11, ollama 0.32.1.
Workload: ollama run <model> --verbose generating from a fixed ~60-word prompt with a unique per-iteration prefix (defeats ollama’s prompt cache, which otherwise reports cache-hit rates that measure nothing). Three iterations per model.
Telemetry: nvidia-smi --query-gpu=power.draw,clocks.gr,temperature.gpu,utilization.gpu,memory.used,... polled at 1Hz for the whole profile window; the published watts are medians over samples with utilization ≥ 50% so idle seconds between iterations never dilute the load figure.
Pairing: each efficiency figure divides a profile’s median decode rate by that same profile’s median loaded watts — never a rate from one run by watts from another.
Decode, not prefill: the parser anchors on ollama’s eval rate: line start; a substring match also catches prompt eval rate: and silently records prefill — a bug these capture scripts had and fixed, documented in the scripts themselves.

Limitations, honestly

One prompt shape. Single-stream interactive decode from a short prompt; batch serving, long-context prefill, and draft-model setups will land elsewhere. The throughput dataset covers context scaling; its decode rates are the canonical speed numbers for this card.
Board power only. nvidia-smi reports GPU board draw — CPU, RAM, fans, and PSU efficiency losses are excluded. Wall draw for the whole box runs higher; my measured whole-rig figures live in the perf-per-watt article.
Stock power limit only (for now). The obvious next axis — the same ladder at 400/350/300W caps — needs an elevated shell for nvidia-smi -pl; that sweep is queued as v1.1.
Windows + this driver. P-state and idle behavior differ across OS/driver/monitor configurations; the 70W idle is my system’s truth, not a universal constant.

Use the data (CC BY 4.0)

Cite as “TechFuelHQ RTX 5080 LLM power-efficiency dataset, v1.0.0”. The table CSV is at /data/rtx-5080-llm-power-efficiency.csv; the raw 1Hz telemetry CSVs (one per run) and the capture manifest are in /data/rtx-5080-llm-power-efficiency-raw/. Attribution: TechFuelHQ / Lowell K. Wood IV, link to this page.

Change log

1.0.0 (2026-08-19) — initial publication: 4-model stock-power ladder (3B/7B/14B/20.9B), loaded-basis power medians, joules-per-token and $/Mtok at $0.184/kWh, raw telemetry CSVs, idle-power finding.

Best Motherboards for Ryzen 7 9800X3D (2026)

LK Wood IV — Tue, 18 Aug 2026 00:00:00 -0500

By LK Wood IV · Published 2026-08-18 · 14 min read · St. Louis County, MO

The three boards at a glance

The 9800X3D reaches full gaming speed on a well-built mainstream board. These picks buy three different layouts; CPU performance stays in the same class, so every dollar above the B850 default must purchase a port, lane, form factor, debug control, or expansion path the build will use.

Pick	Best for	The features that justify it	Aug. 17 reference
MSI MAG B850 Tomahawk Max WiFi	Best ATX value for most builds	PCIe 5.0 x16, Gen5 M.2, Wi-Fi 7, 5GbE, strong 80A-stage listing	$209.99 standalone
ASUS ROG Strix B850-G Gaming WiFi	White micro-ATX build	Four M.2, Wi-Fi 7, 2.5GbE, 20Gbps USB-C, PCIe 5.0 x16	ASUS listed $259.99 standalone; bundle was $1,059.99
ASUS ROG Crosshair X870E Hero	Storage, USB4, and expansion-heavy build	Five M.2, SlimSAS, dual USB4, 5GbE + 2.5GbE, Wi-Fi 7	ASUS listed $569.99 standalone; bundle was $1,599.99

The standalone MSI price is a dated Newegg feed snapshot. The ASUS figures came from the official product-page offers captured on August 18. The bundle figures are current retailer snapshots described later. Check the live number before ordering.

The rule that prevents motherboard overspending

Buy the cheapest well-built board that has the ports you will use. Then verify its slot and lane map. Write those requirements down before opening retailer tabs; otherwise every extra feature looks useful in isolation.

The Ryzen 7 9800X3D is an eight-core, 120W AM5 processor. A decent B850 board already supplies ample CPU power. Moving to X870 or X870E changes the connectivity floor and lane layout; it does not add gaming frames by itself.

I would reject a board for:

no BIOS Flashback on an expensive build
weak rear I/O for the devices you own
only gigabit Ethernet when faster networking matters
a lane-sharing rule that disables a card or drive you plan to install
too few M.2 slots for the build’s life
a price that approaches premium X870E territory without premium I/O

A lower chipset rung does not disqualify a board. A missing port or broken lane plan does.

1. MSI B850 Tomahawk Max WiFi is the default

The B850 Tomahawk Max WiFi is the board I would put under a 9800X3D gaming system unless the build brief names a reason to move. That reason should be concrete: a smaller white case, five NVMe drives, USB4 peripherals, or an add-in-card layout this board cannot serve.

The exact Newegg row lists:

ATX form factor
B850 chipset and AM5 socket
PCIe 5.0 x16
a Gen5 M.2 slot
Wi-Fi 7
5GbE
four DDR5 slots
four SATA ports
an 80A smart-power-stage design

That is the useful part of a modern high-end platform without a flagship tax. The August 17 feed captured $209.99 against a $229.99 regular field. Even if the live price moves, the board belongs in the low-$200 class. A $500 board serves a different build.

There is one layout caveat in the retailer specification: the lower PCIe 4.0 x4-length slot drops to x2 when M.2_3 is populated. If you plan to run a fast capture card, storage adapter, or 10GbE NIC there, read the manual before filling every M.2 slot. Gaming builds with one GPU will rarely care. Hybrid workstation and homelab builds can care immediately.

For a gaming tower with one GPU, two or three NVMe drives, and onboard networking, this is the complete answer.

2. ROG Strix B850-G is the white micro-ATX pick

The B850-G exists for a different build. It compresses a premium-looking white AM5 platform into micro-ATX without stripping the storage and rear I/O that usually disappear first.

ASUS specifies:

micro-ATX
14+2+1 power stages
PCIe 5.0 x16
four M.2 slots, including one Gen5 slot
Wi-Fi 7
Intel 2.5GbE
ten rear USB ports, led by 20Gbps Type-C
BIOS Flashback and Clear CMOS buttons

The fourth M.2 slot sits on the underside, which matters for access and cooling. Two SATA ports are also lean for anyone reusing several 2.5-inch drives. Those layout costs should be in the case plan. Install the underside SSD before the board goes into the chassis; discovering it later turns a two-minute upgrade into a teardown.

ASUS’s page listed $259.99 at capture. That premium over the MSI buys a smaller white board and its particular I/O arrangement. It does not buy a faster 9800X3D.

Search NeweggLink checked 2026-08-18

3. Crosshair X870E Hero is for expansion

The Crosshair X870E Hero is not the “best gaming” choice. It is the choice for a system that needs to behave like a workstation while keeping an X3D gaming CPU.

Its reason to exist is the I/O map:

five M.2 slots, three of them Gen5 with a Ryzen 9000 or 7000 processor
SlimSAS plus four SATA ports
two USB4 40Gbps rear ports
eight additional 10Gbps rear USB ports
5GbE and 2.5GbE
Wi-Fi 7
two full-length CPU-connected slots with configurable lane sharing
onboard Q-Code, start controls, BIOS Flashback, and Clear CMOS

The lane-sharing rules deserve attention. Populate the second and third CPU-connected M.2 slots and the primary graphics slot can fall to x8 while the second full-length slot changes or disables. That is normal on a feature-dense desktop platform, but it means the installation order needs a plan. Sketch the final drive and card map first. Buying five slots is useless if populating the wrong two breaks the slot you bought the board to gain.

ASUS listed $569.99 at capture. Spend that only when the five-drive layout, USB4, dual wired networking, or slot flexibility replaces hardware you would otherwise add. A single-GPU gaming PC with two drives does not need it.

Search NeweggLink checked 2026-08-18

B850 vs X870 vs X870E for the 9800X3D

Chipset class	Buy it when	Do not buy it for
B850	One GPU, normal NVMe count, gaming-first value	More FPS from the CPU
X870	You want USB4 and a stronger modern-I/O baseline	A belief that “X” means faster games
X870E	You need more high-speed expansion and can map the lanes	One GPU, two drives, and no add-in cards

AMD’s AM5 chipset table is the right starting point, but a model’s manual is the final authority. Two boards with the same chipset can expose different slots and controllers. Their sharing rules can differ too.

That is why the shortlist crosses chipset tiers. It follows build requirements.

Are the CPU bundles worth it?

The August feed contained several Ryzen 7 9800X3D motherboard bundles. Three illustrate why “bundle” is not a synonym for “deal.”

Bundle	Aug. 17 snapshot	Rendered seller check, Aug. 18	What to verify
Sapphire NITRO+ B850M + 9800X3D	$969.99	TECH EDGE; new; ships from China; not fulfilled by Newegg	Manufacturer warranty flag was false; returns were non-replaceable
ASUS ROG Strix B850-G + 9800X3D	$1,059.99	TECH EDGE; new; ships from China; not fulfilled by Newegg	Manufacturer warranty flag was true; still compare return freight and delivery
ASUS Crosshair X870E Hero + 9800X3D	$1,599.99	TECH EDGE; new; ships from China; not fulfilled by Newegg	Manufacturer warranty flag was true; the premium only works if you need the board

The seller was rated 4.6/5 over 39 reviews in the prior 12 months and marked Top Rated in the embedded listing data at capture. That is useful context. It is not the same purchase path as a direct Newegg item. A heavy motherboard-and-CPU return to China can consume the paper discount in freight and delay. It also adds transit risk.

Price the CPU and board separately first. Newegg’s exact 9800X3D row was $479 in the same feed. Add the $209.99 MSI board and the parts total is $688.99 before tax. A $969.99 micro-ATX bundle therefore needs to justify roughly $281 through a different board, availability, or terms. The Crosshair bundle is a specialist purchase rather than a value shortcut.

If you still want a bundle, use the current searches below and inspect the exact seller block before payment.

Search NeweggLink checked 2026-08-18

What about B650 and X670?

You do not need to replace a good AM5 board merely because B850 and X870 exist.

If you already own B650, B650E, X670, or X670E, check the manufacturer’s 9800X3D BIOS support and the ports you need. A supported existing board is usually the value winner. The ROG Strix B650-A review covers one real example of a B650 board running an X3D system with ample power delivery.

Before a BIOS update, back up important data and do not interrupt power during the flash. Use BIOS Flashback when the board supports it and the installed CPU cannot boot the current firmware.

This page covers a new board purchase. A working compatible platform should stay in service.

RAM, cooling, and the rest of the build

Use two DDR5 modules. DDR5-6000 with an AMD EXPO profile is the low-drama target; the DDR5 buying guide explains why a larger advertised number is not automatically a better AM5 result. For the purchase itself, use the open RAM price index: its August 18 capture reviewed 583 listings, still found only three of 12 tracked kits that cleared the direct-retailer rules, and put the cheapest qualifying 32GB observation at $459.99. The gate remains closed, so treat the table as dated offers rather than a broad market average.

The 9800X3D does not include a cooler. Board selection should therefore leave room in the case and budget for the cooling hardware you want. The board does not need a giant VRM heatsink to survive this CPU, but the case still needs airflow across the socket, memory, SSD heatsinks, and graphics card. Header placement matters here: count pump and fan headers against the actual radiator and case layout, rather than assuming a premium board has one in the convenient corner.

One build can overturn the entire default. Imagine a 9800X3D workstation with an RTX 5080, three Gen5 scratch drives, two more archive SSDs, a capture card, 10GbE today, and a USB4 RAID enclosure already on the desk. The Crosshair’s price is suddenly easier to defend because one board replaces an add-in network card, a storage adapter, and a Thunderbolt-style expansion plan. Remove those devices and the logic collapses back to B850. That is the standard: every premium interface should displace another cost or solve a named constraint. The workstation case can defend the X870E premium because its five-drive map, USB4 enclosure, faster wired links, debug controls, and second expansion slot replace a pile of adapters while keeping the build coherent; a one-GPU gaming tower with two SSDs receives none of that value, even though both machines use the same processor and can post the same frame rate. Run the same test in reverse before paying: remove USB4, the fifth drive, the second network link, and the extra card from the parts plan; if the system still works exactly as intended, the premium board has lost every job that made it rational and the B850 choice is stronger.

Finally, map the whole build before checkout:

exact case form factor
GPU thickness and slot obstruction
number of M.2 and SATA drives
front USB-C header requirement
wired network speed
add-in cards now and later
fan and pump-header count

The PC Builder catches the basic socket and form-factor problems. Its open 126-part compatibility dataset exposes the source and last-verified date behind each supported row. The board manual catches the lane-sharing rules that a category-level dataset cannot.

The shortest honest recommendation

Buy the MSI B850 Tomahawk Max WiFi for a normal ATX 9800X3D gaming build.

Buy the ROG Strix B850-G when the machine must be white and micro-ATX.

Buy the Crosshair X870E Hero only when five M.2 slots, USB4, dual wired networking, or its expansion controls are already part of the plan.

Anything beyond that is paying for a feature list you have not assigned a job.

Best RTX 5080 Prebuilt Gaming PCs (2026)

LK Wood IV — Tue, 18 Aug 2026 00:00:00 -0500

By LK Wood IV · Published 2026-08-18 · 13 min read · St. Louis County, MO

The three picks at a glance

All three finalists use the same performance core: Ryzen 7 9800X3D, GeForce RTX 5080 16GB, 32GB DDR5, and a 2TB NVMe SSD. The table therefore ranks what usually stays hidden in a prebuilt listing.

Pick	Why it made the list	Disclosed power supply	Newegg feed snapshot, Aug. 17
ABS Kaze II Ruby	Best disclosed parts list and power hardware	Gamdias HELIOS P2-1000G, 1000W Gold	$2,939.99
Andromeda Insights V3 Ultra 50	Best value; explicitly lists DDR5-6000 and an 850W Gold supply	850W Gold, brand not stated	$2,799.99
Acer Nitro UD.P02AA.070	Brand-name alternative with liquid cooling	850W, efficiency and model not stated	$3,299.99

Those prices are dated retailer-feed snapshots. The exact Newegg pages still resolved to the matching item on August 18, and all three pages showed Newegg as both seller and shipper at capture. Inventory can move before this page does.

How I ranked the systems

I started with a hard floor, then let disclosed component quality break the tie. A product page that names the PSU model, memory arrangement, storage generation, board, and seller path can justify a modest premium because each disclosed field removes a return-window investigation; a page that repeats only the CPU and GPU cannot.

RTX 5080 16GB and Ryzen 7 9800X3D. A cheaper processor can still run a 5080, but it is less hardware at this price. Every finalist uses AMD’s eight-core X3D chip.
32GB DDR5 and 2TB NVMe. A $3,000 gaming PC should not arrive with 16GB or a cramped 1TB system drive.
At least 850W. NVIDIA lists 850W minimum system power for the 360W RTX 5080. The full RTX 50-series PSU guide explains when 1000W becomes the better buy.
A listing that names the weak links. PSU model, memory speed, motherboard, cooler, seller, and warranty matter. Silence is a risk, not a premium feature.
The title, item number, and destination had to agree. I discarded feed rows whose product name and Newegg URL described different hardware.

RGB earned zero points. A giant discount badge against a price the system may never have sold for earned zero too.

1. ABS Kaze II Ruby has the strongest disclosed parts list

The Kaze II Ruby wins because its parts list answers the most expensive hidden question. Newegg names the power supply as a Gamdias HELIOS P2-1000G 1000W 80 Plus Gold unit. That changes the decision: the other two finalists list capacity, but they never identify the complete model.

The rest is the right shape for a high-end gaming system:

Ryzen 7 9800X3D
RTX 5080 16GB
32GB DDR5
2TB PCIe NVMe SSD
Wi-Fi 6
Windows 11 Home

The August 17 feed showed $2,939.99, down from a listed $3,499.99 regular figure. I care more about the $2,939.99 checkout number than the size of that markdown. The flashy percentage badge can disappear tomorrow; the named power supply is still the hardware inside the case.

There are still three checks to make. Confirm the 32GB arrives as two modules, identify the motherboard, and read the current warranty and return language. A named PSU does not make every undisclosed part disappear. It does make this the easiest system to approve. If the checkout configuration swaps any of those fields, stop and re-price the machine.

2. Andromeda V3 Ultra 50 is the value pick

The Andromeda was the least expensive qualified system in the feed at $2,799.99. It also discloses more memory detail than the other listings: 32GB of DDR5-6000. The 2TB drive is described as Gen4, and the power supply is rated 850W Gold.

That is a strong specification sheet for $140 less than the ABS. The trade is confidence around the power supply. “850W Gold” tells you the capacity and efficiency tier; it does not identify the platform, protections, cable, or warranty. NVIDIA’s 850W floor means the capacity is sufficient. The missing model is why this system finishes second. Ask for the exact unit before the return window closes; a photo of the side label settles it in seconds.

The exact page showed the matching Andromeda title. Newegg handled both the sale and shipment from the United States when checked. That removes the marketplace ambiguity that sinks many cheaper-looking results.

Buy this one when the price gap matters and the listing or support team can provide the exact PSU and memory configuration before the return window closes.

Check NeweggLink checked 2026-08-18

3. Acer Nitro is the brand-name alternative

Acer’s Nitro UD.P02AA.070 keeps the same core specification and adds liquid CPU cooling. The listing names a Ryzen 7 9800X3D, RTX 5080 16GB, 32GB DDR5, 2TB PCIe NVMe SSD, and an 850W power supply.

It also asks the most. The feed captured $3,299.99, which is $360 above the ABS and $500 above the Andromeda. The listing does not name the PSU model or efficiency certification, and it specifies gigabit Ethernet rather than a faster wired interface.

That does not make the Acer a bad machine. It makes the premium hard to defend from the published parts list alone. Choose it if the exact Acer service package, local availability, or chassis design has value to you. On hardware disclosure per dollar, it ranks third. At this price, brand familiarity needs to arrive with a better support path, not merely a familiar badge.

Check NeweggLink checked 2026-08-18

What I rejected

The live search results contain dozens of RTX 5080 systems. Most fail for one of five reasons.

A lower-tier CPU at the same system price

A Core i7-14700F or Ryzen 7 9700X can be a good processor. It does not belong in a system priced beside these 9800X3D builds unless the rest of the machine is materially better.

Sixteen gigabytes of system memory

That is an immediate upgrade on a new flagship PC. It also raises the chance of a single-module configuration. Thirty-two gigabytes is the floor here.

One terabyte of storage

Modern game libraries fill it quickly. A 2TB system drive is a modest requirement at this budget, and all three picks meet it.

A vague or undersized power supply

The RTX 5080’s official requirement is 850W system power. A listing below that floor is out. A listing that says only “1000W” without a model still needs investigation; wattage cannot tell you build quality.

Marketplace ambiguity

The product page must identify seller and fulfillment. It must also state the condition and warranty. The return path needs to be clear. A low price from an unknown seller can erase its savings with one freight return, and on a 40-pound glass-sided tower the expensive failure is rarely the missing five percent of benchmark performance; it is discovering after delivery that the power supply, memory layout, or warranty differs from the product tile while the only remedy is packing the entire machine again.

The price ceiling for a 32GB and 2TB build

My cutoff for this specification is roughly $3,500 before tax. Cross it, and I want a visible reason:

64GB instead of 32GB
4TB instead of 2TB
a premium factory-overclocked RTX 5080
a clearly better motherboard, PSU, and cooling stack
a service package worth buying

A basic 32GB/2TB system at $3,700 is too close to premium-custom pricing. It also gets uncomfortably close to the next GPU tier. If you are willing to assemble the machine, compare the full bill against the $2,500-class RTX 5080 build and load the same parts into the PC Builder.

What performance should you expect?

NVIDIA specifies the RTX 5080 with 10,752 CUDA cores, 16GB of GDDR7, a 360W total graphics power rating, and an 850W minimum system requirement. The Ryzen 7 9800X3D supplies eight Zen 5 cores and 96MB of L3 cache on AM5.

Those specifications put every finalist in the same broad performance class. Cooler design and the installed GPU model decide some of the small gaps, while power limits, BIOS behavior, and memory configuration decide the rest.

For a measured reference, the ROG Astral RTX 5080 OC review includes first-party 4K results and a 308-sample power log. The open bench dataset carries the underlying game and clock rows, plus thermal and power measurements, under CC BY 4.0. Use it as a picture of what one well-cooled premium 5080 did; an OEM card may hold different clocks.

The practical target is 4K gaming. At 1440p, a cheaper GPU can often deliver the experience without forcing the rest of the build into this price band. The 2026 4K GPU guide maps that break point. If your monitor is still 1440p/144Hz, spend against the display before paying for unused GPU headroom.

Here is the edge case that changes my answer. A buyer who keeps a PC for six years, moves from 1440p to a 4K OLED next spring, runs local models on the 16GB card, and refuses to replace parts mid-cycle can justify buying the 5080 tower before the current monitor demands it. That is a planned multi-use purchase, not a vague future-proofing claim.

There is measured evidence for the local-model half. On TechFuelHQ’s retail RTX 5080, the open Ollama throughput dataset recorded gpt-oss:20b fully GPU-resident at roughly 13.7–14.0 GiB and 187–190 decode tokens per second; the raw CSV is mirrored on Kaggle and Hugging Face. That does not benchmark image generation or prove every 16GB workload fits. It does show that a named local-AI role can be real rather than speculative.

The six-year plan has named workloads and a named display upgrade, with enough time for the premium to spread across several roles. Remove the 4K display and local workload, and the logic collapses: a gaming-only 1440p buyer is left with expensive capability no current screen or workflow can turn into visible value.

The 60-second checkout audit

Do this after clicking through and before payment.

Match the item number to the exact row in this guide.
Confirm Ryzen 7 9800X3D and RTX 5080 16GB in the selected configuration.
Look for two memory modules. If the page stays silent, ask or check immediately after delivery.
Confirm the PSU model and a native 12V-2x6 cable where possible.
Count open M.2 slots and accessible DIMM slots for future upgrades.
Read who sells it and who ships it.
Open the warranty and return terms.
Screenshot the final configuration and delivery promise.

If one of those fields changes, re-rank the system. The model name on the case matters less than the parts and terms attached to the exact SKU, because two towers wearing the same product-family badge can differ in the power supply and memory layout. They can also arrive with a different motherboard, SSD, cooler, seller, warranty, or delivery promise. Those details decide whether a prebuilt stays an easy purchase or becomes an expensive return. The exact-SKU check is the purchase: without it, a familiar family name can hide a lower-tier power supply, one memory module instead of two, a different motherboard, or a return path that turns a small discount into a freight bill after the tower is already in your house.

Best RTX 5090 Prebuilt Gaming PCs (2026)

LK Wood IV — Tue, 18 Aug 2026 00:00:00 -0500

By LK Wood IV · Published 2026-08-18 · 14 min read · St. Louis County, MO

The three picks at a glance

These systems share the expensive core: Ryzen 7 9800X3D, GeForce RTX 5090 32GB, 32GB DDR5, and 2TB of solid-state storage. The ranking turns on the platform around those parts and the price attached to the exact SKU.

Same GPU and CPU. Very different risk.

Pick	Why it made the list	Disclosed power and cooling	Live Newegg price, Aug. 18
Stormcraft Valkyrie	Best pick; most complete useful disclosure	1300W 80 Plus Gold, 360mm AIO	$5,599.99
Acer Nitro N80-181-UR19	Best value; same gaming core for $300 less	1200W, liquid cooling; PSU model not stated	$5,299.99
Thermaltake View 9890S	Premium white X870 alternative; not the value choice	1200W Gold ATX 3.0, Thermaltake 360mm AIO	$6,699.99

All three pages showed sold and shipped by Newegg when captured. These are live-page snapshots. Prices can move. Thermaltake is the important warning: its August 17 affiliate feed showed $6,090.99, but the rendered product page was $6,699.99 on August 18. The checkout page wins that disagreement.

How I ranked the systems

The full August 17 feed held four direct-catalog RTX 5090 desktops. Two Stormcraft rows used the same chassis and price with different processor platforms, so I narrowed the final comparison to the three Ryzen 7 9800X3D systems; holding the gaming CPU, GPU, memory capacity, and storage capacity steady exposes the platform differences instead of burying them under a changing processor.

I then scored the parts that can turn a $5,000-plus computer into a poor purchase:

Power path. NVIDIA rates the RTX 5090 at 575W and specifies 1000W required system power. A 1200W or 1300W supply is the right capacity class here, but capacity is only the start. The model, protections, and native GPU cable still need confirmation.
Memory configuration. Thirty-two gigabytes must be two modules. Acer and Stormcraft explicitly showed 16GB x 2 in the captured specifications.
Cooling and airflow. A 360mm AIO earns confidence only as a disclosed component, not as proof of low temperatures or noise. I have not tested these systems.
Storage and motherboard. A 2TB system drive is the floor. Gen4 detail and a named chipset make future expansion easier to judge.
Seller and price integrity. The item number, title, live price, seller, and shipper had to agree on the rendered page.

RGB, “AI powered,” and giant markdown badges earned nothing. Exact parts and a clean return path did.

1. Stormcraft Valkyrie is the best pick

The Valkyrie asks $300 more than Acer and gives a visible reason for most of that difference. Its product page names:

Ryzen 7 9800X3D
RTX 5090 32GB
32GB as two 16GB DDR5-6000 modules
2TB Gen4 NVMe SSD
AMD B850 motherboard
360mm AIO liquid cooler
seven ARGB fans
1300W 80 Plus Gold power supply

That is the strongest platform disclosure in the direct-retailer set. The 1300W capacity sits above the practical 1200W target in the RTX 50-series PSU guide, and the listing gives the memory speed, module count, storage generation, motherboard chipset, radiator size, and fan count. The page also showed Newegg as both seller and shipper.

Several identities remain hidden: “1300W 80 Plus Gold” does not name the PSU manufacturer or model, and the listing says component brands may vary, which means the exact graphics card, memory kit, SSD, board model, and supply can change within the stated specification. I cannot call those parts premium. The page still tells the buyer more than the others.

At $5,599.99, the Valkyrie is the best choice when you want the 5090 tier and would pay $300 to remove several expensive unknowns. Confirm those fields one final time before ordering.

2. Acer Nitro is the value pick

Acer’s N80-181-UR19 is the lowest-priced direct 9800X3D and RTX 5090 system in the captured feed and live pages. At $5,299.99, it is $300 below the Stormcraft and $1,400 below the Thermaltake.

The useful disclosures are better than the short feed title suggests:

Ryzen 7 9800X3D
RTX 5090 32GB
32GB DDR5 as 16GB x 2
2TB PCIe SSD
1200W power supply
liquid CPU cooling
Wi-Fi 6 and gigabit Ethernet

The 1200W capacity is appropriate. The weak point is identity. The page does not name the PSU model or efficiency certification, and its detailed table says only “Liquid Cooling” even though the title advertises a 240mm AIO. It also leaves the motherboard model and SSD generation unstated.

That makes Acer the value pick, with a plain trade: save $300 and accept less component identity, or pay Stormcraft for DDR5-6000, a named B850 chipset, Gen4 storage detail, a larger listed radiator, and another 100W of supply capacity. Choose Acer when the support channel, chassis, and saving matter more. Photograph the PSU label and memory modules after delivery, before the return window gets short.

Check NeweggLink checked 2026-08-18

3. Thermaltake View 9890S is the premium alternative

The View 9890S has the clearest named cooling and platform combination:

Ryzen 7 9800X3D
RTX 5090 32GB
32GB DDR5-6000
2TB NVMe SSD
AMD X870 chipset
Thermaltake 360mm ARGB AIO
1200W 80 Plus Gold ATX 3.0 power supply
Wi-Fi 7
white panoramic chassis

Those are real differences. X870, a named Thermaltake radiator, Wi-Fi 7, a white build, and a more explicit ATX 3.0 supply description can matter to a buyer who wants this exact design.

The price breaks the general recommendation: the live page showed $6,699.99, or $1,100 above Stormcraft and $1,400 above Acer, while the prior feed showed $6,090.99. At the live number, the premium buys appearance and platform detail rather than more GPU, CPU, memory, or storage capacity.

I would skip that premium for gaming performance. This system stays on the list as the distinct white X870 alternative. It does not compete for value at the captured price. If it falls near the Valkyrie, re-run the comparison.

Check NeweggLink checked 2026-08-18

Why these are 9800X3D systems

At this price, the processor should fit the job. The Ryzen 7 9800X3D is an eight-core, 16-thread, 120W AM5 processor with 96MB of L3 cache. It is the gaming-first choice in the captured direct-retailer set.

The feed also held a $5,599.99 Stormcraft Valkyrie with an Intel Core Ultra 7 270K Plus, a system that can make sense for a different workload mix but would blur this gaming comparison by changing the processor platform while every other finalist stays on the 9800X3D.

I kept the CPU constant on purpose. Once every row uses a 9800X3D and RTX 5090, the reader can compare the system rather than decoding two product categories at once.

What a $5,000-plus prebuilt must disclose

The expensive GPU cannot be permission for everything around it to become vague. A machine at this price should make its electrical and upgrade constraints easy to inspect before you pay, then easy to verify again when the box arrives. Two facts from this comparison show why the second check matters. Thermaltake’s live price had moved $609 above the prior feed snapshot. Stormcraft warns that component brands may vary inside the stated configuration. Save the checkout screenshot. When the box arrives, compare the delivered graphics card and power supply against the order. Check the memory module count and motherboard next. Finish with the SSD and cooler. Inspect the cabling before the return window gets short.

A native high-current power path

NVIDIA lists 575W total graphics power and 1000W required system power for the RTX 5090. A capacity label of 1200W or 1300W clears the first test. The exact PSU model and a native cable clear the second.

Avoid treating four adapter leads as a harmless visual issue. This is a high-current connection behind a large card. Confirm the cable type, seat it fully, and avoid a tight bend at the connector.

Two memory modules

The captured Acer and Stormcraft pages showed 16GB x 2. Thermaltake disclosed 32GB DDR5-6000 but did not expose the module count in the same table. Confirm two modules before accepting the configuration.

Thirty-two gigabytes is enough for gaming. The DDR5 buying guide covers capacity and timing tradeoffs if this tower will also be a 64GB creator or local-AI machine.

Storage that fits the price

Two terabytes is the floor at this tier. Stormcraft identifies its drive as Gen4. Acer says 2TB PCIe, while Thermaltake says 2TB NVMe. None of those capacity lines tells you controller, endurance, or sustained write behavior.

Identify the installed SSD after delivery and count the open M.2 slots. A $5,500 tower should not require replacing its only system drive just to add working space.

A motherboard and case you can expand

Stormcraft discloses B850. Thermaltake discloses X870. Acer leaves the board unnamed in the saved specification. The chipset will not create gaming frames. It does help define storage lanes and USB. It also tells you more about networking and future cards.

Case dimensions and slot clearance matter too. An RTX 5090 is not a small component. Confirm that the installed model has room to breathe and that adding another card or bottom-mounted fans will not choke it.

RTX 5090 or RTX 5080 prebuilt?

The RTX 5090 tier needs a named reason. Mine would be one of these:

maximum native or lightly upscaled 4K performance
a 4K high-refresh display that can expose the difference
32GB of VRAM for local AI, rendering, or creation
one machine serving both gaming and a GPU-heavy paid workload

If the computer is for ordinary 1440p gaming or 4K with DLSS, the best RTX 5080 prebuilt guide starts at $2,799.99 in the same dated retailer feed. The jump from that value pick to the least expensive 5090 system here was $2,500. That money can buy a serious display and a later GPU upgrade. It can also fund the memory and storage the system will use every day.

The RTX 5090 is faster. It is not automatically the better purchase. NVIDIA’s official specifications put the difference in plain terms: 32GB versus 16GB of GDDR7 and a 575W versus 360W power rating. The 2026 4K GPU guide places both cards in the wider buying ladder.

The price ceiling

My practical ceiling for this configuration is about $6,000 before tax. That means a 9800X3D, 32GB, 2TB, and an RTX 5090. Cross the line only when the premium buys something you can name.

Above that line, I want several of these:

64GB of memory
4TB or more of quality storage
an explicitly named premium RTX 5090 model
a named high-end power supply
a motherboard and networking stack worth the difference
a service package with measurable value
a chassis and cooling configuration you were already willing to buy separately

Thermaltake’s live $6,699.99 can be defended only by the buyer who already values its white panoramic design, X870 platform, Wi-Fi 7, named 360mm cooler, and ATX 3.0 power description. Those features do not make it $1,100 faster than Stormcraft.

The 60-second checkout audit

Do this after clicking through and before payment.

Match the item number to the exact system in this guide.
Confirm Ryzen 7 9800X3D, RTX 5090 32GB, 32GB DDR5, and 2TB storage.
Look for two memory modules and record their speed.
Identify the exact PSU model and native GPU cable.
Identify the graphics-card, motherboard, SSD, and cooler models.
Confirm who sells it and who ships it.
Open the warranty and return terms, including freight.
Check case clearance, open M.2 slots, and usable expansion slots.
Screenshot the final configuration, price, delivery date, and seller block.

If the configuration changes, the ranking changes with it. At this price, a family name is not a substitute for the exact hardware and terms you are buying.

TechFuel HQ

LM Studio vs Ollama on an RTX 5080: Measured (2026)

The verdict, by use case

What people claim vs what I measured

Same engine underneath, same process name

The defaults are the real story

Memory: VRAM is a tie, RAM is not

The portability catch travels

Which one belongs on your machine

Method and limits

The Self-Hosted SSO Tax: A Verified Tracker (2026)

What is the self-hosted SSO tax?

What counts, and what does not

SAML, OIDC, LDAP: not the same thing

The tracker: self-hosted apps that charge for SSO

What happened with Planka SSO

Self-hosted apps where SSO stays free

Your escape hatches

Related retreats: not SSO, same pattern

The maintainer’s side

How this page is maintained

Critical Process Died? Check the Drive First (2026)

What CRITICAL_PROCESS_DIED means

Step 1: Which of the three situations are you in?

Step 2: If your files matter, secure them before any repair

Step 3: Check the drive first — the two-minute test the checklists bury

Step 4: The software half, cheapest fixes first

Step 5: Locked out — the boot-loop path through WinRE

Step 6: RAM and the rest of the ladder

Step 7: If the drive is the verdict — rescue, then replace

Keeping it from coming back

Sources

Home Assistant + llama.cpp: Fully Local LLM Voice, Measured (2026)

What I measured, and what I did not

The architecture, corrected

Hardware tiers, honestly

Step 1: Run llama-server where the compute is

Step 2: Connect Home Assistant

Model choice: the accuracy table I went looking for and had to build

Latency results

Tuning notes from the bench

Why local, briefly

Sources

Memory Management BSOD? Don't Buy RAM Yet (2026)

The new-RAM question, answered first

Step 1. Read the signature - when does it hit?

Step 2. The ten-minute test that beats an overnight one

Step 3. Test the sticks so the result means something

Step 4. The storage crossover nobody checks

Step 5. Drivers and Windows - the honestly-bounded half

If a stick really is dead - replacement, priced honestly

Keeping it stable

Sources

Why Hard Drives Got So Expensive in 2026 (and What to Do About It)

What an 8TB NAS drive costs right now, measured

Step 1: what kind of buyer are you?

Why are hard drives so expensive in 2026?

Why did it hit hard drives later than RAM?

New vs recertified vs SSD: the $/TB math

When will hard drive prices drop?

The reliability question the prices force

How I track this

Best Local LLM for Coding in 2026: Tested on a 16GB RTX 5080

Picks as of August 2026, by VRAM tier

What the top-ranking lists get wrong

How I tested

The 16GB tier, measured

System RAM quietly gates offloaded models

12 GB and 8 GB: what transfers and what does not

24 GB and up, cited rather than tested

Agentic coding: which models drive tools

When the cloud is honestly better

Running the winner

Method, limits, changelog

Jellyfin Remote Access: Pick the Right Path for Your Situation (2026)

Why “just use Tailscale” keeps failing people

Path 1: Tailscale (or another mesh VPN)

Path 2: Reverse proxy + your own domain

Path 3: VPS relay - the CGNAT escape hatch

Path 4: Cloudflare Tunnel - free, easy, and built on someone else’s tolerance