Pocket Core AI

A few weeks after we started posting proof-of-privacy demos for Pocket Core AI, a message came in from a security consultant. He hadn't been prompted with a survey or a discount code — he'd just watched the USB Ghost Mode video and recognized his own problem in it.

The problem: AI he legally can't use

Security consultants spend most of their working hours on other people's machines. Client laptops, client networks, client data — all covered by confidentiality agreements that are usually explicit about one thing: nothing gets installed on the client's machine that wasn't already vetted and approved, and nothing about the engagement leaves the premises in a form the client didn't sign off on.

That rules out cloud AI almost entirely. Pasting a log file into ChatGPT to help triage it, or asking an AI to help draft part of a report, means sending client data to a third-party server outside the consultant's control — a straightforward confidentiality breach, regardless of whether the tool's privacy policy sounds reassuring. And even a "local" AI tool is a problem if installing it leaves an executable, a config file, or a cache sitting on a client's drive after the engagement ends.

So the actual requirement wasn't "cheaper AI" or "better AI." It was: AI that touches nothing on the host machine, that can be verified rather than taken on faith, and that leaves the client's system exactly as it was found.

Why USB Ghost Mode fit

Ghost Mode runs the entire Pocket Core AI app — chat, voice, everything — directly off a USB drive. There's no installer, no setup wizard, nothing written to the host machine's disk at any point. Unplug the drive at the end of the day, and the laptop is back to exactly the state it was in before.

That's a claim, though, and a security consultant is exactly the kind of person who doesn't take claims at face value — which is part of why this story is worth telling in the first place. The proof we now show (and that first caught his attention) is:

• A full-machine search for "Pocket Core" after the drive is unplugged — every folder, every drive, whole-system scope — returning zero results.

• A Process Monitor log, filtered to the host disk only (excluding the USB drive itself), covering the entire session — showing zero file writes to the machine for the full time the app was running.

Both of those are things a consultant can run himself, on his own equipment, rather than trust in a video. That's the detail that made this land — not "we don't track you," but "here's how you check that we don't."

What it actually changes for him

For a working security consultant, this turns AI from something he has to leave outside a client engagement into something he can bring to it. No separate install-and-uninstall cycle per client machine, no residual files to explain in an audit, no confidentiality risk from a chat log sitting on someone else's server. The drive goes in his bag between jobs like any other tool.

He's not alone in this either — the same shape of problem showed up independently from a doctor working under hospital IT policy, a lawyer on a client's computer, and a journalist on a laptop her employer monitors. Different professions, same underlying constraint: not "I'd prefer not to use cloud AI," but "I am not permitted to."

Try it yourself

If your work puts you on machines you don't control, under confidentiality rules that don't bend, this is the exact use case Pocket Core AI's USB Ghost Mode was built for — and you don't have to take a video's word for it either. Every tier ships with a 30-day money-back guarantee, so you can run the same full-machine search and Process Monitor check on your own hardware before deciding it's real.

For consultants and firms outfitting a whole team, the Team tier ($249, 5 seats) is the natural fit. Solo practitioners can start with Pro ($89) or grab a pre-loaded Flash Drive ($149) if you'd rather not set one up yourself.

Try Pocket Core AI →

After several months of building, Pocket Core AI ships with four local AI inference pipelines in a single desktop app. Here's how it's actually structured for anyone attempting something similar.

THE ARCHITECTURE PROBLEM

The core challenge: four completely different AI frameworks need to coexist in one app and run across Windows, macOS, and Linux without requiring the user to install Python, CUDA, or any other dependency.

Most guides cover one model or one framework. Nobody writes about shipping four together.

THE SOLUTION: ELECTRON + PYINSTALLER

The app is split into two processes:

1. Electron shell (Node.js)

   • Handles the UI (HTML/CSS/JS)

   • Spawns the Python backend as a child process

   • Communicates via HTTP to localhost

2. Python FastAPI backend

   • Bundled via PyInstaller into a single executable

   • Exposes REST endpoints for all AI operations

   • Manages model loading and inference

The PyInstaller build includes:

• llama.cpp Python bindings (chat inference)

• diffusers + torch (FLUX.1 image generation)

• ONNX runtime (Kokoro TTS)

• XTTS-v2 dependencies (voice cloning)

• FastAPI + uvicorn (the server itself)

• newspaper3k, beautifulsoup4 (web content)

• All hidden imports specified in .spec file

The resulting backend executable is large (1.5-2.5GB depending on platform) but the user sees none of this complexity.

THE USB GHOST MODE IMPLEMENTATION

When the app detects it's running from removable media, it redirects all data paths:

Windows detection: import wmi c = wmi.WMI() for disk in c.Win32_LogicalDisk(): if disk.DeviceID == drive_letter: is_removable = (disk.DriveType == 2)

macOS detection: diskutil info [mount_point] | grep "Removable Media"

Linux detection: Parse /proc/mounts, check /sys/block/[device]/removable

Once detected, all data paths redirect to the USB drive. The host filesystem is never touched. Verified with Process Monitor — zero file operations on host drive during a full session.

THE CROSS-PLATFORM BUILD PROBLEM

PyInstaller cannot cross-compile. A Windows PyInstaller build produces a Windows binary. A Linux build produces a Linux binary.

Solution: GitHub Actions matrix with three jobs:

• windows-latest runner builds the Windows installer

• macos-latest runner builds the macOS DMG

• ubuntu-latest runner builds the Linux AppImage

Each runner builds the PyInstaller backend for its platform, then packages it with electron-builder.

Challenge we hit: the ubuntu-latest runner has ~14GB free disk space. Our ML stack (torch, diffusers, TTS, etc.) plus PyInstaller output fills it.

Fix: add a disk cleanup step at the start of the Linux job:

sudo rm -rf /usr/share/dotnet sudo rm -rf /usr/local/lib/android sudo rm -rf /opt/ghc sudo apt-get clean docker system prune -af

This frees ~20GB and gives enough headroom.

THE MODEL BUNDLING STRATEGY

Not all models bundle the same way:

Kokoro TTS (~300MB): bundled with the app. Fast to download, small enough to ship.

FLUX.1-schnell (~8GB quantised): downloaded on first use via huggingface_hub.snapshot_download() with a progress UI. Too large to bundle.

XTTS-v2 (~1.8GB): downloaded on first use of voice cloning.

llama.cpp models (4-20GB): user selects on first launch. We ship a model download manager that fetches the appropriate GGUF file from Hugging Face based on the user's available RAM.

DEPENDENCY CONFLICTS WE HIT

The most painful: misaki version conflict.

requirements.txt had misaki==0.7.4 kokoro 0.7.16 requires misaki>=0.7.16

pip resolution fails silently in some environments and loudly in CI. Fix: update misaki to >=0.7.16 and pin kokoro to the minimum compatible version.

WHAT I WISH I KNEW EARLIER

1. Test PyInstaller on a completely clean VM before shipping. Hidden imports that work in your dev environment silently fail in a bundled executable.

2. XTTS-v2 has a memory leak on long inference sessions. Reinitialise the model every 50 generations as a workaround.

3. GPU detection should happen at startup, not at model load time. Users want to know immediately if their GPU will be used.

4. The Kokoro ONNX runtime and PyTorch (used by FLUX and XTTS) have conflicting CUDA library requirements on some systems. Run them in the same process but initialise ONNX before PyTorch.

Happy to answer technical questions about any of these. The implementation was messy in places — I'm sharing the real version, not a cleaned-up retrospective.

getpocketcore.com

Five days ago I launched Pocket Core AI at getpocketcore.com. This is an honest account of what happened.

THE PRODUCT

Pocket Core AI is a desktop app that runs four AI capabilities completely offline — no internet connection required during use:

• AI chat (Llama 3 / Phi-4, uncensored)

• Image generation (FLUX.1-schnell)

• Text to speech (Kokoro-82M, 10 voices)

• Voice cloning (XTTS-v2, 6 seconds → 17 languages)

Plus a USB Ghost Mode that runs the entire app from a flash drive and leaves zero trace on the host machine.

One-time pricing: $49 Starter / $89 Pro / $249 Team / $149 Flash Drive.

No subscription. Ever.

WHY I BUILT IT

I was paying $129/month across three AI tools:

• ChatGPT Plus: $20/month

• ElevenLabs: $99/month (voice cloning)

• Midjourney: $10/month

All three had the same problems:

1. They read everything I type

2. They refused legitimate research questions

3. They stopped working without internet

4. They could raise prices whenever they wanted

So I spent 6 months building the offline version of all three combined.

THE STACK

For anyone technical:

• Electron shell + Python FastAPI backend

• llama.cpp for local inference

• FLUX.1-schnell via diffusers (images)

• Kokoro-82M via ONNX (TTS)

• XTTS-v2 (voice cloning)

• SearXNG client (optional web search)

• Hardware fingerprint + JWT (licence binding)

• Railway (licence server) + Resend (email)

• Hostinger Horizons (website)

• PayPal (payments)

• Cloudflare R2 (file hosting)

Built by me, alone. Based in South Africa.