3Blue1Brown's Manim Hasn't Shipped Since 2024. Its Community Fork Just Proved That's Fine

If you search GitHub for "manim" right now, you'll land on two different repositories, both called Manim, both MIT-licensed, both claiming to be an "animation engine for explanatory math videos," and both, confusingly, correct. One of them just shipped a release six days ago. The other hasn't tagged one since December 2024.

That split — 3b1b/manim versus ManimCommunity/manim — is not a fork drama in the usual open-source sense of a hostile takeover or a license dispute. It's something more interesting: two codebases with the same name, the same origin, and the same core idea, that have quietly optimized for opposite audiences for six years, and the gap between them just got wide enough to matter to anyone deciding which one to pip install.

What happened

3b1b/manim sits at roughly 91,000 GitHub stars and was pulling in over 2,000 new stars in a single week as of this writing — trending-page numbers, not vanity metrics, and unusual for a six-year-old repository with no recent release. It's the original codebase, written by Grant Sanderson, the creator of the YouTube channel 3Blue1Brown, as a personal tool to produce the animations in his videos. Its most recent tagged release is v1.7.2, from December 13, 2024. As of this writing, that's about twenty months of no versioned release, against 464 open issues and 29 open pull requests sitting in the repo.

Meanwhile ManimCommunity/manim — the community-governed fork, sitting around 40,000 stars — shipped v0.21.0 on August 10, 2026, according to its PyPI release history. That's six days before this article. The release adds first-class support for Typst as a text and math markup renderer alongside (and potentially instead of) LaTeX, cuts NumPy array-hashing CPU time by 94–98% through a caching rewrite, adds parallel partial-movie-file encoding via a new max_inflight_encoders setting, and reports a 2.2x rendering speedup on animation-heavy scenes through its Cairo backend. It also ships breaking changes — Code mobject color handling now delegates to Pygments instead of accepting custom overrides, and Camera.convert_pixel_array() lost an argument.

Two things are true at once here. The original repo is the one with the stars and the name recognition, because it's the one Grant Sanderson's videos are built with and the one people find first. And the actively maintained, currently-shipping, currently-refactoring codebase is the fork. That inversion is the actual story, and it's one neither repo's README fully prepares a newcomer for — both explain the split exists, but neither tells you what it costs you in practice to guess wrong.

What Manim actually does

Strip away the fork politics and Manim (either version) is a Python framework for turning code into precisely-timed vector animation, aimed specifically at mathematical and technical explanation rather than general motion graphics. You define a Scene subclass, populate it with Mobjects — mathematical objects: circles, graphs, LaTeX-rendered equations, 3D surfaces, number lines — and then animate transitions between states: Transform, Create, FadeOut, Write. The library computes every intermediate frame, renders it, and stitches the frames into a video file. Nothing is hand-drawn or captured from screen recording; every frame is generated from the same object graph a matplotlib chart would be, except animated and vector-precise down to the sub-pixel interpolation of a rotating triangle.

This is the mechanism behind 3Blue1Brown's visual style — the smoothly morphing graphs, the equations that rearrange themselves in place, the camera that pans and zooms through 3D vector fields — and it's why the library has such deep gravitational pull for anyone doing math, physics, ML, or CS education content. You're not fighting a general-purpose animation tool to make it precise; precision was the design brief from the start.

In practice that looks like this, roughly, for either fork:

class GradientDescent(Scene):
    def construct(self):
        axes = Axes(x_range=[-3, 3], y_range=[0, 9])
        curve = axes.plot(lambda x: x**2, color=BLUE)
        label = MathTex(r"f(x) = x^2")

        self.play(Create(axes), Create(curve))
        self.play(Write(label))

        dot = Dot(axes.c2p(2.5, 6.25), color=YELLOW)
        self.play(FadeIn(dot))
        for x in [1.5, 0.8, 0.3, 0.05]:
            self.play(dot.animate.move_to(axes.c2p(x, x**2)), run_time=0.6)

Nothing here is imperative "draw a line from A to B" instruction. You describe object state, and self.play() is the primitive that turns a change in state into an interpolated animation over a duration — the .animate proxy in the loop above is syntactic sugar that lets you write the target state and have Manim compute the tween. That declarative shape is consistent across both forks even where the underlying mobject class hierarchy and renderer differ, and it's the reason code samples "look" portable between ManimGL and ManimCE even when they don't actually run without edits.

