DEV Community: PocketCoreAI

PHP2Shell: What PHP Developers Should Do After the Critical October 2026 Security Releases

PocketCoreAI — Thu, 22 Oct 2026 09:47:42 +0000

Two critical PHP vulnerabilities were disclosed on October 21, 2026. If you maintain a PHP application, here's how to check your runtime, patch safely, and avoid turning an urgent security update into a production incident.

The PHP team has released security updates for two vulnerabilities that can allow unauthenticated remote code execution on affected systems.

The vulnerabilities are:

CVE-2026-109618

CVE-2026-109619

Both have a CVSS v4.0 score of 9.2 and have been associated with the name PHP2Shell.

The official PHP advisory is here: https://www.php.net/archive/2026.php

The key takeaway is straightforward: identify every affected PHP deployment and apply the appropriate security update immediately.

The more complicated part is making sure the fix reaches the PHP runtime actually serving production traffic.

Which PHP versions are affected?
The PHP project has published the following fixed releases:

PHP 8.1 and earlier are no longer supported upstream. Some operating-system vendors and long-term-support providers may offer backported security fixes, so check the guidance for your specific environment.

Don't assume that running an older version automatically means you must rewrite your application. The immediate priority is to establish whether your actual runtime has the necessary security fix, then plan any broader upgrade work that is required.

Understand what you're patching

These vulnerabilities affect PHP's runtime rather than a single application framework.

According to the PHP security advisory, one vulnerability involves unsafe handling of an out-of-memory condition, while the other involves stale internal state referencing memory that has already been freed.

Under exploitable conditions, these issues can lead to remote code execution.

This distinction matters because upgrading a Laravel package or changing application-level validation rules does not, by itself, fix a vulnerability in the PHP runtime.

Likewise, a well-written application is not automatically protected if it runs on a vulnerable PHP build.

The correct remediation depends on your runtime, operating system, hosting platform, and deployment process.

*Check the PHP version you actually run
*
Start with the command-line PHP installation:

php -v

You should see the installed CLI version.

For example:

PHP 8.4.27 (cli)

However, there's an important catch: the CLI version may not be the version serving web requests.

A server can have multiple PHP installations. Your terminal may use one version while PHP-FPM, Apache, a container, or a managed hosting service uses another.

Check the relevant deployment configuration and confirm the runtime used by your application.

For PHP-FPM, inspect the service and pool configuration for the relevant PHP version. For Docker-based applications, inspect the image and rebuild configuration. For managed platforms, consult the provider's runtime documentation.

Avoid exposing a public diagnostic endpoint containing phpinfo() just to check a version. If you use one temporarily in a controlled environment, remove it immediately afterward.

Patch the runtime and redeploy

For a directly managed installation, use the appropriate patched package supplied by your operating-system vendor or update your PHP build according to the official instructions.

On container-based deployments, updating PHP on your laptop or host does not update an image that has already been deployed.

A typical workflow looks like this:

# Inspect the current CLI runtime
php -v

# Inspect PHP dependencies
composer check-platform-reqs

# Run your project's test suite
# Use the test command defined by your project

These commands are diagnostic and validation steps, not a complete patching procedure. The actual runtime update depends on your operating system, package manager, container image, and deployment platform.

After updating, rebuild affected images or packages and redeploy the application where required.

Restart the relevant workers or services if your platform requires it, then verify that the running processes use the patched runtime.

For managed hosting, ask the provider to confirm whether the fix has been applied to your specific application.

Don't confuse a runtime patch with an application upgrade

This is where legacy applications can become difficult to maintain.

Imagine a Laravel application that has been running successfully for years. Its dependencies were installed under an older PHP version, automated test coverage is incomplete, and the original developers are no longer available.

The team may need to move to a supported runtime, but the application may rely on outdated packages or behaviours that have changed between PHP versions.

That does not mean the security fix should be delayed unnecessarily. It means the team needs to distinguish between two related tasks:

Immediate remediation: Get the appropriate security fix into the running environment.

Longer-term modernization: Address unsupported runtimes, incompatible dependencies, framework constraints, and application code that prevents safe upgrades.

Sometimes the first task is straightforward. Sometimes the second requires a carefully planned migration.

Keeping those tasks separate helps teams prioritize the security response without losing sight of their underlying technical debt.

A practical deployment checklist

Before considering the incident resolved, work through the following:

Inventory PHP applications, servers, containers, and background workers.
Confirm the PHP version serving each application.
Check whether the runtime has the appropriate security fix.
Apply the vendor-supported patch or upgrade.
Rebuild and redeploy container images where necessary.
Restart affected services or workers when required.
Verify the runtime version after deployment.
Run automated tests and validate critical application workflows.
Review logs and investigate suspicious activity if exposure may have occurred.
Document the fix and identify any remaining unsupported components.

If immediate remediation is not possible, follow the official advisory and your security team's incident-response guidance. Temporary controls may reduce exposure, but they are not a substitute for installing the appropriate fix.

What about Composer and Laravel?

Composer helps manage application dependencies, but updating Composer packages alone does not patch the PHP engine.

You should still check platform requirements and dependency compatibility when planning a runtime upgrade.

Useful commands include:

composer check-platform-reqs
composer outdated

The first checks whether the current PHP and extensions satisfy the installed packages' requirements. The second helps identify packages with newer releases, but it does not tell you that every update is safe or necessary.

Review the output before making changes. Updating every dependency at once during an urgent security incident can introduce unrelated risks.

For Laravel applications, also verify that your Laravel version and third-party packages support your target PHP version.

Run the test suite, inspect deprecation warnings, and validate important workflows in staging before deploying application-level changes.

What should you do if your application is too old to upgrade easily?

This is a common problem for business-critical software.

An application can continue working for years even when its framework, dependencies, or runtime are approaching the end of their supported lifetimes.

The difficulty often isn't knowing that an upgrade is necessary. It's understanding how much needs to change and how to prove that the updated application still works.

A sensible approach is to:

Establish the current runtime and framework versions.

Identify unsupported dependencies and compatibility constraints.

