ManimCat: a dual-mode AI workspace that turns math descriptions into Manim and matplotlib output

The gap ManimCat fills between a prompt and a rendered math clip

Manim Community Edition gives you a Python scene graph, a LaTeX pipeline and a renderer, but it does not give you a prompt box. Writing a Manim scene for a geometric series proof means choosing camera moves, timing, colour constants and object lifecycles by hand, then rerendering until the pacing looks right. ManimCat puts a React front end in front of that process and accepts natural language in place of scene code. The README's own example prompt asks for a proof that 1/4 + 1/16 + 1/64 and so on equals 1/3, and it specifies the aesthetic constraints in the same sentence: elegant zooming, smooth camera movement, a slow pace, at least two minutes of duration, a creamy yellow background, a macaroon palette. That prompt shape tells you who the project is for. It is aimed at people who can describe what a good explanation looks like but who do not want to hand-author the timeline. The repository topics name 3blue1brown, educational-project and mathematics-visualization, which matches the classroom explanation and worked-example framing in the README. The project is built on top of manim-video-generator, and the README describes ManimCat as a broader system rather than a single generation flow.

Two modes, two engines, and why the split matters for adoption

The README organises the product around three axes it calls dual-mode, dual-engine and dual-studio. Mode is the first split. Workflow Mode is direct generation and rendering when you want output quickly. Agent Mode is Studio-based collaborative work with longer-lived sessions, task state, review and iteration. Engine is the second split, and it is the one that changes what you can produce. Manim handles animation and timeline-based mathematical storytelling. matplotlib handles static math visuals, charts and teaching figures inside Plot Studio. Studio is the third split, and the README is unusually direct about maturity here: Plot Studio is described as the more mature Studio path today for static visual work and iterative editing, while Manim Studio is the animation-oriented path and is still at an earlier stage. That sentence should drive your evaluation more than any feature list. If your need is a labelled chart or a teaching figure you will edit several times, the static path is the one with the stated track record. If your need is a two-minute animated proof, you are working on the path the maintainer flags as less settled.

What runs where: Express, Bull, Redis and the SSE layer

The backend is Express with TypeScript. Job processing uses Bull with Redis, and upstream model calls go through an OpenAI-compatible routing layer, which means the model endpoint is a configuration choice rather than a hard dependency on one vendor. History storage through Supabase is optional, so a self-hosted instance without Supabase credentials is a supported shape rather than a degraded one. The realtime layer differs by mode, and that difference is a real architectural signal. Workflow jobs are polled. Agent sessions use Server-Sent Events for session updates, permission requests and task updates. Polling suits a job that starts and finishes. SSE suits a session that stays open and may ask the user for permission mid-run, which is why the agent path carries a session, run, task, work and result lifecycle rather than a single job record. The front end is React 19 with Vite and Tailwind CSS, and the README names three distinct surfaces: the classic generator UI, the Studio workspace shell, and the Plot Studio minimal workspace UI. The Python side is the rendering runtime, and the README pins Manim Community Edition 0.19.2 and Node.js 18 or later.

Getting it running: the documented commands and the Docker alternative

The Quick Start section gives four commands and they are not a single install step. From the repository root you run npm install, then cd frontend && npm install, then cd .. and npm run dev. The two install passes exist because the front end is a separate package, so a root-only install will leave the React app without its dependencies. The documented entry point is http://localhost:3000. The README then points at DEPLOYMENT.md for environment variables and deployment-specific setup, and that file is where the model routing credentials, Redis connection and any Supabase configuration will live. It also mentions a direct Docker path: instead of building locally you can start from the published image wingflow/manimcat. The README does not reproduce the environment variable list in the section supplied here, so treat DEPLOYMENT.md as required reading before you assume a working configuration. Node.js 18 or later is stated, and the Python side needs Manim Community Edition 0.19.2 plus a working LaTeX installation, since LaTeX support is named in the project description. Neither the README excerpt nor the release notes state a check command for the Python toolchain, so verifying that Manim and LaTeX resolve inside whatever container or host you use is your own step.

Auto-code fixing is the feature to scrutinise, not the feature to trust

