Video
that is code.

Video is a sequence of still images (stills) shown very quickly, one after another. Each of these images is called a frame. The eye and the brain can't keep up with the "jumps" between images, so they stitch them together into continuous motion, like a flipbook.

FPS (frames per second) = how many images are shown each second. At 60fps each image stays on screen for 1/60 of a second ≈ 16.7 milliseconds. Why 60 and not 30? Because most screens refresh 60 times per second, and in fast motion (a button growing, a camera pushing in) at 30fps every step is twice as big, so the eye starts to notice "stairs". The price: twice as many images to produce.

Notice what just happened: you jumped to frame 240, and the image appeared instantly, without "playing" the 239 frames before it. That's not obvious at all, and it's the heart of the whole method. To understand why, we first need to understand what a language model is good at.

A function is a machine: a value goes in, a value comes out. A pure function is one where the same input always gives the same output, and that doesn't depend on anything else: not on the computer's clock, not on what happened before. seek(t) takes a time t in seconds (say, 4.2) and draws the screen exactly as it should look at that moment. From nothing. Without remembering anything.

<div id="dot"></div>
<script>
const spring = (t, w = 12, z = 0.8) => { if (t <= 0) return 0;
  const wd = w * Math.sqrt(1 - z*z);
  return 1 - Math.exp(-z*w*t) * (Math.cos(wd*t) + (z*w/wd) * Math.sin(wd*t)); };

window.seek = (t) => {                 // t in seconds. Nothing else.
  const grow = spring(t - 0.5);         // starts growing at 0.5s
  const w = 44 + (380 - 44) * grow;     // circle (44px) -> pill (380px)
  dot.style.width = w + 'px';
  dot.style.borderRadius = '999px';
};
seek(0);
</script>

Why not just run a regular animation and record it? Because a regular animation (a CSS transition, setTimeout, requestAnimationFrame) reads the real clock: "300 milliseconds have passed since I started, so I'm at 30%". But when we render, a single Playwright screenshot takes a variable amount of time: sometimes 40 milliseconds, sometimes 200. The clock keeps running during the screenshot, so every frame gets "caught" at a random moment. When we play the images back at a steady 60fps, the motion stutters, speeds up and slows down. With seek(t) we tell the page "be at t=4.2", wait as long as it takes, take the screenshot, and the next t is exactly 4.2 + 1/60. The film's time is completely decoupled from the computer's time.

What you saw in the graph: the seek(t) line is perfectly straight (every frame advances exactly 1/60 of a second), while the timer line is jagged and jumpy, because each frame gets "caught" after a different screenshot time. And here are three more gifts seek(t) gives us:

• Jump to any moment: Claude can capture just frame 240 to check the drop, without rendering everything.
• Parallel rendering: 7 browsers can render 7 different parts of the film at the same time (as we did in EP04 on the RTX 4090), because no frame depends on the one before it.
• Surgical fixes: changing the scene at second 6 doesn't touch a single frame before it.

Intuition first: picture a weight hanging from a spring, and we suddenly move the point it hangs from 10 cm down. The weight doesn't jump straight to the new spot: it accelerates toward it, overshoots a little, comes back, and settles. Two things determine how this looks:

• Stiffness (ω, "omega"): a stiff spring = fast motion. In units: the natural frequency, in radians per second. ω=12 → a natural oscillation period of 2π/12 ≈ 0.52 seconds.
• Damping (ζ, "zeta"): how much "friction" there is. ζ less than 1 → it overshoots the target and comes back (springy). ζ=1 → it arrives as fast as possible without overshooting (critical damping). ζ greater than 1 → it crawls, "muddy".