Define a supported target version.

Make the smallest safe set of changes needed to reach that target.

Test the resulting application and document any remaining risks.

You do not necessarily need to rewrite a working application from scratch.

For teams that need help with this process, Unstale focuses on modernizing existing codebases through tested upgrade pull requests.

You can also read the PHP 8.2 to 8.4 upgrade guide for more on compatibility challenges involved in moving between PHP versions.

Final thoughts

PHP2Shell is a reminder that application security depends on more than writing secure code. It also depends on maintaining the runtime, keeping dependencies supported, and being able to deploy fixes quickly.

Start by verifying your production runtime and applying the appropriate security update. Then use the incident as an opportunity to identify older applications that are becoming increasingly difficult to maintain.

The goal is not to make every application undergo a major migration after every security advisory.

It's to make sure that when the next critical update arrives, you can respond confidently rather than discovering that your production codebase has become too fragile to change.

Useful references

Official PHP security advisory

PHP releases and downloads

Unstale PHP upgrade guide

Unstale.dev

This article is for general technical information and is not a substitute for the official security advisory or a review of your specific deployment.

How I Actually Prove an Offline App Is Offline (Not Just Trust the Marketing)

PocketCoreAI — Thu, 15 Oct 2026 06:43:16 +0000

"Runs offline" is the easiest claim in software to make and one of the least frequently checked. I build an offline AI app, so I'm on the hook for the claim — here's the testing I actually run, which is the same thing you could run against anything else that claims it.

1. Disable the network adapter, not just Wi-Fi.
Airplane mode and the Wi-Fi toggle leave more running than people assume, and on a laptop with an ethernet port you've only closed one door. Disabling the adapter in the OS is the version that's actually airtight, and it's the one I film.

2. Watch the filesystem, not the app.
On Windows, Process Monitor filtered to the process plus the host drive, running for a whole session, tells you what the app wrote and where. On macOS, sudo fs_usage does the equivalent. This catches the thing a network check doesn't: an app that writes cached data, logs or model files somewhere you didn't expect, which matters a lot if the selling point is portability with no trace left behind.

3. Search the whole machine after unplugging.
Full-disk filename and content search for anything the app might have left — config folders, temp directories, registry entries on Windows. Zero results is the only passing grade. Someone did this to my app before buying it and told me afterwards, which is exactly the right instinct.

4. Check it in a state you didn't design for.
The interesting failures aren't in the happy path. Launch it with no network at all from a cold boot, rather than disconnecting after it's already running and warm — plenty of software quietly fetches what it needs on first launch and then appears to work offline forever after.

What I got wrong first time:
I tested on my own development machine, which had every model file already downloaded and every dependency already resolved. It proved nothing. The test only means something on a machine that has never seen the app before, which is why the video version of this is filmed on a different laptop.

Why bother being this strict about it?
Because the people who care about offline AI are, by definition, people who check. The security consultant who messaged me about this app had already run his own trace search before he got in touch. If the claim doesn't survive that, it was never worth making.

If you've got a sharper method than the four above — particularly for catching network calls a process makes before you've started watching it — I'd like to hear it.

The app, if you want to run these tests against it yourself: getpocketcore.com

I Tracked Every AI Subscription I Was Paying For — Here's What It Actually Added Up To

PocketCoreAI — Thu, 08 Oct 2026 07:08:37 +0000

Like a lot of people building with AI daily, I was paying for it in pieces — a chat subscription here, an image generation credit pack there, a voice API key somewhere else — and had never once put all of it in one place to see the real total. So, I did, and I'm sharing the actual process, not just the number.

The tracking method: nothing fancy — a single spreadsheet, one row per tool, columns for monthly cost, what tier I was actually on, and a rough estimate of how much of that tier I was actually using versus paying for unused headroom. The unused-headroom column is the one that mattered most; it's easy to know what you're paying and never check whether you're using enough of it to justify the tier.

The finding that changed my own habits most wasn't the total — it was where the waste actually was. It wasn't "I use AI too much." It was specific, fixable behavior: defaulting to the most expensive model tier for tasks that didn't need it, letting chat threads run long instead of starting fresh ones (every message in a thread gets re-sent to the model in full on every new message — a genuinely under-known mechanic), and never checking whether my actual usage still matched the tier I'd signed up for months earlier.

The part worth building, if you want to do this properly instead of a one-time spreadsheet pass: most platforms expose usage via their API or a billing dashboard export — a small script that pulls each tool's usage on a schedule and drops it into one sheet would turn this from a one-time audit into an ongoing check, the same category of problem as the weekly performance-pull.py script I've written about before on this account. Haven't built this yet myself; if you have, I'd genuinely like to see how you approached it.

What I did with the finding: moved my own daily-use AI (chat, image generation, voice cloning) off the metered model entirely, onto something that runs locally on my own hardware for a one-time cost instead. That's obviously the product I build and sell, so take that with the appropriate grain of salt — but the actual audit process above is genuinely tool-agnostic and worth doing whatever you land on afterward.

Full breakdown, with nine other tips that don't require switching anything:

Pocket Core AI – Private Offline AI | Chat, Images, TTS & Voice Cloning | From $49

Run AI completely offline on your laptop, phone, or USB drive. AI chat, image generation, TTS, and voice cloning. One-time purchase from $49.

getpocketcore.com

Two Months, Zero Sales, and the Bug Wasn't a Bug: Diagnosing a Dead Funnel

PocketCoreAI — Thu, 17 Sep 2026 06:36:44 +0000

Two months of content across seven platforms, real engagement, real traffic to a real website — and zero sales, the entire time. Here's what the actual diagnosis looked like, because "check your funnel" is easy advice and useless without the specifics.

The number I was tracking was measuring the wrong thing.
For weeks, the conversion metric I watched was Gumroad's own store-view dashboard: views up, sales flat at zero. The actual fix turned out to be upstream of that number entirely — a direct review of the live site found the real checkout isn't Gumroad at all. It's an embedded PayPal Buttons integration, built directly into the page during a later site rebuild, with zero remaining links to Gumroad anywhere on the site or in any campaign UTM link. I'd been optimizing against a dashboard that had quietly stopped being the real measurement weeks earlier.