The project description advertises auto-code fixing alongside LaTeX support. The README excerpt supplied here does not document the mechanism: there is no description of how generated Manim code is validated, what errors trigger a repair pass, how many attempts are allowed, or whether a repaired scene is rerendered from scratch. That absence is the main gap in the material. It matters because generated Manim code fails in ways that are not uniform. A missing import is trivially fixable. A camera frame that drifts off the mobject, a LaTeX expression that compiles but renders too small to read, or a two-minute animation whose pacing is technically valid and pedagogically useless are not fixed by an error-driven repair loop, because nothing raised an error. The README's example prompt asks for pacing and palette, which are exactly the properties a code-fixing pass cannot check. Until the repair behaviour is documented, the honest position is that auto-code fixing should be treated as a convenience for syntax and runtime errors, not as a guarantee that the rendered result matches the prompt.

The licence is split, and the release notes say so explicitly

The repository metadata reports the licence as NOASSERTION, and the release notes explain why. Version v0.0.16 is titled License Transition: MIT Retained + AGPL for Current Versions. So the project is not under one identifier. Earlier versions retain MIT terms, and current versions carry AGPL. For anyone embedding ManimCat in a hosted service, that distinction is the first thing to resolve, because AGPL obligations attach to network use in a way MIT does not. The README's badge reads MIT + AGPL, which is consistent with the release note but is not a licence you can hand to a compliance reviewer as-is. This article is not legal advice. The practical step is to read the actual licence files in the version you intend to deploy and confirm which applies to the code you are running, particularly if you plan to modify it and expose it over a network. The Docker image wingflow/manimcat is a separate distribution channel, so the licence of the source tree and the terms of the published image should be checked independently.

Where ManimCat is the wrong tool, and what to use instead

ManimCat is the wrong choice when you need a deterministic, version-controlled scene that renders identically every time. A model sits between your intent and the Python file, so the same prompt can produce different code on different runs. If your workflow requires a reviewed .py file in git that a colleague can diff and approve, generating through a prompt box adds a step you will have to undo. The direct alternative is Manim Community Edition itself, used without any generation layer. The difference in approach is not cosmetic: with plain Manim you write the Scene subclass, choose the animations and set self.wait durations explicitly, and the file is the artifact. ManimCat instead treats the prompt as the artifact and the Python file as an intermediate that may be regenerated. For a one-off explainer where you will iterate on look and feel, that trade is reasonable. For a course with fifty videos that must be rebuilt next semester against a newer Manim, hand-authored scenes are easier to keep stable. matplotlib is the other axis, and for a static figure that only needs to exist once, writing the plotting code directly is faster than describing it, because the description and the code are about the same length.

Maintenance cost and what to check before committing

The last push recorded for this repository is 2026-08-08, and the most recent release in the supplied list is v0.0.16 from 2026-05-19, so the version numbering is still in the 0.0.x range. Treat that as a signal about API and configuration stability rather than about quality. The dependency surface is the cost driver. A working instance involves Node.js 18 or later, a Python environment with Manim Community Edition 0.19.2 and LaTeX, Redis for Bull job queues, and an OpenAI-compatible model endpoint. Each of those can break a deployment independently, and the README routes environment configuration to DEPLOYMENT.md rather than inlining it. Upgrades are the second cost. Because the licence changed between versions, a version bump is not a routine dependency update. Before you commit, confirm three things: that the Python and LaTeX toolchain resolves in your target environment, that the environment variables in DEPLOYMENT.md cover your hosting model, and that you know which licence text governs the release you are deploying. If those three hold, the dual-engine design is the reason to pick this over a prompt wrapper around a single renderer, because the same workspace covers both a static teaching figure and an animated proof.

Editorial conclusion

Adopt ManimCat if you already run Python with Manim Community Edition and want a browser front end that turns prompts into both animated and static teaching visuals, and if you are comfortable that the animation-oriented Studio path is described as earlier stage than the static Plot Studio path. Do not adopt it if you need a single unambiguous licence identifier, if you cannot host Python, Redis and Bull alongside the Node process, or if your teaching material must be reproducible from a stored script rather than regenerated through a model. Verify first that the environment variables and Python toolchain in DEPLOYMENT.md match your host, confirm which licence text applies to the specific version you pull, and check whether the published wingflow/manimcat image is the version you intend to run.

Official sources

1. Issues
2. README
3. Releases
4. Wing900/ManimCat on GitHub