On this page
The ROG Flow Z13-KJP is the Kojima Productions edition of ASUS’s 2025 Flow Z13 (model GZ302EAC): an AMD Ryzen AI Max+ 395, 128 GB of LPDDR5X shared between CPU and GPU, all inside a 13.4-inch tablet with a detachable keyboard. On paper it is the dream machine for AI-assisted coding: room for local models next to a Rust workspace, in a bag.
I used it as my daily machine on CachyOS with Hyprland for more than a month. It started out great. Then it started crashing, and I spent a lot of evenings finding out why. I’m returning it. If you are looking at this machine, or at its sibling the ProArt PX13, for heavy development work, this is what I wish I had known.
The short version#
- Ports are tight. Two USB4 ports carry both of my monitors, which leaves a 10 Gbps USB-A port for everything else.
- Clamshell mode has no proper setup on Linux, and getting it wrong means a laptop cooking in your bag.
- No ASUS Pen 3.0. The newer ProArt PX13 supports it; the Z13 does not.
- The SSD slot is M.2 2230, and every drive that size is DRAM-less.
- My 2 TB Kingston NV3 replacement died twelve times, and it was not a heat problem.
- It is a tablet with a kickstand, which is miserable in a car.
- Under sustained compile load it overheats and powers off, even with the fans at full speed.
1. Two USB4 ports and a USB-A port#
The Z13 has two USB4 Type-C ports (40 Gbps, DisplayPort and charging), one HDMI 2.1 port, a single USB 3.2 Gen 2 Type-A port at 10 Gbps, a microSD reader and a headphone jack.
With two external monitors on the two USB-C ports, both USB4 ports are gone. My dock ended up on the USB-A port, which has no display output, no charging and a quarter of the bandwidth. For a machine sold on its ability to run a desk setup, that is a tight budget.
2. Clamshell mode: easy to get wrong, expensive when you do#
Closing the keyboard over the screen and running on external monitors sounds trivial. On Linux, nothing sets it up for you, and the failure mode is the worst one: the machine stays awake with the lid shut and slowly cooks itself in a bag.
After several hand-written scripts, the version that finally behaved is three lines of systemd-logind configuration. logind already knows whether external displays are connected:
# /etc/systemd/logind.conf.d/10-gz302-lid.conf
[Login]
HandleLidSwitch=suspend # on battery, no external display: sleep
HandleLidSwitchExternalPower=ignore # on AC: never suspend on a miscounted display
HandleLidSwitchDocked=ignore # external display connected: keep runningSleep itself needed more work on this board. I had to:
- disable panel self-refresh (
amdgpu.dcdebugmask=0x610), or the internal screen stays black after waking; - re-bind the keyboard folio’s USB interfaces after resume, because they come back silent;
- blacklist the camera driver (
amd_isp4), which hangs the machine on resume, at the cost of the webcam; - stop the USB4 controller from waking the machine.
None of this is exotic, but none of it is documented either.
3. No ASUS Pen 3.0#
The Z13 supports the ASUS Pen 2.0 (SA203H, MPP 2.0). The follow-up ProArt PX13 supports the newer ASUS Pen 3.0 (SA205H). If you were hoping to use the current pen, the Z13 is the wrong machine.
4. M.2 2230, and what DRAM-less means for builds#
Both the Z13 and the PX13 take a single M.2 2230 SSD. At 30 mm long there is no room for a DRAM chip, so in practice every drive you can buy in this size is DRAM-less. Such a drive borrows a small slice of system RAM (HMB) for its mapping tables and absorbs writes in a fast SLC cache on the flash itself. Once a long burst of writes fills that cache, speed drops to whatever the raw flash can do.
That matters for Rust. Debug builds write gigabytes of artifacts, again and again. The choice of drives is small, and the drive takes a beating.
5. The Kingston NV3 that kept dying#
The stock 1 TB drive was too small, so I put in a 2 TB Kingston NV3 (2230, Silicon Motion SM2268XT2 controller, firmware SDX01100). It worked fine at first. Then the machine started freezing, with the filesystem flipping to read-only. Local logs never survived, so I streamed the kernel log to a Raspberry Pi over UDP. Every time, the drive’s own controller had crashed:
nvme nvme0: controller is down; will reset: CSTS=0x3, PCI_STATUS=0x10
nvme nvme0: Disabling device after reset failure: -19
BTRFS: error (device nvme0n1p2 state EA) in ... Transaction aborted (error -5)CSTS=0x3 means Controller Fatal Status: the SSD’s firmware gave up, and the drive vanished from the PCIe bus. I captured this twelve times in a month. It was not heat. At the most recent death the machine was nearly idle (29 W, 55 °C) and the drive itself sat at about 34 °C.
| What I tried | Result |
|---|---|
Disable NVMe power-state transitions (nvme_core.default_ps_max_latency_us=0) | crashed again |
Disable PCIe ASPM (pcie_aspm=off) | crashed again |
| LTS kernel 6.18 | crashed again |
| BIOS 301 → 304 | crashed again |
| Firmware update | Kingston has none for SDX01100 |
| Remove and rescan the device after a crash | never came back without a full power-off |
Also, SMART stays clean through all of this. A controller that hangs cannot log its own hang.
I had one unit, so I cannot tell you that every NV3 does this. I can tell you that mine did, that no software setting helped, and that the same 2230 limitation applies to the PX13. If you do heavy compilation on either machine, choose the drive carefully, and keep the build directories somewhere you can afford to lose.
6. Not a laptop in a car#
The Z13 is a tablet. The screen angle is set by a kickstand on the back, not by a hinge. On a desk that is fine. On your lap in a moving car there is nothing holding the angle, and I gave up on working in the car.
7. Heat: the second way it dies#
After the SSD there was a second crash, and it looked identical from the outside: freeze, hold the power button. The logs told a different story. The kernel log simply stopped mid-line, with no error at all. The machine had lost power instantly.
Five of these happened during sustained load (cargo builds, local inference), and each one came within a single degree:
| Last sample before power-off | CPU temp | SoC power | Fans (RPM) |
|---|---|---|---|
| Sep 28, 13:28 | 86.00 °C | 62.5 W | 6500 / 6900 |
| Sep 28, 17:55 | 85.25 °C | 62.6 W | 5700 / 6100 |
| Sep 29, 07:44 | 85.75 °C | 60.1 W | 6400 / 6800 |
| Sep 29, 13:06 | 85.38 °C | 67.1 W | 6400 / 6800 |
| Sep 29, 14:04 | 86.00 °C | 66.1 W | 8600 / 8600 |
Five shutdowns within less than one degree is a cut-off threshold, not a runaway. While chasing it I found a real bug: the fan curve topped out at 64 % at 70 °C. I fixed it, the fans went to full speed, and the machine still powered off at 86.00 °C, the last row above. Over the whole capture the CPU spent almost half its time at 84 °C or above. This chassis cannot hold that chip at sustained full load. I returned it before finishing the last experiment, a lower power profile.
Verdict: buy a desktop#
If you want 128 GB of unified memory for AI coding (local models, big builds, everything at once), don’t put it in a tablet. RAM is painfully expensive right now. If you are paying for 128 GB, put it somewhere it can run flat out.
The Framework Desktop uses the same Ryzen AI Max+ 395 with up to 128 GB, two M.2 2280 slots instead of one 2230, and real fans with room to breathe. The Z13 is a beautiful object, and as a tablet that can game, it is impressive. As a development workstation it ran hot, ran out of ports and ate an SSD. Mine is going back.