Project-Feynman

Project-Feynman turns a request into a narrated explainer video. You ask for a topic, and Claude Code agents script it, lay it out, check it and render it. The engine underneath is ManimGX, a GPU renderer for the kind of mathematical animation 3Blue1Brown made famous, and the name is a promise about the result: an explanation a good teacher would give, not a slideshow read aloud.

I started it in late October 2026 as a question about speed: how fast can an agent turn a request into a finished educational video, and which abstractions, tooling or model choices change that. It grew into a route with several stages, a Mac window that runs them, and a measured record of what each change bought.

The route

A video of about a minute takes roughly ten minutes and a few dollars of model usage at the default level. One command runs the whole route from a facts sheet, a short file of what the video must say.

1. Facts. The facts sheet comes from me, or a session writes it first. For a video about a codebase, that session reads the folder read-only and can change, run or reach nothing.
2. Plan. A session writes the captions and a plan for every beat: what is on screen, the claims in order, a word budget, and the next beat's claims.
3. Narrate. A narrator model voices the plan beat by beat. A judge reads every beat for fidelity, and a beat that drifts from the plan is retried.
4. Build. In parallel, a builder session animates the fixed captions with narration off. The plan's lines say what has to be on screen; how it is drawn is the builder's call, under a style skill.
5. Render. The final render takes the narration, the lines are spoken while the build runs so the render only draws, and a picture check reads the storyboard against the plan and reports, per beat, which things are shown, missing or only named.

The animation is written on a thin layer over ManimGX where a video is a title, a sequence of beats and a close. Each beat is a caption, the animations that happen with it, and a hold. Captions become subtitles, holds come from reading speed, and the stage has named rows so an agent places things without computing coordinates. Before any render an agent type-checks the scene and runs an inspection that prints a storyboard sheet, a timeline and the layout problems it found, so most mistakes are caught in a tenth of a second rather than after a render.

Swappable boundaries

Three parts of the route are the ones most likely to change, so each sits behind a contract.

• The agent. The sessions run on the Claude Code or Codex command-line tool installed on the machine, headless, on whichever subscription is logged in. The briefs are the same for both, and the agent that builds the video also judges the narration.
• The narrator. A narrator is a run folder with a config file naming its provider: Claude, a ChatGPT model, or a local model served by Ollama, including a fine-tuned one. Sampling, judging and comparing go through one interface, so a new model is a new folder and no new code.
• The voice. Text-to-speech is a provider behind one contract: the macOS voice by default, Kokoro locally, or ElevenLabs.

The agents follow written skills

The sessions do not improvise the method. A set of Claude Code skills at the repository root packages it: one for the layer and its layout menu, one for the contract a single segment of a longer video must meet when several agents build in parallel, one for the orchestrator's procedure, one for pedagogy, one for style, and one that is the whole route written for a fresh session. Changing how videos get made means changing a skill, and the measured record says whether the change was worth keeping.

What I learned so far

• Planning dominates. On a first video, no toolkit changed the wall time, because an agent spends most of it deciding the layout before writing. The levers that move the number are the ones that remove decisions from planning.
• A script written by someone else makes the build slower. Handing a builder a finished caption script made it plan twice as long. The script and the layout are one decision.
• A judge needs a noise floor. Two runs of the same system can disagree by a few points on a rubric. A change counts only when it beats both baseline runs by more than that.
• The fix loop is the part that can be cut. One command for the type check, the render and the layout report took most of the time out of the loop after the first draft.

Where it stands

The repository is a private workspace: the engine, the narrator interface and the video skills sit beside past runs, training material and research notes. A public subset is built from it behind an allowlist gate whose rule is that public text never cites private text. The gate runs with the tests, so the decision to open-source is one decision rather than a clean-up project.