The real number was worse, and also cleared something up. PayPal's own transaction history: zero, all-time. Not zero this month — zero since the checkout has existed. That sounds like the worst possible finding, but it actually ruled something out: a real end-to-end test purchase (my own money, my own laptop) confirmed the entire payment chain works — PayPal charges the card, the licence server's webhook fires, the licence email arrives, the download works. So this isn't a hidden technical failure. It's a genuine, if stark, traffic-and-conversion problem, and that's a much more useful thing to know than "something's broken somewhere."

Website analytics answered the harder question: is anyone even arriving?
Three weeks of Cloudflare data showed 380 total page views, and zero of them attributed to any social platform as a referrer. Almost all of it was internal navigation plus a page-builder's own preview-link traffic (worth checking early — a preview URL from your site builder showing up in referrer data isn't real audience traffic, it's you testing your own changes). That ruled out "the checkout is scaring people off" as the leading theory, because barely anyone was reaching the checkout at all.

A stranger found two real friction points a dashboard can't show you. One outside tester, watching them try to buy without any prompting: the checkout opened as a small centered popup rather than anything that read as a dedicated checkout screen, and the site's own header was cluttered enough (8 nav links, 6 social icons) that where to even start wasn't obvious. Neither of those shows up in analytics as anything specific — they just look like a slightly lower conversion rate you can't attribute to anything.

What actually got fixed, in order of leverage: broken links on the highest-performing content (a video's best-performing format had a description link that wasn't actually hyperlinked — completely invisible in every other metric), a positioning mismatch between the homepage's hero copy and the campaign's actual audience, and then the two UX findings above — redesigned as a proper checkout panel and a decluttered header, without touching the payment integration underneath either.

The pattern worth taking away: a metric that used to be accurate can silently stop being accurate after literally anything changes underneath it — a site rebuild, a tool migration, a rebrand — and nothing tells you that happened except checking the live thing directly instead of trusting the dashboard that's always been "the number." I'd been doing the latter for weeks.

If you want to see what the actual fixed funnel looks like: https://getpocketcore.com/

Automating a Weekly Marketing-Analytics Pull Across 7 Platforms (and What Broke Immediately)

PocketCoreAI — Thu, 10 Sep 2026 06:54:12 +0000

I wanted one script that pulls a week's worth of marketing performance data — Gumroad sales, YouTube views, Dev.to stats, Product Hunt votes, Hacker News mentions, Pinterest and Instagram engagement — into a single markdown report I could review every Monday instead of manually checking seven dashboards. Here's what worked immediately, what didn't, and why.

What worked with almost no friction: Gumroad's sales API, YouTube Data API v3, Dev.to's own API, and the Algolia-powered Hacker News search API. All four are either keyless (HN) or a five-minute token generation away, and all four returned clean, predictable JSON on the first real request.

What broke immediately: Pinterest and Instagram. Pinterest's v5 API gated most useful endpoints behind an approved "Standard Access" application tier — a plain access token gets you a 401 with a message pointing at their support team, not the endpoint. Instagram's Graph API needs a long-lived token minted through a Facebook Developer app linked to a converted Business/Professional account and a Facebook Page — there's no shortcut, and a malformed or expired token fails with a generic "Cannot parse access token" error that gives you almost nothing to debug from.

The design choice that mattered most: every platform pull is wrapped independently, and a failure in one (missing credentials, an API error, an auth failure) logs a line and moves on rather than crashing the whole run. Marketing automation scripts get run unattended or by someone non-technical — a single broken credential shouldn't mean zero data instead of six-sevenths of the data.

What I'd tell someone building the same thing: budget real setup time for Pinterest and Instagram specifically if you want them included — they're not "add an API key" integrations like the others, they're "apply for access and wait" integrations. Build and ship the script with the easy platforms first rather than blocking the whole automation on the slow ones.

If you're curious what this actually surfaces: two weeks of real data already showed something worth acting on — a piece of Short-form video content that looked like a 50x outperformer against long-form on a partial-week pull turned out to be closer to 3x once a full week of data came in. Automating the pull is only half the value; not overreacting to a partial window is the other half.

How I Run a Full AI Studio Off a USB Drive With Zero Disk Writes

PocketCoreAI — Thu, 03 Sep 2026 06:44:57 +0000

Most "portable" software still isn't actually portable — it writes config files to %APPDATA%, drops a cache somewhere in the user profile, or registers itself in the Windows registry even when you run it from a flash drive. For Pocket Core AI's USB Ghost Mode, none of that was acceptable, because the entire feature only means something if it's verifiably true, not just technically true.

Here's the actual constraint I built against: after unplugging the drive, a full-machine search for any trace of the app returns zero results, and a Process Monitor log filtered to the host drive (excluding the USB drive itself) shows zero write operations for the entire session, no matter how long the app ran or what was done in it.

What that ruled out:

Any use of the OS temp directory for anything that outlives the process — had to redirect all temp file handling to a path on the USB drive itself, not the system default
Any registry writes on Windows — no install-time registration, no "recently used" entries, nothing Electron's default userData path, which normally lives in the user profile — repointed to the drive
Any local model cache falling back to a system-wide location — voice models, embeddings, everything reads and writes only from paths under the drive's own root

What that required:

Explicit app.setPath() overrides for every Electron-managed path (userData, cache, temp, logs) before any other initialization code runs
Auditing every dependency (the TTS engine, the local model runtime) for its own default cache/config behavior — several assume a writable home directory exists and fail silently if you don't redirect them first
A startup check that fails loudly rather than falling back to a default path if the drive itself isn't writable, so there's never a silent "oh, it wrote to C:\ instead" failure mode

How it's verified, not just claimed: every public demo of this feature ends with the actual test — full-machine search post-unplug, Process Monitor log across the session, both run live on camera rather than described. That verification step turned out to matter more to actual buyers than the technical achievement itself; the professionals this feature is built for (security consultants, people under NDA-heavy client work) don't take portability claims at face value and shouldn't.

