Beyond the Pelican Test: Opus 5 Renders the Lord of the Rings With a 1M-Token Budget

We're starting to leave the territory where you'd test an LLM by e.g. "create an svg of pelican on a bicycle". As one idea to generalize it, I was interested what Opus 5 would do if I gave it the first paragraph of the Lord of the Rings, a 1M token budget (~$10) and asked for three js render of it. Opus went off for ~2 hours and wrote 5500 lines of code that (procedurally) rendered the story. It's kind of janky but fun. But it's a bit mindboggling that the LLM has to place and orchestrate various polygon assets in (x,y,z) coordinates and write code that animates it all, and that it even does anything at all.

On August 2, Andrej Karpathy published the most useful long-context experiment of the week. The setup is one sentence: give Claude Opus 5 the first paragraph of the Lord of the Rings, a 1M-token budget (his estimate, about $10), and ask it for a three.js render of the story. The result, attached to the post as video, is roughly two hours of agentic work compressed into 5,500 lines of JavaScript that procedurally places polygon assets in (x,y,z) space and animates them into a crude retelling of the opening of the book. It is janky. It is unfinished. It is also the clearest demonstration yet of a workload class that barely existed six months ago.

What the experiment actually shows#

Three things make this more than a novelty video.

The workload is agentic, not a single completion. Five thousand lines of coordinated three.js do not come out of one prompt. Producing them required scaffolding, iterative asset placement, animation wiring, and repeated corrections across a two-hour run. This is the shape of work we have been describing all year: a long-horizon coding run where the constraint is a token budget rather than a single completion window. The model behaved like a contractor with unlimited stamina and a deadline expressed in dollars, not hours.

The economics flip the build decision. Karpathy's framing is the important part: LLMs have all the patience in the world, so a task shifts from "no one would ever do this" to "sure, why not, it is ~free." A bespoke 3D interpretation of one paragraph of a novel is the kind of artifact that previously required a studio budget and a production schedule. At a marginal cost of roughly $10, the question stops being whether it is worth building and becomes why you would not.

Verification is the bottleneck. The model could not watch its own render. It had to take screenshots at different points of the scene - slowly, painstakingly, with retries - and it made mistakes along the way, leaving the jank Karpathy freely admits to. His own summary: agents are not yet able to "efficiently and natively perceive videos or play games within them," and raw multimodal self-audit is one of the capabilities that is still genuinely lacking. For anyone building long-running agents, this is the sentence to write down.

What developers are saying#

The developer discussion around the post settled into four camps, and all four are worth separating.

Benchmark design. A large group argues the pelican SVG test was always a gimmick rather than a serious evaluation, and that long-form generation with an explicit budget is a strictly better stress test: it measures sustained execution, cost discipline, and self-correction, not a single lucky completion. A smaller countergroup says the cheap single-image test still has value as a fast sanity signal, and that a comic or multi-image task would keep that advantage while testing more. Both sides agree the era of testing models with one artifact is ending.

Skepticism about generated games. Former game developers pushed back hard on the "drop players into an ephemeral world" vision. Their argument is that token-generated games are demos, not games: no real mechanics, no tuning loops, no iteration from hours of playtesting, and engagement that collapses once the novelty of provenance wears off. The measured failure mode they cite is time-in-game, not click-through. Generation capacity is not game design, and the distinction matters for every team tempted to ship vibes as product.

Entertainment as a shared experience. Several commenters argued that most people do not actually want to be in charge of content production; they want to sit on the couch and share the experience with friends, which is why blockbusters survive. The counterpoint, argued well, is that media is already drifting toward choose-your-own-adventure structures, and that fan-scale collaborative productions will coexist with big studios rather than replace them. The interesting middle position: the floor for solo and small-team production drops dramatically, which is where the developer opportunity actually lives.

Credibility, for better and worse. A minority saw the post as marketing for the author's employer, given earlier public statements that reliable agents were about a decade away. The majority pushback was more useful: the eight months since that statement produced exactly this kind of run, and being early on a capability curve is not the same as being wrong. The exchange is a good reminder to grade demos on the artifact, not the source.

Dev-to-dev take#

The verification asymmetry is the part that matters for production work. Opus 5 built an interactive artifact and then had to audit it through a straw - screenshots, retries, manual inspection - at roughly human speed. Every team running long-horizon agents in the visual or interactive domain will hit this wall. The good news is that the pattern is well understood in adjacent spaces: deterministic observation loops are exactly what browser automation harnesses provide for web work, and what renders loops provide for 3D, and the fix is to wire the loop explicitly rather than ask the model to self-inspect from memory.

There is a second, subtler lesson in the thread: rigid intermediate representations reduce the auditing problem to zero. Several commenters noted that CAD-style tool integrations work precisely because the geometry is anchored to a deterministic interpretation engine, so the model's output is validated by construction instead of by screenshot. The more an agent's output space is constrained by an executable ground truth, the less it needs to see to know it succeeded. That is a design principle worth applying to any agent that produces artifacts, not just 3D scenes.

Finally, the token-budget frame is a genuinely useful discipline for your own runs. Treating a session as "a run with a budget" instead of "one prompt" changes how you review it: the artifact is judged on what a bounded amount of compute produced, the failures are categorized as cost problems or capability problems, and the inevitable jank becomes a spec for the next iteration rather than a disappointment. We wrote about why benchmarks mislead last week; this experiment is the constructive counterpart - a way to evaluate a model that does not reduce to a number.

Continue Reading#

• Claude Opus 5: Near-Fable Intelligence at Half the Cost - The release, the benchmarks, and what the model is actually good at
• Karpathy's Loopy Era Is the Best Way to Understand Codex - Why agent loops, not prompts, are the unit of modern AI engineering
• Your Benchmark Is Lying to You - What a wave of eval audits says about trusting any single model score
• Benchmarking Opus 5 on SlopCodeBench - How Opus 5 behaves when requirements emerge across 17 checkpoints
• Claude 5 Context Engineering Rules - Practical rules for designing long-context agent sessions

Sources#