DEV Community: C. Wheatley

AI This Week: Distillation Wars Go Geopolitical

C. Wheatley — Thu, 23 Jul 2026 13:12:26 +0000

This was the week AI stopped being a product story and became a foreign-policy one. A White House official publicly accused a Chinese lab of copying Anthropic's frontier model, OpenAI put more than $30 billion behind a single data center campus, and four separate enterprise "agent platforms" landed within weeks of each other. The through-line: capability is now cheap enough, and strategically important enough, that governments are treating model weights the way they once treated enriched uranium.

Model Releases & the Distillation Fight

White House accuses Moonshot of distilling Anthropic's Fable model

OSTP Director Michael Kratsios publicly alleged that Moonshot AI distilled Anthropic's Fable model to build Kimi K3 — a 2.8-trillion-parameter model claiming a 76% win rate on Frontend Code Arena and an 88.3 Terminal-Bench score, with open weights due July 27. Kratsios called it "large-scale covert industrial distillation." It's the first time a US official has named a specific model as stolen IP.

Independent analysis adds fuel to the claim

Redwood Research chief scientist Ryan Greenblatt published a cross-entropy analysis finding that Kimi K3 identifies itself as "Claude" disproportionately often across many prompts — the kind of statistical fingerprint that distillation tends to leave behind. Kratsios separately alleged Moonshot accessed export-restricted Nvidia GB300 chips through servers in Thailand.

DeepSeek V4 and Kimi K3 land within days of each other

The Chinese frontier is shipping fast and cheap: DeepSeek V4's stable release arrived July 24 at $0.44 per million output tokens, with Kimi K3's open weights following July 27. Both continue to narrow the capability gap with US labs at a fraction of the cost — the exact dynamic that made this week's accusations so charged.

Agentic AI

OpenAI launches Presence, its enterprise agent platform

On July 22, OpenAI shipped Presence, a platform for deploying agents into customer support, sales, and other high-risk workflows, with BBVA, SoftBank, and IAG as early adopters. It joins a suddenly crowded field: Google Gemini Enterprise, Meta's Business Agent Platform, and the NVIDIA/ServiceNow Project Arc all launched in the same window. The enterprise agent war is officially on.

Infrastructure & Business

OpenAI breaks ground on Project Camellia, a $30B+ data center

Announced July 22, Camellia is a 3.2-gigawatt campus across 1,400 acres in Effingham County, Georgia, with spending exceeding $30 billion and power delivery staged from 2028 to 2032. OpenAI paired it with $80 million in community benefits plus $71 million in Codex credits — a reminder that the constraint on frontier AI is now electricity and concrete, not algorithms.

BlackRock and MGX pour another $5B into data centers

BlackRock and Abu Dhabi's MGX committed an additional $5 billion to Aligned Data Centers on top of a $40 billion acquisition, with total potential deployment reaching $100 billion including debt. Meanwhile, the Albany NanoTech Complex received components of a $400 million ASML High-NA EUV lithography system expected to be operational by year-end.

A federal judge approves Anthropic's $1.5B copyright settlement

A San Francisco federal judge signed off on Anthropic's $1.5 billion settlement with authors over pirated books used to train Claude. Over 91% of eligible authors and publishers filed claims, with $101 million set aside for attorney fees — one of the largest resolutions yet in the AI-training copyright fights.

Defense AI clears $3B in disclosed July funding

Defense-focused AI attracted well over $3 billion in disclosed funding this month alone, led by Shield AI's $1.5 billion Series G and Helsing's earlier €1.8 billion round, alongside a new Anduril–Archer partnership. Capital is following the same geopolitical logic driving the week's headlines.

Science & Healthcare

AI drug discovery investment tops $2B as timelines collapse

AI-driven drug discovery pulled in more than $2 billion in recent investment, with technology cutting development timelines from 4–5 years to 12–18 months while roughly doubling clinical success rates. About 175 AI-originated drug programs have entered human trials since 2019, and 15–20 could reach pivotal Phase III this year. The FDA is expected to finalize guidance on AI in drug development during 2026.

Policy & Regulation

The US and China schedule formal AI talks for September

Washington and Beijing are preparing formal AI negotiations in September — before President Xi Jinping's planned September 24 US visit — covering military AI, cyberattacks, model access, and open-weight releases. After a week of distillation accusations and chip-smuggling allegations, the diplomatic channel suddenly looks less like a formality and more like a pressure valve.

If there's a single takeaway, it's that the interesting AI questions are no longer just "which model scores highest." They're "who trained on what," "who's allowed to buy which chips," and "who pays for the gigawatts." The benchmarks are converging; the politics are diverging.

Sources

AI This Week: Compute Becomes the Bottleneck

C. Wheatley — Thu, 16 Jul 2026 14:07:05 +0000

The story this week wasn't a smarter model — it was the realization that raw capability is no longer the thing that's scarce. Frontier labs shipped cheaper, faster tiers instead of bigger ones, Google literally started rationing GPU access to a competitor, and the money moving around the industry began to dwarf the technical headlines. Compute and capital, not IQ, are now the binding constraints.

Model Releases

OpenAI ships the GPT-5.6 suite

GPT-5.6 went live on July 9 as a three-tier lineup: Sol for high-end reasoning, coding, and science at $5.00 / $30.00 per 1M input/output tokens; Terra, targeting GPT-5.5-level quality at roughly half Sol's cost; and Luna for fast, high-volume work. The split is the whole point — OpenAI is selling price/latency tiers, not one monolithic model.

Meta's Muse Spark 1.1 undercuts everyone

Meta's agentic model arrived with a 1-million-token context window at $1.25 / $4.25 per 1M tokens, ranked first on JobBench and Finance Agent V2, and shipped with Meta's first-ever paid developer API ($20 in free credits, US-only). It adds parallel subagent delegation plus computer use across desktop, browser, and mobile.

Grok 4.5 and Claude Fable 5 round out the frontier

xAI's Grok 4.5 is a 1.5-trillion-parameter Mixture-of-Experts model scoring 83.3% on Terminal-Bench 2.1 at $2.00 / $6.00 per 1M tokens, and reportedly burns about 25% as many output tokens as comparable models. Anthropic's Claude Fable 5 returned July 1 after a 19-day pause, retaking the coding crown at 80.3% on SWE-Bench Pro.

Gemini 3.5 Pro is on deck

Google delayed Gemini 3.5 Pro from June into July while tuning it on early feedback, with a launch expected around July 17 — reportedly a 2-million-token context window at $1.25 input / $10 output per 1M tokens. The current Gemini 3.1 Pro already posts 94.3% on GPQA Diamond and 77.1% on ARC-AGI-2.

Business & Industry

Google caps Meta's access to Gemini

In the clearest sign of where the real constraint sits, Google limited Meta's access to its Gemini models, citing insufficient compute to meet Meta's requests. When one of the largest infrastructure owners on Earth has to turn a paying customer away, the bottleneck is silicon, not smarts.

OpenAI floats a 5% government stake

OpenAI proposed handing the US government a 5% equity stake worth about $42.6 billion at an $852 billion valuation, part of a broader pitch for leading AI firms to seed a public sovereign wealth fund modeled on Alaska's permanent fund. A poll cited alongside it found 69% of US workers support requiring such transfers.

Anthropic preps an October IPO

Anthropic is reportedly preparing an S-1 for an October 2026 IPO on roughly $47 billion in annualized revenue and 2026 profitability, while negotiating with Samsung for a custom AI chip. Meanwhile TSMC posted Q2 revenue of NT$1.27 trillion ($39.62 billion), up 36% year-over-year on AI chip demand, and global startups raised $510 billion in H1 2026 — most of it AI.

Agentic AI

Enterprise agent platforms go head-to-head

Google unveiled an expanded Gemini Enterprise portfolio for building, orchestrating, and governing fleets of agents across an organization — squaring off directly against OpenAI's ChatGPT Work (launched July 9, pairing ChatGPT with Codex so non-technical staff can build docs, sheets, and apps) and Anthropic's Claude Cowork, which handles long-running email, calendar, and file tasks that keep going even when your device is offline.

Gemini reasoning lands inside Boston Dynamics' Spot

Boston Dynamics integrated Gemini Robotics-ER 1.6 into its Spot robots, giving them autonomous spatial reasoning and on-the-fly decision-making for industrial inspection — agents stepping off the screen and onto four legs.

Science & Healthcare

A pan-cancer AI predicts immunotherapy response

A model called COMPASS, published in Nature Medicine, analyzes tumor gene expression to forecast immunotherapy success across 33 cancer types and multiple checkpoint inhibitors. Trained on over 10,000 tumors, it outperformed existing methods and generalized to cancers it had never seen during training.

The FDA clears its first patient-facing generative AI

The clearance is deliberately narrow — the tool is bound to non-diagnostic tasks and does not write prescriptions — but it's a first. Alongside it, Evernorth placed a $100 million bet on AI pharmacy automation and roughly $95 million flowed into clinical trial automation, signaling that regulatory and pharmacy workflows are the next high-value frontier.

Policy & Regulation

The FTC targets "AI accuracy suppression"

