DEV Community: keeper

The Router Couldn't See My NAS — A 3-Hour Debug Into a Silent Intel NIC Bug

keeper — Fri, 29 May 2026 16:31:13 +0000

The Router Couldn't See My NAS

My TRIM NAS at 192.168.3.135 had been running Hermes Agent 24/7 for months — handling Telegram gateway, proxy routing (mihomo), cron jobs, and file serving. It's a solid Debian 12 box with a custom 6.12.18 kernel.

Then one evening I noticed I couldn't reach Telegram. Then my Windows machine (T2) lost internet. Then even the router's device list showed the NAS as offline.

Ping to the router gateway (192.168.3.1) worked fine from the NAS itself. But the router couldn't see it.

This is the story of what I found — and how the real culprit was a feature meant to save electricity.

Phase 1: The Obvious Suspect — Mihomo

The first thing I checked was mihomo, my proxy daemon. It's the gateway between my LAN and the outside world. If it crashes, everything behind it loses connectivity — Telegram, web browsing, API calls — the whole stack.

May 29 23:52:17 trim-0c5b mihomo[692755]: level=fatal msg="Parse config error:
  rules[14] [DOMAIN-SUFFIX,api.telegram.org,📱DEFAULT] error:
  proxy [📱DEFAULT] not found"

Clear enough. The config had rules referencing proxy groups (📱DEFAULT and 📱Telegram) that no longer existed — likely from a subscription update that replaced the proxy-groups section but left the old rules untouched. Mihomo refused to start. Fix was straightforward: point those rules to an existing group (🚀节点选择).

But this was the consequence, not the root cause. Why did I reset the NAS in the first place?

Phase 2: Looking Deeper — System Logs Tell a Story

The reset happened at 22:47. Working backwards through /var/log/syslog.1, I found the real timeline:

21:00 — node[368932]: [fetch-timeout] fetch timeout after 10000ms
         url=https://api.telegram.org/bot***/getMe
21:01 — same timeout
21:02 — same timeout
...repeats every 60 seconds until 22:47...

This was the Hermes Telegram gateway — a Node.js process — unable to reach Telegram's API. Each request timed out after 10 seconds. Meanwhile:

21:09 — mihomo error: 🇺🇸美国圣何塞06 failed health check: context deadline exceeded
21:19 — 🇯🇵日本东京03, 🇯🇵日本东京04 also failing
21:24 — 🇹🇼台湾, 🇺🇸洛杉矶 also failing
...proxy node health checks kept failing in waves...

The proxy nodes were dropping one by one. Curl through the proxy to Google worked fine, but sustained connections kept timing out.

Key insight: The NAS was technically online (I could SSH in), but under high proxy load, the NIC was becoming invisible to the router. The router's ARP table expired and couldn't re-resolve the NAS's MAC address.

No kernel panics. No OOM. No driver crash. No link-down events in dmesg, syslog, or kern.log. The NIC just... stopped responding at layer 2 under sustained load.

Phase 3: Hardware Fingerprint

03:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection
Driver: igb (in-kernel, version 6.12.18-trim)
Firmware: 0.4-1

Intel I211. Not the notoriously buggy I225/I226 that plagues many 2.5GbE boards — just a plain, reliable old 1GbE chip. I211 has been shipping since 2012. It should be bulletproof.

But the boot params told a different story:

GRUB_CMDLINE_LINUX="modprobe.blacklist=pcspkr pcie_aspm=off"

pcie_aspm=off — someone had already encountered PCIe power management issues with this NIC before me.

Phase 4: The Real Culprit — EEE

I checked the NIC's Energy Efficient Ethernet settings:

EEE status: enabled - inactive
Supported EEE link modes: 100baseT/Full, 1000baseT/Full
Advertised EEE link modes: 100baseT/Full, 1000baseT/Full

EEE (IEEE 802.3az) lets the NIC drop into a low-power idle state between packets. On paper it saves a few watts. In practice, on the igb driver with an I211, the NIC sometimes fails to properly re-establish the link when exiting EEE under high connection churn.

This is exactly what was happening:

The Telegram gateway was creating and closing connections at high frequency (one timeout-retry every 60 seconds × hours = hundreds of connections)
Each connection teardown triggers EEE negotiation
At some point, the link doesn't come back cleanly
The router sees the port as active (switch lights are on) but gets no response to ARP queries
From the router's perspective: NAS is gone

EEE is the most common cause of "link light is on but device is unreachable" on Intel NICs. It affects I210, I211, I225, and I226 to varying degrees.

Phase 5: The Three Fixes

Fix 1 — Kill EEE (immediate)

ethtool --set-eee enp3s0 eee off

This disables EEE immediately without a reboot. The NIC stays in full-power mode and never enters low-power idle. Confirmed:

EEE status: disabled

Fix 2 — Double the Ring Buffers

The default ring buffer on the igb driver is 256 descriptors for both RX and TX. Maximum is 4096. Under sustained proxy load with hundreds of concurrent connections, 256 is a bottleneck — the NIC runs out of buffer space and starts dropping packets.

ethtool -G enp3s0 rx 2048 tx 2048

This increases the buffer to 2048 descriptors each. The NIC now has 8× more room to queue packets before dropping them.

Fix 3 — Make It Stick (persistence)

For the boot params:

# /etc/default/grub
GRUB_CMDLINE_LINUX="modprobe.blacklist=pcspkr pcie_aspm=off igb.eee=0"

igb.eee=0 tells the igb kernel module to never enable EEE, regardless of what the link partner advertises.

For the ring buffer and EEE state, I created a systemd oneshot service:

[Unit]
Description=NIC tuning - Intel I211 fixes
After=network.target
Before=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/sbin/ethtool --set-eee enp3s0 eee off
ExecStart=/usr/sbin/ethtool -G enp3s0 rx 2048 tx 2048
RemainAfterExit=true

[Install]
WantedBy=multi-user.target

This runs before the network is declared online, so every service that follows sees the tuned NIC.

What I Learned

The hardest bugs leave no logs. The NIC didn't crash, didn't report errors, didn't trigger a kernel oops. It just silently stopped responding to ARP. If I hadn't checked the EEE status, I'd still be blaming mihomo or the router.

EEE is a false economy. The power savings on a 1GbE desktop NIC are negligible — maybe 0.3-0.5 watts. The stability cost far exceeds the benefit. For any always-on server, NAS, or gateway running the igb driver: turn EEE off.

Ring buffer defaults are tuned for desktops, not servers. 256 descriptors is fine for a web browser but chokes under proxy load. Doubling or quadrupling it costs zero overhead in practice and eliminates an entire class of packet-drop edge cases.

The mihomo config bug was a distraction. It was the symptom that I noticed, but the real problem was at layer 2. If I'd just fixed mihomo and moved on, the EEE drop would have come back within days.

Current State

EEE status:          disabled
Ring buffer RX/TX:   2048 / 2048
Boot param:          pcie_aspm=off igb.eee=0
Systemd service:     hermes-nic.service (enabled)

Router has been seeing the NAS continuously for 24+ hours since the fixes. Telegram gateway stable. Proxy health checks clean.

Using this? A ⭐ or a one-word issue tells me what to build next — helps more than you'd think.

Windows vs Linux for Local AI: My Radeon 890M Has 96GB of RAM, but Windows Only Lets Me Use 3.5GB

keeper — Mon, 25 May 2026 23:40:54 +0000

The Setup

I run a Ryzen AI 9 HX 370 mini PC as my daily AI workstation. 96GB of system RAM, a Radeon 890M integrated GPU (gfx1150, RDNA 3.5). On paper, this should be a capable local inference box — 96GB is enough to run Gemma 4, Llama 3 70B, even Mixtral 8x22B at reasonable quantization.

There's just one problem: Windows refuses to let the iGPU use more than ~3.5GB of that memory.

I spent the better part of a week trying every workaround I could find. Here's what I learned — and why Linux won this round.

The Windows VRAM Wall

The Radeon 890M is an integrated GPU. It has no dedicated VRAM. On Windows, the GPU driver allocates a fixed shared GPU memory budget from system RAM. For the 890M, that budget caps at roughly 3.5GB.

I tried everything:

Registry hacks (GpuMemoryAllocation, HwSchMode) → no effect
DirectML via PyTorch → OOM on anything above a 7B model
llama.cpp with Vulkan backend → same 3.5GB limit, enforced by the driver
Disabling Memory Integrity / VBS → freed up ~500MB, still hit the wall
BIOS UMA Frame Buffer tweaking → the 890M's firmware-based allocation is hard-coded

The root cause? Windows' WDDM driver model + Hypervisor-based security (VBS). When Memory Integrity is enabled (and on modern Windows 11 installs, it is by default), every GPU memory allocation goes through an extra hypervisor verification layer. The driver responds by clamping shared GPU memory to a conservative default. And there's no "unlock" switch — even in Group Policy or AMD's own Adrenalin control panel.

For a 7B model at Q4_K_M (~4.5GB VRAM needed), that 3.5GB wall means the model doesn't fit. Period. The alternative is CPU-only inference — using all 96GB of RAM, but at maybe 2-3 tokens per second for anything larger than 7B.

Windows gives you a choice: tiny models on GPU, or glacial models on CPU. There's no middle ground.

The Linux Promise (and Its Own Problem)

Linux doesn't have this VRAM cap. The Mesa Vulkan driver for AMD GPUs (amdgpu, radv) lets the GPU use as much system memory as needed. You can allocate 64GB for a model and the driver won't blink.

So I set up a dual-boot, installed ROCm, and ran a few tests. The performance difference was dramatic — llama.cpp with Vulkan on Linux could load a 14B Q4_K_M model entirely on the GPU, no VRAM wall.

But there was a catch. ROCm does not support the Radeon 890M.

AMD's official stance, confirmed by the Framework community (Framework Laptop 13 Ryzen AI 9 HX 370):

"AMD ROCm does not support the Radeon 890M (gfx1150). PyTorch cannot run with ROCm on this GPU."

The Vulkan backend in llama.cpp does work on Linux. It's faster than CPU and has no VRAM cap. But it's nowhere near as fast as native ROCm acceleration would be. You're getting maybe 40-60% of the performance you'd get with a supported GPU stack.

The Decision Matrix

Option	Works?	Performance	VRAM Limit	Verdict
Windows + DirectML	✅	Low	3.5GB hard cap	Fine for 3B-7B, useless for anything bigger
Windows + llama.cpp Vulkan	✅	Medium-low	3.5GB hard cap	Same cap, slightly better perf
Linux + ROCm	❌	N/A	N/A	ROCm doesn't support gfx1150
Linux + llama.cpp Vulkan	✅	Medium	No cap	Best option for iGPU inference today
Linux + CPU-only (96GB)	✅	Slow (2-3 tok/s)	No cap	Works for everything, patience required

