# ManimCat: package version 2.0.0, one release tag at v0.0.16, and an empty header logo

> Wing900/ManimCat is a TypeScript workspace that drives Manim and matplotlib from natural language, with a direct workflow mode and a longer-lived agent studio. The build compiles only the frontend, the image is based on a floating Manim tag with Chinese package mirrors swapped in, and the interface documentation is four headings above four empty boxes.

**Wing900/ManimCat** — ManimCat: AI-generated math animations from natural language. High-quality Manim rendering with LaTeX support and auto code-fixing.

- Repository: https://github.com/Wing900/ManimCat
- Stars: 465 · Forks: 70
- Language: TypeScript
- License: NOASSERTION
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/wing900-manimcat

## package.json says 2.0.0 and the only release tag is v0.0.16

Two version numbers describe the same project and they do not agree. The npm manifest in src names the package manim-cat and gives it version 2.0.0. The repository's release list holds a single tag, v0.0.16, and that tag's title is itself a licensing note: a license transition that retains MIT while applying AGPL for current versions. So the published manifest has moved two minor versions past the newest tag without a corresponding release, and the one release that does exist announces a license change rather than a feature set.

The build target matches the manifest rather than the tag, since the Dockerfile copies package.json and package-lock.json into the image before installing, and npm install resolves whatever version string is written there. Anyone pinning a deployment to a release tag gets code whose manifest claims a different version than the tag implies, and the tag itself carries no version history to compare against.

## The root holds two license policies and a notices file, and the metadata names neither

The licensing arrangement is spread across six files at the top of the tree: LICENSE, a LICENSES directory, LICENSE_POLICY.md, LICENSE_POLICY.en.md, THIRD_PARTY_NOTICES.md and THIRD_PARTY_NOTICES.zh-CN.md, with the header navigation linking to a License and Copyright section. The one release states the shape of the transition, retaining MIT and applying AGPL to current versions. That leaves a real question about coverage: whether a given file predates the transition or postdates it decides which terms apply, and no single sentence in the release title settles it for a specific artifact. This write-up does not pick one. Read LICENSE_POLICY.md alongside LICENSE for the file you actually intend to use, and read THIRD_PARTY_NOTICES.md before redistributing anything, since the rendering stack pulls in fonts and Python imaging libraries that carry their own terms.

## The interface section is four headings above four empty boxes

The header is built from decorative HTML and the documentation of the interface is decoration too. An h1 element wraps a picture element that has no source and no img child, so the title slot renders as an empty box where a logo would sit. Around it sit a top decorative wave comment, a cat paw accent div carrying opacity 0.3 and no content, a math symbol divider, a geometric divider and a bottom decorative wave, plus a centered paragraph that holds only whitespace.

The Interface section repeats the pattern with actual headings. It lists UI, then a second UI heading, then Workflow, then Plot Studio, and each of those four subsections is followed by a bare div with align set to center and nothing inside it. The Examples section is the only place in the README with a real payload, and it holds one item: a blockquoted prompt asking for a geometric proof of 1/4 + 1/16 + 1/64 summed as 1/3, with styling instructions for a creamy yellow background and a macaroon palette, a looping video, and a caption crediting background music.

## Both architecture diagrams stop on a node with no arrow

The Workflow Mode and Agent Mode diagrams are the only description of how requests move, and both end mid-statement. The Workflow diagram walks from a user prompt through the classic UI to problem framing and generate or modify requests, then into the workflow APIs, and the last line is the bare node identifier with nothing attached to it. The Agent diagram walks from a user instruction to the Studio UI, into session and run APIs, on to a studio runtime service and then to Manim Studio or Plot Studio, and its last line is a different dangling identifier.

The prose around them carries more information than the shapes do. Workflow Mode is the direct path for fast outputs; Agent Mode is for studio work with longer-lived sessions, task state, review and iteration. The state model is described as a session, run, task, work and result lifecycle, and the realtime layer differs by mode, with polling for Workflow jobs and Server-Sent Events for Agent sessions, permission requests and task updates. One maturity claim is stated plainly: Plot Studio is the more mature Studio path today, and Manim Studio is still at an earlier stage.

## npm run build compiles the frontend and never touches the backend

The scripts section of the manifest contains a backend build that the top-level build does not call. build:backend runs tsc, and build runs npm run build:frontend, which changes into the frontend directory and runs its own build. So the shipped image contains compiled frontend assets and backend sources that are executed as TypeScript at runtime, through tsx in both the dev script, tsx watch src/server.ts, and the start script, tsx src/server.ts. The dev script runs those two in parallel with concurrently, which is why the quick start needs an npm install inside frontend as well as at the root:

```bash
npm install
cd frontend && npm install
cd ..
npm run dev
```

Testing is split three ways rather than one. test chains a frontend run, a workflow run and a studio-agent run, and each of the latter two compiles through its own tsconfig, tsconfig.workflow-tests.json and tsconfig.studio-agent-tests.json, then writes a package.json with type set to commonjs into the output directory before invoking node, so the compiled CommonJS tests load under a package that otherwise declares type module.

## A type stub for version 15 sits beside a version 16 runtime package

The dependency list of the root package contains fourteen entries, and two of them do not belong there in the usual arrangement. react-syntax-highlighter is required at version 16.1.0, while @types/react-syntax-highlighter is required at 15.5.13, so a type stub one major behind the package it describes is installed as a runtime dependency rather than a development one. That pair ships to every production install and inflates the image with type declarations that no runtime code reads.

