Google Built a Three.js Compiler Because It Does Not Trust the Code an AI Writes

A compiler turns code into something else so it can run where the original could not. Google announced one on Tuesday for a narrow, strange job: taking the Three.js a language model wrote for you and turning it into a 3D file before it ever executes in front of a user. The project is called Three-Live. It is Apache-2.0, and the reason it exists sits in the second paragraph of Google's announcement, which states that "runtime AI-generated code is not trusted, and requires security sandboxing for safe execution."

Script in, asset out

Three.js is the library most models reach for when you ask for a 3D scene in code, and they are good at it now. A mesh, a material, two lights, an animation loop. Three-Live takes that script, runs it somewhere contained, reads the scene graph it produced, and serializes the result in memory to binary glTF (GLB), the container the free-asset pipelines already speak, plus uncompressed USDZ for Apple. Google says the serialization typically takes two to five milliseconds. What reaches your renderer is a file. Files do not make network calls.

The containment is most of the engineering. In the browser your script runs inside a Web Worker, with an opaque-origin sandboxed iframe as an optional second layer, and fetch, XMLHttpRequest, WebSocket and dynamic import() are stripped before the code gets control. Off the web there is no browser to borrow. Android, iOS, macOS and the command line run the same scripts through a Rust compiler that embeds Boa, an ECMAScript engine also written in Rust. Both paths enforce execution timeouts and geometry quotas, counted in vertices, triangles, meshes and procedural textures. A model that decides a coffee table needs four million triangles gets stopped by a number.

What you actually put on the page

The web half ships as a custom element, <three-live>, modelled on Google's own <model-viewer>. Behind it sits a zero-dependency WebGL2 renderer handling PBR shading, studio HDRI reflections, SSAO, bloom and shadow mapping. AR handoff goes to Android Scene Viewer, Apple AR Quick Look or WebXR, depending on what the visitor is holding. Inline scripts can be edited by the client, so they need an explicit allow-client-scripts opt-in. Generate the script server side instead and script-src covers it.

The headset half is a second element, <xr-live>, and it is the more interesting one. It adds 6DoF hand gestures, spatial DOM projection so ordinary HTML cards hang in the room beside the model, and voice or text to 3D synthesis inside a running WebXR session. Behaviour rides in the asset rather than in code. userData.interactivity maps to KHR_interactivity, and userData.xr carries traits such as grab, scale, billboard and anchor. Android gets a Kotlin SDK feeding ByteBuffers to Filament. iOS and visionOS get a Swift package targeting RealityKit.

The announcement is behind the repository

Google's post introduces v1.0.0 as a Developer Preview, a release GitHub dates to October 6. The release list on github.com/google/three-live reads v1.0.0, v1.1.0, v1.1.1 and v1.2.0, and the changelog dates 1.2.0 to November 3, the same day the post went up. npm is further along: three-live 1.2.1 was published at 03:53 UTC on November 3, about 15 hours before the post went live at 11:30 a.m. Pacific, and 1.2.2 followed at 17:17 UTC on November 4. The post's own copy-paste snippet pins three-live@1.0.0 on jsDelivr, and npm has never carried a 1.0.0, so that script tag returns a 404. The version you are being introduced to is not one you can install.

The gap matters, because 1.2.0 is where the spatial work landed. It expanded the XRSpatial module to 14 plugins across web, Android and iOS. Among them: a point-to-point tape measure with live bounding-box callouts, surface and socket snapping, a gaze-dwell selector with a refractory cooldown, and an exploded-view mode for CAD assemblies. None of it appears in the blog post. The bundle figures drifted too. The announcement quotes roughly 45 KB gzipped for the standard build, and the screenshot embedded in the post shows a 45.0 KB badge. The playground it links to read 53.2 KB on the morning of November 4, then 58.6 KB once 1.2.2 shipped that afternoon.

Read the allowlist before you point an agent at it

The repository is built to be read by the things it refuses to trust. An AGENTS.md sits at the root, there is a skills directory, and the playground gathers /llms.txt, /llms-full.txt, a cookbook and a SKILL.md under a heading calling them LLM and coding agent context feeds. The compiler is built around a declarative subset of Three.js, listed as allowed THREE.* constructors in docs/llm-guide.md. Anything outside that list degrades instead of failing: shaders fall back to standard materials, unknown classes become silent no-op proxies, and the only record is a console warning. Read that file first. The licence means nothing stops you.

Keep the scale in view: 134 commits, one human contributor plus a GitHub Actions bot, 20 stars, and a README line saying this is not an officially supported Google product. The post's first paragraph says the code was "written entirely by Google Antigravity, in partnership with one former software engineer turned product manager." So a tool built to distrust AI-written code was itself written by an AI. Which is a little funny, and also the point: the compiler got reviewed and shipped once, while the scripts it handles would otherwise run fresh in every visitor's browser. Google calls it a simple, unofficial companion to XR Blocks, the larger Android XR framework whose October release brought WebGPU to its desktop simulator. That is honest. XR Blocks is the platform bet. Three-Live is a smaller idea with a harder edge. Treat the model's output as hostile, and ship a file instead of a script.

Plenty has been written here about AI writing WebXR, back to agents that build and debug whole scenes in April. The part left open was what happens when that generated code reaches a stranger's browser. This is the first answer that does not ask you to be brave about it. The code never gets there.