Why This Matters

The HX 370 is AMD's flagship mobile AI chip. It's built on a 4nm process, has an XDNA 2 NPU rated for 50+ TOPS, and pairs with a capable RDNA 3.5 iGPU. AMD clearly wants this chip in the "AI PC" category.

But the reality:

AMD's GPU software stack is fragmented. ROCm works on their discrete GPUs (RX 7900 series, some W-series) and Instinct cards. It does not work on RDNA 3.5 integrated GPUs. Period. The Windows HIP SDK also doesn't support it. If you bought an HX 370 machine thinking ROCm would be available, you bought a paperweight for AI workloads.
Windows' driver model is actively hostile to shared-memory GPUs. The 3.5GB hard cap isn't a bug. It's a deliberate safety boundary in WDDM. Apple Silicon Macs can share 64GB+ between CPU and GPU seamlessly. The HX 370 with 96GB of RAM should be able to do the same. It cannot. Not on Windows.
Linux works, but not well enough. The Vulkan backend lifts the VRAM cap, which is the most important win. But without ROCm, you're leaving performance on the table — roughly 40-60% of what a properly supported GPU would deliver.

So What Does Work?

For this exact machine (HX 370 + Radeon 890M), the realistic stack is:

For production workloads / multi-model serving: Linux + CPU-only. 96GB RAM handles Gemma 4 27B, Llama 3 70B, Qwen 2.5 72B at Q3/Q4. Slow but reliable.

For single-user inference / experimentation: Linux + llama.cpp Vulkan. Best balance of VRAM headroom and acceleration. No hard cap, no heavy tuning.

For portability / Windows-only environments: Windows + llama.cpp Vulkan. Stuck at the 3.5GB cap. Fine for 3B models, frustrating for anything larger.

The Structural Problem

This isn't about Windows vs Linux fanboyism. The structural issue is:

AMD's software commitment stops at their discrete GPU line. Integrated GPUs are second-class citizens for AI — despite being in every Ryzen AI chip shipping today.
Windows' driver architecture assumes dGPUs with dedicated VRAM. Shared-memory GPUs are an afterthought, and the security hypervisor layer makes it worse.
Linux avoids the cap but can't fill the acceleration gap. Without ROCm, you're running on Vulkan — which is a translation layer, not a native compute stack.

The HX 370 is a great CPU with a mediocre AI story. If you're building a local inference box today, you're better off pairing it with a discrete GPU — or just skipping Windows entirely for AI workloads.

Using an HX 370 for LLMs? A ⭐ or a one-word issue tells me what to build next — helps more than you'd think.

Visualize Your AI-Written Code as an Interactive Knowledge Graph

keeper — Mon, 25 May 2026 13:00:33 +0000

▸ Understand-Anything-Public is a new open-source GitHub project that converts your entire codebase into an interactive knowledge graph. If you've ever inherited a 200K-line project with zero documentation, you know the pain — this tool draws you a map instead of forcing you to read file by file.

▸ The same project highlights a growing trend in AI-assisted development: when bugs surface, devs now respond with "I need to check — I don't know how the AI wrote it either." It's a candid acknowledgment that AI-generated code is increasingly opaque, making tools like Understand-Anything-Public essential for maintenance.

▸ By mapping code structure visually, these tools help teams onboard faster, identify dead code paths, and trace dependencies without manually following imports. For teams shipping AI-generated code at velocity, a knowledge graph layer isn't a luxury — it's becoming table stakes.

▸ As LLM-generated code proliferates, the bottleneck isn't writing — it's understanding. The next wave of devtools will focus less on generation and more on comprehension.

Source: @https1024 (互联网从业者充电站)

Two items today from Chinese tech Telegram channels — merged into one briefing.

Kirin 2026 vs Snapdragon 2026: The Full Chip Gap Landscape

keeper — Mon, 25 May 2026 10:02:02 +0000

Executive Summary

At ISCAS 2026 (May 25, 2026), Huawei board member and Semiconductor Business President He Tingbo unveiled two things:

Tau (τ) Law — A design philosophy that replaces geometry scaling with signal propagation delay (τ) optimization
Kirin 2026 — The first chip using "logic folding" technology, shipping fall 2026

Key specs of Kirin 2026:

Spec	Kirin 9030 Pro (current)	Kirin 2026 (fall)	Improvement
P-core frequency	2.75 GHz	3.1 GHz	+12.7%
Transistor density	~155 MTr/mm² (est.)	238 MTr/mm²	+53.5%
P-core efficiency	baseline	+41%	+41%
First milestone	—	First Kirin over 3GHz	—

To evaluate these numbers, we need a complete 2026 mobile chip landscape.

The 2026 Mobile SoC Leaderboard

Data source: unite4buy AnTuTu 11 ranking, May 2026

#	Chip	AnTuTu 11	GB6 (SC/MC)	Process
1	Snapdragon 8 Elite Gen 6 Pro	4,587,993	14,273 / 4,388	2nm
2	Snapdragon 8 Elite Gen 5 LV	3,834,473	12,658 / 3,873	3nm
3	Snapdragon 8 Elite Gen 5	3,717,334	12,216 / 3,768	3nm
4	Snapdragon 8 Gen 5	3,518,837	9,894 / 2,744	3nm
5	MediaTek Dimensity 9500	3,168,848	10,155 / 3,451	3nm
6	Snapdragon 8 Elite (Gen 4)	3,109,884	10,111 / 3,211	3nm
13	Samsung Exynos 2500	2,421,783	8,999 / 2,525	3nm
~14	Kirin 2026 (est.)	~2,400,000	~6,500 / ~1,900	Domestic + Logic Fold
18	HiSilicon Kirin 9030 Pro	2,099,856	5,808 / 1,677	Domestic process

SD 8 Elite Gen 5 (currently shipping flagship) core config:

2x Phoenix @ 4.61 GHz (Prime cores)
6x Phoenix @ 3.63 GHz (Performance cores)
Adreno 840 GPU
TSMC N3E (3nm)

The Gap, Quantified

Frequency — The Least Painful Dimension

Kirin 2026's 3.1 GHz is its P-core (performance) frequency:

Comparison	Level	Gap
SD 8 Elite 5 Perf @ 3.63 GHz	P-core vs P-core	-15%
SD 8 Elite 5 Prime @ 4.61 GHz	P-core vs Prime	-33%
SD 8 Elite 6 Pro @ 5.2 GHz	P-core vs peak	-40%

Frequency is actually the least of Kirin's problems. The gap is in IPC and microarchitecture.

Single-Core — The Bleeding Edge

Geekbench 6 single-core comparison:

Chip	GB6 SC	vs Kirin 2026 (est.)
SD Elite Gen 6 Pro	14,273	0.46×
SD Elite Gen 5	12,216	0.53×
Apple A19 Pro	10,728	0.61×
Dimensity 9500	10,155	0.64×
SD Elite Gen 4	10,111	0.64×
SD 8 Gen 5	9,894	0.66×
Kirin 2026 (est.)	~6,500	1.00×
Kirin 9030 Pro	5,808	1.12× improvement

At ~6,500 GB6 single-core, Kirin 2026's CPU performance is roughly equivalent to a 2022 Snapdragon 8 Gen 2 (~6,800 points). In peak raw CPU performance, Huawei trails by about 4 years.

Transistor Density — The One Dimension Where Kirin Leads

Chip	Density	Process	vs Kirin 2026
Kirin 2026	238 MTr/mm²	Domestic + Logic Fold	—
SD 8 Elite Gen 5	~200 MTr/mm²	N3E	19% behind
SD 8 Gen 3	~180 MTr/mm²	N4P	32% behind

On a sanctioned process, Kirin 2026 achieves higher transistor density than TSMC N3E. This is the direct payoff of logic folding — exactly what τ Law predicts.

The τ Law Lens

τ Law says: "When geometry scaling hits the wall, stop making transistors smaller. Make the signal between them faster instead."

Kirin 2026 is the first production validation of this thesis.

Metric	Grade	Note
Density	A	238 MTr/mm² beats N3E
Efficiency	A-	P-core efficiency +41%
Raw CPU perf	C	~4 years behind
Peak experience	D	Most apps will feel the gap

This is exactly what you'd expect from a first-gen logic folding product. You can't simultaneously optimize density, frequency, power, and IPC on a brand-new design methodology. The real test will be the iteration curve:

Can Gen 2 (2027) push single-core to ~8,000? → This path is viable
Is it stuck at 6,500-7,000? → This path is "least bad under sanctions"

What This Really Matters

Kirin 2026 is a mirror with two reflections:

Mirror 1: Under sanctions, with no access to TSMC's leading edge, no full EDA tooling, and limited ARM architecture access — Huawei delivered a chip whose transistor density beats everyone. That is a world-class engineering achievement.

Mirror 2: But density doesn't run apps. Single-core performance does. And at ~50% of Qualcomm's latest, users will notice. On every app launch. Every scroll. Every load.

Both reflections are true. They don't contradict each other.

Bottom Line

Kirin 2026 proves τ Law works for density. It has yet to prove it works for performance.

The logic folding path is one of the most interesting engineering bets in the post-Moore era. But it needs 2-3 generations of iteration before it can threaten Qualcomm on user-perceptible benchmarks. Until then, the gap graph tells the real story: Huawei is competing in a different league, with a different playbook, and the scoreboard reads what the sanctions intended it to read.

Sources: cnBeta 1563522 (ISCAS 2026 coverage) | unite4buy Mobile Processor Ranking 2026
Written 2026-05-25

Windows Has an AI Problem. Can HarmonyOS PC Be the Answer?

keeper — Sun, 24 May 2026 18:18:32 +0000

Windows Has an AI Problem. Can HarmonyOS PC Be the Answer?

In May 2025, a mini PC with a Ryzen 7 8845HS sat on my desk. It had an NPU rated at 16 TOPS — just enough for Microsoft's Copilot+ checklist. I was trying to run a 14B local model on it. The result: 2.1 tokens per second on CPU, the iGPU was bottlenecked by shared memory bandwidth, and the NPU was completely unusable — it only worked with Microsoft's proprietary QNN API, and no open-source LLM runtime supported it.

This isn't a hardware problem. It's a structural one.

The Windows AI Trap

Windows has a fundamental architectural disadvantage for local AI that no amount of NPU TOPS marketing can fix. It stems from three layers:

1. Fragmented Memory Architecture