The Federal Trade Commission opened public comment (due July 31) on a policy statement arguing that state laws pressuring companies to alter model outputs — Colorado's AI Act is named — may be impliedly preempted where they conflict with federal rules. It frames tampering with AI outputs as a potential deceptive practice.

The EU fuses cybersecurity and AI oversight

On July 7 the European Commission presented an Action Plan on Cybersecurity and Artificial Intelligence, merging two previously separate regulatory regimes. Stateside, at least 35 AI-related bills have now been enacted across states, with California, Texas, Illinois, and Utah duties already in force and Colorado's replacement framework arriving January 2027.

Sources

Building LibreSprite From Source: The Free GPL Fork, Built With an All-Open Toolchain

C. Wheatley — Tue, 14 Jul 2026 02:45:24 +0000

A while back I compiled Aseprite from source — a source-available, paid editor I built for myself with Visual Studio and a prebuilt Skia. This is the other half of that story. LibreSprite is the free, GPL fork of Aseprite, and I wanted to build it the way it's meant to be built: with a fully open toolchain, no proprietary compiler, no pinned vendor binary. I cloned the repo, installed a pile of dependencies through a package manager, and ended up with a working libresprite.exe (LibreSprite 1.2-dev) that launches with the full GUI — drawing canvas, palette, animation preview, the lot. Claude was my pair programmer for it, and most of the work was figuring out that the project's own official Windows instructions no longer point at anything that exists.

What it is

LibreSprite is a free and open-source pixel-art and sprite-animation editor: layers and frames, onion skinning, real-time animation preview, tiled drawing, palette management, the usual pixel-precise toolset. If that sounds exactly like Aseprite, that's because it is one — or was. LibreSprite started as a fork of Aseprite back when Aseprite was distributed under the GNU General Public License v2. On August 26th, 2016, Aseprite moved to a proprietary license; LibreSprite forked from the last GPL commit and has been maintained as a free, GPL project by its community ever since.

That history is the whole reason this post exists as a companion to my Aseprite build, not a rerun of it. Aseprite today is source-available under its own EULA — you can compile it for yourself, but you can't redistribute the binary, and the canonical build uses Visual Studio plus a prebuilt Skia. LibreSprite is genuinely free software under the GPL, and its build leans on an all-open toolchain: an open compiler (g++ via MSYS2), open dependencies installed from a package repository, and an open build system (CMake + Ninja). Same lineage, opposite license, opposite toolchain. Full credit for the editor goes to the LibreSprite project and its contributors — and, further back, to David Capello and the original Aseprite authors. My work here was purely getting it to compile on Windows.

How it was built

The supported Windows toolchain for LibreSprite is MSYS2 — the project ships with no Visual Studio solution you'd actually want to use today, and the real path runs through MinGW. The toolchain that worked for me:

MSYS2 with the ucrt64 environment — using g++ 16.1.0. This is far newer than the codebase targets, but it built clean anyway.
Dependencies installed via pacman, all from the mingw-w64-ucrt-x86_64-* set: cmake, ninja, pkgconf, curl, freetype, giflib, libjpeg-turbo, libpng, libwebp, pixman, SDL2, SDL2_image, tinyxml2, zlib, and libarchive.
CMake + Ninja as the configure-and-build pair: from a ucrt64 shell, cmake -G Ninja -DCMAKE_BUILD_TYPE=RelWithDebInfo .. followed by ninja libresprite.

That build ran 1351 steps to completion with zero errors. The one thing that didn't resolve was V8 — the project couldn't find it, so the scripting engine fell back to the bundled duktape interpreter, which is a perfectly fine default and cost nothing. SDL2 and freetype do the windowing and font rendering, the image libraries handle the file formats, and the whole thing links against the MSYS2 runtime rather than the MSVC one.

The contrast with the Aseprite build is the point. There, the hard part was a proprietary-adjacent stack: a specific Visual Studio version and a prebuilt Skia binary pinned to an exact revision. Here, every piece is open and installable from a package repo. The pain moved somewhere else entirely.

The gotchas

INSTALL.md's official Windows path is dead — mingw32/i686 no longer exists in modern MSYS2. This is the one to know before you start. LibreSprite's INSTALL.md lists Windows 10 + VS2015 at the top, then gives the real instructions as a pacman command to run "in mingw32" using the 32-bit i686 dependency set (mingw-w64-i686-gcc, mingw-w64-i686-cmake, and so on). That environment was removed from MSYS2 in 2023. If you follow the documented steps on a current MSYS2 install, the i686 packages simply won't resolve and there's no mingw32 shell to run them in. The fix is to use the ucrt64 environment instead and substitute the ucrt-x86_64 package names for every i686 one in the list. That's the entire difference between "the official instructions fail immediately" and "1351 steps, zero errors." On this machine ucrt64 was the only environment with a working toolchain at all — the mingw64 directory existed but was empty — so ucrt64 wasn't just the modern choice, it was the only one available.

The finished .exe needs C:\msys64\ucrt64\bin on PATH to run. Because LibreSprite is built against the MSYS2 runtime, the binary dynamically links a stack of DLLs that live in the ucrt64 bin directory — libstdc++, SDL2, freetype, and friends. Double-clicking libresprite.exe from a plain Windows shell that doesn't have that directory on PATH gets you a missing-DLL error, not the editor. The fix is to make sure C:\msys64\ucrt64\bin is on PATH when you launch it (or to ship those DLLs alongside the exe for a standalone build). This is the open-toolchain tax: a Visual Studio build statically pulls in its runtime, but a MinGW build expects its runtime to be findable. Worth knowing before you conclude a successful build is "broken."

A GUI-subsystem binary prints nothing to --version, which looks like a failure but isn't. libresprite.exe is compiled as a Windows GUI-subsystem program, so it has no console attached. Run libresprite.exe --version from a terminal and you get... nothing — it prints no text and exits cleanly. The first time, that reads as a silent crash. It isn't: the binary is fine, it just has no stdout to write to. The way to actually verify the build is to launch it and look at the window — which is exactly what the screenshot at the top of this post is: LibreSprite 1.2-dev running, with a sprite open on the canvas, the palette docked on the left, and the animation preview floating over it.

What shipped

A working build/bin/libresprite.exe (LibreSprite 1.2-dev), built entirely from source on Windows with a fully open toolchain: MSYS2 ucrt64, g++ 16, pacman-installed dependencies, and CMake driving Ninja. I verified it the only way a GUI binary lets you — by running it and confirming the editor comes up live, drawing canvas and palette and preview all working. The whole build is reproducible from a clean checkout once you know to reach for ucrt64 instead of the dead mingw32 path the project's INSTALL.md still advertises.

To be clear about what this is: LibreSprite is someone else's software — a free, GPL project built and maintained by its contributors. My contribution was narrow: getting it to compile on a modern Windows machine, and pinning down that the official instructions had quietly rotted. Set next to the Aseprite build, it's a neat study in contrasts — same family of editor, but one is paid and source-available with a proprietary-flavored toolchain, and the other is free, GPL, and built with nothing but open parts.

It's one of a series of projects I've been building this way; the running list is on the projects page.

Building Aseprite From Source: A Paid Pixel-Art Editor, Free If You Compile It

C. Wheatley — Tue, 14 Jul 2026 02:45:06 +0000

Aseprite is a pixel-art editor and animation tool that costs about twenty dollars on Steam and itch.io. It's also source-available: the full source lives on GitHub, and the project explicitly allows you to compile it yourself for your own use. So I did. I cloned the repo, fought the toolchain, and ended up with a working aseprite.exe (~20.6 MB) that launches and reports "Aseprite 1.x-dev" — the same editor, built by me, on my own machine. I did it with Claude as a pair programmer, and most of the work was untangling exactly one non-obvious trap.

What it is

Aseprite is the editor a lot of pixel artists reach for first: a tight tool for drawing sprites, tilesets, and frame-by-frame animation, with onion skinning, palette management, and sprite-sheet export. The binaries are paid, but the source is genuinely public — not open-source in the OSI sense, but source-available under its own EULA. The distinction matters: building it for personal use is explicitly fine, while redistributing the binaries you produce is not. So this is a build-it-yourself story, not a fork-and-republish one. Full credit for the editor belongs to Igara Studio S.A. — David Capello and contributors; my work here was purely getting it to compile on Windows.

Why bother compiling something you can buy? Partly because the option exists and it's a clean test of a real toolchain — Aseprite is a substantial C++ codebase with a pile of vendored dependencies and a custom graphics backend. If you can build it, you can build almost anything. And partly because a build you control is a build you can patch, instrument, or pin to a specific commit. My checkout sits at 7063d5362, near the v1.3.18-beta3 tag on main.

The division of labor was the usual one for these projects: I decided what I wanted and made the judgment calls, and Claude wrote the scripts, read the error logs, and worked out which knob to turn next.

How it was built

Aseprite's renderer is built on Skia, Google's 2D graphics library — the same one behind Chrome's canvas. Skia is famously painful to compile from scratch, so the good news is you don't have to. Aseprite's own build.sh --auto downloads a prebuilt Skia matching the version the project expects, which is m124-08a5439a6b (the exact tag is pinned in laf/misc/skia-tag.txt). That one decision removes the single biggest source of pain from the whole build.

The toolchain that worked:

Visual Studio 2022 Build Tools for the compiler (cl 14.44, x64). My machine also has VS 2026, but Aseprite officially targets VS 2022, so I pointed the build at the 2022 Build Tools deliberately rather than letting it find the newer one.
CMake 3.31.6, portable — unzipped into .deps/, used instead of the CMake 4.x I had installed via winget. This is the trap; more on it below.
Ninja 1.13.2 as the build generator.
Prebuilt Skia m124, auto-downloaded into .deps/skia-m124/.

The repo ships a build.cmd for Windows, but it's not usable as-is on my setup: it hardcodes a Visual Studio 2022 Community vcvars path I don't have (I have the Build Tools, not the full IDE), and it ends in a pause that hangs any non-interactive run. So I wrote a thin launcher, build-everything.bat, that does four things in order: prepends the portable CMake and Ninja to PATH, calls the VS 2022 Build Tools vcvars64.bat to set up the compiler environment, prints a tool-check so I can see exactly which cl, cmake, and ninja are about to run, and then hands off to the official build.sh --auto --norun through Git's bundled sh.exe. The --auto flag does the Skia download and dependency wiring; --norun keeps it from launching the editor when it finishes.

To rebuild after a source change, I just re-run that one batch file — Ninja handles the incremental build from there.

The gotchas

CMake 4.x refuses to configure the build, and "newer" is the problem, not the fix. This is the one that cost the most time and is the single most important thing to know if you try this yourself. CMake 4.x removed support for old cmake_minimum_required declarations: if a project (or any library it pulls in) asks for a minimum CMake version below 3.5, CMake 4.x treats it as a hard error and stops. Aseprite vendors a stack of dependencies, several of which still declare ancient minimums — 2.4, 2.8, 3.0, 3.2, 3.4. With the winget-installed CMake 4.3.3, configuration dies on the first one it hits. The fix is counterintuitive: install an older CMake. I dropped a portable CMake 3.31.6 into .deps/ and put it ahead of everything on PATH. CMake 3.31 only warns about those old minimums instead of erroring, so the configure step completes. If you take one thing from this post: when a C++ project with vendored libraries won't configure, check your CMake version before you change anything else — bleeding-edge CMake is often the cause, not the cure.

The repo's own build.cmd assumes a setup you probably don't have. It's written for someone running full Visual Studio 2022 Community, so its vcvars path is wrong for a Build Tools install, and the trailing pause means it can't be driven by a script or an agent. Rather than patch it in place, I left it alone and wrote a small launcher that sets the environment explicitly and calls the cross-platform build.sh underneath. The lesson that generalizes: when a project's convenience script doesn't match your environment, the official build.sh --auto is usually the more honest path — it's what the project actually maintains, and it does the dependency fetching for you.

Don't try to build Skia yourself — let --auto fetch the pinned binary. It's tempting to think "build from source" means building everything from source, including Skia. Resist it. Aseprite pins an exact Skia revision (m124-08a5439a6b) because its renderer depends on that specific API surface, and build.sh --auto downloads a matching prebuilt artifact for you. Compiling Skia by hand would mean reproducing Google's depot_tools-based build and then hoping the version matched — hours of work to arrive at the same binary the script grabs in seconds. The pin in laf/misc/skia-tag.txt is the source of truth if you ever need to know which revision your build expects.

What shipped

A working build/bin/aseprite.exe, ~20.6 MB, that launches and runs as the real editor — drawing, palettes, animation timeline, the lot — built entirely from source on Windows. Re-running build-everything.bat does an incremental rebuild, so the whole thing is reproducible from a clean checkout: portable CMake 3.31, VS 2022 Build Tools, Ninja, and the auto-downloaded Skia m124.

To be clear about what this is and isn't: it's a personal build of someone else's software, allowed under Aseprite's source-available license for exactly this kind of self-compiling. There's no binary to hand out and no fork to link — the value was entirely in getting a large, real C++ project to compile cleanly, and in pinning down that the CMake version was the thing standing in the way the whole time.

It's one of a series of projects I've been building this way; the running list is on the projects page.

Blender Planets: A Reusable Skill for Building Worlds from Real NASA Maps

C. Wheatley — Thu, 09 Jul 2026 17:46:42 +0000

Most of the projects I write up here are things — a game, a bridge, a tool. This one is a little different. Blender Planets is a reusable Claude Code skill: a written capability that Claude loads on demand, encoding how to build a believable planet, moon, or gas giant in Blender from real NASA-derived map data instead of procedural noise. It isn't a single scene I rendered once. It's the recipe, the gotchas, and a set of helper functions, packaged so that the next time I say "drop Mars into this shot," Claude already knows how to do it well.

What it is

A skill, in Claude Code terms, is a Markdown file (plus optional references) that gets injected into Claude's context when the work matches its trigger. This one triggers whenever I'm "placing a textured sphere into a scene, adding an atmosphere glow, planetary rings, or real terrain relief, or when a planet looks like a flat red/blue decal." That last clause is the honest origin story: the first time I asked for a planet, I got a flat-shaded ball that read like a sticker. The skill exists so that never happens again.

What it encodes is general, not one-off. It doesn't say "here's how I made this Mars." It says: here's how to build any rocky body, any gas giant, any moon — where to get the real imagery, when to add true displacement versus just a bump, how to make the atmosphere read as haze rather than a hard ring, and how to land the body precisely in frame next to other objects without it floating off or hiding behind something. The hero image above is the scene that validated all of it: Earth with real continents, Mars with its rust surface and a thin atmosphere halo, the cratered Moon, and a ringed gas giant, with an orbital station thrown in for scale.

How it works

The whole philosophy is real maps, never procedural noise. Procedural planets always look fake up close, because real planets aren't noise — they're continents and craters and cloud bands that we recognize. So the skill sources actual equirectangular imagery and wraps it on a UV sphere whose default UVs already map equirectangular projection correctly.

The map data comes from two NASA-derived sources, both credited in the skill:

Solar System Scope for the color maps — equirectangular color maps (up to 8K) of Mercury through Neptune (CC BY 4.0, Viking/MOLA-derived), plus a Saturn ring alpha map.
Planet Pixel Emporium for grayscale elevation/bump maps — marsbump, moonbump, earthbump. These are the MOLA (Mars Orbiter Laser Altimeter) and LOLA (Lunar Orbiter Laser Altimeter) datasets, the actual laser-altimetry surveys of Mars and the Moon.

From there the recipe forks by body type. For a rocky body, the elevation map does double duty: it feeds a Bump node for fine shading detail and a real Displace modifier (over a simple subdivision) so the terrain physically breaks the silhouette — Olympus Mons actually pokes out, craters are real geometry, not a painted illusion. For a gas giant, there's no elevation at all; the bands live entirely in the color map, so displacement is skipped and Saturn just gets its rings.

The atmosphere is a separate sphere a few percent larger than the planet, with a material that's transparent except at the grazing angle. A LayerWeight → Facing output drives a color ramp into a mix between a transparent and an emission shader, so the glow only appears at the limb — a Fresnel rim halo. That's what sells "this body has air" without a volumetric.

The part I think makes it a real skill rather than a snippet is the bundle of reusable helpers in references/planet-toolkit.md: download, build_planet, add_atmosphere, add_rings, place_in_frame, and closeup. They're paste-into-execute_blender_code functions, plus a per-body cheat sheet — Mars gets thin rust atmosphere and MOLA relief, Saturn gets pale-gold haze and a ~26.7° tilt, Uranus rolls on its side at ~98°, and so on. Claude doesn't reinvent any of this per scene; it fills in the parameters.

The gotchas

These are the ones the skill captures because they cost real time the first time around.

Height maps have to be loaded as Non-Color, or the relief comes out wrong. This is the quiet one. If you load a grayscale elevation map as a normal sRGB color texture, Blender applies the color transform to it and your bump and displacement both go muddy and inaccurate — the elevations are simply wrong. The fix is a one-liner: set the image's colorspace_settings.name = 'Non-Color' before wiring it into the Bump and Displace nodes. The skill flags it twice because it's invisible until you notice the terrain doesn't match the real planet.

Strong displacement makes peaks punch through the atmosphere shell. Once the Mars relief is real geometry, the tallest features can poke out past the atmosphere sphere, leaving an ugly hard ring where terrain intersects haze. Two fixes, and the skill gives both: size the shell above the maximum displaced radius (base*scale + strength*0.5*scale), or widen the Fresnel color ramp so the halo reads as soft haze that swallows the intrusion rather than a thin detached band. The Mars closeup below is what it looks like when that's tuned right.

Getting a planet precisely "in frame" is harder than it looks — don't hand-roll camera vectors. My instinct was to compute the camera's right and up vectors and offset from there. That breaks the moment the camera has any roll. The skill's place_in_frame instead uses cam.data.view_frame(scene) to get the four actual frustum corners, interpolates between them bilinearly for the target screen position, and then verifies the result with world_to_camera_view — which returns normalized device coordinates where x and y should land in [0, 1] and z is depth. That depth value also tells you whether the body is hidden behind foreground geometry. The rule the skill states plainly: never assume a planet sits in frame — check the NDC.

Why a skill

