ManimGX: A Rust GPU Engine That Lets Coding Agents Render Manim-Style Math Videos

ManimGX is a new open-source animation engine that re-implements the Python API of Manim, the library behind 3Blue1Brown-style math videos, on a Rust core that draws with the GPU through wgpu. Its pitch is blunt: it is built for coding agents. An agent writes a short Python scene, runs one command, and gets back an MP4. The repository from Academa passed 1,600 GitHub stars within about twelve days of its creation on October 5, 2026.

This post explains what it is, how to try it today, what its headline speed number means, and the two catches worth knowing before you build on it: the GPL-licensed wheels and the "mostly Manim, not exactly Manim" compatibility story. Everything below comes from the project README and its documentation unless stated otherwise.

ManimGX at a glance

Why would an agent need a different Manim?

Manim is the standard tool for programmatic math animation. You describe shapes, equations and transformations in Python, and it renders them frame by frame. That makes it attractive to a coding agent: the output is code, so a model can write it, read the error, and fix it. We covered the same code-not-diffusion idea in how Opus 5.5 viral videos are made, and the broader agent video toolchain in OpenMontage and Hyperframes.

The pain point for agents is the loop. A model rarely gets a scene right the first time, so it renders, looks at the result, and tries again. When one render takes minutes, ten iterations take a long afternoon. ManimGX is aimed squarely at that loop: make the render fast enough that an agent can iterate on a clip the way it iterates on a unit test.

Two design choices follow from that. First, the engine ships agent-readable setup instructions in an llms.txt, so you can tell an agent to read the file and install the tool itself. Second, there is a manimgx inspect command that produces storyboards and 2D layout checks, which gives a model something to verify besides "the process exited with code zero". Layout checks matter because the classic failure of generated animation code is overlapping text or objects drifting off screen, and a model that cannot see the frame will not notice.

What it looks like in practice

The README describes scenes as ordinary Python classes with a construct method, rendered from the command line. The shape is familiar to anyone who has seen Manim:

import manimgx as m

class Hello3D(m.ThreeDScene):
    def construct(self):
        cube = m.Cube()
        self.play(m.Create(cube))
        self.play(cube.animate.rotate(1.0))

pip install manimgx
manimgx render scene.py

We have not run this snippet ourselves, so treat the class and method names as illustrative and take the exact API from the documentation. The README confirms the pieces that matter: scenes subclass something like m.ThreeDScene, .animate chains work, keyword arguments and static typing are supported, 2D and 3D can be mixed in one scene, and self.say() syncs narration to the animation.

The showcase clips

The project publishes a gallery of rendered examples. These two show the range: a derivative scene with a tangent sliding along a curve, and the Lorenz attractor traced in 3D.

Tangent line sliding along a curve while its slope traces the derivative, rendered with ManimGX Image: ManimGX (Academa)

Lorenz attractor butterfly traced in 3D by an agent-written Python scene Image: ManimGX (Academa)

Other showcase entries listed on the repository page include a Fourier series drawing the outline of pi, complex-function grid maps, a Hopf fibration and a catenoid-to-helicoid morph. All are the project's own renders, which is useful for judging visual quality but not proof of how often an agent gets such a scene right unaided.

The 90x speed claim, read carefully

The README's headline number: a 36.2-second video made of five 1080p60 scenes rendered in 3.08 seconds on an Apple M4 Pro. The project reports that as roughly 90.6 times faster than ManimCE, 11.5 times faster than ManimGL and 18.7 times faster than Blender Workbench, measured from launch to finished MP4.

The benchmark chart on the project site lists total render times of 3.08 seconds for ManimGX, 35.28 for ManimGL, 57.61 for Blender Workbench, 278.83 for ManimCE and 601.40 for Blender EEVEE. Those figures are consistent with the ratios above.

What we can and cannot say:

• Source: the numbers come from the maintainers, with scripts in the repository's benchmarks folder. We did not rerun them.
• Hardware: one Apple M4 Pro. A GPU-bound renderer will behave differently on an integrated Linux laptop or a CI container with a software rasterizer. The README itself lists Mesa lavapipe among the Linux components, which suggests a CPU fallback exists, but we have no numbers for it.
• Workload: five clean math scenes. Heavy LaTeX layout, very large meshes or long videos may shift the ratios.
• Startup counts: because timing runs from launch to MP4, a fast startup in a compiled binary is part of the win, and it matters for short agent iterations.

