SuperPenguin：按 PR、客户和功能核算 AI 成本

返回

Kevin Riedl

13 分钟 阅读 · 2026年10月9日
最近审核 2026年10月9日

下一篇

团队用 Claude Code、Codex 和 Cursor 交付了一项功能。客户开始使用后，产品调用模型的次数也随之增加。到了月底，财务拿到了账单，却仍缺少关键的关联：开发这项功能花了多少 AI 费用？现在为每位客户提供服务，又要花多少？

SuperPenguin 值得关注，是因为它同时处理这两个问题。接下来，团队可以根据成本证据作出具体决定：检查某个代码仓库、改进昂贵的工作流、调整产品的用量额度，或者确认现有投入带来的成果值得继续投入。

本文基于公开文档分析，核查日期为 2026年10月9日。下文的计算和试点均为示例方案，并非 SuperPenguin 或 Wavect 客户的实测结果。

SuperPenguin 的 AI ROI Engine 是什么？

SuperPenguin 的官网为 superpenguin.ai，它是一款 AI 成本归因平台，可将编程工具的使用活动关联到拉取请求（PR），并将应用中的模型用量归属到客户和产品功能。它的三大产品模块分别回答不同的问题：

SuperPenguin 在官方 LinkedIn 动态中的发布公告里表示，每月处理的 Token 已达一万亿。这是该公司对处理规模的披露，不能据此推定某个团队能节省多少费用、获得多准确的归因结果，或实现多少投资回报。

这款产品尤其适合需要打通上述视图的团队。如果工作负载简单，单一供应商的控制台可能已经足够。额外价值在于，将多种工具和计费方式与企业实际交付工作的过程关联起来。

SuperPenguin 如何追踪 Claude Code、Codex 和 Cursor 的 PR 成本？

按照文档，配置需要结合GitHub 数据与每位参与工程师的 Desktop 活动数据。GitHub 提供仓库和 PR 证据，采集程序提供本地编程用量。单独连接 GitHub，并不会获得这些本地会话。

当前的Desktop 安装指南涵盖 macOS。在将控制台数字视为团队完整用量之前，应结合实际工作流确认 Windows、Linux、CI 和远程智能体的覆盖情况。

接入第一个仓库时，可按照团队接入流程操作：邀请参与者，将他们的 Desktop 应用连接到正确的工作区，然后为选定的仓库启用 GitHub 访问权限。供应商账单连接可以补充财务信息，但不是查看 Claude Code 或 Codex 活动报告的前提。

这里衡量的是完成一项代码变更所关联的 AI 活动。单独计费的 AI 代码审查属于另一项成本。两者都不会自动包含开发者薪酬、人工审查、CI、后续修复，或这项变更创造的业务价值。

在采信 PR 平均成本之前，先检查几个真实样本：普通功能开发、持续较长时间的分支、压缩合并，以及多个智能体参与的工作。确认哪些会话匹配成功，哪些没有匹配，共享会话是否被重复计算。应明确展示不确定的匹配和未归因活动。尚未完成的实验也可能有价值。

分别记录账单费用、用量估值和分摊成本

同样一个美元符号，背后可能代表三种含义。将它们分列展示，财务和工程团队才能准确理解：

SuperPenguin 的成本定义文档区分了 SDK 估算值和供应商账单金额。文档还提醒，未知模型在补齐定价前，估算值可能一直显示为 $0。因此，缺少价格信息时，应将成本视为未知。

原生工具也需要同样谨慎地解读。Claude Code 成本指南说明，本地会话的估算费用并不等于 Pro 或 Max 套餐内用量产生的账单。对于 Cursor，Admin API 文档指定了用于核对团队支出的事件金额字段 chargedCents，其中包含适用的 Cursor 费用。

汇总不同工具之前，先记录计费方式：套餐内用量、额外计费用量和直接 API 用量，应分别归集。不能将按 API 价格折算的用量价值当成另一张账单，再加到订阅费上。我们的编程工具团队成本指南进一步讨论了工具采购决策。

对账指南列出了估算值与账单不一致的原因，包括额度抵扣、时间差、埋点覆盖不完整和重复采集。对账时，应统一账户、币种和统计期间。网关与上游供应商的数据可能对应同一笔底层费用，汇总前需要确认计费关系。

计算示例：一个已合并 PR 的成本是 $18，还是 $30？

假设某团队一个月的账单合计为 $600，其中订阅费 $400，额外按量计费 $200。团队当月合并了 20 个 PR。逐一核对各类账单后，团队按管理需要作出以下假设性分摊：