I could have just kept the Blender Python for that one Earth/Moon/Mars scene lying around in a file. The reason to make it a skill instead is that the knowledge is reusable and the per-scene work is not. The hard-won parts — that elevation maps are Non-Color, that the atmosphere shell has to clear the displaced peaks, that camera placement needs frustum corners rather than basis vectors, that gas giants get no displacement — are the same for every planet I'll ever build. Encoding them once means every future scene starts from the validated version instead of from my first flat-decal mistake.

It's also built on top of a more general blender-scripting skill — probe the API instead of assuming it, isolate work in its own scene, build then render then look. Blender Planets is the planet-specific layer on that foundation, which is itself a small argument for how these skills compose: a general discipline at the base, a domain on top.

The skill is validated in production on the scene at the top of this post — Earth, Moon, Mars, and a ringed giant, all from real maps, with real relief and real atmosphere halos. Credit where it's due: the color imagery is from Solar System Scope and the elevation data from Planet Pixel Emporium, which packages NASA's MOLA and LOLA altimetry. The skill's job is just to put that data on a sphere correctly, every time.

This is one of a series of posts on projects built this way. The running list is on the projects page.

Building Plato's Atlantis in Blender — a Parametric Ring City

C. Wheatley — Thu, 09 Jul 2026 17:46:22 +0000

In Plato's Critias, Atlantis is laid out as a set of concentric rings — a central island crowned by the Temple of Poseidon, wrapped by alternating bands of water and land joined by bridges, sealed by a great outer wall, and pierced by a canal running out to the open sea. It's one of those descriptions that's basically a build spec already. So I had Claude write a single parametric Blender script that generates the whole city from that geometry, and rendered it a few different ways. This is a post about what the script does and how the renders turned out.

What it is

The scene is the city as Plato describes it, built from the centre out. A central acropolis carries the Temple of Poseidon. Around it run three pairs of rings — water, then land, then water, then land — each land ring scattered with buildings, all of it enclosed by a defensive wall and ringed by mountains. A canal cuts straight out through the rings to the sea.

The look is clean and stylized rather than photoreal — smooth marble-white platforms, a gold dome, red-and-gold roofs on the scattered structures, simple conical mountains. It reads more like an architectural model or a diorama than a photograph, and I think that suits a half-legendary city. Everything is driven by a config block at the top of the script, so the island radius, the number and width of the rings, the building count, and the direction of the canal are all just numbers you can change.

How it was built

The split of work was the usual one for these sessions: I decided what to build and judged whether each render looked right, and Claude wrote the Blender Python. The whole thing is one file, atlantis.py, that runs headless (blender --background --python atlantis.py) or from Blender's text editor, and writes a still at the end.

The geometry is generated procedurally, not modeled by hand. The rings and platforms are built with bmesh rather than primitives — there's a disc helper that lays down a solid cylinder for the central island, and a ring helper that builds a hollow annular band for each ring of land, both walked vertex by vertex around 96–140 segments. The script plans the concentric layout first, marching a radius outward and appending a (water, land) pair for each ring, then builds each band at the right inner and outer radius. A single huge sea disc underneath fills every water ring and extends out as the open ocean.

The buildings are scattered, not placed. For each land ring the script drops a set number of structures at random angles and radii — sometimes a round tower with a conical roof, sometimes a rectangular hall — picking from a small palette of marble, stone, and wall materials, with roofs in red tile or gold. It deliberately keeps a wedge clear where the canal runs so nothing gets built across the channel. Because it's seeded (the config fixes the random seed), the same layout comes back every run.

The centrepiece is the Temple of Poseidon, built explicitly rather than scattered: a stepped circular marble base, a ring of sixteen columns, an entablature and a rounded gold dome, topped with a small golden finial. The other set pieces follow Plato's text too — bridges span each water ring along the cardinal axes (skipping the one direction the canal occupies), and the great outer wall is a ring of stone capped and studded with towers, tipped in gold to stand in for orichalcum, the legendary metal Plato says sheathed Atlantis. A band of conical mountains encircles the whole thing.

Materials are plain Principled BSDF shaders set up in code — a palette of sea, land, stone, marble, gold, roof-red, wall, and mountain, each just a base colour with roughness and the odd metallic or transmission value. There are no image textures and no procedural node graphs; the clean diorama look comes entirely from flat-coloured materials under a single sun. The render is EEVEE (the script asks for EEVEE Next and falls back to plain EEVEE), at 1600×1000, with a single sun, a blue-tinted world for ambient light, and an elevated three-quarter camera tracked to the centre of the city. For the hero pass I dropped the sun low and warm to get the sunset light; that's a lighting choice for the shot, not something the script hardcodes.

One small thing worth noting from the code: the material socket for transmission got renamed across Blender versions, so the helper tries Transmission Weight first and falls back to Transmission. That's the kind of version drift that quietly breaks Blender scripts, and it's handled here by probing for whichever socket name exists rather than assuming one.

The renders

I rendered the scene a few ways by varying the camera and the lighting. The hero above is the sunset pass: a low warm sun raking across the rings, the gold dome catching the light, long soft shadows. It's the most flattering angle — close enough to read the temple and the red-roofed towers, low enough to feel like you're standing on the outer wall.

The daylight render here is the plan view — a higher, wider three-quarter angle under a plain blue sky that shows the whole concentric layout at once: the temple at dead centre, the three rings of water and land, the wall, and the mountains closing the ring. It's the shot that makes the Critias geometry obvious.

The third pass is an "underwater" variant — the same city under a heavy teal-green cast, as if the legend had played out and Atlantis had sunk. I should be honest about what that is: it's a colour-and-lighting grade of the same geometry, not a true underwater scene. There's no volumetric water, no caustics, no floating particulate — just the green tint and flatter light selling the idea. It works as a mood, but it isn't a simulation, and I'd rather say so than overclaim it. There's also a turntable that spins the city for a full rotation.

Notes

This one is mostly a geometry exercise: take a 2,000-year-old text that happens to read like a spec, turn it into a parametric generator, and see the legendary city come out the other end with its rings and bridges and gold-roofed temple in the right places. Because every dimension is a config value, it's less a single render than a little machine for making Atlantises — more rings, a wider canal, a different seed, and you get a different city that still obeys Plato. The clean stylized look is a choice the materials make for me, and the sunset pass is the one I'd hang on the wall.

This is one of a series of posts on projects built this way. The running list is on the projects page.

Atlases: 16 Interactive Learning Guides That Run Code in Your Browser

C. Wheatley — Tue, 07 Jul 2026 19:40:22 +0000

Atlases is a learning site: 16 long-form technical guides, each one a 12-chapter deep dive that you read in a browser tab while running the actual thing in another pane of the same tab. The databases atlas ships a real SQLite engine. The Python atlas runs CPython. The C++ atlas compiles C++. Nothing is a screenshot or an animated GIF pretending to be a terminal — it's the real interpreter, downloaded to your browser and running locally. It's live at atlases.vercel.app, and I built it with Claude as a pair programmer.

What it is

The pitch is "pick a topic, build the intuition." There are 16 atlases: Databases, Networking, Linux, Cryptography, Compilers, Observability, AI/LLM Engineering, FiveM/Lua/QBCore, Encoding & Wire Formats, Python, JavaScript, C++, C, Docker, n8n, and Coolify. That spread is deliberately personal — it's the stack I actually touch, from running a FiveM RP server to wiring up n8n workflows to deploying with Coolify, so the topics are the things I wanted a good reference for and couldn't find in one place.

Each atlas has the same 12-chapter spine: origin story, toolchain, the bedrock concepts, a working snippet library, a triage/troubleshooting section, and a roadmap of where to go next. That's 192 chapters across the site. What makes it more than a long blog is the interactive parts:

Real in-browser sandboxes. SQLite via sql.js, CPython via Pyodide, C and C++ via JSCPP, a JavaScript REPL, a working mini-shell, a Lua interpreter for the FiveM atlas, and a live PromQL playground for observability. All client-side — there is no backend, no code execution server, nothing to attack. Your code never leaves the browser.
Curated snippet libraries organized by what you're trying to do, not alphabetically.
Interactive troubleshooting trees that walk you from symptom to diagnosis to fix.
A quiz at the end of every chapter, with explanations rather than just a right/wrong.
Stack profiles — pick your context and the examples adapt as you read.

No signup, no ads, no tracking. Progress saves to localStorage, so the site doesn't need to know who you are to remember where you were.

How it was built

The stack is intentionally boring: Vite + React 18 + Tailwind, with react-router-dom for routing and lucide-react for icons. That's almost the whole runtime dependency list. Each atlas is a single self-contained .jsx file in src/atlases/ — db-atlas.jsx, python-atlas.jsx, and so on — lazy-imported and code-split in App.jsx so you only download the atlas you open. The landing page in src/pages/Landing.jsx just lists them. Adding a new atlas is a three-step move: drop the file in src/atlases/, add a lazy route in App.jsx, add a card on the landing page.

The content pipeline matches the pattern I use for everything: I decided what each atlas should cover and how it should feel, Claude drafted the chapters, and then every claim got a human fact-check pass before it shipped. The sandbox engines are off-the-shelf WASM/JS interpreters wired into React components, so the heavy lifting of "actually run SQLite in a browser" is sql.js doing its job — my work was the glue and the teaching around it.

