测量了执行相同任务的4个代理运行时的令牌消耗。成本从1倍到4倍不等，取决于缓存架构

Reddit r/AI_Agents 新闻
agent-runtimes token-consumption prompt-caching claude-code open-source ai-cost comparison

摘要

对四个代理运行时（Claude Code、OpenClaw、Hermes 和 OpenClacky）在相同任务上的令牌消耗进行比较显示，相对于 Claude Code，成本从0.8倍到4倍不等，这由缓存架构和工具模式设计的差异驱动。

我一直在探究为什么有些代理运行时消耗令牌的速度比其他快得多，即使使用相同的模型。我在三个真实任务上进行了受控比较，差距比我预想的大。设置：相同模型（Claude Sonnet），相同任务，测量总输入+输出令牌。测试的代理包括 Claude Code、OpenClaw、Hermes 以及我们自己的（OpenClacky，开源）。粗略结果，以 Claude Code 为 1.0x 标准化： - Hermes: ~3-4x。它内置了52个工具。每次 API 调用都会发送完整的模式。每轮需要10-25k令牌的工具定义。如果模式发生变化（动态工具），则整个缓存会失效。 - OpenClaw: ~1.5x。运行时稳定，但技能加载会接触系统提示，导致每次技能调用时前缀匹配失效。 - Claude Code: 1.0x 基线。良好的缓存工程，闭源。 - OpenClacky: ~0.8x。16个工具，冻结的系统提示，双重缓存标记。缓存命中率保持在90%以上。 根本问题很简单。每轮中，API 接收：系统提示 + 工具定义 + 完整对话历史。如果提示缓存命中，对于模型已经看到的内容，你只需支付1/10的价格（Anthropic）或半价（OpenAI）。如果缓存未命中，则全额支付。大多数运行时在不知不觉中破坏了自身的缓存。 常见原因： - 在会话中间添加或移除工具会改变系统提示的字节 - 将新上下文加载到系统提示中（技能、记忆、规则） - 在错误的时间压缩历史记录会重写已缓存的内容 - 模型切换会分割缓存命名空间 修复方法在概念上并不复杂：冻结前缀，将动态状态放在其他地方，使用滚动缓存标记，以便历史增长不会使之前的轮次失效。不过，我们花了两个失败的架构和八个月才把顺序搞对。 如果你通过 LiteLLM 或本地 OpenAI 兼容服务器运行本地模型，这是可行的。不过缓存收益取决于你的提供商。目前 Anthropic 和 OpenAI 拥有最好的缓存基础设施。无论如何，本地设置仍然受益于较小的提示。 如果有人想深入了解方法论，我很乐意进一步说明。
查看原文

相似文章

一个 Token 值多少算力？基于 Mixture-of-Agents 测量大模型的每 Token 充分算力

arXiv cs.AI

本文利用由 Qwen、OLMo 和 R1-distilled 系列共 15 个模型组成的 Mixture-of-Agents 评审面板，测量了大模型的每 Token「充分算力」。研究发现，一个 0.5B 的小模型即可复现参考模型 92%–95% 的输出 Token，而成本最高的 10% Token 却占用了 64%–80% 的 FLOPs。由此得到的每 Token 算力分布图将模型路由延迟从 7.59 秒降低至 5.12 秒，并使推测式草稿生成所需的草稿 Token 数比固定窗口基线减少 32.6%。

在单智能体和多智能体配置下节省使用额度

Reddit r/ArtificialInteligence

一位实践者分享了在 Codex 和 Claude 中通过选择单智能体或多智能体配置来节省 AI 使用额度的技巧，并指出子智能体和反复交叉核查会消耗 token，却无法改善结果。作者测试了以 Opus 5.5 作为协调器，动态选择 Haiku 5.5 Short 或 Long，并优化缓存设置，将两小时内的用量降至每周额度的约 5%。