ruflo-cost-tracker 成本燃烧率观测用cost-burn追踪生产环境的日烧钱速率与漂移告警【免费下载链接】ruflo The original agent meta-harness. Deploy intelligent multi-player swarms, coordinate autonomous workflows, and build conversational AI systems. Features adaptive memory, self-learning intelligence, RAG integration, and native Claude Code / Codex / Hermes and many more Integrated项目地址: https://gitcode.com/GitHub_Trending/cl/ruflo导读在 AI Agent 生产环境中预算超支往往不是突然发生的而是燃烧速率burn rate悄悄加速的结果——某个热循环hot loop可能让单日 LLM 开销飙到正常值的 10 倍而传统预算检查要等到接近阈值才会报警。本文基于 ruflo 项目 ruflo-cost-tracker 插件的cost-burn技能SKILL.md及其实现脚本 burn.mjs系统讲解如何把生产环境会话花费按时间窗口分桶、计算窗口间增量并通过可配置的加速度阈值让 CI 构建在烧钱速率失控时直接失败。读完本文你将掌握cost-burn的完整命令行参数、底层算法与边界行为并能在自己的流水线中落地预算无关的速率告警。cost-burn 在成本观测栈中的定位ruflo-cost-tracker 将成本观测拆成了四个互补的视角cost-burn是其中的第四块拼图回答的是趋势问题要回答的问题技能视角我们是否已经越过了阈值反应式cost-budget-check存量检查我们什么时候会越过阈值预测式cost-projection前瞻预测我们本可以花得更少吗对比式cost-counterfactual反事实对比日烧钱速率是否在加速趋势cost-burn← 本文主题速率趋势cost-burn与同为趋势类的cost-trend有本质区别cost-trend读取 docs/benchmarks/runs/*.json 下的基准运行数据回答基准测试指标胜率、延迟是否漂移而cost-burn读取cost-tracking命名空间下的会话记录回答生产环境花费是否在加速。两者数据源不同、问题不同互相补充。前置条件会话花费数据从哪来cost-burn分析的数据源是cost-tracking命名空间中的session-*记录。这些记录由同插件的cost track命令track.mjs生产它扫描~/.claude/projects/编码后的工作目录/下最近修改的会话 jsonl逐行解析 assistant 消息的 usage 字段按模型定价换算成 USD聚合出包含total_cost_usd、capturedAt、endedAt、startedAt、byModel、byTier的结构化记录再通过memory store --namespace cost-tracking --key session-sessionId持久化。插件还在会话结束Stop 钩子时通过 hooks/hooks.json 自动触发捕获无需手动调用。也就是说只要插件在正常使用cost-burn就永远有真实数据可分析。成本换算的定价表由 _prices.mjs 统一维护每 1M tokensUSD模型层级InputOutputCache WriteCache ReadHaiku$0.25$1.25$0.30$0.03Sonnet$3.00$15.00$3.75$0.30Opus$15.00$75.00$18.75$1.50命令行参数与算法参数一览cost-burn的命令行形态为cost burn [--bucket 1d] [--lookback 14d] [--alert-on-acceleration-pct 50] [--format table|json]参数默认值说明--bucket1d分桶窗口时长支持N h\|d\|w\|m小时/天/周/月如1d、1w、6h--lookback14d回看窗口总时长同样支持N h\|d\|w\|m默认覆盖最近 14 天--alert-on-acceleration-pct未设置加速度告警阈值百分比。设置后当最新桶相对历史均值的增幅超过该值时进程以退出码 1 结束--formattable输出格式tableMarkdown 表格或json结构化 JSON供 CI 与脚本消费也可以直接用 Node 调用实现脚本例如node plugins/ruflo-cost-tracker/scripts/burn.mjs --bucket 1w --lookback 90d每周分桶、回看一个季度。此外还支持两个环境变量BURN_NAMESPACE覆盖数据源命名空间默认cost-trackingBURN_QUIET1等价于--format json用于静默脚本化调用。算法步骤从 burn.mjs 的实现看算法共五步读取会话记录通过共享加载器 _sessions.mjs 的loadSessions(NS)拉取cost-tracking命名空间下所有session-*键并解析 JSON按窗口分桶在--lookback时间窗内从当前时刻Date.now()往回数把每条会话按时间戳落进--bucket时长的桶。桶序号从新到旧计数index 0 是最近一个 bucketnow-bucketMs到nowindex 1 是再往前一个依此类推桶数量为ceil(lookbackMs / bucketMs)聚合每个桶每个桶输出{n: 会话数, spendUsd: Σ total_cost_usd}即桶内会话条数与总花费计算增量delta 最新桶.spendUsd - mean(所有非空历史桶.spendUsd)。注意历史均值只统计非空桶n 0既避免除以零也防止稀疏历史把大量空窗口算进均值拉低基线告警判定若设置了--alert-on-acceleration-pct N当deltaPct N时触发告警并以退出码 1 结束。其中deltaPct delta / priorMean × 100。每条会话的时间戳解析优先级为capturedAt→endedAt→startedAt见 _sessions.mjs保证记录字段不完整时依然能落桶。冒烟示例解读技能文档给出的冒烟场景是5 天每天 $0.10今天 $0.50即 400% 加速度| Latest bucket spend | $0.500000 (1 sessions) | | Prior bucket mean | $0.100000 (4 non-empty buckets) | | **Delta (latest vs prior mean)** | **$0.400000 (400.00%)** | # | Window | Sessions | Spend 0 | 2026-06-15 14:16 → 2026-06-16 14:16 | 1 | $0.500000 1 | 2026-06-14 14:16 → 2026-06-15 14:16 | 0 | $0.000000 2 | 2026-06-13 14:16 → 2026-06-14 14:16 | 1 | $0.100000 3 | 2026-06-12 14:16 → 2026-06-13 14:16 | 1 | $0.100000 ...表格按最新在前排列index 0 是最近窗口空桶如 index 1显示$0.000000且不计入历史均值。输出中的六个小数位精度来自源码中对金额的toFixed(6)/Math.round(x * 1e6) / 1e6归一化处理burn.mjs。漂移告警退出码让构建在烧钱加速时失败cost-burn的核心价值在于把趋势信号变成可编程的退出码。文档中的两个对照示例$ cost burn --bucket 1d --lookback 7d --alert-on-acceleration-pct 50 ⚠ ALERT: latest bucket $0.500000 is 400.0% above prior mean $0.100000 (threshold 50%) exit 1 $ cost burn --bucket 1d --lookback 7d --alert-on-acceleration-pct 500 ✓ latest bucket within 500% of prior mean (actual delta: 400.0%) — OK exit 0语义是阈值设 50% 表示最新一天比历史日均值贵 50% 以上就视为失控设 500% 表示贵 5 倍以内都能接受。判定条件在源码中是deltaPct ARGS.alertPct严格大于等于阈值不触发。同时--alert-on-acceleration-pct必须为正数 0否则以退出码 2 报配置错误。CI 集成示例把退出码接入流水线非常简单——直接利用 shell 的短路语义# 当天花费相对周均值加速超过 100% 就失败构建并呼叫值班 cost burn --bucket 1d --lookback 7d --alert-on-acceleration-pct 100 || alert-oncall与预算告警的本质差异文档特别强调告警独立于预算——即使在总花费远低于预算时它也会在速率加速上触发。这正是它比cost-budget-check更早发现问题的原因预算告警是存量视角总花费达到预算的 50/75/90/100% 才逐级报警见 README.md 的告警阶梯燃烧率告警是流量视角哪怕当前总花费只占预算的一小部分只要单日烧钱速度在飙升例如上线了一个烧钱是平时 10 倍的热循环cost-burn会抢在预算报警之前就响起来。边界情况与冷启动保护文档列出了三类边界行为源码中均有对应实现burn.mjs无历史基线冷启动若回看窗口内不存在任何非空的历史桶告警被跳过并输出原因字符串skipped (no prior non-empty buckets to compare — need ≥1)进程正常以退出码 0 结束——避免在数据稀疏的启动阶段对运维产生误报骚扰历史全为 $0、最新桶有花费此时priorMean 0deltaPct在数学上为InfinityJSON 输出中记为null表格中标记为new同样不触发告警没有基线可对比无法判定加速--bucket大于--lookback配置自相矛盾例如--bucket 30d --lookback 7d立即以退出码 2报硬错误burn: --bucket (...) cannot exceed --lookback (...)而不是静默产出无意义结果。同理--bucket或--lookback的时长格式非法非N(h|d|w|m)也以退出码 2 拒绝。JSON 输出供脚本与 CI 消费的结构化契约--format json是cost-burn面向程序化消费的接口。其顶层结构burn.mjs包含字段含义namespace/config数据源命名空间与本次调用的参数快照bucket、lookback、alertOnAccelerationPctbucketsConsidered/sessionsInLookback桶总数与回看窗口内的会话总数latest最新桶windowStart/windowEndISO 时间戳、sessions、spendUsdpriorMean历史均值参与统计的非空桶数量bucketsConsidered与meanSpendUsddeltadeltaUsd与deltaPct不可计算时为nullseries逐桶数组每个桶的bucketIndex、窗口起止、sessions、spendUsdalert告警对象triggered、reason、thresholdPct未设置阈值时为nullgeneratedAt生成时间下游可以这样消费# 最新桶相对历史均值加速超过 100% 时构建失败 cost burn --bucket 1d --lookback 7d --alert-on-acceleration-pct 100 --format json \ | jq -e .alert.triggered true质量保障冒烟测试中的契约插件把burn 技能存在且实现正确固化进了结构化的冒烟测试 smoke.sh其中 step 39d 逐一断言burn.mjs可执行、语法合法、通过受审的_sessions.mjs共享加载器做安全的外部调用、包含bucket/lookback/alert-on-acceleration-pct三个参数、实现priorMean/priorNonEmpty逻辑、具备process.exit(1)失败关闭与process.exit(2)配置错误两条退出路径技能文档本身也必须引用burn.mjs、包含 drift / acceleration / burn-rate 概念关键词与alert-on-acceleration-pct参数说明。验证方式bash plugins/ruflo-cost-tracker/scripts/smoke.sh预期输出44 passed, 0 failed。这也提醒使用者cost-burn不是一次性脚本而是被 CI 契约锁定的插件能力改动其行为会直接被冒烟测试拦截。小结cost-burn用分桶 → 窗口间增量 → 加速度告警三步把生产环境的烧钱趋势变成可观测、可告警、可进 CI 的信号。它和预算检查互补预算回答还剩多少燃烧率回答正在以什么速度烧、是否在失控。对于运行多 Agent 工作流的团队建议在预算阶梯之外至少配一条--alert-on-acceleration-pct的燃烧率门禁——它专治预算没超但速率已经失控这类最危险的中期故障。延伸阅读cost-burn 技能定义 — 本文依据的原始文档burn.mjs 实现 — 算法与退出码的完整源码_sessions.mjs 共享加载器 — 会话读取与时长解析的统一入口track.mjs 数据生产端 —session-*记录从 jsonl 到命名空间的写入流程ruflo-cost-tracker README — 全部 23 个子命令与定价/预算/联邦集成总览cost-trend 技能 — 与cost-burn互补的基准漂移分析冒烟测试 — 对 burn 技能契约的自动化断言【免费下载链接】ruflo The original agent meta-harness. Deploy intelligent multi-player swarms, coordinate autonomous workflows, and build conversational AI systems. Features adaptive memory, self-learning intelligence, RAG integration, and native Claude Code / Codex / Hermes and many more Integrated项目地址: https://gitcode.com/GitHub_Trending/cl/ruflo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
ruflo-cost-tracker 成本燃烧率观测用cost-burn追踪生产环境的日烧钱速率与漂移告警【免费下载链接】ruflo The original agent meta-harness. Deploy intelligent multi-player swarms, coordinate autonomous workflows, and build conversational AI systems. Features adaptive memory, self-learning intelligence, RAG integration, and native Claude Code / Codex / Hermes and many more Integrated项目地址: https://gitcode.com/GitHub_Trending/cl/ruflo导读在 AI Agent 生产环境中预算超支往往不是突然发生的而是燃烧速率burn rate悄悄加速的结果——某个热循环hot loop可能让单日 LLM 开销飙到正常值的 10 倍而传统预算检查要等到接近阈值才会报警。本文基于 ruflo 项目 ruflo-cost-tracker 插件的cost-burn技能SKILL.md及其实现脚本 burn.mjs系统讲解如何把生产环境会话花费按时间窗口分桶、计算窗口间增量并通过可配置的加速度阈值让 CI 构建在烧钱速率失控时直接失败。读完本文你将掌握cost-burn的完整命令行参数、底层算法与边界行为并能在自己的流水线中落地预算无关的速率告警。cost-burn 在成本观测栈中的定位ruflo-cost-tracker 将成本观测拆成了四个互补的视角cost-burn是其中的第四块拼图回答的是趋势问题要回答的问题技能视角我们是否已经越过了阈值反应式cost-budget-check存量检查我们什么时候会越过阈值预测式cost-projection前瞻预测我们本可以花得更少吗对比式cost-counterfactual反事实对比日烧钱速率是否在加速趋势cost-burn← 本文主题速率趋势cost-burn与同为趋势类的cost-trend有本质区别cost-trend读取 docs/benchmarks/runs/*.json 下的基准运行数据回答基准测试指标胜率、延迟是否漂移而cost-burn读取cost-tracking命名空间下的会话记录回答生产环境花费是否在加速。两者数据源不同、问题不同互相补充。前置条件会话花费数据从哪来cost-burn分析的数据源是cost-tracking命名空间中的session-*记录。这些记录由同插件的cost track命令track.mjs生产它扫描~/.claude/projects/编码后的工作目录/下最近修改的会话 jsonl逐行解析 assistant 消息的 usage 字段按模型定价换算成 USD聚合出包含total_cost_usd、capturedAt、endedAt、startedAt、byModel、byTier的结构化记录再通过memory store --namespace cost-tracking --key session-sessionId持久化。插件还在会话结束Stop 钩子时通过 hooks/hooks.json 自动触发捕获无需手动调用。也就是说只要插件在正常使用cost-burn就永远有真实数据可分析。成本换算的定价表由 _prices.mjs 统一维护每 1M tokensUSD模型层级InputOutputCache WriteCache ReadHaiku$0.25$1.25$0.30$0.03Sonnet$3.00$15.00$3.75$0.30Opus$15.00$75.00$18.75$1.50命令行参数与算法参数一览cost-burn的命令行形态为cost burn [--bucket 1d] [--lookback 14d] [--alert-on-acceleration-pct 50] [--format table|json]参数默认值说明--bucket1d分桶窗口时长支持N h\|d\|w\|m小时/天/周/月如1d、1w、6h--lookback14d回看窗口总时长同样支持N h\|d\|w\|m默认覆盖最近 14 天--alert-on-acceleration-pct未设置加速度告警阈值百分比。设置后当最新桶相对历史均值的增幅超过该值时进程以退出码 1 结束--formattable输出格式tableMarkdown 表格或json结构化 JSON供 CI 与脚本消费也可以直接用 Node 调用实现脚本例如node plugins/ruflo-cost-tracker/scripts/burn.mjs --bucket 1w --lookback 90d每周分桶、回看一个季度。此外还支持两个环境变量BURN_NAMESPACE覆盖数据源命名空间默认cost-trackingBURN_QUIET1等价于--format json用于静默脚本化调用。算法步骤从 burn.mjs 的实现看算法共五步读取会话记录通过共享加载器 _sessions.mjs 的loadSessions(NS)拉取cost-tracking命名空间下所有session-*键并解析 JSON按窗口分桶在--lookback时间窗内从当前时刻Date.now()往回数把每条会话按时间戳落进--bucket时长的桶。桶序号从新到旧计数index 0 是最近一个 bucketnow-bucketMs到nowindex 1 是再往前一个依此类推桶数量为ceil(lookbackMs / bucketMs)聚合每个桶每个桶输出{n: 会话数, spendUsd: Σ total_cost_usd}即桶内会话条数与总花费计算增量delta 最新桶.spendUsd - mean(所有非空历史桶.spendUsd)。注意历史均值只统计非空桶n 0既避免除以零也防止稀疏历史把大量空窗口算进均值拉低基线告警判定若设置了--alert-on-acceleration-pct N当deltaPct N时触发告警并以退出码 1 结束。其中deltaPct delta / priorMean × 100。每条会话的时间戳解析优先级为capturedAt→endedAt→startedAt见 _sessions.mjs保证记录字段不完整时依然能落桶。冒烟示例解读技能文档给出的冒烟场景是5 天每天 $0.10今天 $0.50即 400% 加速度| Latest bucket spend | $0.500000 (1 sessions) | | Prior bucket mean | $0.100000 (4 non-empty buckets) | | **Delta (latest vs prior mean)** | **$0.400000 (400.00%)** | # | Window | Sessions | Spend 0 | 2026-06-15 14:16 → 2026-06-16 14:16 | 1 | $0.500000 1 | 2026-06-14 14:16 → 2026-06-15 14:16 | 0 | $0.000000 2 | 2026-06-13 14:16 → 2026-06-14 14:16 | 1 | $0.100000 3 | 2026-06-12 14:16 → 2026-06-13 14:16 | 1 | $0.100000 ...表格按最新在前排列index 0 是最近窗口空桶如 index 1显示$0.000000且不计入历史均值。输出中的六个小数位精度来自源码中对金额的toFixed(6)/Math.round(x * 1e6) / 1e6归一化处理burn.mjs。漂移告警退出码让构建在烧钱加速时失败cost-burn的核心价值在于把趋势信号变成可编程的退出码。文档中的两个对照示例$ cost burn --bucket 1d --lookback 7d --alert-on-acceleration-pct 50 ⚠ ALERT: latest bucket $0.500000 is 400.0% above prior mean $0.100000 (threshold 50%) exit 1 $ cost burn --bucket 1d --lookback 7d --alert-on-acceleration-pct 500 ✓ latest bucket within 500% of prior mean (actual delta: 400.0%) — OK exit 0语义是阈值设 50% 表示最新一天比历史日均值贵 50% 以上就视为失控设 500% 表示贵 5 倍以内都能接受。判定条件在源码中是deltaPct ARGS.alertPct严格大于等于阈值不触发。同时--alert-on-acceleration-pct必须为正数 0否则以退出码 2 报配置错误。CI 集成示例把退出码接入流水线非常简单——直接利用 shell 的短路语义# 当天花费相对周均值加速超过 100% 就失败构建并呼叫值班 cost burn --bucket 1d --lookback 7d --alert-on-acceleration-pct 100 || alert-oncall与预算告警的本质差异文档特别强调告警独立于预算——即使在总花费远低于预算时它也会在速率加速上触发。这正是它比cost-budget-check更早发现问题的原因预算告警是存量视角总花费达到预算的 50/75/90/100% 才逐级报警见 README.md 的告警阶梯燃烧率告警是流量视角哪怕当前总花费只占预算的一小部分只要单日烧钱速度在飙升例如上线了一个烧钱是平时 10 倍的热循环cost-burn会抢在预算报警之前就响起来。边界情况与冷启动保护文档列出了三类边界行为源码中均有对应实现burn.mjs无历史基线冷启动若回看窗口内不存在任何非空的历史桶告警被跳过并输出原因字符串skipped (no prior non-empty buckets to compare — need ≥1)进程正常以退出码 0 结束——避免在数据稀疏的启动阶段对运维产生误报骚扰历史全为 $0、最新桶有花费此时priorMean 0deltaPct在数学上为InfinityJSON 输出中记为null表格中标记为new同样不触发告警没有基线可对比无法判定加速--bucket大于--lookback配置自相矛盾例如--bucket 30d --lookback 7d立即以退出码 2报硬错误burn: --bucket (...) cannot exceed --lookback (...)而不是静默产出无意义结果。同理--bucket或--lookback的时长格式非法非N(h|d|w|m)也以退出码 2 拒绝。JSON 输出供脚本与 CI 消费的结构化契约--format json是cost-burn面向程序化消费的接口。其顶层结构burn.mjs包含字段含义namespace/config数据源命名空间与本次调用的参数快照bucket、lookback、alertOnAccelerationPctbucketsConsidered/sessionsInLookback桶总数与回看窗口内的会话总数latest最新桶windowStart/windowEndISO 时间戳、sessions、spendUsdpriorMean历史均值参与统计的非空桶数量bucketsConsidered与meanSpendUsddeltadeltaUsd与deltaPct不可计算时为nullseries逐桶数组每个桶的bucketIndex、窗口起止、sessions、spendUsdalert告警对象triggered、reason、thresholdPct未设置阈值时为nullgeneratedAt生成时间下游可以这样消费# 最新桶相对历史均值加速超过 100% 时构建失败 cost burn --bucket 1d --lookback 7d --alert-on-acceleration-pct 100 --format json \ | jq -e .alert.triggered true质量保障冒烟测试中的契约插件把burn 技能存在且实现正确固化进了结构化的冒烟测试 smoke.sh其中 step 39d 逐一断言burn.mjs可执行、语法合法、通过受审的_sessions.mjs共享加载器做安全的外部调用、包含bucket/lookback/alert-on-acceleration-pct三个参数、实现priorMean/priorNonEmpty逻辑、具备process.exit(1)失败关闭与process.exit(2)配置错误两条退出路径技能文档本身也必须引用burn.mjs、包含 drift / acceleration / burn-rate 概念关键词与alert-on-acceleration-pct参数说明。验证方式bash plugins/ruflo-cost-tracker/scripts/smoke.sh预期输出44 passed, 0 failed。这也提醒使用者cost-burn不是一次性脚本而是被 CI 契约锁定的插件能力改动其行为会直接被冒烟测试拦截。小结cost-burn用分桶 → 窗口间增量 → 加速度告警三步把生产环境的烧钱趋势变成可观测、可告警、可进 CI 的信号。它和预算检查互补预算回答还剩多少燃烧率回答正在以什么速度烧、是否在失控。对于运行多 Agent 工作流的团队建议在预算阶梯之外至少配一条--alert-on-acceleration-pct的燃烧率门禁——它专治预算没超但速率已经失控这类最危险的中期故障。延伸阅读cost-burn 技能定义 — 本文依据的原始文档burn.mjs 实现 — 算法与退出码的完整源码_sessions.mjs 共享加载器 — 会话读取与时长解析的统一入口track.mjs 数据生产端 —session-*记录从 jsonl 到命名空间的写入流程ruflo-cost-tracker README — 全部 23 个子命令与定价/预算/联邦集成总览cost-trend 技能 — 与cost-burn互补的基准漂移分析冒烟测试 — 对 burn 技能契约的自动化断言【免费下载链接】ruflo The original agent meta-harness. Deploy intelligent multi-player swarms, coordinate autonomous workflows, and build conversational AI systems. Features adaptive memory, self-learning intelligence, RAG integration, and native Claude Code / Codex / Hermes and many more Integrated项目地址: https://gitcode.com/GitHub_Trending/cl/ruflo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