How it works: two renderers, two philosophies

The architectural fork line runs straight through the rendering backend, and understanding it explains almost everything about why the two repos have diverged.

ManimCommunity/manim is built primarily around Cairo, the 2D vector graphics library also used by GTK and, historically, Firefox's rendering pipeline. Cairo gives you deterministic, high-quality, non-interactive rendering — you run a script, it renders to disk, you get a video file. It's the batch-processing model: reliable, testable, CI-friendly. The v0.21.0 release's "2.2x speedup" number is specifically a Cairo-path optimization, and the NumPy hashing fix targets the caching layer Cairo-based rendering depends on to avoid recomputing unchanged frames.

3b1b/manim — ManimGL — moved to an OpenGL-based renderer years ago, specifically so Grant Sanderson could work interactively: tweak a scene, see it update live in a window, iterate on camera angles and object placement in real time instead of re-rendering to a file after every change. That's a genuinely different tool shape. It optimizes for a single power user's live-coding workflow over a video-editing timeline, not for reproducible batch output across a team's CI pipeline. It's also, not coincidentally, the harder codebase to keep stable for external contributors, because interactive/live rendering has more moving parts and fewer natural test boundaries than "render this scene to an MP4 and diff the frames."

That's the real explanation for the release cadence gap. ManimGL isn't stagnant because nobody cares — the star growth says otherwise — it's stagnant because it was never architected as a community-maintainable package, and its BDFL has other things demanding his time between videos. ManimCE exists specifically to be the version other people can safely build on, and its README says so almost word for word: it positions itself as offering "continued development, improved features, enhanced documentation, and more active community-driven maintenance" relative to the original, while explicitly noting Grant Sanderson continues to maintain his own repository in parallel.

Both are legitimately named manim on PyPI in a way that guarantees new users trip over it: the community edition installs as pip install manim, while the original installs under a different package name, pip install manimgl. If you follow a tutorial written against one and install the other, you get import errors and a subtly different API — mobject names, animation builders, and TeX handling have all diverged since the fork.

What changed versus "before"

Version-to-version, ManimCE's last several releases tell a consistent story of a project hardening for production use rather than chasing new visual features. v0.19.2 bumped the minimum Python version to 3.11 and added 3.14 support. v0.20.0 rewrote MathTex parsing for robustness and added a --seed CLI flag for reproducible randomness in generative or noise-driven scenes — a detail that matters if you're rendering the same educational video in CI and need byte-for-byte reproducibility, or generating many stochastic variants of a scene. v0.20.1 focused on Docker image size and bug fixes. And v0.21.0's headline feature, Typst support, is arguably the biggest DX change in years: LaTeX has been Manim's default math-typesetting engine since inception, and it is notoriously heavy to install, slow to invoke per-frame, and a common source of "why won't this render" issues for newcomers. Typst is a from-scratch, Rust-based typesetting system built explicitly to be fast and dependency-light where LaTeX is neither. Making it a first-class option — not a total LaTeX replacement yet, but an alternative path for Typst/MathTypst mobjects — is the kind of unglamorous infrastructure work that shows up nowhere in a highlight reel but removes real friction from the getting-started experience.

ManimGL's last visible release cycle, by contrast, was about rendering performance and interactivity: v1.7.0 improved 3D stroke rendering and interactive scene development; v1.7.1 and v1.7.2 were bug-fix passes on top of that. Then it stopped. The README's own caveat — "code from older videos may not be compatible with the most recent version" — is Grant Sanderson telling you, in the driest possible terms, that API stability was never the point.

Worth noting: ManimCE's own cadence isn't perfectly smooth either. Its PyPI history shows roughly eleven months between v0.19.0 and v0.19.1, then four releases in the following eight months, then a five-and-a-half-month gap before v0.21.0. "Actively maintained" here means the project keeps shipping and hasn't gone dark, not that it ships on a predictable clock — if you're planning a course or a codebase around a specific upcoming feature, that unevenness is worth budgeting for. It's also still, after six years of development, at version 0.21.0 — pre-1.0 by semantic versioning convention, which is a quiet way of saying the project reserves the right to break its own API on any release, refactor or no refactor.

