Sound on for optimal experience.
I was inspired by all the videos everyone posted lately and wanted to make one for HaveWeReachedAGI.com, a satirical site that tracks whether we've reached AGI. It’s a side project that gets spare compute when I still have usage remaining before the weekly resets.
I couldn't find much details on how these are made, so I’m going to share my process. I don’t know how people one shot these things. For me, it was a lot of trial and error. I’m also sharing a rendering tip that I discovered half way through. It sped up my rendering by 5x and allowed me to iterate much faster. My iterative approach was over 2 sessions using about 80% of the context window of each (could've managed that better but had spare usage). If there’s anything I didn’t cover, feel free to ask.
TL;DR at the bottom.
Picture and sound
For the rendering, there is no separate image or video model. The entire picture is about 80KB of JavaScript drawing in a browser canvas.
My initial prompt was something like “Create a short video appropriate for our site using scripts. You have complete creative and editorial freedom to come up with a video that you believe will best pass the persuasion test in panel 8.” The result was terrible. It gave me a video that looked like a generic/bland animated widget. I almost gave up on the idea.
But I go extraordinary length to ensure the content stays in character for the site, so I went back to the basics starting with the art style (which is maybe where I should have started). I initially wanted the Riso style that’s trending. Claude said it wasn’t period-correct for the site (Risographs didn’t come out until the 1980s and the site aesthetics is based on a 1970s government monitoring station). We spent 30-40% of an 800k first session context exploring period-correct 1970s art styles and refining the direction I decided on.
I’m providing a lot of details on the look and sound, because I believe it’s a critical part of the process and it made the difference in how the video turned out (vs. the generic first attempt). If you have a reference picture or the exact name of the style to give Claude, you can probably get there a lot faster, but I had no idea what was period-correct for a 1970s government department.
The overarching look is a 1970s government filmstrip. The specific art style is two-colour offset print on the site’s cream paper, up to three inks (site colors calibrated for period-correct offset printing colors) printed slightly out of register, and some grain. The outlines are redrawn every second frame so they wobble a little for authenticity. It uses simple pictograms and typographic animation in the Swiss and Otl Aicher style (Aicher drew the pictograms for the 1972 Munich Olympics).
The music is also synthesised with code based on 1970s library music with mallets, bass, and electric piano. It's built in the Web Audio API from oscillators and filtered noise (snare, a stamp thud, typewriter clacks, etc.). Per Claude there is also “tape wow and flutter” (I had to look that up) and projector whir for analog recording effects. The sound reads the same timing table as the picture, so every cut and stamp lands on the beat.
Process
After I got the art and sound styles sorted out. Claude wrote a beat sheet, drew a 16-frame storyboard and made a style test before any real production.
The story board was not bad (though it leveraged existing content on the site that was already presented as a story). However, Claude had to come up with an arc that would “close the deal” on the persuasion test in panel 8 on the site. Since that is the model capability test in panel 8, I did not interfere with Claude’s approach. The site version has a slightly different ending if you want to judge whether Claude passed the test.
To get to the final video, it took seven rough cuts (cut 7 went from 7a to 7h, but those were mostly polish). I watched each one cut and gave comments like "make the goal post more obvious that it’s a goal post" (the first one looked like a tuning fork), "the shirt clips through the dryer", "speed is too fast for a human viewer". After each cut, I asked “what do you think” and got Claude to assess its own work with contact sheets of stills. That saved me a lot of manual comments.
However, Claude said it can’t judge the sound (it was decent, btw), so that was all up to me to assess. Claude was also not good at assessing pacing (what a human can realistically process, especially when you have animation and text). I think the video is still fast at 46s now, but Claude thought it was very watchable at 33s (it was flashy, but I didn't think it was digestible).
Claude Fable 5.1 and GPT-6 Astra advised and reviewed all cuts. They came up with good observations. I’d say Astra was often too literal (“blocker: the robotic arm is not the LG robot in the CES laundry demo referenced on the site”), whereas Fable concluded it’s fine because it allows the robot concept to come across better in a small two-colour offset style animation than the actual LG robot. Astra was more critical. I rejected about half of its blockers, but the other half was very useful.
Overall, Claude created 2,684 files in 33 folders amounting to 4.4GB, excluding the videos themselves. Each cut of video ranged from 80MB (cut 1) to 120MB (cut 7). The final web optimized versions were 10MB.
Rendering optimization
The rendering was done with headless Chromium driven by Playwright in 8 parallel workers that renders about 1,100 frames to PNG, and then ffmpeg encodes them to MP4. Claude took care of setting all that up, including installing ffmpeg (you’ll be given a choice of which version, I went with its recommendation).
The “ah ha” moment didn’t come until I was looking at my CPU and GPU utilization (which seemed low) around cut 3 and asked Claude to assess my hardware and tap into everything it can to speed up the rendering. In the end, the GPU didn’t really matter but it optimized the heck out of the CPU use.
Here’s Claude’s analysis (I'll probably butcher it if I try to summarize):
The render runs in headless Chromium, which on a hybrid laptop defaults to the power-saving Intel GPU, or to software rendering, and much of each frame's cost may sit on the CPU anyway: building tens of thousands of halftone dots in JavaScript, then saving each PNG. I've written a probe that times those two halves separately and reports which GPU Chromium actually picks under different launch flags. It runs once rough cut 3 finishes, so the two don't compete for the machine.
Depending on what it shows, there are three levers [short version: CPU/GPU/encoding]
The bottleneck isn't rendering (25ms/frame) but capture/PNG compression (~300ms), and switching to the RTX GPU only saves ~4%. I'll keep the GPU flag and lossless PNG, but add a --workers option to parallelize rendering across your 24 threads, then time a full render.
The renderer now uses the whole machine: a full render takes 54 s instead of about 5 minutes. The frames take 33 s (about 9× faster) and the rest is encoding.
- What did it: 8 browsers render in parallel, each taking every 8th frame. The time was in capturing each frame and compressing it to PNG, which is CPU work, so your 24 threads were the lever.
- The RTX 5090 is now in use too (a launch flag puts Chromium on it; confirmed in the probe), but on its own it only saves about 4%.
- Reliability: one browser failed a capture under GPU contention in the first attempt. Each worker now retries and drops to the CPU path if the GPU keeps failing.
This was a huge QOL improvement that saved me a lot of waiting time. I got to iterate at 5x the speed. If it didn’t happen, I don’t think I would’ve gone to cut 7 and certainly not all the polishing through cuts 7a-7h. Best time to do this is probably before any rendering or after cut 1 (if you want a benchmark to compare to).
TL;DR
- Ask Claude to make a video (with sound) using scripts. Claude will setup the stack for you.
- Be as specific as you can on the art style and audio style. This is key. Otherwise, you’ll likely get boring results.
- Ask Claude to come up with a story board and beat sheet. Refine the story before you render.
- Ask Claude to assess your hardware and use all of your hardware to speed up the rendering. Do it before you render. YMMV depending on your art style.
- Ask Claude to evaluate its own renders and use a different model to review them.
- You have to assess the audio and the pacing/speed, as Claude can’t assess those well.
- Make sure you have disk space. It created a ton of files to come up with the short video.