The sensible reading is that a large speedup is plausible for a GPU renderer against a CPU-oriented Python one, and that you should measure your own scenes before planning around 90x.

License: the catch most people will skim past

The ManimGX code is MIT-licensed. The README then states that its native wheels include x264 and are GPL-3.0-or-later as a whole, and that bundled components keep their own licenses, including FFmpeg (LGPL-2.1-or-later), Noto fonts, and Mesa lavapipe on Linux. Complete source is attached to each GitHub release as a manimgx-X.Y.Z-source.tar.xz.

What that means in practice:

• Rendering videos for yourself, a course or a channel is not affected: the license covers the software, not the clips it makes.
• If you ship the wheels inside a closed-source product or a hosted service that distributes them, talk to someone who knows GPL obligations first. This is general guidance, not legal advice.
• The pure MIT source is a separate matter from the prebuilt binaries, which is why the README spells the split out.

ManimGX versus the Manim you already use

The ManimCE and ManimGL timings are the ManimGX project's measurements. Check the official Manim Community docs for what the established library offers, including its larger ecosystem of plugins and years of community answers. An agent trained on lots of Manim examples will write fluent ManimCE; a re-implementation can fall short wherever it diverges, and that is the main practical risk.

What people are asking

Will my existing Manim scenes just work? Probably many will, but the project does not claim full compatibility. Its docs include a guide for people coming from ManimCE that lists behavioral differences. Start with your simplest scene, render it in both, and compare frames.

Does it replace a video editor or an AI video model? No. It renders mathematical and diagram-style animation from code. It sits beside the agent video tools we cover in video-use with Claude Code and Claude dashboards and motion, and fits best where precision matters more than photorealism.

Is it stable? It is twelve days old. The repository shows about 190 commits, one open issue and nine open pull requests at the time of our check, with a changelog on the project site. Expect the API to move. The Hacker News thread for the project was small when we looked (10 points, 3 comments), so there is little independent hands-on feedback yet.

Why does Academa care? Academa is also the group behind an LLM-integrated calculus course we covered in Academa.ai's multivariable calculus launch. A fast, scriptable animation engine fits a company that wants to generate explanatory video at scale. That is our inference from the two projects, not a stated motive in the README.

How to try it safely this week

1. Create a fresh virtual environment with Python 3.13 or newer and install the package with pip.
2. Ask your coding agent to read the project's llms.txt and write a ten-second scene for a concept you already understand, such as a derivative or a matrix transformation.
3. Render it, then run manimgx inspect and let the agent read the layout report before you look at the video.
4. Time the render against ManimCE on the same scene on your own machine.
5. Keep the first experiments off any product you plan to distribute until you have read the license section above.

A reasonable prompt to start with: "Read the ManimGX llms.txt, then write a scene that animates the quadratic formula by completing the square. Render it, run inspect, fix any overlaps, and report the render time."

The bottom line

ManimGX is interesting less for the Rust than for the problem it picks: making a creative tool fast and legible enough for a model to drive in a tight loop. The claimed speedup, the inspection tooling and the llms.txt all point the same way. What is unproven is how closely it tracks real Manim code, how it performs off Apple silicon, and how well it holds up as the API changes. It is worth an afternoon if you make math or explainer video; it is too new to bet a pipeline on.

For the wider picture of agents that produce video from code, see Voyager's creative agent harness and Karpathy on understanding LLM outputs through diagrams and video. Follow @explainx_ai for updates as the project matures.

Related reading

• How Opus 5.5 viral videos are made: code, not diffusion
• OpenMontage: agentic video production with Claude Code
• Hyperframes: HTML to video for AI agents
• video-use: Claude Code AI video editor guide
• Academa.ai multivariable calculus course
• Voyager creative agent harness
• Sources: ManimGX repository, Manim Community docs, Hacker News thread

Details reflect the repository and README as of October 17, 2026; versions, benchmarks and licensing notes may change.