The Billion-Token Battle: Shipping Our OpenClaw Windows Client

Nexu is an open-source, one-click-install OpenClaw desktop client that puts AI in your hands — locally. GitHub: https://github.com/nexu-io/nexu ⭐ If you find it useful, a Star means the world to us.

Last week we shipped Nexu v0.1.12 with full Windows support. As the world's first open-source OpenClaw desktop client — processing billions of tokens daily — Windows was by far the most requested feature from our community.

But "Windows support" is three words that hide a complete rebuild of our packaging pipeline. Here's what changed:

Metric	Before	After
⏱ Build time	15 min	4 min
📦 Install time	10 min	under 2 min
🔄 CI builds	manual	fully automated
🧩 Update logic	coupled	macOS/Windows decoupled

We hit plenty of walls along the way and made some unconventional technical decisions. Since we're open source, there's no reason to keep these lessons to ourselves. This is the first post in a series — hopefully it saves you some pain if you're shipping Electron apps cross-platform.

Where electron-builder Falls Short

electron-builder is the de facto standard for packaging Electron apps. Most projects use it end-to-end, from source to final installer. So did we, initially.

But once we actually ran the full Windows pipeline in production, the default path started breaking down:

Nexu's packaged file tree contains roughly 38,000 files. Default ZIP compression handles this scale terribly — both in build time and install time
We needed custom installer logic — data migration options, registry cleanup, user-facing choices that electron-builder's defaults don't support
macOS and Windows have fundamentally different update semantics. Forcing them into the same code path was creating fragile, hard-to-debug behavior
CI artifacts need to be reproducible regardless of local machine setup

electron-builder still handles producing win-unpacked (the raw app directory). But from that point on, we took over.

Custom 7z + NSIS Pipeline

Our new pipeline has two stages:

Stage 1: electron-builder produces win-unpacked Standard Electron app directory — exe, dlls, resources. electron-builder still does this well.

Stage 2: Custom packaging takes over

Vendored 7-Zip compresses win-unpacked into payload.7z
makensis compiles a custom NSIS installer
The installer handles extraction, registry writes, shortcuts, and uninstall cleanup

Why 7z? With 38,000 files, 7z's solid compression treats the entire tree as a single block — dramatically better compression ratio and extraction speed than ZIP. This is the single biggest reason install time dropped from 10 minutes to under 2.

Why NSIS? Full control over every aspect of the install flow — paths, migration options, registry, uninstall. No more fighting framework defaults.

We also vendored 7-Zip directly into the repo, so both CI and local builds have zero external dependencies. Reproducibility out of the box.

Platform Update Drivers

This one bit us hard. Our update logic for macOS and Windows used to share a single code path, branched with if (platform === 'win32').

The problem is that these platforms have fundamentally different update models:

macOS can silently update in-app
Windows requires quit → run installer → restart

Cramming both into one path meant every Windows fix risked breaking macOS. So we introduced an Update Driver abstraction — three independent platform drivers:

mac-update-driver — in-app download and install
windows-update-driver — external download + installer redirect
unsupported-update-driver — graceful fallback for other platforms

Each platform now evolves independently. If you're building cross-platform Electron apps, introduce this separation early — you'll thank yourself later.

Runtime Path Resolution

Here's a subtle one: after packaging, runtime file locations depend on your build config. Our old code used loose heuristics to find them — which mostly worked, until it didn't.

Any change in build output layout could silently break runtime discovery. And these failures only showed up in packaged builds — never in local dev.

We wrote a dedicated Windows runtime locator that resolves paths explicitly relative to the exe. The contract between build output layout, runtime packaging, and runtime discovery is now tight.

Before: "it's probably around here." Now: "it must be exactly here, or fail loudly." No more silent breakage in production.

CI/CD Pipeline

Previously, Windows builds were a local-only affair — success depended on your machine's toolchain being set up correctly.

We moved the entire build → package → sign → publish flow to GitHub Actions:

Nightly / beta / release — all three workflows now fully support Windows
Auto-generates latest-win.json update manifests
Artifacts include installer, hashes, and metadata — fully traceable

For open-source projects, reproducible CI is everything. Any contributor can build and get the exact same output.

What's Next

The real value of this work isn't a flashy new feature — it's infrastructure that compounds. More control over packaging, more stable updates, more predictable paths.

We still have experimental optimizations in the pipeline (like lifecycle-driven Windows data migration), which we'll cover in the next post once they're battle-tested.

The whole point of open source is sharing what you learn, not just what you ship.