The defining feature of the M-series Mac is unified memory — a single pool of high-bandwidth, low-latency RAM shared between CPU, GPU, and Neural Engine. A MacBook with 64GB unified memory can run a 70B parameter model (quantized to Q4, ~40GB) because the GPU has full access to all 64GB at 400+ GB/s.

Windows PCs have no equivalent. The architecture is:

System RAM: 16-64GB (DDR5/LPDDR5, 50-80 GB/s)
GPU VRAM: 8-24GB (GDDR6/7, 400-800 GB/s)
NPU memory: Shared with system, but bandwidth-constrained and API-locked

The GPU is the best inference engine, but it's limited to VRAM. A 14B Q4 model needs ~8GB — fits on a 12GB+ card. A 70B Q4 needs ~40GB — only RTX 6000 Ada ($6,800) or server GPUs. The system RAM has the capacity but runs at 1/10th the bandwidth. The NPU has the TOPS but no ecosystem.

Result: Every Windows AI PC is a "here's the capacity, here's the bandwidth, here's the TOPS — but you can't use all three at once" machine. Apple gets to use all three simultaneously.

2. OEM Incentive Misalignment

Microsoft doesn't make the hardware — Dell, Lenovo, HP, ASUS do. Each OEM competes on price. The cheapest SSD, the slowest RAM, the smallest battery. NPU is a checkbox component, not a system-level optimization. No OEM invests in unified memory because it requires a custom SoC and motherboard — which means they can't differentiate on any other dimension.

Qualcomm's Snapdragon X Elite was supposed to fix this. It has unified memory (LPDDR5X, up to 64GB, 135 GB/s). But Windows on ARM has its own problems: x86 emulation overhead, driver compatibility, and the same OEM cost-cutting pressure that makes Lenovo ship a 45W charger with a 28W SoC.

3. The NPU Ecosystem Is Still Born

Every Windows NPU needs a different SDK:

Intel NPU: OpenVINO
AMD NPU: Ryzen AI / DirectML
Qualcomm NPU: QNN / ONNX Runtime
Microsoft's own: DirectML (if it supports your hardware)

No major open-source LLM runtime — not llama.cpp, not MLX, not ExLlamaV2 — supports any of these NPUs for text generation. The 16-45 TOPS on the spec sheet is a marketing number. In practice, those TOPS are only accessible through Microsoft's proprietary pipeline for Copilot+ features like real-time captions or Windows Studio Effects. Try running Llama 3.2 on the NPU. You can't.

Apple's Moat Is Getting Deeper

The M4 Ultra makes 192GB unified memory available to the GPU. A single Mac Studio can run Llama 3.1 405B (Q2, ~100GB) entirely locally. Not fast, but it works. With MLX, a 70B model runs at 15-20 tok/s on an M4 Ultra.

Apple doesn't compete on peak TOPS or FLOPs. It competes on usable architecture — the hardware memory model that makes inference practical. And this advantage compounds as models grow: a 2027-era 1T-parameter MoE model will need 200-300GB. Only Apple's architecture can deliver that at a consumer price point.

Microsoft's response is to push NPUs harder — but a 100 TOPS NPU with 16GB of slow shared memory is still worse than a 30 TOPS GPU with 64GB of fast unified memory. The bottleneck is bandwidth and capacity, not multiply-accumulate operations.

Enter HarmonyOS PC: A Clean Sheet

Huawei launched HarmonyOS PC on May 19, 2025, powered by the Kirin X90 — a 5nm SoC with 14 CPU cores, an integrated GPU (Maleoon), and a self-developed NPU. This is a mobile-SoC-derived architecture — which means it's inherently unified memory. The CPU, GPU, and NPU share the same LPDDR5 pool.

This is the only non-Apple PC architecture that natively supports unified memory. And that matters.

Kirin X90: What We Know

Dimension	Kirin X90	Apple M4	Snapdragon X Elite
Process	5nm (SMIC)	3nm (TSMC)	4nm (TSMC)
CPU	14-core	10-core	12-core
GPU	Maleoon (custom)	10-40 core	Adreno
NPU	Custom, AI +200% vs prev gen	38 TOPS	45 TOPS
Memory	LPDDR5 (unified)	LPDDR5 (unified)	LPDDR5x (unified)
AI Ops (claimed)	~60-80 TOPS*	38 TOPS	45 TOPS

*Estimated from Huawei's "200% improvement over previous gen" claim, assuming Kirin 9010 NPU baseline of ~30 TOPS.

The architecture is right — unified memory is the non-negotiable prerequisite for local AI inference. But capacity is the open question.

The 14B model test: A 14B Q4 model needs ~8GB. If the X90 supports 32GB LPDDR5 — MacBook Air territory — it fits comfortably. The GPU (Maleoon) handles inference via Vulkan/compute shaders, while both the GPU and CPU share the full memory bandwidth. Inference speed would depend on GPU optimization, but 10-20 tok/s is plausible with proper runtime support.

At 16GB, it fits but with memory pressure from the OS and browser. At 8GB (phone territory), forget it.

The Supply Chain Math: CXMT and the Memory Squeeze

Here's where the theoretical architecture meets reality. HarmonyOS PC needs LPDDR5 memory. Huawei's HBM technology (the HiZQ 2.0 used in Ascend 950) supplies — and competes for — the same DRAM fab capacity.

CXMT (长鑫存储) is the only Chinese DRAM IDM. By mid-2026, their three 12-inch fabs (two in Hefei, one in Beijing) reach approximately 300K wafers/month total capacity.

The allocation problem:

Product	Die Consumption	Monthly Wafer Need (Est.)
Ascend 950 HBM (HiZQ 2.0)	Each 144GB chip = 4 stacks of 12-hi = 48 DRAM dies + base dies	30K-50K wafers (at 3x DDR die consumption per GB)
Kirin X90 LPDDR5 (5M units/year)	5M × 4-8 dies/device = 20-40M dies total	~25K-50K wafers (one-time for first batch)
DDR5 commodity	Industry contracts, server, PC aftermarket	Remaining 200K-240K wafers