Deployment is the easy part. The repo is on GitHub at denrod25-del/atlases, and Vercel auto-deploys every push to main. A small vercel.json handles the SPA rewrites so deep links to a specific atlas resolve correctly. npm run build produces a dist/ folder of static files that would deploy anywhere — Vercel just happens to be the zero-config option.

The gotchas

Facts about a fast-moving industry go stale, and a learning site that's wrong is worse than no learning site. Several atlases make time-sensitive claims — the current frontier model lineup, the latest C++ and C standards, the current PostgreSQL and LLVM versions, whether OpenTelemetry's GenAI conventions are stable yet. Those were correct when written and rot quietly. My fix is twofold. First, every fast-moving claim carries an explicit "current as of June 2026"-style stamp right in the text, so a reader can see exactly how fresh the fact is instead of trusting it blindly. Second, refreshing those stamps is now a recurring maintenance task rather than a one-time thing. A single pass already caught real drift: the frontier model lineup needed updating to the current Opus / GPT-5.5 / Gemini lineup, OpenTelemetry's GenAI semantic conventions were still experimental (not stable, as an earlier draft implied), and the FiveM ecosystem's "Overextended" had been renamed to CommunityOx. The lesson: date your claims so the rot is visible, and treat the dates as a checklist.

The site started out written for an audience of one. The first versions were personalized to me — examples referenced my Claw World RP server by name, the Linux sandbox had a hardcoded username from my own setup, and asides assumed you were, well, me. Great for a private reference, useless as a public site. Before launch I did a de-personalization pass: pulled the RP-server references, renamed the Linux sandbox's example user (and updated the challenge checkers that validated against that username — easy to miss, would have broken the exercises), and rewrote the personal asides into something a stranger could follow. If you build a tool for yourself and later want to share it, budget real time for stripping out the assumptions you didn't know you'd baked in.

Deep links break on static hosts unless you tell the host about your router. Because each atlas is a client-side route, hitting atlases.vercel.app/db directly — or refreshing on it — asks Vercel for a file that doesn't exist on disk, which is a 404. The fix is the SPA rewrite in vercel.json that points every unknown path back at index.html and lets React Router sort it out. It's a one-liner, but it's invisible until someone shares a deep link and it 404s for everyone who clicks.

What shipped

Atlases is live and public at atlases.vercel.app, with the source on GitHub at denrod25-del/atlases under an MIT license. Sixteen atlases, 192 chapters, real in-browser sandboxes for SQLite, CPython, C/C++, JavaScript, a shell, Lua, and PromQL, a quiz per chapter, troubleshooting trees, and dated facts you can audit. No signup, no ads, no tracking — just open a topic and start reading.

This is another entry in the series on projects built this way. The running list is on the projects page.

Scrapling MCP: Giving Claude Code a Real Web Scraper

C. Wheatley — Tue, 07 Jul 2026 19:40:04 +0000

Claude Code can read my files and run my shell, but out of the box it can't actually go get a page from the live web in a way that survives modern anti-bot defenses. A curl from the Bash tool gets you a 403 from anything behind Cloudflare. So I took an existing open-source scraper — D4Vinci/Scrapling — installed it locally, and registered its built-in MCP server with Claude Code. Now the agent has ten tools for pulling the real web: plain fetches, headless-browser fetches, stealth fetches that solve Cloudflare, and screenshots. The scraper isn't mine — I want to be clear about that. What I built is the local install and the MCP integration that hands those capabilities to the agent.

What it is

Scrapling is an adaptive web-scraping framework. The part I cared about for this is its fetchers: a fast HTTP client built on curl_cffi that impersonates real browser TLS fingerprints, a Playwright-backed fetcher for pages that need a real browser to render, and a "stealthy" fetcher built on patchright that bypasses anti-bot systems like Cloudflare Turnstile out of the box. It also ships a parser that "learns" a page's structure so your selectors keep working when a site redesigns. That whole engine is the maintainer's work, not mine.

What turns that library into something Claude Code can use is the MCP server Scrapling already bundles. MCP — Model Context Protocol — is the standard way an agent gets extra tools. Register an MCP server and its tools show up in the agent's toolbox alongside the built-in ones. Scrapling's server exposes ten:

get and bulk_get — fast HTTP fetches via curl_cffi, single or batched
fetch and bulk_fetch — full headless-browser fetches via Playwright, for JS-rendered pages
stealthy_fetch and bulk_stealthy_fetch — patchright stealth fetches that get past Cloudflare
open_session, close_session, list_sessions — persistent browser sessions across calls
screenshot — returns an actual image block of the rendered page

The design is deliberately token-conscious, which matters when the consumer is an LLM and every byte of the response eats context. The tools default to returning markdown with main_content_only=True, which strips the page chrome down to the article body (and sanitizes hidden elements, which doubles as a guard against prompt injection hiding in the DOM). You can pass a css_selector to narrow the result before it ever reaches the model — in my testing that cut the payload by roughly 71% on a content-heavy page.

How it was built

There wasn't much code to write here — the value was in the install and the wiring, which on Windows had a few sharp edges.

I cloned the repo to claude/Scrapling/ and installed scrapling[ai] into its own virtualenv at claude/Scrapling/.venv, on Python 3.14. That last part was a small gamble — 3.14 is new enough that I half-expected a dependency to have no wheel — but every package resolved, including curl_cffi, which shipped an abi3 wheel that works across Python versions. Then scrapling install pulled down the browser binaries: Playwright's Chromium and a headless shell into ~/AppData/Local/ms-playwright, with patchright reusing the same cache. That's roughly 700 MB of browser per Chromium build (more on disk once Playwright and patchright pull separate versions), which is the real cost of "can render and stealth real pages."

The integration itself is one block of JSON. MCP servers in Claude Code live in ~/.claude.json, and I added scrapling to the global mcpServers block — the same place the blender, unity, and pixellab servers already lived. It's a stdio server, so the config is just a command and args: the command points straight at the venv's scrapling.exe (C:\Users\skyea\claude\Scrapling\.venv\Scripts\scrapling.exe) with args ["mcp"]. Registering it globally rather than per-project means the scraper is available in every Claude Code session, not just one repo — which is what I wanted, since "go grab this page" is a need that doesn't belong to any single project.

The one non-obvious step: MCP servers are loaded when a session starts, so adding the block does nothing until you restart Claude Code (or re-run /mcp). After the restart it connected, and I ran every tool against quotes.toscrape.com to confirm — get and fetch returned content, stealthy_fetch came up clean, screenshot returned a real image block, and the session tools opened and closed a browser session as expected. All ten verified live.

The gotchas

Three real ones, each of which would have cost time if I'd skipped it.

Editing ~/.claude.json by hand is editing the file that runs Claude Code, so back it up first. That file holds the entire harness config — every MCP server, project history, the lot. A stray comma turns it into invalid JSON and the next launch is a bad time. Before touching it I copied it to ~/.claude.json.bak-scrapling, then made the edit. If the edit had broken anything, recovery was a one-line file restore instead of a debugging session. When the config file is the thing you depend on to debug, you don't get to debug your way out of corrupting it.

The server won't appear until you restart — adding the JSON isn't enough. MCP servers are read at session startup, so right after saving the config the scrapling tools simply weren't there, which looks exactly like a broken registration. The fix is just to restart Claude Code (or run /mcp), but knowing that up front saves you from "re-checking" a config that was already correct. I lost a minute to this before remembering it's load-at-startup, not hot-reload.

