DEV Community: Joey Lee

Every AI Startup Should Watch Out: 1000+ Ghost Accounts Drained Our Platform in 15 Days

Joey Lee — Thu, 16 Apr 2026 12:29:23 +0000

We're building Nexu 🦞, an open-source OpenClaw desktop client on GitHub. When new users sign up, they get free credits to try various LLMs on the platform.

One day, while cleaning up user data, we noticed something odd — an email domain we'd never seen before had an abnormally high number of registered users. Higher than many corporate domains. Sitting near the top of our domain leaderboard.

This article is a complete record of how we went from "that's weird" → multi-dimensional drill-down → baseline comparison → conclusion. We also open-sourced the entire investigation methodology as an installable Skill — you'll find it at the end.

01 / A Domain That Shouldn't Be on the Leaderboard

When we sorted registered users by email domain, the usual suspects were at the top — gmail.com, qq.com, various corporate domains.

But one domain sat suspiciously high (anonymized as xx.love below). It had over 1,000 registered users.

A domain we'd never heard of, with more signups than many enterprise domains. That alone was a signal worth digging into.

A quick background check:

Registered in early 2026, WHOIS privacy protection — no registrant info
DNS hosted on Cloudflare with MX records — capable of sending and receiving email
No A records, no website, no ICP filing

A domain built solely for email, with zero public web presence. Keep this in mind.

02 / Two Distinctly Different Phases

Plotting these 1,000+ accounts on a timeline revealed they weren't evenly distributed — they clearly split into two phases.

Phase 1 (Day 1–7): Low-volume probing

Single digits to a few dozen per day, ~150 total. Email prefixes were varied — some looked like real names (linlong, wuyan), some were obvious test inputs (ooo, qwe), plus some mixed strings. Inconsistent, like someone experimenting.

Phase 2 (Day 8 onward): High-volume flood

700+ in a single day. Prefixes shifted almost entirely to 6-character alphanumeric random strings (e.g., 01mh07, x9k2p3). Within 10-minute windows, we repeatedly saw bursts of 16–18 accounts, with a median registration interval of about 37 seconds.

This wasn't just scaling up — the naming strategy changed entirely. From "someone typing at a keyboard" to "a script doing the work."

03 / User-Agent Fingerprints Shifted in Sync

Registration behavior alone might not be conclusive, but User-Agent changes added another layer of confirmation.

Phase 1: Almost exclusively Chrome N (Windows)
Phase 2: Primary UA shifted to Chrome N+1 (Windows)

Moreover, email prefix patterns correlated with specific UAs:

"Name-like," "5-char," and "7-char" prefixes → almost all Chrome N
"6-char random" prefixes → overwhelmingly Chrome N+1

The prefix switch and UA switch happened simultaneously. It looked like the entire registration environment was upgraded at once.

04 / The Baseline Comparison Exposed Everything

Side by side with the general user population, the differences were stark.

Metric	Suspicious Domain	All Users
Session structure	Almost all single-session	Commonly multi-session
Multi-IP / multi-UA switching	Almost none	Clearly present
UA diversity	~1,000+ sessions / 3 UAs	~4,000 sessions / 190 UAs
Registration → first use	~5 hours	~8 minutes
Accounts with usage	73.8%	81.4%

Highly converged environment. Normal users switch devices and browsers all the time — 4,000 sessions mapped to 190 distinct UAs. The suspicious domain? 1,000+ sessions across just 3 UAs. Two orders of magnitude more concentrated.

Register first, activate later. Normal users start using the product within a median of 8 minutes after signup. These accounts waited a median of 5 hours. Not inactive — more like "build the pool first, activate on schedule."

Selective activation. 73.8% of accounts eventually made API calls. These weren't throwaway registrations — this was a selectively activated account pool.

05 / Not Just Vanity Metrics — Real Resource Drain

If these accounts had just sat idle, the damage would've been minimal. But they didn't — they were making API calls at scale. They consumed billions of tokens across most major models on the platform. The inference cost was significant.