"Step response" = how the spring reacts when the target jumps all at once (a "step") from 0 to 1. "Closed-form" = there's a formula that gives the position at any time t directly, without simulating step after step. And that's the whole point: a step-by-step simulation has to remember the position and velocity from the previous frame (in other words, "state"), and that breaks seek(t) (there's no way to jump to frame 240 without computing the 239 before it). The closed-form formula gives us a spring that is a pure function of time.

"The sum of one spring per change": how the target changes midway

In the prompt: "A value with many targets is the sum of one spring per change, so it stays a pure function of time." Check the "Three targets in a row" box in the lab. The width starts at 44, at 0.0 seconds it gets a target of 380, at 0.35 it changes its mind to 200, and at 0.7 to 300. Instead of remembering "where I was", we compute: value = 44 + (380−44)·spring(t) + (200−380)·spring(t−0.35) + (300−200)·spring(t−0.7). Each change adds its own spring, which starts at the moment of that change. Since every spring starts at velocity 0 and position 0, the sum is continuous (no jump), and the result is still a pure function of t.

The "liquid indicator" trick: two edges, two springs

In the UI morph prompt: "The tab indicator's two edges ride different springs, so the leading edge stretches ahead of the trailing one." The bar that marks the selected tab isn't one object that moves: it's two numbers, the right edge and the left edge. If the edge facing the direction of travel gets a stiffer spring than the trailing edge, the bar stretches along the way and contracts when it arrives, just like a drop of water. Click the tabs:

There's no real camera in a web page. The "camera" = one box that wraps the whole world, and we apply movement and scaling to it (a transform). Scaling the box 2× around a point = "zooming in 2× on that point". All of the camera's motion is a short list of keyframes (moments where we pin down exactly where the camera is), [time, zoom, x, y], with easing in between.

Why "logarithmic"? Zoom is multiplicative: going from 1 to 2 is "2×", and going from 2 to 4 is also "2×", and the eye experiences both as the same distance. If we compute the zoom linearly from 1 to 16, then halfway through the time the zoom is 8.5, meaning we've already covered 8.5× out of 16×. The eye feels a crazy surge at the start and a crawl at the end. In log space (z = a·(b/a)u, where a is the starting zoom, b the final zoom and u the fraction of time that has passed), halfway through the time the zoom is 4 = √16: half of the perceived distance. The speed the eye experiences is the rate of change of ln(z) (the logarithm of the zoom), and that's exactly what the graph below measures.

• "one move per scene": one camera move per scene. Two moves at once (say, a zoom plus a pan, which slides the view sideways, in another direction) = the eye doesn't know where to look.
• "never zooms in and out back to back": zooming in and immediately zooming out looks like a camera that couldn't make up its mind. In the film above, the camera pushes in before the drop, and it makes the return to 1 while the orange flood covers the entire screen. A camera change over a solid-color surface is invisible. It's a classic editing trick.
• "Never put will-change on anything the camera scales": will-change tells the browser "snapshot this element as an image and move the image around". When we scale up an image like that, the text goes blurry. Without it, the browser redraws the text at every size, so it stays sharp.

The problem: a real camera opens its shutter for a stretch of time (for example, half of the frame's duration, known as a "180° shutter"). Anything that moves during that time gets smeared across the image. That smear is "motion blur", and our brains are so used to it that without it, fast motion looks "stuttery" and artificial. But a browser screenshot is a single, infinitely short instant: zero smear.

The fix: for every final frame, we capture N "subframes" at closely spaced times inside the shutter window and compute their pixel-by-pixel average. The average of 8 nearby positions of a circle = a smeared circle. ffmpeg tmix is exactly that: a filter that averages N consecutive frames.

Why 4 isn't enough for fast motion: the distance between two subframes is speed × shutter time ÷ N. If that distance is bigger than the object itself, the copies don't touch each other, and we see 4 separate see-through copies: "ghost copies". The prompt says "use 8 and slow the move down". Those are the two ways to shrink that same number.

And the ffmpeg command. We actually tested it before writing it here: we generated 24 synthetic subframes and verified that every output frame is the average of its own 8 subframes and doesn't mix in its neighbors:

# 60 fps × 8 subframes = 480 images per second of film
ffmpeg -framerate 480 -i sub_%06d.png \
  -vf "tmix=frames=8,select='eq(mod(n\,8)\,7)',setpts=N/(60*TB)" \
  -r 60 -c:v libx264 -pix_fmt yuv420p -crf 16 video.mp4

tmix=frames=8 averages each frame with the 7 before it. select='eq(mod(n,8),7)' keeps only every eighth frame: the one whose average covers exactly one complete group. setpts rewrites the timestamps for 60fps. A gotcha from Howseen's skill: never average across a hard cut (an instant switch from one scene to the next), or the two scenes smear into each other.