Python 3.14 in an isolated venv was a calculated risk that happened to pay off. Installing into a brand-new interpreter version is where dependency wheels go to die — a single package without a 3.14 build would have meant compiling from source on Windows, which is its own afternoon. It worked because the dependency tree had 3.14 wheels (and curl_cffi's abi3 wheel sidestepped the version question entirely). The thing that made the gamble safe wasn't luck, though — it was the dedicated venv. Because Scrapling lives in claude/Scrapling/.venv and nothing else, a failed or weird install couldn't contaminate any other project's Python, and the MCP command points at that exact interpreter, so there's no ambiguity about which environment the agent is launching.

What it does now

The scrapling MCP server is registered globally and connected, and all ten tools are live-verified: get / bulk_get, fetch / bulk_fetch, stealthy_fetch / bulk_stealthy_fetch, the three session tools, and screenshot. In practice that means inside any Claude Code session I can ask the agent to pull a live page and it actually can — fast HTTP for simple sites, a real headless browser for JS-heavy ones, stealth mode for the ones hiding behind Cloudflare, and a screenshot when I want to see the page rather than read it. The same capabilities are reachable from the shell too, via Scrapling's own CLI (scrapling extract get|fetch|stealthy_fetch URL out.md), which is handy when I'm not in an agent loop.

To be clear about the division of credit one more time: the scraper, the stealth, the adaptive parser, and the MCP server are all D4Vinci's Scrapling. My work was the local install on Windows/Python 3.14, the global stdio registration in ~/.claude.json, the backup-and-restart discipline around it, and verifying that all ten tools actually work end to end. The result is that the agent I already use every day can now reach out and read the modern web instead of bouncing off it.

This is one post in a series on projects built this way. The running list is on the projects page.

Rebuilding Space Invaders in Unity, One Verified Milestone at a Time

C. Wheatley — Tue, 07 Jul 2026 18:49:33 +0000

Space Invaders is the one almost everyone can picture: a grid of aliens marching side to side, dropping a row when they hit the wall, and speeding up to a heart-attack tempo as you thin them out. Tomohiro Nishikado built that for Taito in 1978, and the acceleration was famously a happy accident — the hardware just ran faster with fewer sprites to draw. I wanted to rebuild the whole thing in Unity, faithfully, and decided on purpose rather than by accident. I built it with Claude as a pair programmer, driving Unity live through the Unity MCP bridge, and shipped v1 with all nine milestones verified in Play mode.

What it is

This is a faithful recreation of the classic arcade loop, not a reimagining. A 5×11 grid of invaders marches in lockstep, drops and reverses at the screen edges, and accelerates as its numbers fall. You get one cannon, three lives, and the original one-bullet-on-screen rule — you can't spam shots, so every trigger pull is a small decision (the Rapid Fire and Twin Shot power-up capsules can lift that limit for a while, but the default is one shot at a time). Four bunkers sit between you and the swarm and erode from both sides as bullets and bombs chew through them. A mystery UFO drifts across the top on a long timer for bonus points, and clearing the grid starts a new, faster wave that begins one row lower. Lose all your lives, or let the swarm reach your row, and it's game over.

Around that core I allowed only modern game-feel polish — no new mechanics. There's a title screen and a game-over flow, a high score that persists to disk between sessions, screen shake, particle bursts on every kill, and a synthesized four-note marching bass that speeds up in lockstep with the swarm. The whole thing runs in Unity 6 (2D URP) and lives entirely under Assets/_Invaders/ with its own assembly definition and Invaders namespace, because it shares a Unity project with a completely separate game (a metroidvania called Pipe Knight) and the two had to never touch each other.

How it was built

The division of labor was the same one I've settled into: I decided what the game should be and verified each build by playing it; Claude wrote essentially all of the C#. We started with a brainstorming pass that became a design spec, then a plan that broke v1 into nine milestones, M0 through M8 — scaffolding, the swarm math, the game manager and UI, the player, the alien swarm, bunkers, the UFO, juice and audio, and a final flow-polish pass. Each milestone was implemented, then verified live in Play mode before moving on. The project grew to 26 scripts across that run plus several enhancement passes.

The piece I care most about is the swarm. The trickiest, most failure-prone logic — the acceleration curve and the edge-turn decision — got pulled out into a pure, dependency-free SwarmMath class so it could be unit-tested in EditMode with no Unity runtime at all. The speed-up is a single readable line: the step interval lerps from a slow maxInterval when all aliens are alive down to a fast minInterval when one remains, so fewer invaders literally means faster steps. That's the 1978 acceleration made deliberate. ResolveEdge handles the wall: it looks one step ahead, and if the leading alien would cross a limit, it signals a drop and flips the direction for the whole grid. The marching bass cadence is driven off the same step timer, so the music tightens up exactly in time with the swarm.

The second decision that mattered was making projectiles raycast rather than rely on collider overlaps. A player bullet travels at 18 units per second, and the bunker chunks are only 0.25 units thick. At that ratio, a fast-moving trigger collider can leap clean over a thin chunk between two physics frames and never register a hit. So PlayerBullet and AlienBomb don't translate-then-collide; each frame they cast a ray along the exact distance they're about to move, hit the first thing on the Alien or Bunker layer, and resolve through a small IHittable interface. No tunnelling, and it made alien hits robust as a bonus.

The gotchas

Three that cost real debugging time.

Unity freezes the game loop when its window isn't focused, which silently invalidates every runtime test. Driving Unity through MCP, I'd start Play mode, alt-tab to issue commands, and read back results — except frameCount had stopped advancing the moment Unity lost focus, so the swarm wasn't actually marching and every "verification" was a snapshot of a frozen frame. The fix is one line at the start of each play session: set Application.runInBackground = true. Without it, you're testing a paused game and don't know it. A related trap: script recompiles are deferred until you exit Play mode, so editing a script mid-session does nothing until you stop.

The swarm refused to spawn because of subscription timing. AlienSwarm listened for the game's Playing state in OnEnable, but that ran before GameManager.Awake had assigned its singleton, so the subscription either missed the event or hit a null. Moving it to Start helped, but the real fix was architectural: I handed all (re)start responsibility to a single LevelReset object that owns the clean slate — it clears projectiles, rebuilds the bunkers, recenters the cannon, and spawns the wave. The swarm no longer spawns itself, which also killed a double-spawn bug on restart. One object owning "what a fresh round looks like" beat sprinkling that logic across every component.

The HUD piled up in the center of the screen. All the score, high-score, and lives text stacked on top of each other in the middle instead of sitting in the corners. The cause was a zero-size RectTransform on the HUD parent: a center-anchored rect with no width or height, so every child landed at the same point. Stretching that parent to fill the canvas fixed it. The same family of bug bit again later — when I added a letterbox camera to frame the portrait-ish playfield on my very wide monitor, the HUD ended up out in the black side bars, because it was a Screen-Space-Overlay canvas spanning the whole window. Switching it to Screen-Space-Camera pinned the UI inside the pillarboxed game region. Canvas render mode is one of those settings that's invisible until it's suddenly very visible.

What shipped

v1 is complete and verified: title, play, game-over, and restart all work; the swarm marches, drops, reverses, and visibly accelerates as you thin it; the cannon fires one bullet at a time; aliens drop bombs; bunkers erode from both sides; the UFO awards its bonus; and the high score survived a full Unity restart (it loaded 1500 from disk on relaunch). On top of that I ran several enhancement passes — a player death sequence with hitstop, lives drawn as cannon icons, floating score popups, a CRT scanline overlay, pause and mute, on-screen touch controls so it's playable on an iPad, a top-five leaderboard with name entry, and weapon-drop power-ups (Rapid Fire and Twin Shot capsules that fall from killed aliens). Later I swapped the generated placeholder art for free Creative Commons sprites and audio from the open-source pivaders project, with attribution, so the final build reads like a proper space shooter rather than colored blocks.

The hero shot above is that final build — full swarm, eroding bunkers, the planet-and-stars background, and the touch buttons along the bottom. The credit for the design goes to Nishikado and the 1978 original; the work here is the faithful modern recreation of it, built one verified milestone at a time. This is part of an ongoing series on projects built this way — the running list is on the projects page.

MoneyPrinterTurbo, Locally: An AI Short-Video Generator on My Own Hardware

C. Wheatley — Tue, 07 Jul 2026 18:49:16 +0000

I wanted to see how far an AI short-video pipeline could run on my own machine: type in a topic, get a finished vertical MP4 out the other end, with no cloud LLM bill and no proprietary API keys. The answer is "all the way." I took the open-source MoneyPrinterTurbo project, got it running locally on Windows with Claude as a pair, swapped its language model over to a local Ollama instance, and generated a real 1080x1920, 27-second clip about the benefits of drinking water — script, voiceover, subtitles, stock footage, and all.

The project itself is harry0703/MoneyPrinterTurbo. None of the pipeline is mine. What's mine is getting it to run end-to-end on local hardware and working through the handful of things that broke along the way.

What it is

MoneyPrinterTurbo is a one-click AI short-video generator. You give it a subject or a keyword and it produces a finished short: it writes a script with an LLM, derives search terms from that script, pulls matching stock footage, synthesizes a voiceover, generates timed subtitles, and stitches the whole thing together with ffmpeg into a 1080p vertical MP4.

Concretely, the pipeline that ran on my machine looked like this:

Script — the LLM takes the topic ("The benefits of drinking water") and writes a short narration plus a list of visual search terms.
Footage — those search terms hit a stock-video source (I used Pexels) and the matching clips get downloaded into a local cache.
Voiceover — the narration is read aloud by a TTS engine (edge-tts, the free Microsoft Edge voices).
Subtitles — the audio is turned into a timed .srt that's burned onto the video.
Render — ffmpeg concatenates the footage, lays the voiceover and optional background music underneath, overlays the subtitles, and outputs the final MP4.

It's a Python MVC app. There are two ways in: a Streamlit WebUI on port 8501, and a FastAPI service on port 8080 (with Swagger docs at /docs). I drove it almost entirely through the WebUI.

How it was built

Getting it running locally was the whole exercise, so the "build" is really a setup-and-port story.

The environment. My default Python is 3.14, which the project rejects — it wants >=3.11,<3.13. uv sync solved that cleanly by provisioning its own Python 3.11.15 into a project-local .venv. ffmpeg was already on my PATH from a winget install. From there, the WebUI launches via .\webui.bat, which auto-selects the .venv Python and finds a free port in the 8501–8599 range.

The language model. This is the part I most wanted to keep local. The project supports a long list of LLM providers, but I didn't want to pay for any of them or hand over keys. So I pointed it at a native Windows Ollama instance running qwen2.5:7b on http://127.0.0.1:11434/v1 — free, unlimited, and entirely on my own RTX 3070. Script generation on the 7B model took roughly three and a half minutes per run. That's slow compared to a hosted API, but it's free and it never rate-limits.

The footage. Stock video is the one piece that genuinely needs an external service, since you can't synthesize generic B-roll locally. I used Pexels with a free API key. Everything else in the chain — the voice (edge-tts), the subtitles (edge), the render (ffmpeg) — is free and needs no key.

So the final working configuration is: local Ollama for the script, Pexels for the footage, edge-tts for the voice, edge for subtitles, ffmpeg for the render. The only thing leaving my machine is the footage search.

The gotchas

Three things cost real debugging time.

The Pollinations free tier is effectively unusable, so I switched to local Ollama. The config template's default pointed at Pollinations as a free LLM (my own config.toml has since been corrected to local Ollama, but a fresh clone still starts from the template default), and that default is broken two ways. The shipped pollinations_base_url (https://pollinations.ai/api/v1) returns a 405, and even after fixing it to the correct endpoint the code already knows about (https://text.pollinations.ai/openai), the anonymous free tier just returns 429 Too Many Requests on essentially every call. There's no usable free LLM hiding in there. The fix was to stop fighting it and run the model myself: local Ollama with qwen2.5:7b. Slower per request, but it actually completes.

The WebUI rewrites config.toml from memory, so you edit the disk file then restart. This one is a genuine trap. The running Streamlit app holds its startup config in memory and rewrites config.toml on every rerun, reverting any hand-edits you make to the file while it's running. I'd change the LLM provider on disk, the app would quietly stomp it back, and I'd wonder why my change had no effect. The fix is the right order of operations: stop the WebUI, edit config.toml on disk, then restart webui.bat so it reads the new values into memory on startup. (The rewrite itself isn't corruption — it's the app persisting UI defaults. It just fights you if you edit out of band.)

Streamlit's first-run email prompt blocks a headless launch. On its first run, Streamlit prints an interactive "enter your email" prompt, which hangs webui.bat when there's no one to answer it. The fix is to pre-create ~/.streamlit/credentials.toml with an empty email:

[general]
email = ""

With that file in place, the prompt is satisfied and the WebUI boots straight through.

(One more cosmetic one: during the render the Windows console spews UnicodeEncodeError: charmap can't encode ① lines. That's just loguru failing to print circled-number glyphs to the cp1252 console — the video renders fine regardless.)

What shipped

It works end-to-end, locally. The verification run produced a real final-1.mp4: 1080x1920, H.264 video with AAC audio, 27.0 seconds long, on the topic "The benefits of drinking water." The script was written by the local qwen2.5:7b model, the voice is edge-tts (Jenny), the subtitles are a generated .srt, and the footage came from Pexels — assembled by ffmpeg into a finished vertical short. Nothing in that chain cost a cent or required a proprietary LLM key.

All credit for the generator goes to the upstream MoneyPrinterTurbo project. My contribution was narrow but specific: getting it to run entirely on local hardware on Windows, replacing the LLM with a local Ollama model, and documenting the fixes — the Pollinations dead end, the config-rewrite ordering, and the Streamlit email prompt — so the next person can skip the part where I lost an afternoon.

NemoClaw on WSL: Running NVIDIA's Sandboxed Agent Stack Fully Local

C. Wheatley — Tue, 07 Jul 2026 18:42:25 +0000

NVIDIA's NemoClaw is a reference stack for running always-on AI agents inside hardened sandboxes. The examples all point at remote GPU instances and cloud inference. I wanted the opposite: the whole thing on my own desk — WSL, my RTX 3070, a local Ollama model, no cloud and no API keys anywhere in the loop. That took some doing, and the last mile came down to a self-signed certificate and a context-window budget. It now works end to end: I can chat with a sandboxed OpenClaw agent through the dashboard at localhost:18789, and every token of inference is served by a model running on my own GPU.

To be clear up front about credit: NemoClaw is NVIDIA's stack, Apache-2.0 licensed. The sandbox, the blueprint, the routed inference, the network policy — all theirs. What I did was get it running fully local on WSL and work through the two things that stood between "installed" and "actually answering."

What it is

NemoClaw runs an agent — OpenClaw by default — inside an NVIDIA OpenShell sandbox. OpenShell is the container layer that gives the agent a locked-down environment: an L7 egress proxy, a network policy that controls what it can reach, capability drops, and a routed inference path so the agent talks to a model through a managed hostname rather than punching straight out to the internet. NemoClaw wraps all of that in a single CLI that handles onboarding, lifecycle, and the blueprint that defines the sandbox.

The intended deployment is a remote GPU box with a hosted model behind it. My goal was to collapse that to one machine. Inference shouldn't leave the box; the model should be something I run myself; and the sandbox's safety properties should stay intact while I do it. On a Windows machine with an 8 GB GPU, that meant WSL2 for the Linux container host, Docker Desktop's WSL integration for the runtime, GPU passthrough so the sandbox can see the card, and Ollama on the host serving the model that OpenShell's routed inference points at.

How it was built

The host is WSL2 running Ubuntu 24.04, with Docker Desktop's WSL integration enabled for that distro. GPU passthrough works through the WSL2 CUDA path, so the sandbox sees the RTX 3070 — when it comes up it reports the card detected and the GPU policy preset active.

Installation is a script NVIDIA hosts. One wrinkle I hit: the piped curl … | bash form quietly no-ops when it ends up in a detached process, so I downloaded the installer to /tmp and ran it directly with the non-interactive and third-party-acceptance flags. The installer brings up Node 22 through nvm inside WSL, which sidesteps any Windows Node leaking onto the PATH. Provider choice doesn't happen during the install stage — you run nemoclaw onboard separately with NEMOCLAW_PROVIDER=ollama to point it at the local server.

The model is the interesting constraint. Stock Ollama loaded qwen2.5:7b at a 4096-token context, and the sandboxed OpenClaw agent needs roughly 7k just for its system prompt and tool definitions before it does anything useful — so a fresh session couldn't even start. The OLLAMA_CONTEXT_LENGTH environment variable wasn't honored by the Ollama version I had, so I built a derived model from a Modelfile with a PARAMETER num_ctx override. My first attempt aimed low to save VRAM: a derived model at num_ctx 24576, re-onboarded with NEMOCLAW_CONTEXT_WINDOW=24576 so the sandbox's config agreed with it. That failed — the agent's own reserve left too small a usable budget, and a fresh session died on a preflight-compaction error before the first message (more on that below). So I bumped both sides to qwen2.5's maximum: a derived model — qwen2.5-claw:7b — at PARAMETER num_ctx 32768, re-onboarded with NEMOCLAW_CONTEXT_WINDOW=32768. qwen2.5 uses grouped-query attention, which keeps the KV cache small enough that a 32k window still fits in 8 GB of VRAM (it sits around 5.5 GB). NemoClaw's start script supports that exact override — it's a documented env var in the entrypoint.

What you end up with is a sandbox (my-claw in my setup) in the Ready phase, running OpenClaw with its full tool set and the RTX 3070 passed through, with a dashboard forwarded to localhost:18789 on the Windows side via WSL2's localhost forwarding. If the gateway forward ever drops, nemoclaw my-claw recover brings it back.

The gotchas

Two real ones stood between "the sandbox is up" and "the agent actually replies." Both took real digging.

The self-signed inference.local certificate broke every agent turn. This was the big one. OpenShell signs its managed inference route — https://inference.local, the hostname the agent's traffic is routed through — with its own "OpenShell Sandbox CA." A plain curl or a standalone Node process validates that fine, because they honor NODE_EXTRA_CA_CERTS and the CA bundle is mounted in the sandbox. But OpenClaw's provider transport uses a custom undici dispatcher that does not honor NODE_EXTRA_CA_CERTS, so every agent turn died with SELF_SIGNED_CERT_IN_CHAIN. That dispatcher does respect the global rejectUnauthorized flag, so the fix is NODE_TLS_REJECT_UNAUTHORIZED=0. The catch: NemoClaw's environment allowlist passes NODE_EXTRA_CA_CERTS through to the gateway but filters NODE_TLS_REJECT_UNAUTHORIZED out, so setting it from outside does nothing — it has to be exported inside the container's nemoclaw-start entrypoint, before that filtering happens. So that's where it goes, gated behind a NEMOCLAW_TRUST_INFERENCE_TLS flag that defaults to 1 — so it's on by default (opt-out), and you set NEMOCLAW_TRUST_INFERENCE_TLS=0 to turn it off. This is acceptable precisely because of the sandbox's design: all the gateway's egress already runs through the OpenShell L7 proxy and the network policy, so the agent can't reach anything the policy doesn't allow regardless of TLS verification. The proper upstream fix is OpenClaw's dispatcher learning to trust NODE_EXTRA_CA_CERTS; until then, the entrypoint export is the local workaround.

The context window had to clear the agent's reserve, not just fit the model. This was the failure behind my first context attempt. With both the model and the sandbox set to a 24576 window, a fresh session died with "Preflight compaction required but failed." OpenClaw reserves a large slice of the context window for itself — at 24576, the reserve left only about 8000 tokens for a system-plus-tools prompt that was itself around 8090 tokens, so a brand-new conversation was already over budget before the first message. The fix was to stop being clever about fitting and go straight to qwen2.5's maximum: bump both the model's num_ctx and the sandbox's contextWindow to 32768. The rough rule I took away is that the usable budget is roughly half the configured window, so size the window for double what the agent's system prompt and tools actually cost.

One persistence note worth recording: the TLS export survives a container restart because it lives in the entrypoint, and the model's num_ctx survives because it's baked into the host Ollama model — but a full nemoclaw rebuild or re-onboard reverts the config side, so the entrypoint line and the NEMOCLAW_CONTEXT_WINDOW=32768 onboard both have to be re-applied after a rebuild.

What works now

The sandbox is up, the agent answers, and the inference is entirely local. I confirmed the dashboard chat end to end with a headless browser driving the real UI at localhost:18789 — sent a prompt, the sandboxed OpenClaw agent replied through the browser, with the completion served by qwen2.5-claw:7b on my own GPU. No cloud endpoint, no API key, nothing leaving the machine for inference. The agent's full tool set is available and the sandbox's network policy and proxy are doing their job around it.

One honest caveat: the CLI openclaw agent path still falls back to an embedded mode rather than connecting to the gateway over its websocket, so the browser dashboard is the way in that actually works. For a local single-user setup that's fine — the dashboard is where I'd be anyway.

The credit split stays the same as where I started: NemoClaw, OpenShell, and OpenClaw are NVIDIA's and the OpenClaw maintainers' work. Mine was getting the whole stack running on one Windows machine through WSL — local Ollama, GPU passthrough, the right context budget — and tracking the self-signed-cert failure down to the one entrypoint line that fixes it. The payoff is a hardened, always-on agent sandbox that runs start to finish on hardware I own.

This is one post in a series on projects built this way. The running list is on the projects page.

PDF to Podcast, Locally: Running NVIDIA's Blueprint Without Their Keys

C. Wheatley — Tue, 07 Jul 2026 18:42:08 +0000

NVIDIA shipped a neat blueprint called pdf-to-podcast: feed it a PDF and it generates a two-host podcast — a real audio file of two voices discussing the document, complete with a planned outline and back-and-forth dialogue. The catch is that out of the box it wants NVIDIA NIM endpoints for the language model and ElevenLabs for the voices, both of which mean API keys and per-call billing. I wanted to know whether the pipeline itself was good, and then whether I could run the whole thing on my own machine with no NVIDIA or ElevenLabs accounts at all. So I cloned it and built a local-stack overlay. Credit where it's due: the pipeline, the agent flow, the whole "outline then dialogue then audio" shape is NVIDIA's work. What I did was swap the cloud pieces out and fix the things that broke when I did. I built the overlay with Claude as a pair programmer.

What it is

The original is a multi-service blueprint. A document goes in, a Docling-based service extracts the text, an agent service summarizes it and plans an outline, then turns that outline into a two-speaker conversation, and a TTS service renders the conversation to audio. The services talk over Redis and store artifacts in MinIO. You POST a PDF, poll a status endpoint, and eventually pull a finished audio file. It's a genuinely good pipeline — the part I wanted to keep.

My goal was narrow: run that exact pipeline with zero NVIDIA and zero ElevenLabs dependencies. The overlay is seven files. The language-model layer gets a provider field so each role can route to Anthropic, OpenAI, Ollama, or the original NVIDIA NIM, and models.claude.json wires the three roles the blueprint already splits work across — reasoning, iteration, and json — to tiered Claude models. The TTS service gets its ElevenLabs calls replaced with Kokoro, an open TTS model that runs locally and renders 24 kHz mono audio. The result is the same blueprint, the same API, but every external call now hits either the Anthropic API or a model running on my own machine. With the right .env, a POST of a PDF comes back as a playable WAV and nothing went to NVIDIA or ElevenLabs.

How it was built

The script side uses tiered Claude, and the tiering isn't something I invented — the blueprint already separates its LLM calls into three roles, presumably because the authors knew not every step needs the same horsepower. The overlay just maps those roles to Claude models: Sonnet for the heavy reasoning (summarizing the document, planning the outline), Haiku for the cheap iterative folding steps, and Sonnet again — at a larger token budget — for the final structured-JSON step that emits the actual dialogue. That last assignment was a lesson, not a default; more on that below.

The voice side is Kokoro. The TTS service loads one Kokoro pipeline once, maps two speaker slots to two Kokoro voices (the defaults are af_heart and am_michael), and renders each dialogue turn. The two voices alternate so the output sounds like a conversation, not a monologue. The audio is written out as a single 16-bit PCM WAV through soundfile, which matters because of a bug I'll get to.

For scanned PDFs there's an easyocr path. Plenty of the documents I actually wanted to feed it are image-only scans with no text layer — the extractor would otherwise grab nothing useful (or worse, grab a watermark). The OCR workflow renders the target pages to images, runs easyocr over them, rebuilds a clean text-layer PDF, and feeds that into the pipeline. It's slow on CPU and it reads code and symbols poorly, but for prose it produces text clean enough that the summarizer is happy.

The division of labor was the same as my other projects: I decided what the overlay should do and made the calls about which model goes where, and Claude wrote essentially all of the code and the tests.

The gotchas

Three real ones, each of which cost actual debugging time.

A "3-minute podcast" came out 42 minutes long. This was the one that genuinely surprised me. The outline step plans segment durations in seconds — a sensible two-minute plan might be segments of 20, 30, 30, 25, and 15 seconds. But a downstream step stored those numbers into a field that the rest of the pipeline treats as minutes, multiplying by a per-minute word budget. So a 2-minute request quietly became a 21,600-word target and produced a 42-minute monster. The fix is a normalize_segment_durations step that rescales whatever numbers the model emits so they sum to the requested total, unit-agnostic, before anything downstream reads them. On top of that there's a hard cap, cap_dialogue_words, set at WORDS_PER_MINUTE = 130 (Kokoro's real speaking rate), that trims the generated dialogue down to the word budget while always keeping the final sign-off turn. After both fixes, in my testing a 3-minute request lands at about 3.04 minutes regardless of how verbose the source document is. The tradeoff is that very wordy content generates-then-trims, which wastes some tokens, but a request for N minutes now reliably yields roughly N minutes.

