Sonnet 5.5 Real-World Test: Code-Generated Animation at Near Opus Quality for Half the Price

A Reddit user ran a seriously hardcore experiment with Claude's Sonnet 5.5 model: no After Effects, no asset libraries, no video generation models — just pure code to produce a 30-second, 1080p, 60fps animated video. The entire pipeline used headless Chrome to render canvas frames, then ffmpeg to encode them, with a fully synthesized audio track. The result matched the quality of the far more expensive Opus 5.5, at roughly 70% of the cost.

A Video Generated Entirely Through Code

The animation is dense with content. According to the poster, it includes Reddit mascot Snoo self-assembling, kinetic typography, a subreddit ticker, a 3D upvote icon with a karma counter, an isometric feed that auto-sorts, a timelapse playback of r/place, a bar chart race of trending topics, feature tiles, a comment thread morphing into Snoo, and a TIL / ELI5 / AMA montage with an end card.

The key point: all of this is code. No video model was involved in generating any frame. Every frame was drawn in headless Chrome using canvas, then handed off to ffmpeg for encoding, with even the soundtrack synthesized programmatically. This means the model's job wasn't to "generate video" — it was to "write the program that renders this video." At its core, this is a complex programming and engineering orchestration task.

This approach is fundamentally different from mainstream text-to-video pipelines, which rely on large-scale video diffusion models. Here, the idea is to use the language model as a "programmer," translating visual expression entirely into executable, precisely controllable code.

Headless Chrome refers to Chrome running without a graphical interface — it can execute JavaScript, render HTML/Canvas in a server or command-line environment, and capture pixel output frame by frame. This turns animations that would normally play in real time in a browser into a batch-exportable sequence of static images. Combined with ffmpeg — a widely used open-source audio/video processing tool — those image frames can be precisely encoded into a video file at a specified frame rate and resolution. This "code → Canvas rendering → frame sequence → ffmpeg encoding" pipeline is a classic programmatic video generation approach, previously common in data visualization and templated batch video production. In this experiment, a language model takes over the entire pipeline as its "output medium."

The Cost Breakdown: Sonnet 5.5 vs. Opus 5.5

The poster uses a Max 20x subscription, so no actual bill was generated. The costs listed are equivalent figures calculated from session logs using API list prices.

The project broke down into two parts:

• 15-second version (single conversation): 210K output tokens, 10.6M cache reads, 290K cache writes. Approximately $4.94 with Sonnet 5.5, versus $7.77 with Opus 5.5.
• 30-second version (14 sub-agents): 529K output tokens, 91M cache reads, 2.79M cache writes. Approximately $30.46 with Sonnet 5.5, versus $42.72 with Opus 5.5.

Combined: Sonnet 5.5 totals roughly $35.40, Opus 5.5 roughly $50.48.

On pricing structure, Sonnet 5.5 is $2 input / $10 output per million tokens; Opus 5.5 is $4 / $20 — exactly double. Cache reads are $0.20/million for both models, and the poster estimated cache write costs at 1.25× the input price.

Why the Price Gap Is 43%, Not 2×

This is the most interesting insight in the entire experiment. Although Opus 5.5's input/output prices are double those of Sonnet 5.5, the final cost difference is only about 43% — not the intuitive 100%.

The reason lies in the token composition. The vast majority of tokens consumed by this task are cache reads — about 101.6 million of them — while output tokens total only 739K. Cache reads are priced identically across both models ($0.20/million), unaffected by model tier. The input and output tokens that actually differ in price make up a small fraction of the total, so the cost premium from upgrading models gets diluted.

This has practical implications for developers: in long-context, multi-turn, cache-heavy agent workflows, switching to a more powerful model doesn't necessarily mean doubling your costs. The higher the cache hit rate, the more the per-token price difference between models gets averaged out.

Prompt Caching is a cost optimization mechanism offered by Anthropic and other API providers: when multiple requests share the same prefix content (such as system prompts, long documents, or code context), the server caches the KV computation for that portion, and subsequent requests read directly from cache without recomputing — significantly reducing input token processing costs. In multi-turn conversations or multi-agent workflows, each sub-agent often shares a large amount of identical context, resulting in very high cache hit rates. In this experiment, cache read tokens (~100M) outnumber output tokens (~740K) by more than 130×, meaning the bulk of total cost is determined by the cache read price rather than the model's listed input/output rates. Understanding caching is essential for accurately estimating real-world costs in long-context agent workflows.

Engineering Orchestration: 779 Tool Calls and 14 Sub-Agents

For the 30-second version, the poster used 14 sub-agents working collaboratively. The entire process involved 779 tool calls — 161 from the main conversation and 618 from the sub-agents — with a total runtime of about 2.4 hours.

It's worth noting that a large portion of those 2.4 hours wasn't the model "thinking" — it was waiting on rendering. Canvas frame rendering, ffmpeg encoding, and audio synthesis all require real compute time. This explains why what looks like an "AI-generated at the push of a button" result is actually backed by a fairly traditional software pipeline; the model's job was simply to write and orchestrate that pipeline.

This pattern of splitting complex tasks across multiple sub-agents is increasingly becoming a standard paradigm for advanced agent applications: a main agent handles planning and coordination, sub-agents handle individual modules in parallel, and the results are assembled into a final product.

A multi-agent architecture involves decomposing a complex task and having an Orchestrator agent schedule multiple specialized sub-agents to complete their respective modules in parallel or in sequence, then aggregating the results. Each sub-agent typically has its own context window and tool access, allowing it to focus on a single responsibility — for example, one sub-agent generates Canvas rendering code for a specific animation segment, while another handles audio synthesis logic. The advantages of this architecture include bypassing single-context window length limits, enabling parallel processing to reduce total time, and minimizing the impact of individual task failures on the whole. Tool calls are the basic unit of interaction between agents and the external environment — including executing code, reading and writing files, invoking browser rendering, and more. The 779 tool calls reflect the density of interaction between the model and the runtime environment throughout the task.

What This Experiment Tells Us

This single-source test provides at least two valuable observations.

First, using code rather than video models to generate dynamic visuals offers unique advantages in controllability, precision, and reproducibility. Every frame is a deterministic product of code — parameters can be fine-tuned exactly, logic can be reused — something diffusion-based video models simply cannot match.

Second, model selection cost decisions can't be based on list price alone. In cache-intensive agent tasks, the real cost difference can be far smaller than the price difference suggests, which creates genuine room to "afford a more capable model."

It should be noted that all figures above are calculated from the poster's personal session logs and have not been independently verified by a third party. Specific numbers should be treated as reference points rather than precise benchmarks.