The squeeze: HBM consumes roughly 3x the wafer capacity per GB compared to standard DDR (per Tom's Hardware analysis — yield loss from stacking, smaller dies, base die overhead). A single Atlas 950 SuperNode (8,192 Ascend 950 chips, 1.1 PB HBM) uses as much DRAM wafer capacity as millions of PCs.

CXMT's profitability adds pressure. In H1 2026, CXMT reported ¥50-57 billion net profit, driven by the global DRAM shortage. The highest-margin product is HBM, not LPDDR. From a business perspective, CXMT's incentive is to allocate more capacity to HBM for Ascend and less to commodity LPDDR.

Verdict on availability: CXMT's 300K wafer/month capacity can supply both HBM and LPDDR5, but at the volumes Huawei needs, the LPDDR5 allocation is likely constrained. The better question isn't "can CXMT make enough" — it's "how much is Huawei willing to pay vs NAND margins on the spot market."

If Huawei procures CXMT LPDDR5 at above-market prices (internal transfer pricing as a related-party transaction), they secure supply at the cost of lower margins. If they try to source from Samsung/SK Hynix, they face US export controls and uncertain allocation (both Korean vendors prioritize HBM for NVIDIA).

The pragmatic path: CXMT supplies just enough LPDDR5 for Kirin X90 volumes (~25K wafers/month at scale), while the bulk of HBM capacity goes to Ascend 950 — which has higher margins and strategic AI infrastructure importance.

Bottom line: A HarmonyOS PC with 16GB RAM is likely. One with 32GB is possible but expensive. One with 64GB (Mac-level) is unlikely at launch.

The Real Disruption: Distributed AI

The most interesting possibility for HarmonyOS PC isn't local performance — it's what no other platform can do.

HarmonyOS has a distributed hardware abstraction layer that treats all devices in a user's ecosystem as a single resource pool. This was originally designed for file sharing and phone-as-webcam use cases. Applied to AI inference, it becomes something genuinely different:

Your phone's NPU + your PC's NPU + your tablet's NPU = pooled inference
Model layers sharded across devices over high-speed local interconnect
A 14B model's attention layers run on the PC GPU, embedding layers on the phone NPU

Windows can't do this. macOS can't do this (Continuity doesn't extend to GPU compute pooling). HarmonyOS's distributed architecture is unique.

The practical challenge: interconnect latency. Even WiFi 7 at 5Gbps has 1-3ms latency between devices, which is 10-100x slower than on-chip memory access. Real-time layer-sharded inference requires sub-microsecond synchronization. This limits distributed AI to batch/offline workloads (background summarization, async data processing) rather than interactive chat.

But for the use case of "leave your PC processing a large model overnight while sharing the workload with your phone" — it works.

Three Scenarios for HarmonyOS PC

Scenario 1: The "Good Enough" (Likely)

16GB LPDDR5, unified memory, ~60 TOPS NPU
Runs 7B models at 15-25 tok/s via GPU inference
Runs 14B models at 5-10 tok/s (usable but slow)
Distributed AI for async/background workloads
Price: ¥3,999-4,999 ($550-700)
Verdict: A legitimate third option alongside Mac and Windows, but not a "Mac killer"

Scenario 2: The Memory Expansion (Possible)

32GB LPDDR5 (CXMT secures allocation, higher BOM cost)
Runs 14B Q4 models at 15-20 tok/s
Runs 32B Q4 models at 5-8 tok/s
Distributed AI with phone NPU for real-time assistance
Price: ¥5,999-6,999 ($830-970)
Verdict: Genuinely competitive with MacBook Air M4 for local AI workloads
Key risk: CXMT LPDDR5 allocation, BOM margin pressure

Scenario 3: The Distributed Breakthrough (Long Shot)

16-32GB LPDDR5
HarmonyOS 6+ with native distributed inference API
"AI router" mode: PC serves as local inference server for all household HarmonyOS devices
Third-party model runtime (llama.cpp port, MindSpore Lite + Vulkan)
Verdict: Unique value proposition Windows and Mac can't replicate
Key unlock: Software ecosystem maturity, developer adoption

What Needs to Happen

For HarmonyOS PC to matter in the AI era, three things must align:

1. Memory capacity must exceed 16GB. Without this, the unified memory advantage is theoretical. A 14B model barely fits, leaving no room for the OS or applications. 32GB is the sweet spot.

2. An open runtime must exist. If the only way to run AI is through Huawei's MindSpore/CANN pipeline, developer adoption will be slow — the same trap Windows fell into with proprietary NPU SDKs. A Vulkan-based llama.cpp port would be transformative.

3. The distributed inference API must ship as a first-party feature. Not a developer preview. Not an enterprise SKU. A system-level API that any app can call: harmonyos.distribute.infer(model, input, devices=[pc, phone]). This is the feature that differentiates HarmonyOS from every other platform.

The Honest Assessment

HarmonyOS PC solves the architectural problem Windows has — unified memory — and has a theoretical distributed computing advantage no other platform can match. But it faces three constraints:

Manufacturing: 5nm at SMIC is behind TSMC's 3nm. Performance per watt will trail Apple M4.
Ecosystem: No Adobe, no major games, limited developer tools. This limits adoption to first-wave enthusiasts and government/enterprise procurement.
Memory supply: CXMT capacity is strained by HBM demand. 32GB LPDDR5 at scale is not guaranteed.

The best case for HarmonyOS PC: It becomes what Windows should have been in the AI era — a platform where local AI inference is architecturally natural, not bolted on. But it only happens if Huawei prioritizes memory capacity over NPU TOPS, and opens the runtime to the community.

The worst case: It's another Windows — impressive NPU TOPS on paper, functionally inaccessible for real AI workloads, held back by proprietary SDKs and memory constraints.

Right now, the data points toward Scenario 1: a good product that's competitive but not transformative. The switch flips to transformative at Scenario 2 — and that requires CXMT to deliver 32GB-class LPDDR5 at scale, which is a supply chain question, not a technology one.

This analysis is a best-effort public-data assessment. CXMT capacity figures are estimates based on public reporting. Kirin X90 NPU TOPS is inferred from Huawei's "200% improvement" claim relative to an unknown baseline.

750,000 Chips, 140 Trillion Tokens: The Math Behind DeepSeek's Permanent Price Cut

keeper — Sat, 23 May 2026 05:11:10 +0000

DeepSeek made its V4-Pro 75% price cut permanent on May 22. The conventional read: "they got cheaper hardware." The real story is more interesting — and it's about a gap that's not closing fast enough.

What Happened

On May 22, 2026, DeepSeek announced that the 75% discount on its V4-Pro API would become permanent. The new pricing:

Metric	Before	After	Cut
Input (cache miss)	¥12 / 1M tokens	¥3 / 1M tokens	75%
Output	¥24 / 1M tokens	¥6 / 1M tokens	75%
Input (cache hit)	¥0.1 / 1M tokens	¥0.025 / 1M tokens	75%

At current exchange rates, that's roughly $0.44/M input and $0.87/M output — making V4-Pro one of the cheapest frontier-class models on the market, on par with DeepSeek's own V4-Flash but with significantly more capability.

The move came exactly four weeks after V4's launch on April 24, and coincided with growing user frustration over rate limits at Google Gemini and Anthropic Claude.

The Standard Narrative

The surface-level story has three parts:

1. Architectural efficiency. V4 uses a Mixture-of-Experts architecture with 1.6 trillion parameters, but only activates a fraction per token. This gives it a structural cost advantage over dense models of comparable capability — roughly 30% of the gap.

2. Supply chain scaling. Huawei's Ascend 950PR entered mass production in April 2026. Huawei plans to ship ~750,000 units through the year — a 2.5x increase over 2025's 910C output. DeepSeek specifically optimized V4 for the Ascend architecture. More chips → lower unit cost → lower API pricing.

3. Competitive positioning. Western AI providers (Google, Anthropic) have been quietly tightening rate limits as demand overwhelms their GPU supply. DeepSeek is exploiting the backlash, offering unlimited usage at a fraction of the cost to capture disgruntled developers.

All three are true. But none of them fully explains the magnitude of the cut — or why it's permanent rather than promotional.

The Math That Changes Everything

Let's check the numbers.

Demand Side

China's daily token consumption hit 140 trillion in March 2026, according to the National Data Administration. The growth trajectory:

Early 2024: 0.1 trillion/day
End of 2025: 100 trillion/day
March 2026: 140 trillion/day

That's a 1,000x increase in two years, and a 40% jump in just the last quarter — implying ~13% month-over-month growth.

Supply Side

Huawei's mass-produced chip for 2026 is the Ascend 950PR (Prefill-optimized, 1 PFLOPS FP8), with the higher-end 950DT (2 PFLOPS FP8) coming in Q4. The numbers:

Chip	FP8	Memory	Bandwidth	Inference Throughput (est.)
950PR	1 PFLOPS	128GB HBM	1.6 TB/s	~1,200 tokens/sec
950DT	2 PFLOPS	144GB HBM	4 TB/s	~2,400 tokens/sec

(Throughput derived from Huawei's published Atlas 950 SuperNode benchmark: 19.6M tokens/sec across 8,192 cards.)

Now the arithmetic:

Item	Value
Total chips (2026 target)	750,000 (70% PR + 30% DT)
Raw daily throughput	85.7 trillion tokens/day
Inference-allocated (60%)	51.4 trillion tokens/day
vs Current demand (140T)	37% coverage
vs Demand in 6 months (~291T)	18% coverage

Even in the most optimistic scenario — every single chip dedicated to inference at 100% utilization:

Scenario	vs Current	vs +6 months
100% inference, 100% utilization	61% coverage	29% coverage

The conclusion is stark: 750,000 Ascend 950 chips can't cover today's demand — let alone the demand in six months.

So Why Cut Prices?

If supply is still a fraction of demand, permanent price cuts don't make sense in a normal market. But this is not a normal market.

The Real Logic: Pre-Commitment, Not Surplus

DeepSeek is not cutting prices because it has spare compute. It's cutting prices to lock in routing commitments before the hardware arrives.

Here's the timeline:

April 24:  V4 launched, optimized for Ascend
April 24+: ByteDance orders 350,000 Ascend 950 chips (~¥40B)
May 4:     Ascend 950PR mass production confirmed
May 22:    DeepSeek makes V4-Pro 75% cut permanent

The critical insight: DeepSeek's price cut is not a cost pass-through. It's a market share pre-commitment — using the promise of future Ascend supply to grab developer mindshare now, before Western competitors can resolve their own capacity issues.

The Numbers Behind the Strategy

Western providers are capacity-constrained:

Provider	Constraint	Signal
Google Gemini	TSMC CoWoS capacity	Rate limits tightened, user backlash
Anthropic Claude	H100/B200 availability	API throttling, compute-use monitoring
OpenAI	Inference cluster rollout	Delayed GPT-5 token limits

DeepSeek's bet: "Spend the next 6 months building developer dependency on V4-Pro's API — by the time Ascend supply catches up in H2 2026, those developers won't switch back."

This is AWS in 2006. AWS wasn't cheaper than running your own servers in 2006. But it would be once scale kicked in. AWS priced for the scale it planned to have, not the scale it had. DeepSeek is doing the same.

What 750,000 Chips Actually Buys

The popular framing in Chinese media is "75万颗昇腾950产能大爆发." But as the math shows, 750,000 chips isn't abundance — it's barely adequacy.

Think of it this way: China's token demand is growing at roughly 0.5 trillion tokens per day every single month (the monthly increment itself is larger than the entire market 18 months ago). By year-end, demand will be 300-400+ trillion. Against that, 750K chips at the 950PR/DT mix buy roughly 50-85T/day of inference capacity.

Timeframe	Demand (est.)	Inference Supply	Gap
March 2026	140T	~50T	90T
June 2026	~200T	~50T	150T
September 2026	~290T	~55T (DT ramp)	235T
December 2026	~420T	~65T	355T

The gap is growing, not shrinking. Even with 75万 chips fully deployed, the supply-demand deficit more than triples over nine months.

This means DeepSeek's price cut isn't a sign of market saturation. It's a sign of exactly the opposite: a market so unsaturated that the winner gets to define the default API for an entire generation of developers, if they can lock them in before the hardware arrives.

Three Counter-Arguments (And Why They're Weak)

"But cache hits reduce the effective compute needed"

True — cache-hit tokens cost ~1/100th of miss tokens. And DeepSeek's cache hit rates can be high for workloads with stable system prompts. But cache hits are mostly in the input direction. Output tokens — the expensive ones — still need full compute. And as agentic workloads grow (multi-turn, chain-of-thought), output-to-input ratios increase, making cache less effective.

"But not all 140T tokens need 950-class inference"

Also true. Many tokens are generated by smaller models (Flash variants, Qwen, etc.) that don't need 950-level compute. But the growth is in the frontier-class tokens — longer context, more complex reasoning, higher quality requirements. That's exactly where 950-class chips are needed.

"But they can still buy H20 / smuggled H100"

H20 is less capable than 950PR per chip (the US-designed it to be worse). And the CHIPS Act + export controls have made H100 procurement increasingly difficult. Relying on smuggled hardware is not a supply chain strategy.

What This Means

For Developers

Your inference costs are likely going down over the next 12 months, not up — even though demand is exploding. That's unprecedented in any computing market. The driver isn't efficiency gains or manufacturing scale. It's a strategic subsidy by Chinese AI firms betting that locking in your API calls today is worth negative margins for a year.

Take the subsidy. But don't assume today's prices reflect tomorrow's costs — they reflect tomorrow's hopes.

For the Industry

The AI API market has entered a phase that looks like price war but functions like infrastructure land-grab. The playbook is AWS 2006, DoorDash 2019, Uber 2015: lose money on every transaction to own the default routing.

When the hardware does catch up — when Ascend 960 (2027) or 970 (2028) ships with 3-5x the throughput — the providers with the largest captive developer bases will convert negative margins to positive ones. Everyone else will be competing on price against incumbents they can't dislodge.

The Bottom Line

DeepSeek's permanent price cut is not evidence that Chinese AI compute supply has caught up with demand. The math shows it hasn't — and won't for at least 12-18 months. It's evidence that DeepSeek is playing the long game: use today's negative margins to own tomorrow's default inference route, and trust that Huawei's future chips will eventually close a gap that's currently 3-5x wider than headlines suggest.

The 75% cut isn't a cost breakthrough. It's a bet that developer lock-in is worth more than current margins — and that the 75万 Ascend 950 chips shipping this year are just the beginning.

Numbers sourced from: National Data Administration (China daily token data, March 2026), Huawei Connect 2025 (Ascend 950 specs and roadmap), SCMP/DW (ByteDance order volume), DeepSeek official pricing page (May 2026). Throughput calculations based on published Atlas 950 SuperNode benchmarks. Growth projections assume continuation of 40%/quarter rate per published data.

From the Renaissance to the Quantum Dawn: AI, Computation, and the Next Paradigm Shift

keeper — Sat, 23 May 2026 04:36:34 +0000

Five hundred years ago, Florentine craftsmen began using linear perspective to represent three-dimensional space on a two-dimensional canvas. That movement — the Renaissance — was humanity's first systematic liberation of its own cognitive capacity. We were no longer footnotes to a divine plan. We became, in the famous formulation, "the measure of all things."

Today, standing in the early summer of 2026, we are living through another, more radical renaissance: AI is releasing creativity from the tip of the elite's pen into every prompt box, while quantum computing is trying to lay a new runway for this digital explosion at the very edge of classical physics.

1. The Renaissance Echo: From the "Discovery of Man" to the Democratization of Intelligence

The Renaissance achieved two things: a revolution in the carrier of knowledge (Gutenberg's printing press) and a reversal of the subject of cognition (from God to Man). When the Bible no longer required a priest's oral transmission, when perspective allowed ordinary people to paint convincing cathedral ceilings, humanity realized for the first time: individual reason is enough to move the world.

The AI wave today is replaying this exact scene.

Open-source models (Llama, Qwen), AIGC platforms, no-code tools — they let people who don't know how to code command machines to do work that once required a whole team. "Prompt" has become the new Latin. Everyone can use this language to create stories, images, and even code.

AI has driven quality and efficiency gains across every field. It hasn't made humans redundant — it has freed us from repetitive, low-level mental labor to face more complex, higher-dimensional problems.

2. The Computation Explosion: Classical Computing's Ceiling and the Platform Paradox

But liberation comes at a cost: the inflation of desire. When we can generate a million stories effortlessly, we no longer want "more" — we want "better." Longer contexts, more realistic voices, more complex logical reasoning. This pursuit of quality is consuming computational resources at an exponential rate.

The data explosion that was once compressed by platforms has been replaced by an explosion in demand for compute, driven by AI itself.

The numbers are staggering. China's daily token calls grew over 1,000x in two years, surpassing 140 trillion by March 2026. Training a trillion-parameter model requires 15,000 high-end GPUs running for 45 days, consuming 3 million kilowatt-hours. And classical computing — CPU, GPU, TPU — is hitting four walls simultaneously:

Power wall: NVIDIA GB300 draws 140kW per rack. A supercomputing center is a small power plant.
Cost wall: High-end GPUs are scarce and expensive.
Physics wall: Process nodes are approaching atomic limits. Moore's Law is limping.
Data wall: High-quality text data is running out.

It's as if the medieval scriptorium had just invented the printing press — only to discover there wasn't nearly enough paper or ink. What we lack isn't creativity. It's the computational fuel to execute it.

3. The Quantum Dawn: The Next Computing Paradigm

It is against this anxiety that quantum computing has walked out of physics labs and into the视野 of strategists. It's no longer a science-fiction gimmick — it's an engineering parallel universe taking shape.

A classical bit is 0 or 1. A quantum bit can be both simultaneously. This means that when you face a problem requiring you to explore every possibility — predicting all protein folds, simulating a complete brain neural network, finding the optimal logistics route — a quantum computer can finish in seconds what would take a classical computer tens of thousands of years.

The urgency of quantum computing is growing rapidly.

In 2025-2026, global investment in quantum has visibly accelerated:

Both China and the US have designated quantum AI as a next-generation strategic priority
Companies like iFlytek are betting on quantum computing as the breakthrough of the next decade
Industry consensus expects practical "classical-quantum hybrid computing" by ~2030, bringing exponential acceleration to drug discovery, financial risk management, and climate simulation

Of course, today's quantum computers are still like early Renaissance perspective — the principle is right, but the operation is clumsy, error rates are high, and extreme低温 environments are required. But what they solve is not just "speed" — it's complexity explosion itself. If AI is a heuristic pruning of the problem space, quantum computing is a parallel read of the entire search space.

4. Where the Human Fits: From Tool User to Meaning Giver

The more powerful the technology, the sharper a philosophical question becomes: when machines can think, create, and calculate — what is left for humans?

Nietzsche once prophesied the Übermensch — a new species capable of creating its own values in a meaningless world. In the age of AI and quantum computing, this image is being reshaped. The Übermensch is no longer the lone hero, but the meta-conductor who can orchestrate these super-tools.

The user of this essay — who builds local LLM rigs, experiments with GPUs, obsesses over thermal data — is doing one thing at a deep level: active dimensionality reduction. They take the high-dimensional problem of "create a bedtime story" and compress it into a lower-dimensional, executable workflow: pick hardware, tune the model, batch-generate. The real creativity isn't in the details that got compressed away — it's in the choice of what to compress and what to preserve.

This is the deeper meaning of "reducing problem difficulty": not escaping complexity, but using new tools to restructure the problem so it becomes tractable. When quantum computing matures, this dimensionality-reduction capability will leap again — we may even simulate an entire story universe's evolution in real time, then pick the most moving timeline.

5. Epilogue: Walking the Narrow Path of the Post-Renaissance

From the dome of Florence to the network of silicon neurons, humanity keeps repeating the same pattern: liberate ourselves with one tool, then let the liberated desire drive us to seek a more powerful one.

The Renaissance liberated the human eye. The Industrial Revolution liberated human muscle. The Information Revolution liberated the human brain. The AI revolution is liberating human intelligence. And quantum computing may be the ultimate liberation of human computation.

But no matter how powerful the tools become, the original question awakened by the Renaissance remains: by what measure shall humanity judge itself?

When we use AI to generate a bedtime story, we are not competing with the machine. We are in dialogue with our past selves — seeing if this time we can craft a sentence that truly touches someone. When we hope quantum computers will solve protein folding, it's not to replace doctors — it's to free humanity from certain diseases.

Tools can reduce the difficulty of problems. They cannot reduce meaning. Meaning can only be赋予 by the person standing behind the tool — carrying their own life experience and emotional temperature.

That, perhaps, is the most important thing to remember in this long journey that began with the Renaissance.

Written on a night after tuning a local LLM rig's thermals, falling asleep to an AI-generated Arabic bedtime story.
May 2026

How Codex CLI helped me ship 3 releases in 48 hours — and what it got wrong

keeper — Sat, 23 May 2026 00:08:36 +0000

I maintain three open-source 3D printing tools: SupportSage (AI-optimized support structures), Printsight (photo-based quality inspection), and FilamentDB (filament parameter database).

Over two days, Codex CLI (gpt-5.5) helped me fix 15 bugs, add 86 new tests, and ship a unified CLI — across all three projects. Here's what worked, what broke, and what I'd do differently.

The three projects

The three tools form a closed loop:

FilamentDB ──→ SupportSage ──→ 3D Print ──→ Printsight
     ↑                                          │
     └─────────── Feedback loop ←───────────────┘

FilamentDB tells SupportSage optimal print settings for the chosen filament
SupportSage generates optimized support structures
Printsight inspects the result and feeds quality data back into the learning engine

Each was independently installable via pip. The goal was to unify them under one CLI and fix accumulated bugs.

Codex CLI: the workflow

I used Codex CLI v0.133.0 with gpt-5.5 via ChatGPT Plus. The pattern was:

Write a detailed prompt describing all bugs to fix
Run codex exec "$(cat prompt.txt)" from the project root
Review the diff
Add missing tests
Commit and push

This worked well for three projects. The prompts included exact file paths, line numbers, expected behavior, and verification commands.

What Codex got right

Printsight: 5 bugs, 16 tests

Before: tests ran subprocess calls on image files that didn't exist in the repo. All tests silently hung.

Codex fixed:

Cross-version OpenCV crash: cv2.fitLine() returns different types across OpenCV versions. The old code indexed into a float, which crashes on newer OpenCV
Division by zero: Warping detection could divide by zero when the direction vector was zero
Unchecked return value: cv2.imencode() return value was ignored, risking garbage data
Edge cases: All-black and all-white images crashed detectors
Better tests: Rewrote the entire test suite as 16 proper unit tests using synthetic numpy arrays (no external images needed)

FilamentDB: 4 bugs, 42 tests

Before: zero tests.

Codex fixed:

Corrupted JSON crash: json.load() with no try/except — a corrupted database file would crash the CLI
Recursion risk: recommend() called itself recursively when falling back to brand defaults, risking stack overflow
Empty query matched everything: search("") returned every entry because "" in string is always True
Missing tests: 42 tests covering search, recommend, compare, alternatives, list, empty database, and corrupted JSON

SupportSage: 6 bugs, 84 tests

Before: 77 tests.

Codex fixed:

Unupdated parameter: borderline_angle was never updated in the learning loop, always returning the default
Too-slow learning: Angle updates multiplied by 0.1 damping, making 20+ records barely move the needle
Missing validation: quality_score accepted negative values and values over 100
Partial file hash: Hash fallback only read the first 64KB of STL files, causing collisions
Fragile JSON loading: Printer/material profile loading crashed on corrupted JSON
Ignored quality score: Calibration updates ignored print quality entirely

Everything above worked as expected: Codex found the bugs, wrote the fixes, and I approved them.

What Codex got wrong

The approval trap

The first codex exec attempt ran for 21 minutes with zero output. I assumed it was slow — turns out it was hung waiting for approval.

Codex's config had approval = OnRequest. When exec mode needed to write files, it blocked forever because there was no TTY to approve.

Fix: codex exec --sandbox workspace-write bypasses the approval prompt. I added a cxe alias so I never forget.

The hardcoded `--json` bug

The CLI unification code I wrote had a subtle bug: the inspect subcommand always passed --json to Printsight, even when the user didn't ask for it. This meant:

The wrapper's --json flag was meaningless — JSON output was always on
Default output was JSON, not human-readable

Codex caught this in its review and flagged it as CRITICAL. Two-line fix.

Python 3.10 → 3.11 compatibility

I used Python 3.11's tomllib for TOML config parsing. Codex correctly noted that pyproject.toml still claimed >=3.10 support. Fix: add a tomli fallback import for older Python versions.

The stdin piped-prompt confusion

Passing a multi-line prompt as codex exec "$(cat prompt.txt)" works unreliably. The $(cat ...) expansion can break on special characters, and the prompt silently fails if the shell parses it differently.

The robust pattern: cat prompt.txt | codex exec --sandbox workspace-write "" — pass the prompt via stdin instead of as a command argument.

Results

After the Phase 1 unified CLI work and three rounds of Codex review:

Project	Tests before	Tests after	Bugs fixed	New features
SupportSage	77	131	6	CLI unification, shared config
Printsight	0 (broken)	16	5	—
FilamentDB	0	42	4	—
Total	77	189	15	CLI, config, roadmap

New CLI commands:

supportsage inspect photo.jpg      # → delegates to Printsight
supportsage filament search PLA    # → delegates to FilamentDB
supportsage filament recommend -b "Bambu Lab" -m "PLA Basic"
supportsage filament compare "eSun PLA+" "Overture PETG"

Shared config at ~/.supportsage/config.toml:

[printsight]
annotate_default = true  # auto-annotate inspection photos

[filamentdb]
data_dir = "~/.supportsage/data"

What I'd do differently

Test Codex exec with a simple prompt first — before throwing a 3,700-character prompt at it. A two-word test would have revealed the approval hang in seconds.
Pipe prompts via stdin — cat prompt.txt | codex exec ... "" avoids shell escaping issues entirely.
Write CLI delegation tests that verify the delegated argv — my first tests only checked that delegation happened, not what arguments were passed. Codex's review caught this.
Don't guess Codex can write everything — for Phase 1, I ended up writing the code myself after Codex hung. The bug-fix tasks worked; the feature-implementation task didn't.

Releases

All three projects got patch releases with the fixes, plus SupportSage v0.7.0 with the unified CLI:

Full roadmap: docs/ROADMAP.md

Day 11, First Star: What It Feels Like When a Stranger Clicks ⭐ on Your Open Source Tool

keeper — Fri, 22 May 2026 13:11:36 +0000

Eleven days ago, I pushed the initial commit for SupportSage — an open-source tool that optimizes 3D printing support structures.

Today, it has exactly one star.

If you've never maintained an open-source project, you might laugh at that number. One star? That's the celebration?

Yes. Yes it is.

Why One Star Matters More Than a Thousand Page Views

Page views are passive. Someone's browser loaded your page. Maybe they were bored at work, or clicked a link from Reddit, or a search engine sent them. They saw the page for 3 seconds and moved on.

A star is active. Someone looked at your code, your README, your screenshots. They understood what the project does. And they made a deliberate choice to press that button — a small social signal that says "I see value in this."

That's a completely different signal-to-noise ratio.

What This One Star Actually Means

When I check the analytics:

303 total dev.to reads across 10 SupportSage-related articles
24 unique GitHub visitors in 14 days
781 repo clones (people are actually pulling the code!)
1 star

The conversion funnel from visitor to believer is brutally honest. Most people browse, nod, and leave. Only one person said "this matters to me."

And that's fine. Open source is a marathon, not a sprint.

What SupportSage Looks Like After 11 Days

Since launch, the project has grown from a CLI-only script to a full integration suite:

Interface	Status
CLI	✅ Core features
Web Demo (no backend)	✅ Live
Desktop GUI	✅ Released
Cura Plugin	✅ Ready
FilamentDB integration	✅ Auto temp lookup
Printsight integration	✅ Post-print inspection

The benchmarks hold solid at 33% material savings across all test models — tree supports with per-island severity grading consistently outperform traditional uniform supports.

The repo is at github.com/bossman-lab/supportsage if you want to see for yourself.

What's Next for SupportSage

v0.3.0 — Multi-material support (dissolvable interface + standard body)
PrusaSlicer plugin — community demand is loud on this one
Printsight v0.3 — print failure prediction from gcode analysis (not just post-print inspection)

These are real features that take real time. But the one star tells me someone's watching.

Build in Public: The Experiment Continues

I've been documenting every step — from the initial idea through benchmarks, GUI, plugin, and now the first-star milestone. Twenty-one articles on dev.to. Zero dollars in revenue. One star on GitHub.

Would I trade those metrics for a stealth-build that nobody sees? Not a chance.

The build-in-public thesis isn't about virality or overnight success. It's about:

Committing publicly so you can't quietly abandon the project
Getting feedback early from people who actually use the tools
Building a trail of proof that you didn't fake it
Winning one believer at a time

Today, I have one believer. That's one more than day one.

SupportSage is open source. MIT license. Contributions welcome.
Repo: github.com/bossman-lab/supportsage

Anker's 0-to-1: What a $3000 Startup Teaches Us About Replicable Success

keeper — Thu, 21 May 2026 23:56:02 +0000

Anker's 0-to-1: What a $3000 Startup Teaches Us About Replicable Success

In my previous post, I analyzed the mature methodology behind Anker — shallow sea strategy, the 1357 product tier system, and the Big Dipper formation for competitive advantage. That's the 1-to-10 playbook, the system Steven Yang built after they had product-market fit.

But the 0-to-1 story is different. It's messier, luckier, and far more instructive for founders who haven't found their first hit yet.

Here's the full picture — what happened, what made it work, and what can actually be replicated in 2026.

The Timeline: From $3,000 to the First Billion

2011 — The Accidental Discovery

Steven Yang was a senior software engineer at Google. He did something completely unrelated to his later career: he built an automated order processing system for his girlfriend's Amazon shop.

What he discovered changed everything: Amazon's marketplace could put a completely unknown brand in front of global consumers.

Most good businesses aren't "thought up" — they're stumbled upon while doing something else. Yang didn't decide to start a company and then discover Amazon. He used Amazon first (for his girlfriend), then decided to start a company.

Late 2011 — The First Capital

Yang asked his mother: should I take VC money or use family money?

Her answer is worth remembering: "If this is gambling, take someone else's money. If this is what you're meant to do, use mine."

He combined his Google savings with his mother's pharmaceutical career savings — less than $1M in seed capital — and moved from California to Shenzhen.

The source of your 0-to-1 capital shapes the company's genetics. Money you're afraid to lose changes your decision quality — usually for the better.

The First Product: Laptop Batteries

The market landscape:

Option	Price	Quality
OEM laptop battery	$100	Good
Cheap knockoff	$20	Terrible
Anker's slot	$30-40	Near-OEM quality

Yang found a "no-man's land": $100 was too expensive, $20 was too risky. Would people pay $30-40 for near-OEM quality?

Yes, they would. This became their first revenue.

0-to-1 isn't about finding a blue ocean. It's about finding a quality gap — the price point where customers will happily pay 50% more to stop worrying about quality.

2012-2013 — The Forced Pivot

The MacBook Air made built-in batteries standard. The laptop battery category was shrinking. Meanwhile, smartphones were exploding.

Yang pivoted from laptop batteries to phone accessories. Their first phone product? A replaceable battery for the HTC Sensation (Android phones still had removable batteries then). Then power banks, cables, chargers.

Your first category probably won't be your final category. The key is building capability (manufacturing + supply chain + distribution) that can transfer to a bigger market.

2014 — The First Hit: The "Lipstick" Power Bank

The team noticed a very specific problem: women's bags are small. Regular power banks don't fit.

They found a Shenzhen factory making lipstick-sized power banks. Anker didn't design from scratch — they redesigned and improved an existing product.

Result: 1 million units sold. Topped Amazon for 3 consecutive years.

This was Anker's first "breakout" product. Before this, they were "that decent charger brand on Amazon."

Your first hit comes from a narrow, overlooked scenario. Not "a better power bank for everyone" — "a power bank that fits in a small bag." The narrower the entry point, the faster it explodes.

Anker's Three Hidden Weapons

Weapon 1: The Amazon Review Mining Machine

Yang's most underrated innovation wasn't a product — it was a method for finding what to build.

The process: study thousands of Amazon reviews and complaints daily → identify the top 3 customer pain points → design a product that specifically fixes those 3 things → launch → iterate based on new reviews.

Result: Anker's products weren't "designed by engineers." They were complained into existence by customers.

At the 0-to-1 stage, you don't need genius insights. You need a systematic way to let customers tell you what to build.

Weapon 2: The Happy Card

Every Anker product included a card: "Contact us directly if there's an issue. Don't leave a negative review."

Results: complaints handled privately instead of publicly on Amazon, direct customer relationships established, consistent 4-star ratings — not the best, but the most reliable.

The most valuable early-stage asset isn't traffic — it's ratings and word-of-mouth. A "talk to us first" card in every package is worth more than a paid ad campaign.

Weapon 3: PowerIQ

A self-developed technology that auto-detects connected devices and delivers optimal charging power. Technically simple. But in marketing, it transformed Anker from "cheap charger brand" into "the brand with technology."

Early-stage technology doesn't need to be revolutionary. It needs to give customers a label they can repeat. "The one that auto-detects your phone" spreads faster than "Anker's charger."

What You Can't Replicate: Three Windows That Closed

1. Amazon's Traffic Window (2011-2014)

In 2011, few Chinese sellers were on Amazon. Competition was minimal, ad costs were low, and the platform was hungry for third-party sellers. Yang wasn't "grabbing share in a crowded market" — he was planting flags on empty land.

Today: thousands of competitors per category, CPC costs of $1-5, Amazon pushing its own Basics line, and 4.5-star products everywhere.

2. The Shenzhen Manufacturing + Three-Way Arbitrage

In 2011, Yang was one of the few people who simultaneously understood three things:

What US consumers wanted and what they'd pay
How Amazon's marketplace and rules worked
What Shenzhen's supply chain could actually do

Today, that three-way knowledge is table stakes for every cross-border ecommerce operator.

3. The Category White Space

In 2011, the charging accessories market had OEM ($100) and garbage ($20) — with nothing in between. Today, search "power bank" and you'll find hundreds of brands at every price point, all rated 4.5+. That quality gap has been filled.

What You CAN Replicate: Four Patterns That Haven't Aged

Pattern 1: Find Demand on a Platform, Don't Guess It

Yang's sequence: find a platform (Amazon) → study complaints → build product. Most founders do the reverse: have a product idea → validate on a platform.

The 2026 version: Find a platform where users publicly complain (Reddit subreddits, Xiaohongshu comments, GitHub Issues, Discord servers). Let their complaints tell you what to build.

Pattern 2: Don't Be the Cheapest, Don't Be the Best — Be the Most Reliable Middle Ground

Anker owned the "four-star review" slot — between five-star OEM and three-star no-name.

The 2026 version: In any category, "best value" scales better than "cheapest" or "premium." Find the price point where customers pay 50% more for "won't let me down."

Pattern 3: The First Hit Comes From a Ridiculously Specific Scenario

Not "a better power bank" — "a power bank that fits in small bags."

The 2026 version: Don't build "an AI writing tool." Build "an AI writing tool for cross-border ecommerce listings." Don't build "project management software." Build "a progress tracker for renovation contractors." Narrow entry, wide exit.

Pattern 4: Early Tech Doesn't Need to Be Revolutionary — It Needs to Be Shareable

PowerIQ wasn't hard to build. But it gave customers a one-liner: "It's the one that automatically detects your phone's charging needs."

The 2026 version: Your first feature doesn't need to be a patentable invention. It needs to be describable in one sentence that a customer would actually say to a friend.

How to Apply This Framework in 2026

Don't start a charger brand (red ocean). Don't expect Amazon blue oceans (gone). But the framework works:

Step	What to Do	Anker's Equivalent
1	Find a "high-density complaint" platform	Amazon review mining
2	Identify a quality gap ("clearly better than budget, 60% less than premium")	Laptop battery positioning
3	Build a first product for a very narrow scenario	Lipstick power bank
4	Create a trust mechanism (direct founder access, no-questions refund)	Happy Card
5	Give the product a label customers repeat	PowerIQ

0-to-1 vs 1-to-10: Completely Different Games

Dimension	0-to-1 Phase (2011-2014)	1-to-10 Phase (2014-onward)
Strategy	Find quality gaps, test fast	Shallow sea, systematic expansion
Innovation	Improve existing products	9-grid innovation framework
Team	A few friends from Google/Peking U	6,000-person President+Federation
Pricing	$30-40 sweet spot	1357 tiered system
Competition	One person can win	Big Dipper formation

Anker's mature methodology fills the LatePost interview. But the blood, sweat, and luck of 0-to-1 isn't in that article.

Read the companion Chinese version on our blog. This is the second in a two-part series: Part 1: The five principles uniting Anker and community-building

Companies Are the Hardest Products, Communities Are the Hardest Companies: What Anker and the Internet Taught Me About Building

keeper — Thu, 21 May 2026 23:25:57 +0000

Companies Are the Hardest Products, Communities Are the Hardest Companies

Two readings, same week, same room, different worlds — and they converged on the same five principles.

Reading 1: LatePost's interview with Anker founder Steven Yang — a man who lost 15kg to depression in 2022, cut 10 product categories, then rebuilt his company from first principles.

Reading 2: Wang Yizhou's essay People, Content, Community from the Chinese publication Mingyeji — a framework for why most "community products" fail: they solve communication but not identity.

One is about building a $3.6B consumer electronics company. The other is about building online communities that don't die. They look like different universes. They're not.

This post distills the five shared principles — a unified lens I wish I'd had when I started building.

1. Terrain Dictates Strategy, Not the Other Way Around

Anker: Shallow Waters

Yang's most quoted line: "Even with $5-10 billion in chips, don't sit at a table where the blind is $500 million."

Anker categorizes all markets into two terrains:

Type	Size	Anker's stance
Shallow sea	≤ $50B/year	Fights here
Deep sea	$100B+ (phones, TVs, PCs)	Won't touch

This isn't about ambition — it's about what the terrain allows. A $50B category with many sub-niches (like consumer electronics accessories) rewards breadth + systems. A $500B category dominated by mobile phones rewards depth + a single moonshot. Anker chose the terrain that matches its nature: a "third-category company" that wins through portfolio and process, not a single breakthrough product.

REMIX: Cultural Boundaries

The community framework makes the same point. A real community needs five elements:

Element	Meaning	Counterexample
Role	A recognized identity	Everyone is just a "user"
Action	A specific way to contribute	Everyone can only like/comment
Status/incentive	Reputation, influence, money	Pure volunteerism burns out
Hierarchy	Levels + sequence + mobility	Flat = no growth feeling
Cultural boundary	Anti-scale exclusivity	Anyone can join = no identity

The last element is the most counterintuitive: a community that scales infinitely is not a community — it's a content platform. Cultural boundaries are the "shallow sea" of community design. If you don't accept that growth will be constrained by identity, you'll build a content platform instead.

The shared principle: The shape of your battlefield determines your strategy — not your vision, not your talent, not your funding. Denying the terrain doesn't change it.

Put it to work: Before choosing a category (product) or a community (people), draw a map of the terrain. What does success at your chosen size look like? If the map shows "deep sea" dynamics, don't enter with a shallow sea strategy.

2. Don't Design for 'Everyone' — Design a Ladder

Anker: The 1357 System

Anker's products aren't a flat list. They're a gradated hierarchy:

Series	Character	Price vs. peers	Strategic role
1系	Cheapest	Lowest	Funnel entry
3系	Value	Low-mid	Volume base
5系	Reliable, quality	+50-100%	Core (first 10 years)
7系	Best, most expensive	Premium	Future

Target: 7系 grows from 3% (2020) → 15% (2025) → 30% of revenue by 2030.

"How do you judge a world-class company? Look at whether 7系 products are at least 30% of revenue."

The hierarchy gives every user a clear upgrade path without leaving the brand. Solarbank 1 (€1k) → Solarbank 2 Pro (mid) → Solarbank 3 Pro (AI-powered, premium) — same user, same ecosystem, natural upgrade.

REMIX: Hierarchy + Sequence

The community framework's fourth element — hierarchy — isn't about inequality. It's about making growth visible. A community without levels is a chat room. Levels create:

A path: "I start here, I can get there"
Recognition: Your effort maps to a visible status
Retention: Leaving means losing your accumulated standing

The framework calls this "a sequence" — not just tiers, but a progression with clear advancement criteria.

The shared principle: Don't sell one thing. Design a ladder. Let users grow without leaving your ecosystem.

Put it to work: Whether you're building products or a community, map your 1系→3系→5系→7系. Your entry point should be easy to try (low barrier), your core should deliver reliable value (high retention), and your premium tier should set the standard for the entire category (brand elevation).

3. From Factory to Playground: The Remix Model

Anker: The Creator's Paradise

Yang's revised mission for Anker: "Build a creator's paradise that inspires each other. Create a brand that global consumers love."

He contrasts two organization models:

Model	Used by	Logic
King + Knights	Apple, Tesla	Single ultra-category, concentric talent
President + Federation	Anker	Multiple mid-categories, distributed leadership

Anker is explicitly the second model. The CEO doesn't design products — he designs the system that produces product designers. The company at scale: 6,000 people, 800+ making >¥1M/year, organized as "branches build, headquarters orchestrates."

Yang's diagnosis after the 2022 crisis: "Five pots, only two lids" — too many product lines, not enough great managers. The fix wasn't hiring more people. It was reducing from 100 products → 30 → ~10 by 2025, then rebuilding the system.

REMIX: The Playground

The community framework's core metaphor: product as playground, not factory.

Dimension	Factory (traditional platform)	Playground (AI-era community)
Rhythm	Publish, done	Open every day, ongoing
Structure	Platform decides the flow	Platform provides equipment, users decide
Goal	User consumes content	User exists in the group
Barrier	Low entry, low depth	Low entry, depth optional
Repeat behavior	Scroll more	Play deeper

The critical insight: AI's core capability isn't creation — it's editability/remix. The old product model assumed "seed units" were completed works (tweets, photos, videos). The new model assumes seed units are open and editable — a character, a world, a conversation — and the product's job is to enable remix, not factory output.

Anker's "creator's paradise" is a playground for employees. REMIX's "playground" is a product model for users. Both reject the assembly line.

The shared principle: Stop building factories that output standardized units. Start building playgrounds where participants create value through interaction, remix, and evolution over time.

Put it to work: Ask yourself: is my company/product a factory or a playground? Am I hiring people to execute my instructions, or am I creating conditions where they figure out better paths? Am I producing content for users, or am I creating spaces where users produce value for each other?

4. System Over Individual: The Formation Advantage

Anker: The Big Dipper Formation

Yang's problem: Anker's department heads are "middle horses" — good, not geniuses. How do they beat competitors' CEOs ("top horses") in one-on-one battles?

Answer: don't fight one-on-one. Use a formation.

"In Jin Yong's novels, the Big Dipper Formation uses 7 average martial artists in a coordinated pattern to defeat a master. Wang Chongyang could have fought everyone himself, but he didn't want to — so he built the formation."

Anker's formation has four layers of compounding advantages:

Channel reuse: Amazon → offline → global, one product supports another
User group cross-pollination: Security customers buy cleaning, buy storage
Shared technology: Chips, systems, models — built once, used everywhere
Unified brand: Anker → eufy → soundcore, one name = one trust signal

Result: the department head isn't alone. They bring the entire formation to every fight.

REMIX: Collaborative IP via Open Source Mechanics

The community framework maps this exactly:

Open source mechanic	Mapped to collaborative IP
Clear main branch	A maintained "canon" version of the IP
Forkable + PR-mergeable	Users fork AU (alternate universe) versions; good ones merge back
Standardized protocol	Fork/adopt/co-create/consensus mechanism
Maintainer role	IP stewards
Reputation system	Contributors earn naming rights, revenue share, voice

The theoretical foundation is Hayek's The Use of Knowledge in Society: modern society works because distributed local knowledge aggregates through exchange. The same applies to creation — IP can be collaboratively grown by distributed contributors.

Fan fiction communities have already proven this works (roles, events, deadlines, recognizable tiers, co-creation mechanisms). AI makes the model massively scalable — characters and worlds no longer degrade as they get remixed.

The shared principle: Don't depend on individual genius. Build a system where coordinated average talent outperforms scattered exceptional talent. The system itself is the moat.

Put it to work: Before hiring a "rockstar," ask: what's the formation they'll fight in? What does your compounding advantage stack look like? If your new person needs to win alone, you have a hiring problem — but also a system problem.

5. Bet Half, Reinvest, Repeat: The Sequencing Principle

Anker: Aggressive Conservatism

"We're aggressive conservatives. Conservative: out of ¥10, we bet at most ¥5-6. Aggressive: we always place that ¥5-6."

The math:

Start with 10 → Bet 5 → Make 20 → Total 25 → Bet 12 → Repeat
The pot grows, but the proportion stays at ~50%

This isn't risk aversion. It's sequence discipline: don't over-expand before the system can support it. After 2022's over-expansion (four+ new categories in one year), Yang cut to 10 and rebuilt.

"From 100 products to 30 to ~10... everyone thinks I'm constantly restructuring. Yes."

The sequencing principle also governs who gets paid first:

"In consumer electronics, excess value is created by workers. Workers should get the majority."

Metric	Before	Now
Employee comp as % of revenue	~8%	13%
Employees making >¥1M	500 (2024)	800+ (2025)
Gross margin	Baseline	+8pp over 5 years

Compensation structure: distribute opportunity first (values-based), distribute returns after (results-based).

REMIX: Sequence in Community

The playground model has a natural sequencing logic:

Catch a crowd (people who want to remix)
  → Form a community (roles + cultural circle)
  → Build mechanics (fork / adopt / co-create)
  → Let collaboration become assets (IP + collective memory)
  → Product grows into a continuously operating playground

Each step depends on the one before. You can't build mechanics without a community. You can't have a community without a crowd that wants to remix. Skip a step and the system collapses.

The shared principle: Growth isn't about how fast you can go. It's about what you can afford to sustain. Sequence your expansion so each step is funded by the last. Distribute opportunity before returns.

Put it to work: What's your current "pot" (resources, talent, trust)? Never bet more than half. On the next win, reinvest half of the gain. Repeat. And ask yourself: am I distributing opportunity to the right people first, or am I trying to buy my way out of a system problem?

The Unified Chart

Principle	Anker	REMIX	Get to "yes" question
Terrain over ambition	Shallow sea (≤$50B) vs. deep sea	Cultural boundary vs. mass platform	"Does the shape of my battlefield allow my kind of win?"
Ladder over flat	1357 product hierarchy	Role + hierarchy + sequence	"Do users have a visible path to grow within my system?"
Playground over factory	Creator's paradise organization	Open-seed-unit product model	"Am I building a system that enables, or an assembly line that standardizes?"
Formation over individual	4-layer compounding advantage	Forkable IP + maintainer + reputation	"Can 7 average people in formation beat 1 genius alone?"
Sequence over speed	Aggressive conservatism (bet 50%)	Step-by-step community building	"Is my next expansion funded by the last win?"

What This Means for a Founder With 3-24 Months of Runway

This isn't theory. Here's the real checklist:

Month 1: Map your terrain

Is your category shallow sea or deep sea?
If deep sea: can you enter through a niche that the dominant player ignores for 3+ years?
Does your potential community have enough cultural identity to survive growth?

Month 2: Design the ladder

What is your 1系 (entry, easy to try)?
What is your 5系 (core, reliable value)?
What is your 7系 (aspirational, sets the standard)?
Same question for community: what's the entry role vs. the top role?

Month 3-6: Build the playground, not the factory

Are you producing things for users, or are you building a space where users produce things for each other?
What's the "seed unit" — is it completed (factory) or editable (playground)?
For Anker: the seed unit is a product category operated by a semi-autonomous team. For REMIX: the seed unit is a character/world that can be forked. What's yours?

Month 6-12: Install your formation

What 3-4 compounding layers can you build that each competitor would need to build from scratch?
Can your "middle horse" department heads access the same resources that your CEO would?
For community: can a new contributor become a maintainer through a clear path?

Month 12-24: Sequence, don't sprint

What is your ¥10? Bet 5. Don't bet 8.
Did your last win pay for your next expansion?
Are your most valuable people getting more opportunity, not just more money?

Closing

Yang's ultimate aspiration, quoting Laozi: "The highest ruler is one whose existence is barely known." He places himself at the third level (feared) but wants to reach the first (barely known — the system runs itself).

The community framework says the same thing differently: the best products aren't destinations you visit — they're playgrounds you live in. The creator becomes invisible; the creation becomes self-sustaining.

A company is the hardest product. A community is the hardest company. But the principles that govern them — terrain, ladder, playground, formation, sequence — are the same.

The question isn't what you build. It's what system you set in motion.

Four Routes to EUV: LPP, LDP, Gas Cluster, and the Soft X-Ray Dark Horse

keeper — Thu, 21 May 2026 14:55:23 +0000

Today there are three actively competing approaches to generating extreme ultraviolet (EUV) light for chip lithography. And there's a fourth one — soft X-ray — that's too early to call a competitor, but worth watching.

ASML's LPP dominates — it's what powers every 7nm-and-below fab from TSMC, Samsung, and Intel. But it costs $200M per machine and took $20B+ in R&D.

China's LDP route trades peak performance for accessibility — simpler hardware, lower cost, but stuck on electrode erosion.

Russia's gas cluster approach targets a fundamentally different wavelength (6.7nm vs 13.5nm) and produces no debris because its "target" is a gas.

And then there's soft X-ray / B-EUV — 6.5–6.7nm, 185–190 eV photon energy. Still in the lab. No production light source exists. No mirrors exist for this wavelength. But in 2025, Johns Hopkins published a resist breakthrough in Nature, and a startup called Substrate raised $100M at a $1B valuation with a X-ray lithography story.

Let's break down all four.

The Four Routes at a Glance

Route	Representative	Wavelength	Source	Target	Power
LPP	ASML (Netherlands)	13.5nm	CO₂ laser→tin droplet plasma	Tin (Sn) droplets	250-600W (production)
LDP	Multiple Chinese institutes	13.5nm	Pulsed discharge→tin vapor plasma	Tin electrodes/vapor	~100W (lab)
Gas Cluster	Russian Academy of Sciences	6.7nm (target)	Yb femtosecond laser→gas cluster plasma	Li-Xe nanoclusters	150-200W (theoretical)
Soft X-ray / B-EUV	Johns Hopkins / Substrate (lab)	6.5–6.7nm	Gd LPP (experimental)	Zinc-based resists	No production source

How Each Works

LPP (Laser Produced Plasma): A CO₂ laser (10.6μm) hits a stream of 30μm tin droplets at 50,000 times per second. Each impact vaporizes the droplet into 500,000°C plasma that emits 13.5nm light. ASML has spent $20B+ perfecting this.

The three fundamental problems:

Tin debris — fragments coat the collector mirror. ASML uses hydrogen buffers + self-cleaning coatings. It works, but adds enormous complexity.
CO₂ laser efficiency — CO₂→EUV conversion is ~5-6%.
Plasma absorption — tin plasma reabsorbs some 13.5nm radiation, limiting usable plasma size.

LDP (Laser Discharge Plasma): A pulsed electrical discharge runs through tin vapor to create plasma. Simpler and cheaper.

The single bottleneck: electrode erosion. Every discharge eats the electrodes. Lifetimes range from thousands to millions of shots. In a 24/7 fab, that's uptime. Research directions include rotating electrodes (like X-ray tubes), liquid tin streams, and cryogenic plasma maintenance.

Gas Cluster (Russian Academy of Sciences, May 2026): Lithium vapor mixed with xenon gas forms Li-Xe nanoclusters. A Yb femtosecond laser (1030nm) excites these clusters to emit 6.7nm EUV light.

The crucial difference: everything is a gas. When the cluster explodes, the fragments are also gas — pumped out by vacuum pumps. No debris, no mirror contamination.

Three bottlenecks:

Multilayer mirrors for 6.7nm — Mo/Be or Mo/Y coatings need Å-level precision. Thinner, tighter, harder than 13.5nm Mo/Si stacks.
Gas jet stability — laser-to-cluster coupling depends on cluster size distribution. Complex fluid dynamics.
Ion damage — 6.7nm photons carry more energy. Different damage mechanisms, zero long-term data.

Timeline Reality Check

Milestone	ASML LPP	China LDP	Russia Gas Cluster	Soft X-ray / B-EUV
Proof of concept	2000s	2010s	2010s-present	~2025 (JHU resist)
Lab prototype	2012	~2023-2025	~2026 (announced)	None (needs source+optics)
Fab prototype	2016	~2027-2029	350nm node is real	No roadmap
Mass production	2018 (hundreds delivered)	~2030+	6.7nm EUV: 10-15 years	15+ years, if ever

The Fourth Route: Soft X-ray / Beyond EUV

Soft X-ray (B-EUV) is not competing with the three routes above. It's on a different wavelength track entirely.

The physics argument is compelling. Halve the wavelength, double the resolution — even with moderate NA (0.3-0.5) you could reach <5nm features, comparable to what Hyper-NA EUV (0.75+ NA, estimated $1B per tool) promises at 13.5nm. The catch: everything needed to make it work doesn't exist yet.

Current Progress

Johns Hopkins University (Nature Chemical Engineering, 2025): Solved one of the four critical bottlenecks — resist chemistry. Zinc absorbs 6.5-6.7nm soft X-rays efficiently and emits electrons that trigger chemical reactions in imidazoles. They developed Chemical Liquid Deposition (CLD) to apply zinc-imidazolate frameworks (aZIF) at 1nm/sec onto silicon wafers and successfully created fine patterns.

The team's own assessment: "Years from building even an experimental prototype."

Substrate (California startup, October 2025): $100M funding, $1B valuation. Claims X-ray lithography (XRL) using synchrotron sources can reach sub-2nm nodes. Published 12-13nm CD images of random logic contact arrays. Has disclosed zero details on source type, optics, mask design, or 300mm wafer throughput.

Technology Readiness Comparison

Dimension	LPP	LDP	Gas Cluster	Soft X-ray
Light source	✅ Production	🔧 Lab	🔧 Proof of concept	❌ None available
Optics	✅ Production	⚠️ Basic	🔧 Multilayer needed	❌ From zero
Resist	✅ Mature	✅ Reusable	✅ Reusable	🔧 JHU initial breakthrough
Supply chain	✅ Complete	⚠️ Partial gaps	❌ Nearly zero	❌ Entirely non-existent
First tool cost	~$200M	~$10M+	~$10-30M (est.)	Unknown (needs accelerator)

Critical Obstacles

Light source — No production-capable 6.5-6.7nm source exists. Gadolinium LPP is experimental, far below required power.
Optics — 6.5nm light is absorbed by almost every material. Entirely new multilayer mirror designs needed. None exist.
Zero supply chain — Masks, pellicles, metrology, source — everything must be invented from scratch. No company has the incentive to invest ASML-level capital at this stage.
Substrate's XRL approach — Proximity printing (1:1 mask-to-wafer, no reduction). Synchrotrons are 30m to >1km in circumference, costing $100M+.

The Most Realistic Role

Soft X-ray / B-EUV is not an "EUV replacement." Its most plausible role: a wavelength-based alternative path when Hyper-NA EUV hits its cost ceiling (estimated $1B/tool) — assuming 6.7nm source and optics technology mature by then.

What This Actually Means

1. Four routes, four time windows, not zero-sum.

13.5nm (LPP + LDP) → the present. Covers advanced and mature nodes.
6.7nm gas cluster → next generation (10-15 years). Advantage in efficiency and wavelength differentiation.
6.5-6.7nm soft X-ray → long-term (15+ years). A wavelength hedge against Hyper-NA cost escalation.

2. EUV is a cost variable, not a survival threshold.
Chiplet architectures + DUV multi-patterning cover enormous real-world demand. Advanced packaging reduces dependence on any single lithography node.

3. The gas cluster route's real contribution.
Russia's scheme won't replace ASML. What it does is demonstrate that a third path might exist — breaking the "only LPP can do EUV" assumption.

4. Soft X-ray is the longest bet.
Johns Hopkins cleared one obstacle (resist). Dozens remain. B-EUV's timeline is measured in decades, not years — but if Hyper-NA EUV really hits $1B/tool, the industry will be glad someone started working on alternatives.

Sources: ASML annual reports, published Chinese LDP research papers, Russian Academy of Sciences report (May 2026), Johns Hopkins / Nature Chemical Engineering (2025), Substrate public disclosures, and public industry data.