The CHUWI AuBox Ai365: My AI Home Lab in a Box

The CHUWI AuBox Ai365 is a mini PC almost nobody has heard of, from a brand best known for cheap tablets, built around a chip that normally lives in laptops. It sits behind my monitor, draws less power at the chip than a phone charger, and runs eight named AI agents, a family chat app, an email triage service and every website I maintain. It has been the most boring piece of hardware I have owned in years, and after the machine it replaced, boring is the entire point.

Full Specifications

Component	Spec
Model	CHUWI AuBox Ai365 (BIOS AuBox_06)
CPU	AMD Ryzen AI 9 365 "Strix Point" — 10 cores / 20 threads (4× Zen 5 + 6× Zen 5c), up to 5.0 GHz, 24 MB L3, 4 nm
GPU	AMD Radeon 880M — RDNA 3.5, 12 compute units, up to 2.9 GHz
NPU	AMD XDNA 2 — 50 TOPS (73 TOPS platform total)
RAM	2× 16 GB DDR5-5600 SODIMM, dual channel — 30 GB usable, expandable to 96 GB
Memory bandwidth	~90 GB/s over a 128-bit bus
Storage	1 TB PCIe 4.0 NVMe, 2× M.2 2280 slots (both now occupied)
Ethernet	2× Realtek RTL8125 2.5GbE
Wireless	Realtek RTL8851BE — Wi-Fi 6 (802.11ax), Bluetooth 5.3
USB	2× USB4 40 Gbps (DP alt-mode, 100 W PD in), 3× USB 3.2 Gen 2 Type-A
Video	HDMI 2.1, DisplayPort 1.4, plus both USB4 — up to 4 displays, 8K60 / 4K144
OS	Bluefin 44 (20260721) — Fedora Silverblue atomic, GNOME 50.3 on Wayland, Linux 7.0.12
Power	19 V / 6.32 A 120 W barrel adapter
Physical	140 × 139 × 55 mm, 846 g, all-metal, single fan — VESA-mountable
Price	$899 list; I paid about $900

Why This Box

My previous home lab was a ROG Flow Z13 — a gaming tablet with 128 GB of unified memory. In July 2026 it developed a power fault: it powers on, hangs on the logo, and puts itself to sleep about thirty seconds later, every time. The full post-mortem is here. The short version is that it never reaches a bootloader, so nothing I could do from software was ever going to touch it.

That gave me a fairly specific shopping list. I needed a Linux host with at least 32 GB of RAM, enough GPU for local vision work, wired networking, and — after watching a battery-powered machine fail at power management — no battery and no USB-PD negotiation in the critical path. A barrel connector and a fan.

The unusual thing about this box is that it's a Strix Point desktop. The Ryzen AI 9 365 is a laptop chip; it lives in ThinkPads and OmniBooks and, until recently, in the tablet I just lost. Putting it in a 140 mm metal cube with two 2.5GbE ports and two USB4 ports is the sort of decision that only happens when a smaller OEM builds something a little strange. That strangeness is exactly what a home lab wants: laptop efficiency, desktop power delivery, server networking.

Linux On This Hardware

This is the part I expected to be painful and wasn't. Every device in the box is supported by an in-tree driver on a stock Fedora kernel. There is no third-party repository, no DKMS module, and no GPU environment-variable override anywhere in my configuration.

Device	Driver	Status on Linux 7.0.12
Radeon 880M (gfx1150)	amdgpu	Works. Reports as strix1, no override needed.
2× RTL8125 2.5GbE	r8169	Both detected and working, no module parameters.
RTL8851BE Wi-Fi	rtw89_8851be	Mainline since 6.5. Works — but see the caveat below.
XDNA 2 NPU	amdxdna	In-tree since 6.14. Enumerates as /dev/accel/accel0.
USB4	thunderbolt	Works.