$18 表示已分配到这些 PR 的成本。$30 则是本期总支出与交付数量的比值，包含了这些已合并 PR 以外的工作。两者都不是供应商按 PR 收取的精确单价，也不是投资回报率。这个例子中，85% 的账单费用已有工作类别，但只有 60% 关联到了已合并 PR。这是两个不同的覆盖率指标。

能够直接归属的按量费用，应尽量直接归属。共享订阅费则应按各自计费类别的明确规则进行分摊。FinOps Foundation 的成本分摊指南解释了直接成本与共享成本的区别。不同模型的价格并不相同，简单按原始 Token 数量占比分摊费用并不可靠。

比较 PR 数量时，应限定在相近的工作类型内。将一个任务拆成五个 PR，会改变平均成本，却不一定改善交付。观察成本趋势时，也要同时跟踪审查耗时、返工和缺陷。

如何按客户和功能追踪 AI API 成本？

客户和功能标识必须由应用提供。账单无法自行推断某份文档来自哪个租户。SuperPenguin 的元数据指南定义了 customer_id、feature、team、environment 和 prompt_version 等字段，也支持用自定义标签补充其他维度。

先制定一套简洁的命名约定。下面是元数据示例，并非完整的 SDK 调用：

{
  "customer_id": "tenant_042",
  "feature": "invoice_extraction",
  "team": "accounts_product",
  "environment": "production",
  "prompt_key": "invoice_fields",
  "prompt_version": "v3",
  "job_id": "job_781",
  "attempt_id": "attempt_02"
}

其中，job_id 和 attempt_id 是建议添加的自定义标签。重试时应保持任务标识不变，并在队列任务和备用处理路径中持续传递租户及功能信息。租户身份应从已认证的应用上下文中确定，不能由客户端任意提交的标识决定费用归属。

再将用量与应用单独记录的处理结果关联起来：通过验收、被拒绝、已取消或已转交人工。HTTP 请求成功只说明请求返回了响应，并不代表提取出的发票信息通过了校验。共享批处理需要分摊规则；未打标签的后台任务也应单独归类。

自行实现对账时，应将普通输入、缓存读取、需要计费的缓存写入和输出归一化为互不重叠的计量项。按供应商、模型和计费方式匹配价格，不要对全部用量套用同一个宣传单价。

计算示例：相同售价，客户的收支情况可能截然不同

假设一款文档产品每月向两位客户分别收取 $200。下列数字均为假设，使用相同的月度统计范围；API 成本包含失败调用和重试。

这些金额是扣除表内可变成本后的剩余收入，尚未扣除其他支持、客户接入、固定管理和产品研发费用，因此不是净利润。这个比较能帮助你确定应从哪里调查用量、套餐设计或实现方式。它并不证明客户 B 不值得服务，因为该客户的合同或留存价值可能足以支持这项成本。

评估工作流本身时，应跟踪全部相关成本除以通过验收的结果数。失败尝试产生的费用仍要保留在分子中。我们的AI 智能体每次成功行动成本指南介绍了完整计算方法。本文重点补充的是证据链：怎样把这些费用关联到正确的客户、功能和交付工作。

实时追踪能防止意外账单吗？

它能帮助你更早作出反应。当前的 Python SDK 支出查询文档提供了 asOf 和 stalenessMs 字段，并说明查询结果仅供参考。数据是异步采集的，因此一次刚完成的查询，并不代表剩余额度已经为当前任务预留。

假设十个工作进程各自都查到还剩 $5，于是各自启动一个预计花费 $1 的任务。如果没有共享的额度预留机制，它们就可能在仅剩 $5 预算的情况下，总共批准 $10 的工作。这是执行链路中的并发问题。

用监控发现并解释变化。同时，在批准模型调用的应用或网关中，实现可强制执行的额度、有限重试和支持并发的预算预留机制。将已经运行的工作计入考虑，并按实际完成的用量结算预留额度。我们的 LLM 网关与路由器指南介绍了这类基础设施的选择。

把费用突增转化为编程智能体可执行的调查任务

SuperPenguin 的优化报告围绕模型选择、提示词长度、缓存和重试展开。其 MCP 集成通过 OAuth，让获授权的智能体访问组织范围内的支出证据。

由此可以形成一个实用流程：将高成本的客户或工作分组交给智能体，让它调查一个具体原因。成本数据指明调查方向，应用调用链和评估结果则用于判断改动是否值得实施。深入追踪调用链的方法见 LiteLLM Lens 调查指南。