The model kept emitting JSON that wouldn't parse — so I stopped trusting it to. The final step asks the model to re-emit the entire conversation as one strict JSON object, and that turned out to be the architecturally fragile part of the whole pipeline. It would return the dialogue as a JSON string (double-encoded), and that inner string was itself malformed — unescaped quotes inside the text, mangled unicode, the occasional "K&R" breaking the parse. A strict json.loads rejects all of it. The fix came in layers: first bump that role to Sonnet (Haiku failed it outright, returning a scratchpad with the dialogue field missing); then, when the string is still malformed, fall back to json-repair; and finally an entry sanitizer that rebuilds the dialogue list by hand — keeping only entries with real text, coercing a missing speaker by alternating from the previous turn, and unescaping the text. After the sanitizer the step is structurally unable to fail schema validation no matter what the model hands back. Verified on real failing data in my run: 51 entries, zero invalid.

The key wiring resolved to empty even though it was set. The compose file originally interpolated ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY} from the shell. My shell exports an empty ANTHROPIC_API_KEY, and Docker Compose lets a shell variable shadow the one in .env — so the value resolved to empty string and every Claude call failed for no obvious reason. The fix was to give the agent service env_file: [.env] and delete the interpolation line entirely, so the key is read straight from the file. I confirmed it by checking the key length inside the running container (108 characters, not zero). It's the kind of bug that looks like an auth problem and is actually a config-precedence problem.