The Wi-Fi caveat is worth stating plainly, because CHUWI's own marketing is vague about it and one spec sheet I found calls it Wi-Fi 7. It is not. The RTL8851BE is a Wi-Fi 6, single-stream, 2×2-less, no-6 GHz part — it identifies as an 802.11ax controller and delivers roughly 300–400 Mbps in practice. It is comfortably the weakest component in the machine. It is also an M.2 2230 A/E-key card, so it can be swapped for a MediaTek MT7925 if you want Wi-Fi 7. I haven't bothered: this box lives on wired 2.5GbE, and the Wi-Fi interface is simply down.

Bluefin, specifically

I chose Bluefin over Bazzite here deliberately. Same ublue foundation — image-based rpm-ostree, Flatpak-first, roll back a bad update with one reboot — but Bluefin tracks the stock Fedora kernel rather than a patched gaming kernel. On a machine whose newest hardware is an NPU with a young driver, tracking upstream is the safer bet.

It has been the easiest part of this build. The thing that makes an atomic desktop right for a machine like this isn't any single feature, it's that the operating system is not a thing you maintain. It arrives as one signed image. It either boots or you reboot into the previous one. There is no half-applied update, no dependency that got orphaned three months ago, no slow accumulation of hand-edits that nobody remembers making — which is exactly the rot that turns a home server into something you're afraid to reboot.

What that looks like in practice, checking the machine as I write this: zero failed user services, the deployment matching its published digest, and every part of the stack that's supposed to be running, running. The one failed system unit is systemd-remount-fs, which tries to remount / read-write and cannot, because on this image / is a read-only composefs mount. That's the design working as intended and a cosmetic error line, not a fault.

The honest cost is the one in the gotchas below: updates arrive as a new deployment and want a reboot, which is a real consideration when a job might be running. And because the base is immutable, anything that expects to install itself into the system with a package manager needs a different home — a container, a Flatpak, or a user-level install. That's a genuine adjustment coming from a traditional distro, and it's also the whole reason the machine stays clean.

What It Runs

Everything is a systemd --user service. No Docker, no supervisor scripts, no manual restarts after a power cut. The whole zoo comes back on its own.

Service	What it does	Where it listens
openclaw-gateway	The agent gateway — routing, tools, sessions	port 18789, loopback only
local-chat	DisPatch, the chat app the household uses	port 8765, LAN + Tailscale
lm-studio	Local model server, OpenAI-compatible	port 1234, loopback
comfyui	Local image generation — now the fallback path	port 8188, loopback
openclaw-email	Email triage across two mailboxes. Drafts replies, never sends one.	—
hermes-gateway	A second, separate messaging gateway	—
rgb-idled	Power-state daemon — sets the system power profile from screen and session state	—
openclaw-backup.timer	Nightly config and agent-state backup	02:17 daily
arkvault-backup.timer	Nightly Borg snapshot	02:00 daily
arkvault-mirror.timer	Nightly dated mirror to the second drive	02:30 daily

The agent roster

Eight named agents plus two mailbox agents. The split that matters is where each one's model runs: cloud for anything interactive, this box for anything private or long-running, and a second machine on the network for the vision models.

Agent	Job	Model runs
Bits	Front desk. Takes the request, delegates, reviews the result.	Cloud
Brains	Hard thinking — architecture, debugging, review	Cloud
Flash	Quick cheap work — summaries, lookups, chasing stuck jobs	Cloud
Hermes	The deploy lane. Dry-run by default, live only on my explicit go.	Cloud
Doxy	Bulk grinding and anything private — runs overnight for the cost of electricity	This box — 35B MoE
Charley	Vision — screenshots, diagrams, error dialogs	Second machine
Alpha	Safe front desk for family devices — read-only tools only	Cloud
Beta	Second safe bot for family devices	Second machine

Alpha and Beta are the ones my family talks to. They can look things up and answer questions; they cannot touch files or run commands, and the chat app enforces that separately from the agent config, so a mistake in one layer doesn't open the other. The reasoning behind the cheap-cloud/local split is in the cost breakdown.

How A Message Moves Through The Box

Two details carry most of the reliability. If a model is busy or down, a fallback answers instead rather than the request failing. And whenever a job is dispatched, a watchdog is armed — if the worker goes quiet past its window, Flash gets sent to find out why. Neither is clever; both are the difference between a stack that runs unattended and one that needs babysitting.