The root package also requires react, react-dom and @supabase/supabase-js while a separate frontend directory carries its own package.json and its own install step, so React appears on both sides of a split that the scripts treat as two projects. The backend stack around that is conventional and heavier: express with cors, bull and ioredis for the queue, openai for the upstream calls, https-proxy-agent for proxying, zod for validation, uuid for identifiers and dotenv for the environment file.

## The image is built on a floating Manim tag with two package mirrors swapped in

The Dockerfile takes manimcommunity/manim:stable as its final base and copies Node from a separate node:22-bookworm-slim stage, pulling /usr/local/bin and /usr/local/lib/node_modules across. Because the base image is a floating tag rather than a digest, two builds of the same commit are not guaranteed to produce the same layers. The package sources are then rewritten to regional mirrors before anything is installed:

```dockerfile
RUN sed -i 's/deb.debian.org/mirrors.aliyun.com/g' /etc/apt/sources.list.d/debian.sources && \
    apt-get update && \
    apt-get install -y redis-server fontconfig \
    fonts-noto-cjk fonts-noto-cjk-extra \
    fonts-wqy-zenhei fonts-wqy-microhei fonts-lxgw-wenkai \
    ffmpeg curl ca-certificates && \
    fc-cache -f -v
```

The npm registry is redirected the same way, to registry.npmmirror.com, in a separate layer. Note that redis-server is installed inside the application image while the compose file also runs a redis service, so there are two Redis installations in the stack. Python gets matplotlib and a pinned mypy at 1.19.1, with a comment explaining that matplotlib is declared explicitly rather than inherited from whatever the base image happens to ship. The last layer downloads three background music tracks from the repository's raw file host, and its comment records that an earlier version chained those downloads with a trailing alternative that silently swallowed a failure, which the current form avoids by enabling errexit first.

## Upstream routing is four parallel variables and three ten-minute timeouts

Calls to a model go through OpenAI-compatible routing, and the configuration for it is positional rather than structured. Four variables have to stay aligned by index: MANIMCAT_ROUTE_KEYS, MANIMCAT_ROUTE_API_URLS, MANIMCAT_ROUTE_API_KEYS and MANIMCAT_ROUTE_MODELS, described as one bearer key mapped to one upstream profile. The compose file marks them as required for server-side generation unless the frontend passes a custom API config, and the example environment file ships a demonstration profile pointing at a placeholder host with a small model name. Generation is two-stage, a concept designer producing a scene design and a code generator writing the Manim code, and each stage has its own temperature, token ceiling and thinking budget rather than sharing one.

Timeouts are set per layer and all three defaults are the same number: REQUEST_TIMEOUT, JOB_TIMEOUT and MANIM_TIMEOUT at 600000 milliseconds. A usage rate limit of 30 requests per 60000 milliseconds window sits alongside retention knobs for media hours, job results and usage days, and optional switches turn on Supabase history, Studio persistence and a render-failure export guarded by an admin token. One file at the top level deserves attention on its own: .env.production is committed next to .env.example, and nothing in the README explains what it holds.

## Conclusion

Use it if you already have an OpenAI-compatible endpoint and a Redis instance, and if you want a studio with task state rather than a single generation call. Plot Studio is the path to try first, since the README calls it the more mature of the two studios and places Manim Studio at an earlier stage. Before you build, read the license policy rather than the single LICENSE file, because the repository states a transition that retains MIT while applying AGPL to current versions and the release tag is v0.0.16 while the package says 2.0.0. Check that your model endpoint sits behind the four routing variables, that three separate ten-minute timeouts fit your hardware, and that the render actually needs LaTeX and ffmpeg in the image before you point a classroom at it.

## FAQ

### What is ManimCat and what does it produce?

It is a dual-mode workspace for mathematical visuals built on top of manim-video-generator. Workflow Mode generates and renders directly for fast outputs, Agent Mode runs Studio sessions with task state, review and iteration, Manim handles animation and matplotlib handles static figures, and both video and image outputs are supported.

### Can I run ManimCat without Docker?

For development, yes: npm install, then npm install inside the frontend directory, then npm run dev, which starts the Express backend through tsx and the Vite frontend together, and the interface is served at http://localhost:3000. A published image named wingflow/manimcat is offered as an alternative to building locally.

### Which ManimCat studio path is more finished?

Plot Studio, which the README calls the more mature Studio path today for static visual work and iterative editing, using matplotlib. Manim Studio is the animation-oriented path and is described as still at an earlier stage.

### How does ManimCat repair generated code that does not run?

A static analysis guard runs py_compile and mypy against generated code before rendering, with AI-powered auto-patching for up to three passes. Generation itself is two-stage: a concept designer produces a scene design, then a code generator writes the Manim code.

### What license governs ManimCat code?

The repository root carries LICENSE, a LICENSES directory, LICENSE_POLICY.md, LICENSE_POLICY.en.md and THIRD_PARTY_NOTICES.md, and the single release is titled as a license transition retaining MIT while applying AGPL to current versions. The package manifest itself carries no license field, so read the policy files rather than guessing from one LICENSE file.

## Sources

- [Issues](https://github.com/Wing900/ManimCat/issues)
- [README](https://github.com/Wing900/ManimCat/blob/main/README.md)
- [Releases](https://github.com/Wing900/ManimCat/releases)
- [Wing900/ManimCat on GitHub](https://github.com/Wing900/ManimCat)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wing900-manimcat