(There was also a smaller one worth flagging: the original TTS service concatenated audio at the byte level, which corrupts the WAV because each turn carries its own header. Rendering all the samples and writing a single WAV header — with 350 ms of silence inserted between turns — fixed both the corruption and the pacing.)

What works now

It runs end-to-end on a stack with zero NVIDIA and zero ElevenLabs keys. A smoke test against a sample PDF produced a valid 24 kHz mono 16-bit WAV through the API — POST the PDF, poll status, GET the audio — using only an Anthropic key and local Kokoro. The duration normalization and the hard cap mean a requested length actually maps to roughly that length: the C++ chapter that once overshot to nearly 8 minutes now lands at 3.04 minutes for a 3-minute request in my run. Both text PDFs and scanned image-only PDFs work, the latter via the easyocr path. The JSON-repair-plus-sanitizer chain holds up against the malformed output the model genuinely produces.

It's not perfect. The fragile part is still the final "re-emit everything as strict JSON" step — I made it un-failable, but un-failable is not the same as elegant, and a future version should probably stop asking the model to round-trip the whole conversation through JSON at all. TTS on CPU is slow (no GPU is wired into that container yet), and the OCR path reads code and symbols badly. The large-document story is also weak: the pipeline is built for short documents and sends the whole text in one summarize call, so a 900-page reference blows past the context window — for now the answer is to trim to the chapter you actually want. But for the thing I set out to prove — that NVIDIA's pdf-to-podcast blueprint can run, end to end, on a fully local stack with none of the keys it asks for — it delivers, and it produces a real audio file at the length I asked for.

This is one post in a series on projects built this way. The running list is on the projects page.