Performance On This Silicon

Power. This is the number that surprised me. Measured at the SoC package over a five-second window, with the full stack up and a load average around 2, the chip drew 4.6 W. Add the mainboard, two NVMe drives, RAM, the NIC and the fan and you land somewhere near 10 W at the wall — but the processor itself sipping under 5 W while hosting eight agents is the clearest illustration of what Zen 5c efficiency cores buy you. Idle temperatures sit around 40 °C on Tctl.

CPU. Ten Zen 5 cores at 5 GHz is more than this workload needs. Agent routing is invisible in the load average; the machine spends most of its life almost idle and the fan is inaudible from a metre away.

Local inference. This is where the box has real limits, and they're bandwidth limits rather than compute limits. The Radeon 880M has 12 compute units and ~90 GB/s of memory bandwidth to work with. For comparison, the Z13 had 40 CUs and 256 GB/s, and my desktop's discrete cards have roughly 1.8 TB/s each. Local generation on this box is measured in low tens of tokens per second, not hundreds. That is fine for the job it has — overnight bulk work and anything that must not leave the building — and useless for interactive chat, which is why interactive chat goes to the cloud.

NPU. The XDNA 2 NPU enumerates cleanly at /dev/accel/accel0 and does nothing. This is honest rather than disappointing: the 50 TOPS are real, but the software path from "I have an NPU" to "my agent stack uses it" doesn't exist yet for the models I care about, which need long context windows and strong tool calling. Where it will eventually earn its place is small, fixed jobs — serving an embeddings endpoint for the email agent's search index, or a first-pass triage classifier that decides which mail is worth waking a real model for. That's a project for later, and the box was stood up completely without it.

Networking. Both 2.5GbE ports work with no configuration. One is wired to the network; the second is spare.

What I Gave Up

The honest cost of this move is memory, and it is not a small cost. The Z13 had 128 GB of unified LPDDR5X, of which I carved 64 GB as VRAM and ran a 120B-parameter model locally. This box has 30 GB usable, total, shared between the OS and everything else.

So the 120B tier is simply gone. The local agent now runs a 35B mixture-of-experts model instead — a real model that does real work, but not the same class of thing. Several older posts on this site describe a local 120B as part of my stack; that was true on the Z13 and it is not true now.

What I got in exchange is the entire reason the change happened: no battery to age, no USB-PD negotiation under load, no Modern Standby state machine to crash into. The board can be upgraded to 96 GB across two SODIMM slots, which would bring back some of the ceiling. I'm not doing it yet — DDR5 prices roughly doubled this year, and adding capacity wouldn't add bandwidth, which is the axis that actually constrains local inference here.

The Z13's SSD Lives Here Now

There's a detail I like more than I should. The one user-serviceable part of the Z13 was its SSD, behind a door in the kickstand. It came out healthy, went through a 2230-to-2280 adapter bracket, and is now installed in this box's second M.2 slot.

It holds the backups. Every night at 02:30, a dated mirror of this machine's state is written to the drive that used to be the machine. The dead computer's last job is making sure its replacement can be restored. It also still carries a full image of the old system taken the day before the failure — the thing that made the migration a copy rather than a rebuild.

What It Costs

Cost	Amount	Notes
The box	~$900 once	$899 list, 32 GB + 1 TB configuration
Cloud API credits	~$24/month	All the interactive agents — full breakdown
Electricity	~$4.50/month	Running 24/7 at Tokyo rates
Local models	$0	The privacy tier. You already paid for the hardware.

Call it under $30 a month to run the whole thing. The hardware pays for itself against any comparable hosted service inside a year, and the private tier isn't available at any price from a hosted service.

Gotchas

Things that actually bit me, in rough order of how much time they cost:

• The 30 GB ceiling is real. 32 GB nominal minus what the firmware and iGPU reserve leaves 30 GB in free -h. Local image generation and the local language model cannot both be resident, so image generation starts on demand and stops when idle — and the default image path moved to a second machine on the network entirely.
• The local model server crashed under memory pressure. Same bug that hit the old machine: the AppImage's temporary mount gets recycled when memory gets tight and the process takes a bus error rather than a clean out-of-memory kill. Running an extracted copy under systemd instead of the AppImage fixed it permanently.
• Timeouts assume cloud speed. A large model on an iGPU is slow, not broken, but the gateway's default provider, turn and abort timeouts will kill it mid-answer and report a stall. They have to be raised as an ordered chain — request, then turn, then abort — or you just move where the failure happens. Reasoning models additionally have to be flagged as such, or they look stalled while they're thinking and get aborted.
• Agent IDs are lowercased in one code path and not another. Cross-agent messages failed silently until the allowlist had lowercase entries. No error, no log line, just nothing delivered — the worst failure mode there is.
• Atomic updates reboot the machine. Silverblue stages an update into a new deployment and reboots into it. If that lands mid-job, the job dies. Updates now happen on my schedule, in a quiet window.
• Old configuration follows you. Part of the migration re-injected a stale identity file from the old machine's backup and put the gateway into a crash loop. Restoring a working system is not the same as restoring a correct one; config that an agent can rewrite is config that can bite you from six months ago.

What I'd Change

• Better Wi-Fi, if I used Wi-Fi. The single-stream Wi-Fi 6 card is the one genuinely weak component. It's a swappable M.2 2230 A/E-key part, so it's a fifteen-minute fix. Wired networking means I haven't needed to.
• More memory, eventually. 96 GB across the two SODIMM slots would restore some of what the Z13 had. Current RAM prices make it a bad deal, and it wouldn't raise bandwidth.
• Firmware updates are a mystery. There's no public BIOS download for this model. Getting one means emailing the vendor with the model and serial and hoping. That's the cost of buying something obscure.
• The NPU needs a reason to exist. Fifty TOPS sitting idle is a standing invitation. An embeddings endpoint is the obvious first job.

Verdict

I'd buy it again. Not because it's fast — it isn't, particularly — but because it does exactly what an always-on home lab needs and nothing it doesn't. It's small, silent, sips power, has no moving failure modes beyond one fan, runs mainline Linux without a single out-of-tree driver, and has two Ethernet ports and two USB4 ports on a machine the size of a sandwich.

The lesson from the machine it replaced was that exciting hardware that dies is worth less to infrastructure than boring hardware that stays on. This is the boring hardware. Two weeks in, it has done nothing interesting at all, which is the highest compliment I can pay it.

Weekly Log

Week of 26 July – 1 August 2026

Date	What happened
29 July	Gateway self-heal reworked to be event-driven: a rescue unit now fires only when the service actually enters a failed state, and gives up after three attempts rather than fighting a deliberate shutdown. An agent had stopped the gateway and left it down for an evening.
30 July	Remote access set up properly, with two deliberately separate doors: one serving the login screen from cold boot, one mirroring the live desktop session. Different credential stores, so a failure in one doesn't lock me out of the other.
30 July	Power-state daemon added. Screen off drops the machine to a low-power profile and kills the keyboard lighting; an active remote session outranks both, because remote input otherwise looks like idleness.
31 July	Full audit of the agent gateway. Found agent IDs being normalised to lowercase in one path but not in a directory override, which had silently forked one agent's memory into a second directory. Removed the overrides so the paths derive correctly.
31 July	The old machine's SSD went into the second M.2 slot as the backup target. Nightly dated mirrors now run at 02:30, after the existing Borg snapshot at 02:00.
31 July	Image generation moved to a second machine on the network by default; the local instance is now the fallback. Freed the memory contention described in the gotchas above.
1 August	Chat app gained ephemeral reaction images — a picture pops over every connected device for ten seconds and dismisses on any input. Restricted to one bot by design.
1 August	Measured SoC package power for the first time: 4.6 W with the full stack running. Idle Tctl 40 °C, disk 286 GB used of 952 GB.

Current snapshot

Metric	Value
OS	Bluefin 44 (20260721), Linux 7.0.12
Uptime	1 day
Load average	0.67
Memory	7.8 GB used of 30 GB
Disk	286 GB used of 952 GB (31%)
SoC package power	4.6 W
Agents responding	8 of 8, plus 2 mailbox agents