我的代码智能体在 2026 年全年使用 Claude Fable 5 以及 OpenAI 的 GPT-5.4、GPT-5.5 和 GPT-5.6 系列模型处理真实工作：网站、iOS 应用、电子商务、CRM、音乐工具、SEO 系统以及我自己的智能体工作流。当我汇总仍留在我 Mac 上的本地会话日志时，数字定格在 215.4 亿 Token。
这个数字荒谬至极。同时也需要背景语境。
这其中大部分并非为我新撰写的 215 亿个单词。长时间的智能体会话会多次通过上下文发送大型代码库和指令。很大一部分是从缓存中读取的。Token 计数主要显示了我的代码智能体处理了多少上下文。
经过这段时间，我的结论依然明确：我们已经升级了。模型能够维持更长的任务，使用工具，并在一年前还感觉遥不可及的水平上修复错误。然而，模型本身仍然是可靠系统中最无趣的部分。
215 亿 Token 揭示了关于代码智能体的什么
我通过保留的 Codex 日志中的每个 `last_token_usage` 值统计了 OpenAI 的使用量。对于 Fable，我使用 Claude 日志中独特的助手消息进行统计，包括正常输入、缓存创建、缓存读取和输出。结果是本地活动测量值——而非 OpenAI 或 Anthropic 的账单。
| 模型 | 记录的活动 Token 数 | 独特使用事件/模型回复数 |
|---|---|---|
| --- | ---: | ---: |
| GPT-5.5 | 129.6 亿 | 95,930 |
| GPT-5.6 Sol, Terra, and Luna | 18.8 亿 | 12,370 |
| GPT-5.4 including Mini | 34.3 亿 | 26,624 |
| Claude Fable 5 | 32.7 亿 | 16,878 |
| 总计 | 215.4 亿 | 151,802 |
使用高水位线法，GPT-5.4 约占 32.1 亿缓存输入 Token，GPT-5.5 占 123.0 亿，GPT-5.6 系列约占 18.2 亿。Fable 日志包含约 30.5 亿次缓存读取和 1.81 亿次缓存创建 Token。
这就是为什么将总数与人类可阅读的文本量进行比较会产生误导。智能体工作会重用大型上下文。相关的问题是系统是否用它们做了正确的事情。
使用量背后的代码库：59 个 GitHub 项目
在测量时，我的 GitHub 账户拥有 59 个仓库：50 个私有库和 9 个公共库。大致分类如下：
在 26 个具有完全相同名称的本地检出的 GitHub 仓库中，在过滤掉供应商、构建、缓存和压缩文件后，我发现了 690 万行被追踪的源代码。这个数字主要由三个大型遗留 PHP 平台主导。如果去掉它们，在更现代、更多自建的表面（包括 TypeScript、Python、Swift、Shell 和 Astro）中，大约还剩下 35.7 万行。
这并不是为了赢得代码行数竞赛。一百万行糟糕的代码仍然是债务。这些统计数据展示了模型测试环境的广度：移动端、后端、前端、自动化、内容、运营和业务逻辑。
Fable 5 和 GPT-5.6 更好——但在不同方面
Anthropic 将 Fable 5 描述为其用于大型代码项目、迁移和长时间自主会话的模型。OpenAI 将 GPT-5.4 描述为前沿编码、知识工作和计算机使用的融合。GPT-5.6 系列则将重点进一步推向长期运行的智能体工作。
这与我的经验非常吻合。Fable 通常在开始更改代码之前更擅长理解难题的形状。GPT-5.6 Sol 则更有可能抓住问题，使用工具，并推动工作向前发展。
X 上的辩论也显示了同样的分歧：
这种批评是公平的。如果路由、定价、上下文限制或安全策略难以理解，更好的模型仍然可能导致更糟糕的工作日。
模型是引擎，而不是汽车
语言模型可以对代码进行推理。代码智能体还必须在真实系统中运行。
我的实用堆栈如下所示：
每个部分解决不同的问题。没有工具的技能只是文档。没有策略的工具是风险。没有源代码控制的内存会变成旧的传说。没有实时检查的构建仍然可能导致生产环境崩溃。
MCP 开发者工作流：真正的控制层→ 尤为重要，因为它将集成从自定义提示转移到多个客户端都能理解的契约中。例如，我的个人页面 MCP 可以进行研究、创建草稿、生成图像、分析 SEO 并发布。同一个智能体仍然必须知道何时在未发布的草稿处停止。
巨大的飞跃是更长的工作链
在我早期对 Codex 中的 GPT-5.5→ 的测试中，我看到了同样的转变。一年前，一次好的编码会话通常是：提问，获取代码块，复制，自己测试。现在，智能体可以阅读项目规则，找到正确的仓库，检查路由，更改代码，构建，解决冲突，推送，并验证生产环境。
这是一个质的飞跃。
同时，我也见过模型：
最后一步仍然是最昂贵的：证明结果存在于正确的位置并能为真实用户工作。
我们仍然缺乏什么
更好的自动模型路由
我不希望为每个子任务选择模型名称和推理级别。系统应该将架构审查发送给最擅长全局视野的模型，将机械性更改发送给更快的模型，并将最终验证发送给单独的检查器。
可移植的工作内存
上下文仍然被困在特定的客户端、模型或会话文件中。技能和 MCP 减轻了痛苦，但智能体应该能够在不丢失项目经证实的工作方式的情况下切换模型。
将验证作为一流功能
大多数演示智能体奖励代码生产。我想衡量以验证正确的外部状态结束的任务比例：实时路由、数据库行、已安装的应用、发送的消息或已批准的构建。
更清晰的成本
缓存 Token 更便宜，有时报告方式也不同，但用户通常只看到一个迅速消失的条形图。智能体应该能够说：此任务使用了 X 个新输入 Token，Y 次缓存读取，Z 个输出 Token，并创建了以下已验证的结果。
我的建议：在超级提示之前先构建系统
从一个可以验证的狭窄任务开始。给智能体一小套工具，为该工作流编写一个技能，并定义什么算作完成。然后，当你看到重复出现的需求时，再添加内存和更多工具。
一个有用的代码智能体不需要对所有东西的自由访问权。它需要正确的访问权限、正确的顺序和一个停止规则。
我现在使用 Fable 和 OpenAI 模型时，不再像对待神谕，而是更像对待组件。Fable 可以审查艰难的设计。GPT-5.6 Sol, Terra, and Luna→ 可以按工作配置文件拆分，而 GPT-5.6 可以驱动长期的工具流。较小的模型可以进行翻译或分类。MCP 将它们连接到真实系统。技能赋予 Codex 可重用的工作方式→。Git 和测试决定结果是否可以推进。
215.4 亿 Token 之后，最大的进步并不是模型写出了更漂亮的代码。它们可以在工作中停留更长时间。我们的工作就是构建护栏、内存和验证，让这段时间变得有价值。