The calls weren't concentrated on one or two models, but spread broadly — thousands to tens of thousands of calls per model.

This wasn't "sign up, grab credits, leave." It was systematic consumption of platform API resources.

06 / Technical Retro: Four Takeaways

🔍 Always establish baselines

Many metrics are meaningless in isolation. "Created a session shortly after signup" sounds normal — but 80% of all users do that. Only by comparing against the baseline can you distinguish "normal" from "anomalous."

📊 Cross-dimensional analysis > single-metric judgment

Prefixes alone, UA alone, registration timing alone — each could be dismissed as coincidence. But when all three dimensions shift in sync, the probability of coincidence approaches zero.

⏱ Zoom into the timeline

Aggregated data masks phase transitions. Break it down by day or even by hour to spot the "probing → flooding" inflection point.

🎯 Restraint is more convincing than accusations

Throughout this analysis, we never said "this is a malicious attack." We only described the patterns the data revealed. Restrained conclusions are actually more persuasive — because the facts speak for themselves.

07 / Conclusion

The 1,000+ accounts under this suspicious domain form a highly homogeneous, batch-processed, systematized account cluster.

✅ Clear "probing → flooding" two-phase transition
✅ Prefix patterns, UA fingerprints, and registration cadence all shifted in sync
✅ Compared to the general population: environment convergence, activation timing, and session structure all significantly deviated
✅ More consistent with "build an account pool, then selectively activate" than simple spam registration

For early-stage SaaS products, this kind of batch registration may not be immediately fatal. But the impact is real — stolen API costs, polluted growth metrics, and the risk of escalation if left unchecked. The sooner you build anomaly detection capabilities, the sooner you stop the bleeding.

08 / We Open-Sourced Our Investigation as a Skill

We packaged the entire investigation workflow into an open-source Skill called abuse-hunter.

Install it in Nexu:

/skill install https://github.com/nexu-io/harness-engineering-guide/tree/main/skills/abuse-hunter

Then kick off an investigation with one sentence:

Check for email domains with abnormally high registration volumes and look for signs of batch account farming

It automatically runs a 6-step investigation and outputs a scored report:

Email domain clustering — identify domains with abnormal signup volume
Registration cadence analysis — organic growth vs. batch injection
Prefix pattern recognition — human-created vs. script-generated
UA fingerprint comparison — environment diversity vs. convergence
Activation timing analysis — instant use vs. delayed activation
Credit consumption stats — quantify actual financial impact

Final output: a 12-point composite score with recommended actions. It also ships with a Python script for offline CSV analysis.

🔗 abuse-hunter Skill: https://github.com/nexu-io/harness-engineering-guide/tree/main/skills/abuse-hunter

📘 Harness Engineering Guide — hands-on tutorials for harness engineering: https://github.com/nexu-io/harness-engineering-guide

09 / About Nexu

Nexu is a one-click installable OpenClaw desktop client that lets you control everything with AI, locally.

Whether you use WeChat, Feishu, DingTalk, WeCom, QQ, Slack, Discord, WhatsApp, or Telegram — your Agent lives right in your chat window, helping you write code, fix bugs, run automations, manage schedules, and do research.

🦞 Nexu: https://github.com/nexu-io/nexu

If you're interested in real-world AI Agent practices — whether it's architecture, product design, or growth security — give us a Star ⭐, or open an Issue / Discussion to chat.

The Billion-Token Battle: Shipping Our OpenClaw Windows Client

Joey Lee — Wed, 15 Apr 2026 12:30:30 +0000

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 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.

Speaking of sharing — we're also building a free, open-source knowledge base for AI Agent engineering: the Harness Engineering Guide.

It covers architecture patterns, technical deep-dives, product comparisons, and frontier research in the AI Agent space. 20+ in-depth articles and growing.

🌐 Website: https://harness-guide.com
📦 GitHub: https://github.com/nexu-io/harness-engineering-guide

