Andrej Karpathy gave Anthropic’s Opus 5 a budget of one million tokens and a single instruction: render the opening paragraph of The Lord of the Rings as a Three.js scene. The model wrote back roughly 5,500 lines of code, building its own polygon assets from scratch and choreographing them to track the text as it unfolded. Karpathy posted a video of the result on X. His point was not that the demo looked good. It was that no human engineer would ever sit down and write 5,500 lines of bespoke animation code to stage a single paragraph of a novel, and that refusal is exactly what makes the exercise worth studying.
For the past couple of years, the shorthand test for a new model has been a quick, single-shot sketch: an SVG of a pelican riding a bicycle, a unicorn drawn in one pass, something a reader can judge in a glance. Karpathy has leaned on tests like that before. What he is describing now is a different category of evaluation entirely. A pelican SVG takes seconds to generate and seconds to judge, and a model can only get it right or wrong once. The Tolkien render asked for sustained reasoning across thousands of lines of interdependent code, all of which had to stay coherent with everything written before it, not just land one clever frame.
The property that makes this useful is the combination of enormous effort and zero economic reason to expend it. Nobody writes hand-coded Three.js adaptations of Tolkien paragraphs for a living, so nothing resembling this task sits in any training corpus in meaningful volume. That absence matters. A benchmark question with a known answer can leak into training data, or a model can learn the shape of the test rather than the underlying skill. A task this laborious and this pointless as a commercial proposition is close to unfakeable by memorization. It measures whether a system can hold a long, unsupervised plan together, not whether it has seen the answer key.
The honest problem is that “impressive to look at” is not a metric. There is no score attached to the Tolkien render, no baseline run against an earlier model, no rubric a second reviewer could apply, and no way to compare Opus 5’s attempt against a rival model’s except by watching two videos and picking a favorite. That is a demonstration, not a measurement. Treating a demonstration as evidence of capability is precisely the mistake that formal benchmarks, with their held-out test sets and reproducible scores, exist to prevent. A striking video can make a model look further ahead than it is, and taste is not a substitute for a number.
Elsewhere in today’s issue, a private production benchmark and an eval framework that treats its own test harness as part of the system under evaluation take the opposite approach, building measurement infrastructure instead of posting a clip. The contrast between that discipline and Karpathy’s demo is the point: one produces a number a competitor can be checked against, the other produces a feeling.
A test like this should count for something, just not as a ranking. It is a legitimate signal that a model can sustain a coherent, self-directed plan across a long stretch of code with no external checkpoints correcting it along the way, which a short prompt cannot expose and which matters for anyone deploying models on multi-step agentic work. It should not be read as proof that one model beats another, and any team tempted to use tasks like this to pick a vendor should still demand a benchmark that outputs a score, not just a video worth sharing.
Andrej Karpathy posted the thread describing the Opus 5 Three.js experiment on X on Aug. 3, 2026.