Why developers should actually care

Most of what gets called an "open-source library deep dive" is really about a startup's product decision. This one is closer to a genuine engineering-culture case study, because the fork gives you a controlled comparison: same domain, same original author, same rough feature set, and six years of divergent incentives to see the results of.

Cost and lock-in: both are free and self-hosted, and there's zero platform lock-in — a Manim scene is a Python file. Compare that to SaaS explainer-video tools or Adobe After Effects with Lottie exports, where your output is tied to a specific tool's project format or a subscription. If you can write Python, you can render mathematically precise animation forever, offline, without a rendering-credits meter.

Latency and iteration speed: this is where the fork actually matters for your day-to-day. If you're iterating on camera framing and object choreography, ManimGL's live OpenGL preview is a materially faster feedback loop than "edit script, re-render to file, open video player" — the workflow ManimCE's Cairo path defaults to (though ManimCE has gained experimental OpenGL support of its own over time). If you're producing finished output for a course, a paper, or a channel, ManimCE's batch-render reliability, CI-friendliness, and now-faster Cairo path matter more than live preview ever will.

Maintainability: this is the sharpest asymmetry. ManimGL's own docs warn you that old code may break on upgrade, and with 464 open issues against a lone-maintainer cadence, if you build a course or a codebase on top of it, you're accepting API instability as a permanent condition, not a temporary one. ManimCE's "currently undergoing a major refactor" warning in its README is a shorter-term version of the same risk — expect breaking changes while it lands — but it comes with a governance model, tests, and a stated intent to stabilize, which ManimGL's structure doesn't really offer even in principle.

Security and supply chain: neither project has an unusual attack surface — this is local rendering of local scripts, not a network service — but it's worth noting explicitly that manim and manimgl are two different PyPI packages with overlapping purpose and near-identical names, which is exactly the kind of naming collision that both confuses newcomers and, in less benign ecosystems, gets exploited by typosquatters. It hasn't happened here, but it's a pattern worth being alert to whenever a popular project has two similarly-named packages on the same registry.

Developer experience and documentation: this is where the fork gap is least ambiguous. ManimCE ships versioned documentation on Read the Docs, a public example gallery, and Docker images maintained well enough that v0.20.1 specifically shipped a release to shrink the image. ManimGL's README describes its own documentation as "in progress" — after six years. If you've ever tried to onboard a team onto a tool where the answer to "where are the docs" is a half-finished wiki, you already know what that does to ramp-up time and support burden, independent of how good the underlying engine is.

Reproducibility: ManimCE's --seed flag, added in v0.20.0, is a small feature with an outsized implication — it means a render pipeline built on ManimCE can guarantee the same stochastic scene produces byte-identical output run to run, which matters if you're rendering in CI, diffing output for regression testing, or need a compliance-style audit trail for how a visualization was generated. That's the kind of feature a single-maintainer, personal-use tool has little incentive to build, because Grant Sanderson doesn't need his own videos to be independently reproducible by a third party — he just needs them to look right once.

Practical use cases

The obvious one is what it was built for: math and CS education content, in the 3Blue1Brown mold — linear algebra, calculus, algorithm visualization, proofs made spatial. Less obviously, Manim shows up in university course material (professors building lecture visualizations they can version-control and re-render when a syllabus changes), in ML and research communication (visualizing attention mechanisms, gradient descent, or neural architecture diagrams with actual mathematical precision instead of hand-drawn approximations), in conference-talk preparation, and increasingly in quant and finance contexts for visualizing algorithmic behavior over time. The Jupyter %%manim magic that ManimCE ships lets you render scenes directly in a notebook cell, which matters more than it sounds — it turns Manim from "a tool for making finished videos" into something usable for exploratory, iterative visual debugging of an idea while you're still developing it, not just packaging it for an audience afterward.