If you're building something that claims to be portable, the test I'd suggest: don't trust your own assumptions about what "portable" frameworks handle for you by default. Redirect every path explicitly, then verify with the same tools a skeptical user would use.

If you want to see the actual test run live (including on a machine I don't own), I posted the full video here:

Cross-lingual voice cloning with XTTS-v2: implementation notes, quality observations, and a memory leak you should know about

PocketCoreAI — Mon, 24 Aug 2026 06:01:00 +0000

INTRO

XTTS-v2 is the best open-source voice cloning model available in 2026. It produces cross-lingual output — take 6 seconds of English audio, generate speech in Japanese, Arabic, or Spanish using the same vocal characteristics. It runs entirely locally with no API required.

It is also significantly under-documented for production desktop application deployment.

I built XTTS-v2 into Pocket Core AI — an offline AI desktop app — and hit every sharp edge it has. This post covers what I learned: the pipeline, the quality observations across languages, the chunking strategy for long texts, and the memory leak that will bite you in production if you don't know about it.

If you're evaluating XTTS-v2 for local deployment, this is the post I wish existed when I started.

HOW CROSS-LINGUAL TRANSFER ACTUALLY WORKS

XTTS-v2 separates voice identity from language content using a speaker encoder.

When you provide reference audio, the model extracts a speaker embedding — a high-dimensional vector representing the vocal characteristics of that voice. This captures timbre, rhythm, and prosody independently of the phoneme content.

The synthesis step conditions on both:

The speaker embedding (who is speaking)
The target language phonemes (what they say)

This is why cross-lingual transfer works: the speaker identity is encoded separately from the language. You can apply any speaker embedding to any language's phoneme sequence.

In practice the quality of cross-lingual transfer varies significantly by language family — more on that below.

THE BASIC PIPELINE

python
# core/voice_cloner.py

import os
import io
import base64
import hashlib
import tempfile
from pathlib import Path
from pydub import AudioSegment
import soundfile as sf
import numpy as np

class VoiceCloner:
    def __init__(self, model_path: str = None):
        self.model = None
        self.model_path = model_path
        self.generation_count = 0
        self.MAX_GENERATIONS_BEFORE_REINIT = 50
        self._supported_languages = [
            'en', 'es', 'fr', 'de', 'it', 'pt',
            'pl', 'tr', 'ru', 'nl', 'cs', 'ar',
            'zh-cn', 'ja', 'ko', 'hu', 'hi'
        ]

    def _load_model(self):
        """Load XTTS-v2. Deferred until first use."""
        from TTS.api import TTS
        import torch

        device = "cuda" if torch.cuda.is_available() else \
                 "mps" if torch.backends.mps.is_available() else \
                 "cpu"

        if self.model_path:
            self.model = TTS(
                model_path=self.model_path,
                config_path=os.path.join(self.model_path, "config.json")
            ).to(device)
        else:
            self.model = TTS(
                "tts_models/multilingual/multi-dataset/xtts_v2"
            ).to(device)

        self.generation_count = 0

    def _ensure_model_ready(self):
        """
        Load or reinitialise the model.
        Reinitialisation every 50 generations 
        works around the memory leak.
        """
        if self.model is None:
            self._load_model()
            return

        if self.generation_count >= self.MAX_GENERATIONS_BEFORE_REINIT:
            self._reinitialise()

    def _reinitialise(self):
        """
        Reinitialise model to clear leaked memory.
        Do NOT skip this in production.
        """
        import gc
        import torch

        del self.model
        self.model = None
        gc.collect()

        if torch.cuda.is_available():
            torch.cuda.empty_cache()
        elif hasattr(torch.backends, 'mps') and \
             torch.backends.mps.is_available():
            # MPS doesn't have explicit cache clearing
            # gc.collect() handles most of it
            pass

        self._load_model()

    def preprocess_audio(self, audio_path: str) -> str:
        """
        Convert any audio format to 22050Hz mono WAV.
        XTTS-v2 requires this exact format.
        Returns path to processed WAV file.
        """
        audio = AudioSegment.from_file(audio_path)

        # Convert to mono
        if audio.channels > 1:
            audio = audio.set_channels(1)

        # Resample to 22050Hz
        audio = audio.set_frame_rate(22050)

        # Validate minimum duration
        duration_seconds = len(audio) / 1000.0
        if duration_seconds < 3.0:
            raise ValueError(
                f"Reference audio too short: {duration_seconds:.1f}s. "
                f"Minimum 3 seconds required. "
                f"15-20 seconds recommended for best quality."
            )

        if duration_seconds < 8.0:
            # Warn but don't block — short audio works, just worse
            print(f"Warning: {duration_seconds:.1f}s reference audio. "
                  f"Quality improves significantly above 15 seconds.")

        # Export to temp WAV
        temp_wav = tempfile.mktemp(suffix='.wav')
        audio.export(temp_wav, format='wav')
        return temp_wav

    def chunk_text(self, text: str, 
                   max_chars: int = 250) -> list[str]:
        """
        Split text at sentence boundaries.
        XTTS-v2 has a ~300 character practical limit.
        We use 250 to leave headroom.
        """
        import spacy

        # Load spacy model — en_core_web_sm is sufficient
        try:
            nlp = spacy.load("en_core_web_sm")
        except OSError:
            # Fallback: split on punctuation
            return self._simple_chunk(text, max_chars)

        doc = nlp(text)
        chunks = []
        current_chunk = ""

        for sent in doc.sents:
            sent_text = sent.text.strip()

            if len(current_chunk) + len(sent_text) <= max_chars:
                current_chunk += (" " if current_chunk else "") + sent_text
            else:
                if current_chunk:
                    chunks.append(current_chunk)
                # If single sentence exceeds max_chars,
                # split it at word boundaries
                if len(sent_text) > max_chars:
                    chunks.extend(
                        self._simple_chunk(sent_text, max_chars)
                    )
                else:
                    current_chunk = sent_text

        if current_chunk:
            chunks.append(current_chunk)

        return [c for c in chunks if c.strip()]

    def _simple_chunk(self, text: str, 
                      max_chars: int) -> list[str]:
        """Fallback chunker — splits at word boundaries."""
        words = text.split()
        chunks = []
        current = ""

        for word in words:
            if len(current) + len(word) + 1 <= max_chars:
                current += (" " if current else "") + word
            else:
                if current:
                    chunks.append(current)
                current = word

        if current:
            chunks.append(current)

        return chunks

    def join_audio_chunks(self, 
                          chunks: list[np.ndarray],
                          sample_rate: int = 24000,
                          silence_ms: int = 150) -> np.ndarray:
        """
        Join audio chunks with natural silence between them.
        XTTS-v2 output is 24000Hz.
        """
        silence_samples = int(sample_rate * silence_ms / 1000)
        silence = np.zeros(silence_samples)

        parts = []
        for i, chunk in enumerate(chunks):
            parts.append(chunk)
            if i < len(chunks) - 1:
                parts.append(silence)

        return np.concatenate(parts)

    def clone(
        self,
        text: str,
        reference_audio_path: str,
        language: str = 'en',
        speed: float = 1.0
    ) -> dict:
        """
        Main voice cloning method.
        Returns dict with audio_base64 and duration_seconds.
        """
        if language not in self._supported_languages:
            raise ValueError(
                f"Language '{language}' not supported. "
                f"Supported: {self._supported_languages}"
            )

        self._ensure_model_ready()

        # Preprocess reference audio
        processed_ref = self.preprocess_audio(reference_audio_path)

        try:
            # Split text into chunks
            text_chunks = self.chunk_text(text)

            if not text_chunks:
                raise ValueError("Text is empty after processing")

            # Generate audio for each chunk
            audio_chunks = []

            for chunk in text_chunks:
                wav = self.model.tts(
                    text=chunk,
                    speaker_wav=processed_ref,
                    language=language,
                    speed=speed
                )
                audio_chunks.append(np.array(wav))

            # Join chunks with silence
            if len(audio_chunks) == 1:
                final_audio = audio_chunks[0]
            else:
                final_audio = self.join_audio_chunks(audio_chunks)

            # Convert to WAV bytes
            buffer = io.BytesIO()
            sf.write(buffer, final_audio, 24000, format='WAV')
            audio_bytes = buffer.getvalue()

            # Base64 encode for API response
            audio_b64 = base64.b64encode(audio_bytes).decode('utf-8')

            duration = len(final_audio) / 24000.0

            self.generation_count += 1

            return {
                "audio_base64": audio_b64,
                "duration_seconds": round(duration, 2),
                "chunks_processed": len(text_chunks),
                "language": language
            }

        finally:
            # Always clean up temp file
            if os.path.exists(processed_ref):
                os.remove(processed_ref)

    def get_supported_languages(self) -> list[dict]:
        """Return language list with metadata."""
        language_info = {
            'en': {'name': 'English', 'accent': 'American', 
                   'quality': 'excellent'},
            'es': {'name': 'Spanish', 'accent': 'Neutral', 
                   'quality': 'excellent'},
            'fr': {'name': 'French', 'accent': 'French', 
                   'quality': 'excellent'},
            'de': {'name': 'German', 'accent': 'German', 
                   'quality': 'very good'},
            'it': {'name': 'Italian', 'accent': 'Italian', 
                   'quality': 'very good'},
            'pt': {'name': 'Portuguese', 'accent': 'Brazilian', 
                   'quality': 'very good'},
            'pl': {'name': 'Polish', 'accent': 'Polish', 
                   'quality': 'good'},
            'tr': {'name': 'Turkish', 'accent': 'Turkish', 
                   'quality': 'good'},
            'ru': {'name': 'Russian', 'accent': 'Russian', 
                   'quality': 'good'},
            'nl': {'name': 'Dutch', 'accent': 'Dutch', 
                   'quality': 'good'},
            'cs': {'name': 'Czech', 'accent': 'Czech', 
                   'quality': 'good'},
            'ar': {'name': 'Arabic', 'accent': 'MSA', 
                   'quality': 'moderate'},
            'zh-cn': {'name': 'Chinese', 'accent': 'Mandarin', 
                      'quality': 'moderate'},
            'ja': {'name': 'Japanese', 'accent': 'Standard', 
                   'quality': 'moderate'},
            'ko': {'name': 'Korean', 'accent': 'Standard', 
                   'quality': 'moderate'},
            'hu': {'name': 'Hungarian', 'accent': 'Hungarian', 
                   'quality': 'good'},
            'hi': {'name': 'Hindi', 'accent': 'Standard', 
                   'quality': 'moderate'},
        }
        return [
            {'code': code, **info}
            for code, info in language_info.items()
            if code in self._supported_languages
        ]

THE MEMORY LEAK — WHAT IT IS AND WHY IT HAPPENS

If you run XTTS-v2 in a long-running process and generate audio hundreds of times, you will eventually see your process consuming multiple gigabytes of RAM that it never releases.

This is a known issue in the XTTS-v2 / Coqui TTS library related to how PyTorch tensors accumulate in the speaker encoder cache across inference calls.

The symptom: RAM usage grows steadily from ~2GB at startup to 6-8GB+ after several hundred generations, then the process crashes or becomes unusably slow.

The fix: Reinitialise the model periodically. Yes, this means recreating the TTS object and reloading weights. It takes 5-10 seconds. It completely clears the accumulated memory.

python
def _reinitialise(self):
    import gc
    import torch

    # Delete the model object
    del self.model
    self.model = None

    # Force garbage collection
    gc.collect()

    # Clear GPU cache
    if torch.cuda.is_available():
        torch.cuda.empty_cache()

    # Reload
    self._load_model()

We trigger this every 50 generations. For our use case (desktop app with human-paced usage), this means a reinitialisation roughly every few hours of heavy use. Users never notice it because the next generation just takes slightly longer than usual.

If you're building a high-throughput voice generation service, you'll want a more sophisticated approach — perhaps a pool of model instances you cycle through. For a desktop application, periodic reinitialisation is the pragmatic solution.

LANGUAGE QUALITY — HONEST ASSESSMENT

From English reference audio, here is the honest quality breakdown across language families:

Excellent (near-native quality):

Spanish, French, Italian, Portuguese

These share significant phoneme overlap with English and have similar prosody patterns. The cross-lingual transfer works cleanly.

Very Good (clearly intelligible, minor accent artifacts):

German, Dutch, Polish, Czech, Hungarian

Germanic and Slavic languages work well despite different phoneme sets. The rhythm and stress patterns transfer reasonably well.

Good (intelligible with noticeable synthetic quality):

Turkish, Russian

The speaker embedding transfers but the output has more obvious synthesis artifacts. Still usable for most content creation purposes.

Moderate (functional but clearly synthetic):

Japanese, Mandarin Chinese, Korean, Arabic, Hindi

These languages have fundamentally different phoneme inventories, tonal or pitch-accent systems, and prosody patterns. The voice identity transfers but the output quality is noticeably lower. For many use cases this is still adequate — particularly for long-form content where listeners adapt to the synthetic quality.

Quality improves with:

Longer reference audio (15-30 seconds vs 6 seconds minimum)
Multiple reference samples averaged together
Clean recording environment (quiet, no reverb)
Consistent speaking pace in the reference

INFERENCE TIMING ON REAL HARDWARE

These are measured times for generating approximately 20 seconds of audio output:

Hardware Time Notes
Apple M2 Pro (16GB) ~8s Via MPS
Apple M1 (8GB) ~14s Via MPS
Intel i7 + RTX 3070 ~2s Via CUDA
Intel i7 + RTX 3080 ~1.2s Via CUDA
Intel i7 (CPU only) ~55s No GPU
AMD Ryzen 7 + RX 6800 ~4s Via ROCm
Raspberry Pi 4 (8GB) ~8min Not viable

Key observations:

CPU-only inference is usable for short clips but becomes frustrating for long content. A dedicated GPU makes the experience dramatically better.

Apple Silicon via MPS is surprisingly good — an M2 Pro produces output faster than real-time, which means no waiting during normal usage.

CUDA inference is fast enough to feel instantaneous for conversational use.

AUDIO PREPROCESSING REQUIREMENTS

XTTS-v2 has specific requirements for reference audio that are not well documented:

python
REQUIRED_FORMAT = {
    "sample_rate": 22050,  # Hz — must be exact
    "channels": 1,          # Mono only
    "format": "wav",        # WAV container
    "bit_depth": 16,        # 16-bit PCM
    "min_duration": 3.0,    # seconds
    "recommended_duration": 15.0,  # seconds
}

The sample rate is particularly important. Submit audio at 44100Hz and you'll get degraded output without any error message. Always resample to 22050Hz before passing to the model.

We use pydub for preprocessing because it handles every input format through ffmpeg and makes sample rate conversion trivial:

python
from pydub import AudioSegment

def prepare_reference_audio(input_path: str) -> str:
    audio = AudioSegment.from_file(input_path)
    audio = audio.set_channels(1)           # Mono
    audio = audio.set_frame_rate(22050)     # Required sample rate
    audio = audio.set_sample_width(2)       # 16-bit

    output_path = input_path.rsplit('.', 1)[0] + '_processed.wav'
    audio.export(output_path, format='wav')
    return output_path

THE FASTAPI ENDPOINT

python
# In server.py

from fastapi import FastAPI, UploadFile, File, Form
from fastapi.responses import JSONResponse
import tempfile
import os

voice_cloner = VoiceCloner()

@app.post("/api/clone-voice")
async def clone_voice_endpoint(
    text: str = Form(...),
    language: str = Form(default='en'),
    speed: float = Form(default=1.0),
    reference_audio: UploadFile = File(...)
):
    # Save uploaded audio to temp file
    suffix = os.path.splitext(reference_audio.filename)[1]
    with tempfile.NamedTemporaryFile(
        suffix=suffix, delete=False
    ) as tmp:
        content = await reference_audio.read()
        tmp.write(content)
        tmp_path = tmp.name

    try:
        result = voice_cloner.clone(
            text=text,
            reference_audio_path=tmp_path,
            language=language,
            speed=speed
        )
        return JSONResponse(content=result)

    except ValueError as e:
        return JSONResponse(
            status_code=400,
            content={"error": str(e)}
        )
    except Exception as e:
        return JSONResponse(
            status_code=500,
            content={"error": f"Generation failed: {str(e)}"}
        )
    finally:
        if os.path.exists(tmp_path):
            os.remove(tmp_path)

@app.get("/api/tts/voices")
async def get_voices():
    return voice_cloner.get_supported_languages()

@app.post("/api/tts/preview")
async def preview_voice(
    reference_audio: UploadFile = File(...),
    language: str = Form(default='en')
):
    """Generate a 5-second preview to evaluate voice quality."""
    preview_text = {
        'en': "Hello, this is a preview of your cloned voice.",
        'es': "Hola, esta es una vista previa de tu voz clonada.",
        'fr': "Bonjour, ceci est un aperçu de votre voix clonée.",
        'de': "Hallo, dies ist eine Vorschau Ihrer geklonten Stimme.",
        'ja': "こんにちは、これはクローンされた声のプレビューです。",
    }.get(language, "Hello, this is a preview of your cloned voice.")

    # Same logic as clone_voice_endpoint
    # [abbreviated for clarity]
    pass

WHAT I'D DO DIFFERENTLY

Test with more diverse voice types early

I tested primarily with my own voice during development. In production, I discovered that voices with unusual characteristics (strong accents, high/low pitch extremes) sometimes produce NaN outputs on CPU inference.

Add a retry mechanism:

python
MAX_RETRIES = 3

for attempt in range(MAX_RETRIES):
    try:
        wav = self.model.tts(
            text=chunk,
            speaker_wav=processed_ref,
            language=language
        )
        # Check for NaN/Inf
        audio_array = np.array(wav)
        if np.isnan(audio_array).any() or \
           np.isinf(audio_array).any():
            raise ValueError("NaN/Inf in output")
        audio_chunks.append(audio_array)
        break
    except Exception as e:
        if attempt == MAX_RETRIES - 1:
            raise
        time.sleep(0.5)

Implement voice profile caching

Computing the speaker embedding from reference audio takes ~1 second. If a user generates multiple outputs from the same voice profile, cache the speaker embedding rather than recomputing it.

Add voice similarity scoring earlier

We eventually added cosine similarity between reference and output embeddings as a quality score. I should have added this from day one — it catches generation failures that sound wrong but don't produce errors.

WRAPPING UP

XTTS-v2 is genuinely impressive for a locally-runnable open-source model. The cross-lingual capability is remarkable — 6 seconds of reference audio producing intelligible speech in 17 languages is not something most people expect from a model that runs on their laptop.

The rough edges (memory leak, preprocessing requirements, language quality variance) are manageable once you know about them.

I built all of this into Pocket Core AI — an offline AI desktop app at getpocketcore.com if you want to see it in action without writing any code.

Questions about the implementation — drop them in the comments. I'm reading all of them.

How I bundled llama.cpp, FLUX.1, XTTS-v2, and Kokoro into one Electron app that ships on Windows, macOS and Linux

PocketCoreAI — Mon, 17 Aug 2026 09:23:30 +0000

I just shipped Pocket Core AI — a desktop app that runs four AI inference pipelines completely offline. This post is a technical walkthrough of how it's built, the problems I hit, and the solutions that actually worked.

This is the post I wish existed when I started building.

THE ARCHITECTURE OVERVIEW

┌─────────────────────────────────────┐
│ Electron Shell │
│ (Node.js + Chromium) │
│ │
│ ┌─────────────────────────────┐ │
│ │ UI Layer │ │
│ │ (HTML + CSS + JavaScript) │ │
│ └─────────────┬───────────────┘ │
│ │ HTTP localhost │
│ ┌─────────────▼───────────────┐ │
│ │ Python FastAPI Backend │ │
│ │ (PyInstaller executable) │ │
│ │ │ │
│ │ ┌──────────────────────┐ │ │
│ │ │ llama.cpp (chat) │ │ │
│ │ │ diffusers (images) │ │ │
│ │ │ ONNX (TTS) │ │ │
│ │ │ XTTS-v2 (cloning) │ │ │
│ │ └──────────────────────┘ │ │
│ └─────────────────────────────┘ │
└─────────────────────────────────────┘

The key insight: Electron handles the UI and OS integration. Python handles all AI inference. They communicate via HTTP to localhost. The Python backend is bundled as a platform-specific executable via PyInstaller so the user never needs Python installed.

THE PYTHON BACKEND

FastAPI serves all AI operations through REST endpoints:

python
# server.py — simplified structure
from fastapi import FastAPI
from fastapi.middleware.cors import CORSMiddleware

app = FastAPI()

# Only allow localhost — never exposed to network
app.add_middleware(
    CORSMiddleware,
    allow_origins=["http://localhost:*"],
    allow_methods=["*"],
    allow_headers=["*"],
)

@app.post("/api/chat")
async def chat(request: ChatRequest):
    return StreamingResponse(
        generate_response(request),
        media_type="text/event-stream"
    )

@app.post("/api/generate-image")
async def generate_image(request: ImageRequest):
    result = image_generator.generate(
        prompt=request.prompt,
        negative_prompt=request.negative_prompt,
        width=request.width,
        height=request.height,
        steps=request.steps,
        seed=request.seed
    )
    return {"image_base64": result.base64, 
            "generation_time": result.time}

@app.post("/api/tts")
async def text_to_speech(request: TTSRequest):
    audio = tts_engine.speak(
        text=request.text,
        voice=request.voice,
        speed=request.speed
    )
    return {"audio_base64": audio.base64,
            "duration": audio.duration}

@app.post("/api/clone-voice")
async def clone_voice(request: VoiceCloneRequest):
    audio = voice_cloner.clone(
        text=request.text,
        reference_audio=request.reference_audio,
        language=request.language
    )
    return {"audio_base64": audio.base64}

BUNDLING WITH PYINSTALLER

The tricky part is bundling four different AI frameworks together. The .spec file needs careful attention:

python
# pocketai-backend.spec
a = Analysis(
    ['main.py'],
    pathex=['.'],
    binaries=[],
    datas=[
        # Include Kokoro model files
        ('models/kokoro', 'models/kokoro'),
        # Include any required config files
        ('config', 'config'),
    ],
    hiddenimports=[
        # llama-cpp-python
        'llama_cpp',
        'llama_cpp.llama',
        # diffusers / FLUX
        'diffusers',
        'diffusers.pipelines',
        'diffusers.pipelines.flux',
        'transformers',
        'accelerate',
        # ONNX / Kokoro
        'onnxruntime',
        'kokoro_onnx',
        # XTTS
        'TTS',
        'TTS.api',
        'TTS.tts.configs',
        # Web search
        'newspaper',
        'newspaper3k',
        'bs4',
        'requests_cache',
        # FastAPI
        'fastapi',
        'uvicorn',
        'uvicorn.logging',
        'uvicorn.loops',
        'uvicorn.loops.auto',
        'uvicorn.protocols',
        'uvicorn.protocols.http',
        'uvicorn.protocols.http.auto',
        # Other common hidden imports
        'multipart',
        'aiofiles',
    ],
    hookspath=[],
    runtime_hooks=[],
    excludes=[
        'tkinter',  # Not needed, saves space
        'matplotlib',  # Only if not used
        'PIL._tkinter_finder',
    ],
)

KEY LESSON: Missing hidden imports fail silently in development and loudly in production. Test your PyInstaller build on a completely clean VM before shipping.

THE CROSS-PLATFORM BUILD WITH GITHUB ACTIONS

yaml
# .github/workflows/build.yml
name: Build PocketCore AI

on:
  workflow_dispatch:
  push:
    tags:
      - 'v*'

jobs:
  build:
    strategy:
      matrix:
        include:
          - os: windows-latest
            name: windows-installer
          - os: macos-latest  
            name: macos-dmg
          - os: ubuntu-latest
            name: linux-appimage

    runs-on: ${{ matrix.os }}

    steps:
      - uses: actions/checkout@v4

      - name: Set up Python 3.11
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'

      # Linux only — free disk space first
      - name: Free disk space (Linux)
        if: matrix.os == 'ubuntu-latest'
        run: |
          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 2>/dev/null || true

      - name: Download Kokoro TTS model
        run: |
          pip install huggingface_hub
          python -c "
          from huggingface_hub import snapshot_download
          snapshot_download(
              repo_id='hexgrad/Kokoro-82M',
              local_dir='./models/kokoro',
              allow_patterns=['config.json', 
                             '*.pth', 
                             'voices/*.pt']
          )"

      - name: Build Python backend
        run: |
          pip install --no-cache-dir -r backend/requirements.txt
          pip install pyinstaller
          cd backend
          pyinstaller pocketai-backend.spec --noconfirm

      - name: Set up Node.js 18
        uses: actions/setup-node@v4
        with:
          node-version: '18'

      - name: Build Electron app
        run: |
          cd app
          npm install
          npm run dist

      - name: Upload installer
        uses: actions/upload-artifact@v4
        with:
          name: pocketai-${{ matrix.name }}
          path: app/dist/*.{exe,dmg,AppImage}
          if-no-files-found: error

THE DEPENDENCY CONFLICT THAT COST ME A DAY

ERROR: Cannot install misaki==0.7.4 
and kokoro 0.7.16

kokoro 0.7.16 depends on misaki>=0.7.16

This fails on CI across all three platforms simultaneously. The fix:

# requirements.txt
# Before (broken):
misaki==0.7.4
kokoro==0.7.12

# After (working):
misaki>=0.7.16
kokoro>=0.7.16

Simple once you know it. Took too long to find because the error message was buried in pip's dependency resolution output.

THE USB GHOST MODE IMPLEMENTATION

When the app detects removable media, it switches all data paths to the USB drive:

python
# utils/path_manager.py

import platform
import os
import subprocess
from pathlib import Path

def detect_removable_media() -> bool:
    """Detect if app is running from removable media"""
    current_path = Path(os.path.abspath(__file__))

    if platform.system() == "Windows":
        return _windows_detect(current_path)
    elif platform.system() == "Darwin":
        return _macos_detect(current_path)
    else:
        return _linux_detect(current_path)

def _windows_detect(path: Path) -> bool:
    try:
        import wmi
        c = wmi.WMI()
        drive_letter = str(path.drive)
        for disk in c.Win32_LogicalDisk():
            if disk.DeviceID == drive_letter:
                return disk.DriveType == 2  # 2 = Removable
    except Exception:
        return False
    return False

def _macos_detect(path: Path) -> bool:
    try:
        result = subprocess.run(
            ['diskutil', 'info', str(path.anchor)],
            capture_output=True, text=True
        )
        return 'Removable Media: Yes' in result.stdout
    except Exception:
        return False

def _linux_detect(path: Path) -> bool:
    try:
        mount_point = str(path.anchor)
        with open('/proc/mounts', 'r') as f:
            for line in f:
                parts = line.split()
                if len(parts) >= 2 and parts[1] == mount_point:
                    device = parts[0].replace('/dev/', '')
                    removable_path = f'/sys/block/{device}/removable'
                    if os.path.exists(removable_path):
                        with open(removable_path) as rf:
                            return rf.read().strip() == '1'
    except Exception:
        return False
    return False

def get_data_root() -> Path:
    """Return the appropriate data directory"""
    if detect_removable_media():
        # Run from USB — store everything on the drive
        app_dir = Path(os.path.abspath(__file__)).parent
        return app_dir / "PocketCoreData"
    else:
        # Run from install — use OS app data directory
        if platform.system() == "Windows":
            return Path(os.environ['APPDATA']) / "PocketCoreAI"
        elif platform.system() == "Darwin":
            return Path.home() / "Library" / "Application Support" / "PocketCoreAI"
        else:
            return Path.home() / ".config" / "PocketCoreAI"

XTTS-V2 MEMORY LEAK WORKAROUND

XTTS-v2 has a memory leak during long sessions. Our fix — reinitialise periodically:

python
# core/voice_cloner.py

class VoiceCloner:
    def __init__(self):
        self.model = None
        self.generation_count = 0
        self.MAX_GENERATIONS = 50

    def _ensure_model_loaded(self):
        if self.model is None or \
           self.generation_count >= self.MAX_GENERATIONS:
            # Reinitialise to clear leaked memory
            if self.model is not None:
                del self.model
                import gc
                gc.collect()
                if torch.cuda.is_available():
                    torch.cuda.empty_cache()

            self.model = TTS("tts_models/multilingual/multi-dataset/xtts_v2")
            self.generation_count = 0

    def clone(self, text: str, reference_audio: str, 
              language: str) -> bytes:
        self._ensure_model_loaded()

        # Generate audio
        output = self.model.tts(
            text=text,
            speaker_wav=reference_audio,
            language=language
        )

        self.generation_count += 1
        return output

WHAT I'D DO DIFFERENTLY

Test on a clean VM before every release PyInstaller hidden imports that work in dev silently fail in bundled executables. I discovered this the hard way on the first user install reports.
Start cross-platform CI earlier I built on Windows and assumed it would work on macOS and Linux. It didn't — different hidden imports, different CUDA paths, different filesystem conventions.
The model bundling strategy from day one I changed my approach to model delivery three times. Final approach (bundle small models, download large models on first use) should have been the first approach.

WHAT I SHIPPED AND WHERE TO GET IT

Pocket Core AI is live at getpocketcore.com. $89 one-time for the Pro tier — all four inference pipelines, all platforms, USB Ghost Mode, lifetime updates.

The source isn't open (it's a commercial product) but I'm happy to discuss any implementation detail in the comments.

Questions, criticism, better approaches to any of this — I'm reading all the comments.