I spend a lot of time working on a real game built with Three.js. Most days that means looking at things that don't make very good videos: frame time, shaders, asset loading, browser differences and whatever has made a phone warmer than it should be.

Over the last few months, something else has become difficult to ignore. I open X and find another browser game made with an AI coding agent. Usually several. Driving games, shooters, small physics experiments, strange little worlds. Many of them use Three.js and some are already much better than I would expect from something that started with a prompt.

After seeing enough of them, I looked at the npm downloads for three.

The package had 14,134,422 downloads between 2 and 8 August 2026. Just over two million per day. The equivalent week in 2025 had 2,194,558, while a week in 2020 had 227,473.

This is ridiculous when you think about it.

Of course, fourteen million npm downloads doesn't mean fourteen million games. It includes automated installs, CI and people repeatedly creating projects they will never open again. I still think AI is responsible for a large part of the recent growth. The timing matches what I see every day, and most of the agent-made 3D games I see begin by installing the same package.

There are also already millions of play sessions happening inside Three.js games every day. I get to see that scale from inside the development of one of them. The npm number is surprising, but the audience for browser games is not theoretical.

Why agents keep reaching for Three.js

Three.js gives you scenes, cameras, geometry, materials, animation, loaders and renderers without deciding how the whole game must be built. Everything lives in JavaScript and there are years of small examples showing how each part works.

That happens to be a very comfortable environment for a coding model. It can create a scene, run the page, read the browser error, change the code and try again. The result is visual, so an agent can also take a screenshot and notice that the camera is inside the floor or the car is facing backwards. This still happens quite often.

I like Three.js for a similar reason. It stays close enough to the browser that I can inspect what is happening, but I don't have to build a renderer before I can put something on the screen. It also means the finished game is a link. Somebody can open it a few seconds later without installing an engine, launcher or enormous update.

The library itself is now being developed with AI too. mrdoob has been very open about using Claude for experiments and contributions. The official r183 release credits mrdoob and Claude for work including BezierInterpolant, image-based lighting and renderer changes. r184 includes more work credited to them, including depth textures, an SSGI ball-pool example, clouds and atmosphere, roller-coaster banking and fixes.

He also posted an experiment where Claude ported a racing starter kit to Three.js. Other people immediately started changing it. I find this much more interesting than treating AI as something outside the project. It is already being used by the people building the library.

Three.js has fifteen years of work behind it, from many people who cared about browser graphics long before an agent could generate a scene. AI can now use that work, contribute to it and make it accessible to people who would never have started a 3D project on their own.

What happens after the first prototype

The short AI-made game on X is the beginning. Working on a game for a long time changes the things you notice.

When I look at generated Three.js code, I look for allocations inside the animation loop, a new material for every object, expensive shadows, GPU resources that are never disposed and collision code that depends on the frame rate. None of these ruin a six-minute prototype. They become important when the scene grows, the game stays open for an hour or somebody plays it on an older phone.

AI is useful during this part as well. It can follow a problem through several files, explain unfamiliar renderer code and produce a fix quickly. It just needs direction. If nobody measures the frame time or checks the memory use, a model is quite happy to leave working code alone.

This is where dedication still shows up. More people can now reach the first playable version, which is a big change. The better games come from the people who continue after that version and spend time on controls, feedback, performance, art and all the small decisions that make the game feel deliberate.

Generating a GLB without Blender

Code generation is also starting to blur the line between game code and game assets.

Three.js has an official GLTFExporter that exports a scene as glTF or a binary GLB. It supports meshes, materials, textures, skins, morph targets and animation clips. An agent can construct an object in code, add animations and export a portable asset without opening a traditional 3D editor.

A very small version looks like this:

mesh.name = 'GeneratedThing';

const clip = new THREE.AnimationClip('float', 1, [
    new THREE.VectorKeyframeTrack(
        'GeneratedThing.position[y]',
        [0, 0.5, 1],
        [0, 0.4, 0]
    )
]);

const glb = await new GLTFExporter().parseAsync(scene, {
    binary: true,
    animations: [clip]
});

This only moves an object up and down. The same file format can contain a rig, skinning, morph targets and several complete animation clips. A more useful generator could create exact collision geometry, predictable origins, controlled polygon counts and repeatable variations. Because the source is code, it can be reviewed and versioned with the rest of the game.

There is another route now: generate the mesh from an image or text. Microsoft's TRELLIS can produce several kinds of 3D representation from text or an image. Tencent's Hunyuan3D 2 separates shape and texture generation and can save the result as a GLB.

I started listing more systems here and the article quickly turned into a survey of 3D generation tools. That needs its own post, preferably after actually putting several outputs into a game. The short version is that these models are already useful for props, prototypes and reference material. They also produce meshes with excessive polygon counts, awkward topology and details that only make sense from the reference camera. Games eventually show every side of an object.

Why the browser matters

The part I keep coming back to is how little distance there is between making a browser game and letting somebody play it.

An agent can write the code, run it in a real browser, inspect the result and deploy it. A developer can send the link immediately. That makes experiments cheap, and it also produces a large amount of public Three.js code: projects, fixes, shaders, loaders, exporters, bug reports and examples of what did or didn't work.

Future coding models will have much more Three.js material to learn from than the previous ones did. They will generate more projects, some of those projects will be corrected and published, and the useful corrections become part of the ecosystem. I don't think we need to make this more complicated than it is. There is more working material every month and the tools are getting better at using it.

I don't know how much of the jump from 227,000 weekly downloads to fourteen million belongs to AI. I do know that my X feed has changed, the Three.js releases themselves now contain work made with Claude, and a good 3D experiment can become a playable link before the idea has had time to become sensible.

I already use both of these approaches and they are awesome. Generating a GLB from code, including the animations, is surprisingly easy. Image-to-3D also means an experiment can have a good-looking asset almost immediately, even if I replace it later. It is much easier to judge whether an idea is worth continuing when it already looks like something instead of a collection of boxes.