Sonnet 5.5实测：半价实现Opus级质量的代码生成动画

一位Reddit用户用Claude的Sonnet 5.5模型完成了一项相当硬核的实验：不用After Effects、不用素材库、不用任何视频生成模型，纯靠代码生成了一段30秒、1080p、60fps的动画视频。整个流程通过无头Chrome绘制canvas帧，再用ffmpeg编码，配上合成的音轨。结果不仅质量接近更昂贵的Opus 5.5，成本却只有其大约七成。

一段完全由代码生成的动画

这段视频的内容密度很高。据发帖者描述，动画包含了Reddit吉祥物Snoo自我组装、动态排版文字、subreddit跑马灯、带karma计数器的3D点赞图标、会自动排序的等距信息流、r/place的时间轴回放、热门话题的条形图竞速动画、功能磁贴、一条评论线程变形成Snoo，以及TIL / ELI5 / AMA的蒙太奇和片尾卡片。

关键在于：这一切都是代码。没有视频模型参与画面生成，每一帧都是在headless Chrome里用canvas绘制出来的，然后交给ffmpeg编码成视频，连配乐都是合成的。这意味着模型的任务不是"生成视频"，而是"写出能渲染出这段视频的程序"——本质上是一个复杂的编程与工程编排任务。

这种做法与主流的文生视频路线截然不同。文生视频依赖大规模视频扩散模型，而这里的思路是让语言模型充当"程序员"，把视觉表达完全转化为可执行、可精确控制的代码。

Headless Chrome是指以无图形界面模式运行的Chrome浏览器，可以在服务器或命令行环境中执行JavaScript、渲染HTML/Canvas，并截取每一帧的像素内容。这种方式让原本在浏览器中实时渲染的动画，变成可以批量、逐帧导出的静态图像序列。配合ffmpeg——一款广泛使用的开源音视频处理工具——这些图像帧可以被精确地编码成指定帧率和分辨率的视频文件。这套「代码→Canvas渲染→帧序列→ffmpeg编码」的管线，是程序化视频生成的经典工程路径，过去多用于数据可视化或固定模板的批量视频生产，在本实验中被语言模型作为「输出媒介」整体接管。

成本账：Sonnet 5.5 vs Opus 5.5

发帖者使用的是Max 20x订阅套餐，所以实际上并没有产生账单。文中列出的费用是他根据会话记录，按API标价折算出来的等价成本。

从数据看，整个项目分两部分：

• 15秒版本（单次对话）：输出21万tokens，缓存读取1060万，缓存写入29万。按Sonnet 5.5计价约为 $4.94，若换成Opus 5.5约为 $7.77。
• 30秒版本（14个子代理协作）：输出52.9万tokens，缓存读取9100万，缓存写入279万。Sonnet 5.5计价约 $30.46，Opus 5.5约 $42.72。

合计下来，Sonnet 5.5约 $35.40，Opus 5.5约 $50.48。

价格结构上，Sonnet 5.5是每百万tokens输入 $2、输出 $10；Opus 5.5则是 $4 / $20，翻了一倍。两者的缓存读取都是 $0.20，发帖者对缓存写入按输入价的1.25倍估算。

为什么价差不是2倍，而是43%

这是整篇实验里最值得玩味的一点。虽然Opus 5.5的输入输出单价是Sonnet 5.5的两倍，但最终折算下来Opus只贵了大约43%，而非直觉中的100%。

原因在于token构成。整个任务消耗的绝大部分token是缓存读取（cache reads），高达1.016亿，而输出token只有73.9万。缓存读取在两个模型上的价格完全相同（都是 $0.20/百万），不受模型档次影响。真正拉开差距的输入、输出token占比很小，所以模型升级带来的成本增量被稀释了。

这个细节对实际开发很有启发：在长上下文、多轮、重度依赖缓存的agent工作流中，切换到更强的模型未必意味着成本翻倍。缓存命中率越高，模型单价差异对总成本的影响就越被摊薄。

Prompt缓存（Prompt Caching）是Anthropic等API提供商推出的一种成本优化机制：当多次请求包含相同的前缀内容（如系统提示、长文档、代码上下文），服务端会将该部分的KV计算结果缓存起来，后续请求直接读取缓存而无需重新计算，从而大幅降低输入token的处理费用。在多轮对话或多子代理协作场景中，每个子代理往往共享大量相同的上下文，缓存命中率极高。以本实验为例，缓存读取token（约1亿）是输出token（约74万）的130余倍，这意味着整体费用的主体由缓存读取价格决定，而非模型的标牌输入输出单价。理解缓存机制是评估长上下文agent实际成本的关键前提。

工程编排：779次工具调用与14个子代理

完成30秒版本时，发帖者动用了14个子代理（sub-agents）协同工作。整个过程涉及779次工具调用——主对话161次，子代理们贡献了618次——总耗时约2.4小时。

值得一提的是，这2.4小时里很大一部分并不是模型在"思考"，而是在等待渲染。canvas绘帧、ffmpeg编码、音频合成这些环节都需要实际计算时间。这也解释了为什么一个看似"AI一键生成"的成果，背后其实是一套相当传统的软件流水线，只是把编写和调度这套流水线的工作交给了模型。

这种多子代理拆分复杂任务的模式，正逐渐成为高级agent应用的常见范式：主代理负责规划与统筹，子代理并行处理各个模块，最终汇总成品。

多子代理（Multi-agent）架构是指将复杂任务拆解后，由一个主代理（Orchestrator）调度多个专职子代理并行或串行完成各自模块，最终汇总结果。每个子代理通常拥有独立的上下文窗口和工具访问权限，可以专注于单一职责——例如一个子代理负责生成某段动画的Canvas绘制代码，另一个负责音频合成逻辑。这种架构的优势在于突破单一上下文窗口的长度限制、实现并行处理以缩短总耗时，并降低单次任务失败对整体的影响。工具调用（Tool Call）则是代理与外部环境交互的基本单元，包括执行代码、读写文件、调用浏览器渲染等操作；779次工具调用反映了整个任务中模型与运行环境之间的交互密度。

这个实验说明了什么

单一来源的这次实测，至少提供了两条有价值的观察。

其一，用代码而非视频模型来生成动态视觉，在可控性、精确度和可复现性上有独特优势。每一帧都是确定的代码产物，可以精确调整参数、复用逻辑，这是扩散式视频模型难以企及的。

其二，模型选型的成本决策不能只看单价。在缓存密集型的agent任务中，实际成本差异可能远小于标价差异，这为"用得起更强模型"提供了现实空间。

需要说明的是，以上数据均来自发帖者个人的会话记录折算，未经第三方独立验证，具体数字应作为参考而非精确基准。