If you have insights or hands-on experience with AI Agents, we'd love your contribution. Open an Issue or submit a PR — every submission gets a thorough review.

Nexu is fully open source: https://github.com/nexu-io/nexu

If you've dealt with similar Electron packaging headaches on Windows — or found a better approach — come talk to us on GitHub. That's what open source is for.

We Built an Open-Source OpenClaw Desktop Client That Fixes 17 Pitfalls

Joey Lee — Tue, 31 Mar 2026 12:46:06 +0000

If you've deployed OpenClaw in production, you've probably hit at least a few of these — and may not even realize it:

Context window silently truncates — response quality tanks and you don't know why
Some channel plugins require a full restart on first connect
Slack quietly drops group messages — messages just vanish
Bedrock returns 400 because of supportsStore
Default Docker image is 660MB and cold-starts in minutes

We've been running OpenClaw for months and hit all 17 known pitfalls. So we built Nexu — an open-source desktop client that auto-fixes every one of them. Double-click to install, no Docker, no CLI, no YAML.

The 500-Line Config Compiler

At Nexu's core is a 500-line config compiler that automatically generates correct OpenClaw configuration, with all 17 pitfalls pre-patched.

Context: Not Bigger, Smarter

OpenClaw's default context handling brutally truncates when the window fills up. Nexu's compiler injects a safeguard context compression strategy: auto-retry when quality drops instead of silently truncating. It allocates a 200K context window — 50% for conversation history, 20K token floor — and auto-archives old conversations to vector memory.

Channel-Specific Hacks

Channel preheat: pre-loads channel plugins at init so first connect does not require an extra restart
Slack groupPolicy: open: forced globally — group messages no longer silently swallowed
supportsStore: false: set globally to prevent Bedrock/LiteLLM 400 errors

Hot-Reload That Actually Works

Mixed hot-reload: small config changes hot-load instantly; large changes trigger a graceful restart. Zero user-perceived interruption in either case.

Cut in Half

We use a custom dependency closure algorithm that only bundles actually-used modules, cutting the packaged runtime footprint roughly in half compared to shipping full dependency trees. Every new 1MB dependency = 1MB added to the final package. We track this obsessively.

System-Level Process Guard

Not a child process — a macOS native LaunchAgent (system service). Crash auto-restart in 2s with exponential backoff (2s → 4s → 8s → 30s cap). Close the window, your workflows keep running. Reopen, instant re-attach. SIGTERM → 3s → SIGKILL — no zombie processes ever.

Anti-Sleep Guard

Intercepts 5 types of macOS power events. Lid closed, low battery, night — workflows keep processing without forcing screen awake.

Health Probe: 1000x Faster

4.8s → 1-3ms. Disconnect detection is now millisecond-level. No more waiting seconds to know your runtime is down.

10,000+ Skills, Hot-Install

29 curated skills pre-installed. Remote catalog with CDN, auto-synced every 24 hours. Install and use immediately — no restart required. Also supports ZIP file and GitHub repo import.

Channel-Specific Optimizations

Slack: fix for silent group message loss — groupPolicy: open enforced globally
Telegram: BotFather token flow — no self-hosted webhook server required
WhatsApp: QR scan to connect your account
Discord: native bot gateway with auto-reconnect
Feishu/Lark: 27 field types, streaming cards — strong for in-org workflows

Zero Barrier

Double-click to install. OAuth for Slack. QR scan for WhatsApp. BotFather token for Telegram. 10+ models switch without restart. No Docker, no database, no CLI. Universal macOS — Apple Silicon and Intel.

Try It

Download: github.com/nexu-io/nexu/releases

GitHub: github.com/nexu-io/nexu

Honest Limitations

Universal macOS — Intel + Apple Silicon (one .dmg each)
Single-user, no multi-tenant
Channel maturity: Slack and Discord most battle-tested. WhatsApp and Telegram freshly shipped (v0.1.8)

Open-source, MIT licensed. → GitHub Repo