Metatron

The hard part was memory, not modelling

A 12GB card cannot hold a 3D diffusion engine (~8.5GB resident) and a language model (~7–8GB) at once. The ordering turned out to be the whole bug: VRAM has to be clear *before* the engine starts loading, not while. Getting that wrong meant twelve-minute warm-ups with both models resident and the machine frozen solid — no crash, no log, nothing to read afterwards. A keepalive thread quietly reloading the 7GB brain every 60 seconds made it worse. Threads now check ownership of the card before re-warming, and a 535-sample flight-recorder run held the language model at zero VRAM for 18 unbroken minutes through a full engine boot and forge cycle — against about 50 seconds before the fix.

Built to be watched

Every forge reports elapsed time and current stage — removing background, generating, texturing — so a seven-minute job is legible rather than a spinner. Failures name what died and when.

• Queue with retry and discard per job
• Per-job elapsed time and stage
• In-browser mesh preview before approval
• Output straight to GLB, ready for Blender

Freezes leave no evidence, so I built some

A hard freeze writes almost nothing to the Windows event log, which makes it the worst kind of bug: it costs an hour and tells you nothing. So Metatron grew its own forensics — a flight recorder that samples lazily when idle and every two seconds under load, a session seal that can tell a process that died from one that was killed, and a root-cause ranker that reports its own confidence, from hardware-confirmed down to no-data. The write-up is on GitHub.