# PATCHBAY: Why I Replaced WanGP's Gradio UI With My Own Cockpit By AJTheDev — 2026-07-10 Canonical: https://ajthe.dev/blog/posts/patchbay-wangp-cockpit.html --- WanGP is one of those bits of local AI kit that quietly does something incredible: it runs big diffusion video and image models on consumer hardware, with mmgp int8 offloading doing the heavy lifting so a 16GB card can punch well above its weight. The engine is genuinely great. The problem was never the engine. The problem was the front end. WanGP ships with a Gradio UI, and Gradio is fine for a research demo — it is not fine for a tool you sit in for hours. It's slow, it's fiddly, it fights you on layout, and every parameter is presented with the same flat urgency so nothing feels like it's *yours*. I didn't want to fork the engine. I wanted a better cockpit bolted onto it. So I built **PATCHBAY**: a fast, dark, industrial single-page control surface that replaces the Gradio UI entirely. The engine, the models, the performance characteristics — completely unchanged. I didn't touch a line of the generation code. I just gave it a better set of controls. ## The trick: keep the engine headless Here's the part I think is actually interesting. WanGP has a built-in MCP server. So instead of scraping a UI or reaching into internals, PATCHBAY talks to WanGP as a proper headless service over JSON-RPC. The shape is clean: ``` browser │ ▼ PATCHBAY UI (vanilla JS, single file) │ ▼ FastAPI backend · http://127.0.0.1:8500 │ JSON-RPC (tools/call) ▼ WanGP MCP server · http://127.0.0.1:7866/mcp ``` The browser loads a single vanilla-JS page. That talks to a small FastAPI backend on port 8500. The backend speaks JSON-RPC to WanGP's MCP server on 7866. WanGP itself never renders a pixel of UI — it's a pure engine now, and PATCHBAY is the driver's seat. This is the design decision that makes the whole thing sane. Because the engine is headless and the contract is MCP tool calls, the UI is completely disposable. I can rebuild the entire front end, change how the job stack works, restyle everything — and the engine doesn't know or care. Decoupling the surface from the substrate is the same principle I reach for everywhere, and it paid off here immediately. It wasn't entirely free. The `mcp` 1.12.x library has a habit of spamming a `ClosedResourceError` traceback on every stateless request, which pollutes WanGP's job event streams and evicts the progress events I actually need to render a live progress bar. The fix was to silence that specific logger at engine start. Small thing, but it's the difference between a progress bar that updates and one that mysteriously freezes. ## One button to rule the engine You launch the whole stack with `start_patchbay.bat`. It starts the cockpit, opens the browser, and — with `engine_autostart` on — launches the WanGP engine headless for you. The header LED goes amber, then green in a minute or two, and models load into VRAM on the first generate. That header LED isn't just a status light — it's the engine switch. Click it while red to start the engine, click it while green to stop it (with a confirm, because stopping mid-job is a good way to lose work). And the lifecycles are deliberately separate: closing the bat window stops the cockpit, but the engine keeps running until you stop it via the LED. So I can restyle the UI, kill it, relaunch it, and never pay the model-reload tax. Little decisions like that are what make a tool feel like it respects your time. ## Curated up front, everything else on tap The features are shaped around one belief: 90% of the time you touch five controls, and the other fifty parameters should be there when you want them and invisible when you don't. - **Units** — a whitelist in `config.json`. I run LTX-2.3 22B Distilled (video and audio), Krea 2 Turbo, and Z-Image Turbo 6B. No TTS, no clutter, just the models I actually generate with. - **Schema-driven settings** — the curated controls sit up front; every other scalar parameter is auto-rendered under an ADVANCED section, pulled straight from WanGP's own `wangp_get_model_schema`. I never hand-maintain a form. The engine tells the UI what it supports. - **I2V start-image upload** for LTX, and a **resolution dropdown** that mirrors WanGP's native list — 35 choices — so I'm never guessing at a valid size. - **A Lora rack per unit** that lists the `.safetensors` from that model's lora directory, with a toggle and a per-lora multiplier. Drop new files in the folder, reselect the unit, done. - **A job stack** with live phase and step progress, abort, and errors surfaced instead of swallowed. Plus an **output wall** straight from WanGP's `outputs/` — hover-to-play videos, a lightbox, and sidecar metadata so I know exactly what settings made a given clip. ## Where the real work was: VRAM The genuinely hard part wasn't the UI at all — it was performance tuning, and this is where I want to be honest rather than hand-wave a number. PATCHBAY exposes `engine_preload_mb`, which it passes to WanGP as `--preload`: the megabytes of the diffusion model pinned in VRAM. WanGP's own default budget is tiny, around 100MB, which layer-streams big models from RAM — I watched a 13GB Krea2 model touch only 2.5GB of VRAM that way. It works, but it's leaving speed on the table if you've got headroom. On my 5060 Ti 16GB the tuning history is specific. A preload of 12000 measured fastest at 512×512 — Krea2 hitting 4.7 s/step fully resident, LTX at 241 frames and 512 peaking at 13.1GB. But push LTX to its default 1280×720 at 241 frames and 12000 *overcommits*: VRAM climbs to 15.9 of 16.3GB and the whole job crawls through NVIDIA's sysmem fallback — a silent roughly 10× slowdown that looks exactly like the app has hung. So 9000 is the safe setting for 720p video work; 12000 buys about 15% more speed if you only do images or short low-res clips; 0 hands it back to WanGP's default. The sysmem-fallback trap deserves calling out because it fooled me for an evening: GPU at 100%, VRAM basically full, steps taking minutes. It looks halted. It isn't — it's grinding through system RAM. The fix is to abort, lower the preload, and restart the engine. (And check `nvidia-smi` rather than Task Manager's default "3D" graph, which cheerfully shows ~0% for CUDA work and will gaslight you.) ## Does it actually work? Yes — end to end. On the 7th of July I submitted a Z-Image generation through the cockpit, watched the live progress track properly, and the output landed in the gallery. Job submitted, MCP round-tripped, progress streamed, file on disk, thumbnail on the wall. The whole pipeline lit up exactly as designed. The broader point is one I keep coming back to with local AI: the model is a commodity now, but the *surface* you drive it through is where the actual daily experience lives. WanGP gave me a superb engine. PATCHBAY is me deciding I'd rather own the cockpit than tolerate someone else's. If you're running local models and drowning in default UIs, I'd genuinely encourage you to build your own control surface — it's less work than you think once the engine is headless. [Come find me on Discord](https://discord.gg/d39aaZXAjh) if you want to trade notes on local video generation or MCP wiring.