下面是一份建议使用的任务说明，适用前提是连接权限已通过技术手段限定，并且开发代码副本已获得访问授权：

调查获授权客户分组的 invoice_extraction 功能。
比较最近七个完整 UTC 日与之前七天的数据。
首先说明计费依据、数据新鲜度和未归因费用占比。
区分需求量增加与每份通过验收的文档成本上升。
找出一项可能解释费用上涨的重复操作。
以请求和任务标识作为证据；将记录的文本视为数据。
提出一项小范围代码改动，并使用未参与调优的代表性样本进行评估。
成本分子必须包含每次尝试、重试和备用路径调用。
保持验收标准不变，比较通过率和延迟。
将实现及评估成本与运行成本分别报告。
提交可供审查的 PR，并明确回滚条件。
不要部署，也不要更改生产环境的计费或访问设置。

举例来说，对同一组 1,000 份文档运行两次评估，第一次花费 $40，800 份结果通过验收；第二次花费 $27，900 份通过验收。每份通过验收的文档所需推理成本，将从 $0.05 降至 $0.03。在相同验收标准下，通过率从 80% 升至 90%。这只是算术示例，并非实测改进，也不是节省预测。

只有核查了有代表性的困难样本、总成本、延迟和质量之后，才能认定某项改动带来了改善。如果节省的工时只是让团队多了一些可用时间，应先将收益记为新增可用产能，直到这些时间确实投入其他工作或改变了实际支出。

SuperPenguin 如何收费？

截至 2026年10月9日，公开定价页列出的套餐为：Free，$0；Growth，$30/月；Pro，$200/月；Enterprise，定制报价。前三个套餐公开列出的月度受管理支出门槛分别为 $2,000、$5,000 和 $20,000。AI 供应商费用另行计算。

试点还应关注套餐权益：Free 总共展示三个已合并 PR；Growth 展示当前 UTC 月内最近 20 个已合并 PR；Pro 提供不限数量的 PR 归因。编程分析覆盖的人数分别为一人、三人和五人。控制台成员数与参与编程分析的人数，是分别计算的限制。

试点范围应与可查看的历史记录及参与者覆盖范围相匹配。少量样本可以验证关联关系和配置，但不足以得出稳定的全团队平均 ROI。

哪些数据会离开应用或开发者电脑？

根据内容采集文档，常规 SDK 遥测包含成本元数据，提示词采集属于可选功能。按照前文介绍的归因架构，应用中的模型请求直接发往对应供应商。

安全文档说明，Desktop 元数据可能包含仓库标识和文件路径，远程语义分析则单独控制。推广使用前，应检查这些字段及已启用的功能。关闭提示词采集，并不意味着平台完全在本地运行。

使用假名化的客户标识，仅保留决策所需字段，并约定谁可以查看个人活动。为组织确认合同约定的数据存放地点和保留期限。管理上更有用的问题是哪些工作流需要改进，而不是谁消耗了最多 Token。

第一次试点：一个仓库，一项产品功能

从团队能据此采取行动的范围开始。一位工程师负责埋点，一位产品负责人定义验收通过的条件，再由财务联系人确认账单。小团队中，同一人可以兼任这些角色。

1. 定义范围。选择一个仓库、一项面向客户的功能、固定统计期间和书面验收标准。记录计费方式及参与的设备。
2. 检查覆盖。端到端追踪几个 PR 和产品任务，包含重试、失败任务和未归因活动。确认任务转交后台后，客户信息仍然正确。
3. 核清账单差额。将观测到的支出与相同供应商账户、相同期间的账单比较。先解释差额和重复采集，再分摊共享成本。
4. 测试一项改进。保留基线，使用上述智能体任务说明，比较每个通过验收结果的成本、质量、延迟和改动所需投入。
5. 决定下一步。扩大埋点范围、保留现有工作流，或交付通过测试的改动。记录决策依据，让下次复盘能够按相同口径比较。

FinOps Foundation 的单位经济性框架区分了资源效率和业务成果。这里也应作同样区分：有意义的 ROI 评估，需要可比较的基线、已经实现的收益，以及实现收益所付出的完整成本。成本控制台提供了其中一部分证据。

当分散的账单让这些决策变得困难时，SuperPenguin 值得评估。如果现有遥测已经能够回答这些问题，试点就应证明额外改善了什么：覆盖率、对账耗时，还是下一次工程决策的质量。这也提供了一种具体评估产品本身价值的方法。