There's also a use case that gets less attention than it deserves: internal engineering communication. A system-design walkthrough, a data-pipeline diagram that needs to show state changing over time rather than a single static snapshot, an incident postmortem that benefits from visualizing a race condition unfolding step by step — these are all cases where a Manim scene, checked into the same repo as the system it explains, out-communicates a static Miro board or a slide deck, and stays in sync with the codebase the same way a well-maintained architecture diagram should but usually doesn't. The cost is real (you're writing Python and waiting for a render instead of dragging boxes), but for anything you expect to update more than once, code-as-diagram has the same maintainability argument as infrastructure-as-code over a hand-clicked cloud console.

Limitations the hype leaves out

Manim is not fast, even after this release's improvements — a 2.2x speedup on a slow baseline is still slow relative to real-time animation tools; complex 3D scenes with many objects can take minutes to render for seconds of output, and that cost scales with scene complexity in ways that punish exactly the ambitious visualizations people reach for Manim to build. It's also not a live-preview-in-browser tool the way Remotion or Motion Canvas are for their respective domains — ManimCE's default workflow is still edit-then-render, not edit-and-watch, Typst support notwithstanding.

The learning curve is real and understated in most "just write Python" framing: effective Manim requires understanding its coordinate system, its animation-timing model, and a fairly large vocabulary of mobject classes and animation builders before you can produce anything beyond tutorial-level output. The LaTeX dependency, even with Typst now available as an alternative, hasn't disappeared — it's an additional option, not a replacement, and most existing tutorials, community examples, and Stack Overflow answers still assume LaTeX. And the ManimCE "major refactor in progress" warning deserves to be taken seriously if you're starting a large project today: pinning a version and testing upgrades before adopting them is not optional caution here, it's a stated project condition.

Finally, and this is the one that costs the most confused hours industry-wide: nothing in either README makes the fork's implications concrete for a first-time user. You'll find the disclaimer that two versions exist, but not a clear "here's what breaks if you mix tutorials from the two," which is precisely the gap this article is trying to close.

How Manim compares

Independent read

The healthy way to read this split is: it's specialization, not failure. A single-maintainer live-coding tool and a community-governed batch-rendering library are optimizing for genuinely different jobs, and trying to force them back into one codebase would likely make both worse. What's less healthy is the branding. Sharing a name, a README framing, and near-identical taglines across two projects with meaningfully different install commands, APIs, and stability guarantees is a self-inflicted DX tax that's been live for years and costs every new user a "wait, which one do I want" detour that a five-minute decision-tree in either README could eliminate. It hasn't been fixed, and given the incentives on both sides — neither project benefits from steering traffic toward the other's package name — it probably won't be.

For what it's worth, the default answer for almost anyone starting today is ManimCE. It's the one shipping fixes, the one with governance that outlives one person's attention, and as of six days ago, the one with a real answer to LaTeX's weight problem. ManimGL remains worth reaching for only if what you specifically want is Grant Sanderson's own interactive workflow, or if you're maintaining code written against his API and migration isn't worth the cost yet.

Who should try it, and who should wait

If you make technical or educational video content and haven't looked at Manim, ManimCommunity/manim is worth an afternoon regardless of which fork's tutorials you stumble on first — just make sure any tutorial or Stack Overflow answer you're following says which package it targets before you copy an import statement. If you're already deep in a ManimGL-based pipeline, there's no urgent reason to migrate off a working setup, but budget real time for the switch if you ever do, since the APIs have genuinely diverged. If your actual need is programmatic video for a web product — dashboards, data-driven marketing video, UI walkthroughs — neither fork of Manim is the right tool; look at Remotion instead, since its whole premise is React-native video generation for exactly that use case. And if you need real-time interactive visualization embedded in an app rather than pre-rendered video output, Manim in either form is the wrong category entirely — it's a video renderer, not a runtime graphics library.

What's genuinely rare here is a repository pair that lets you watch, in public, what six years of "same idea, different governance model" actually produces in release cadence, API stability, and feature direction. Most forks either die quietly or fully replace the original. This one didn't do either — it just settled into two audiences that don't overlap as much as the identical project name suggests they should.

What's your read: should projects with this kind of long-term, stable fork split be required (by convention or by registry policy) to use clearly distinct package names, or is "same name, different maintainers" a workable long-term state as long as both READMEs are honest about it?

Sources:

• 3b1b/manim on GitHub
• ManimCommunity/manim on GitHub
• manim package on PyPI (release history)
• manimgl package on PyPI (release history)
• 3b1b/manim releases
• ManimCommunity/manim releases
• GitHub Trending