尧图网页设计 
RTK 的节省到底省在哪Bash 输出压缩、Token 估算方法与成本换算全解析【免费下载链接】rtkCLI proxy that reduces LLM token consumption by 60-90% on common dev commands. Single Rust binary, zero dependencies项目地址: https://gitcode.com/GitHub_Trending/rtk4/rtk本文基于 RTK 官方文档docs/guide/resources/savings-explained.md展开讲清 RTK 宣称的最高 90% 节省这个数字到底度量的是什么它只压缩 Agent 读到的 shell 命令输出字节绝不承诺等比例降低账单同时结合 tracking 模块源码 与 never-worse 保护逻辑剖析为什么 token 数只是估算值、而百分比却是可信的这一关键设计帮助读者正确读取rtk gain数据并把它放进成本模型中。RTK 只改变一件事shell 命令回传的字节数RTK 的定位是一个 CLI 代理proxy它横插在 Agent 与命令行之间。当 Agent 执行一条 shell 命令时流程如下agent runs a shell command | v RTK filters the output | v agent reads the result也就是Agent 发起命令 → RTK 负责实际执行 → RTK 压缩filter输出 → Agent 读到的是压缩后的版本。RTK 唯一修改的对象是shell 命令发回来的那部分字节。官方文档特别强调RTK 报告的所有 savings度量单位都是这些字节而不是 token、更不是美元。从源码结构看每条受支持的命令执行完成后都会经过统一的记账入口TimedExecution会分别对原始命令输出和RTK 过滤后输出做 token 估算并写入记录见 src/core/tracking.rs 中的TimedExecution::track。此外还有一层安全网never-worse 保护 保证过滤结果如果比原始输出还长就直接返回原始输出即 RTK 永远不会让 Agent 读到更多 token// src/core/guard.rs pub fn never_worsea(raw: a str, filtered: a str) - a str { if estimate_tokens(filtered) estimate_tokens(raw) { raw } else { filtered } }对应测试 src/core/guard.rs 覆盖了过滤后更小则保留过滤结果过滤后更大则回退 raw打平保留过滤结果等边界并有集成测试 tests/guard_integration_test.rs 佐证。节省传导链从字节到账单每一步都在稀释官方文档用一棵树把输出压缩与成本的关系摆得很清楚Cost ├─ Input tokens │ ├─ Bash output - the only part RTK filters │ ├─ Your prompt │ ├─ System prompt │ └─ Conversation history └─ Output tokens - what the model writes这里有两个关键的稀释层级Bash 输出只是输入 token 的一个组成部分与你的 prompt、system prompt、对话历史并列。压缩 90% 的 bash 输出对整体输入 token 的贡献要打个折输入 token 也只是账单的一部分账单还要计入模型生成的输出 token。因此一条命令输出字节少 90%绝不等于这个会话便宜了 90%。这正是 RTK 选择报告bash 输出压缩率而不是直接报成本节省的原因——bash 输出是 RTK 唯一能控制的变量其余部分取决于你的提示词、所选模型、Agent 回写多少内容、以及每次调用时回放了多少对话历史。为什么 token 数只是估算bytes / 4的设计取舍rtk gain展示的所有 token 数都来自一个极简估算器token ≈ ceil(字节数 / 4)对应源码为 src/core/tracking.rs 中的estimate_tokens// src/core/tracking.rs /// Estimate token count from text using ~4 chars 1 token heuristic. pub fn estimate_tokens(text: str) - usize { // ~4 chars per token on average (text.len() as f64 / 4.0).ceil() as usize }单元测试 test_estimate_tokens 固化了该行为的边界语义空串为 04 字符为 1 token5 字符向上取整为 2 token。RTK刻意不内置真正的 tokenizer。官方文档给出了取舍理由内嵌 tokenizer 会增加启动时间开销每个模型的 tokenizer 都不同要么得为每个模型内置一份要么做按会话的模型查询而 RTK 都不打算实现它追求单一 Rust 二进制、零依赖。这个取舍带来一个值得理解的结论也是本文的核心之一百分比是可靠的原始输出和过滤后输出使用的是同一个估算器比值Save%不受估算器绝对精度影响——即使1 token 4 字符本身有偏差对两边同时近似比例依然成立。它本质上是一个字节压缩比。绝对 token 数只是近似rtk gain里出现的Input tokens: 45,230只能当作量级参考不会与服务商账单上的 token 数对得上不应被当作发票行项。如果需要精确数字官方建议的做法是把原始输出与过滤后输出分别送入你所用模型自己的 tokenizer 计数。如何正确读取rtk gain的四个列rtk gain是查看节省数据的仪表盘完整用法见 Token Savings Analytics 文档。其列的真实含义如下务必按此理解列实际含义Input原始命令输出估算的 token 数bytes / 4Output过滤后输出估算的 token 数bytes / 4SavedInput − Output单位为估算 tokenSave%bash 输出字节的压缩率四列之中Save% 才是有意义的那个数字它是一个字节比值作为比值是准确的。Input / Output / Saved 三列都继承自bytes / 4估算只能用于横向比较趋势比如哪一类命令贡献了最多的可压缩空间。数据落盘方面src/core/constants.rs 定义了数据目录与库名rtk/history.db保留期常量DEFAULT_HISTORY_DAYS为 90 天自动清理记录通过 TimedExecution::track 写入 SQLite由Tracker提供 summary / daily / weekly / monthly 聚合查询。RTK 不减少的部分明确边界官方文档明确列出 RTK不会减少的 token 来源这三条是理解 RTK 能力边界的关键输出 token模型写回的内容RTK 完全不碰你的 prompt、system prompt、对话历史这些输入 token RTK 没有可见性没有匹配到 filter 的命令这类命令走透传passthrough输出原样到达 LLM在追踪系统中记为0% 节省可用rtk gain --history查看最近 10 条记录核实。从源码结构看透传命令的记账同样严谨TimedExecution::track_passthrough 只记录耗时、token 计 0避免透传命令稀释节省统计——0% 的命令是显式追踪到的事实而不是遗漏。实战解读把 Save% 放进成本模型结合以上机制读 RTK 数据时建议遵循三条原则把 Save% 当作字节压缩比来用例如 What RTK Optimizes 中给出的cargo test约 90%、jest/vitest94–99%、git status75–93% 等数字度量口径都是 bash 输出字节绝对 token 数只用于趋势与量级估算公式tokens ceil(chars / 4)对中文、代码、JSON 等不同内容的真实 token 密度差异很大跨命令比较绝对值没有意义精确核算时用真实 tokenizer将 raw 与 filtered 输出分别过一遍所用模型的 tokenizer 得到精确值这是官方文档给出的唯一精确路径。rtk gain还支持--daily/--weekly/--monthly/--all时间维度拆解以及--format json/--format csv导出便于把字节压缩比接入自己的成本模型做进一步换算详见 docs/guide/analytics/gain.md。小结RTK 的节省叙事可以浓缩为一句话它只度量、也只控制 bash 输出字节。90% 的上限数字是字节压缩比经由输入 token → 账单两层稀释后对总成本的实际影响取决于你的命令输出在整体输入 token 中占多大比重。得益于同一估算器同时作用于 raw 与 filtered 两侧Save% 的比值可信而绝对 token 数因bytes / 4启发式无真实 tokenizer只能是近似值。理解这两点就能把rtk gain的数字准确放进自己的 token 与成本模型里而不是误读为账单折扣。相关文档What RTK Optimizes —— 各命令的 bash 输出压缩率明细Token Savings Analytics ——rtk gain仪表盘完整用法源码追踪系统 —— 追踪机制说明【免费下载链接】rtkCLI proxy that reduces LLM token consumption by 60-90% on common dev commands. Single Rust binary, zero dependencies项目地址: https://gitcode.com/GitHub_Trending/rtk4/rtk创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 RTK 的节省到底省在哪：Bash 输出压缩、Token 估算方法与成本换算全解析
RTK 的节省到底省在哪Bash 输出压缩、Token 估算方法与成本换算全解析【免费下载链接】rtkCLI proxy that reduces LLM token consumption by 60-90% on common dev commands. Single Rust binary, zero dependencies项目地址: https://gitcode.com/GitHub_Trending/rtk4/rtk本文基于 RTK 官方文档docs/guide/resources/savings-explained.md展开讲清 RTK 宣称的最高 90% 节省这个数字到底度量的是什么它只压缩 Agent 读到的 shell 命令输出字节绝不承诺等比例降低账单同时结合 tracking 模块源码 与 never-worse 保护逻辑剖析为什么 token 数只是估算值、而百分比却是可信的这一关键设计帮助读者正确读取rtk gain数据并把它放进成本模型中。RTK 只改变一件事shell 命令回传的字节数RTK 的定位是一个 CLI 代理proxy它横插在 Agent 与命令行之间。当 Agent 执行一条 shell 命令时流程如下agent runs a shell command | v RTK filters the output | v agent reads the result也就是Agent 发起命令 → RTK 负责实际执行 → RTK 压缩filter输出 → Agent 读到的是压缩后的版本。RTK 唯一修改的对象是shell 命令发回来的那部分字节。官方文档特别强调RTK 报告的所有 savings度量单位都是这些字节而不是 token、更不是美元。从源码结构看每条受支持的命令执行完成后都会经过统一的记账入口TimedExecution会分别对原始命令输出和RTK 过滤后输出做 token 估算并写入记录见 src/core/tracking.rs 中的TimedExecution::track。此外还有一层安全网never-worse 保护 保证过滤结果如果比原始输出还长就直接返回原始输出即 RTK 永远不会让 Agent 读到更多 token// src/core/guard.rs pub fn never_worsea(raw: a str, filtered: a str) - a str { if estimate_tokens(filtered) estimate_tokens(raw) { raw } else { filtered } }对应测试 src/core/guard.rs 覆盖了过滤后更小则保留过滤结果过滤后更大则回退 raw打平保留过滤结果等边界并有集成测试 tests/guard_integration_test.rs 佐证。节省传导链从字节到账单每一步都在稀释官方文档用一棵树把输出压缩与成本的关系摆得很清楚Cost ├─ Input tokens │ ├─ Bash output - the only part RTK filters │ ├─ Your prompt │ ├─ System prompt │ └─ Conversation history └─ Output tokens - what the model writes这里有两个关键的稀释层级Bash 输出只是输入 token 的一个组成部分与你的 prompt、system prompt、对话历史并列。压缩 90% 的 bash 输出对整体输入 token 的贡献要打个折输入 token 也只是账单的一部分账单还要计入模型生成的输出 token。因此一条命令输出字节少 90%绝不等于这个会话便宜了 90%。这正是 RTK 选择报告bash 输出压缩率而不是直接报成本节省的原因——bash 输出是 RTK 唯一能控制的变量其余部分取决于你的提示词、所选模型、Agent 回写多少内容、以及每次调用时回放了多少对话历史。为什么 token 数只是估算bytes / 4的设计取舍rtk gain展示的所有 token 数都来自一个极简估算器token ≈ ceil(字节数 / 4)对应源码为 src/core/tracking.rs 中的estimate_tokens// src/core/tracking.rs /// Estimate token count from text using ~4 chars 1 token heuristic. pub fn estimate_tokens(text: str) - usize { // ~4 chars per token on average (text.len() as f64 / 4.0).ceil() as usize }单元测试 test_estimate_tokens 固化了该行为的边界语义空串为 04 字符为 1 token5 字符向上取整为 2 token。RTK刻意不内置真正的 tokenizer。官方文档给出了取舍理由内嵌 tokenizer 会增加启动时间开销每个模型的 tokenizer 都不同要么得为每个模型内置一份要么做按会话的模型查询而 RTK 都不打算实现它追求单一 Rust 二进制、零依赖。这个取舍带来一个值得理解的结论也是本文的核心之一百分比是可靠的原始输出和过滤后输出使用的是同一个估算器比值Save%不受估算器绝对精度影响——即使1 token 4 字符本身有偏差对两边同时近似比例依然成立。它本质上是一个字节压缩比。绝对 token 数只是近似rtk gain里出现的Input tokens: 45,230只能当作量级参考不会与服务商账单上的 token 数对得上不应被当作发票行项。如果需要精确数字官方建议的做法是把原始输出与过滤后输出分别送入你所用模型自己的 tokenizer 计数。如何正确读取rtk gain的四个列rtk gain是查看节省数据的仪表盘完整用法见 Token Savings Analytics 文档。其列的真实含义如下务必按此理解列实际含义Input原始命令输出估算的 token 数bytes / 4Output过滤后输出估算的 token 数bytes / 4SavedInput − Output单位为估算 tokenSave%bash 输出字节的压缩率四列之中Save% 才是有意义的那个数字它是一个字节比值作为比值是准确的。Input / Output / Saved 三列都继承自bytes / 4估算只能用于横向比较趋势比如哪一类命令贡献了最多的可压缩空间。数据落盘方面src/core/constants.rs 定义了数据目录与库名rtk/history.db保留期常量DEFAULT_HISTORY_DAYS为 90 天自动清理记录通过 TimedExecution::track 写入 SQLite由Tracker提供 summary / daily / weekly / monthly 聚合查询。RTK 不减少的部分明确边界官方文档明确列出 RTK不会减少的 token 来源这三条是理解 RTK 能力边界的关键输出 token模型写回的内容RTK 完全不碰你的 prompt、system prompt、对话历史这些输入 token RTK 没有可见性没有匹配到 filter 的命令这类命令走透传passthrough输出原样到达 LLM在追踪系统中记为0% 节省可用rtk gain --history查看最近 10 条记录核实。从源码结构看透传命令的记账同样严谨TimedExecution::track_passthrough 只记录耗时、token 计 0避免透传命令稀释节省统计——0% 的命令是显式追踪到的事实而不是遗漏。实战解读把 Save% 放进成本模型结合以上机制读 RTK 数据时建议遵循三条原则把 Save% 当作字节压缩比来用例如 What RTK Optimizes 中给出的cargo test约 90%、jest/vitest94–99%、git status75–93% 等数字度量口径都是 bash 输出字节绝对 token 数只用于趋势与量级估算公式tokens ceil(chars / 4)对中文、代码、JSON 等不同内容的真实 token 密度差异很大跨命令比较绝对值没有意义精确核算时用真实 tokenizer将 raw 与 filtered 输出分别过一遍所用模型的 tokenizer 得到精确值这是官方文档给出的唯一精确路径。rtk gain还支持--daily/--weekly/--monthly/--all时间维度拆解以及--format json/--format csv导出便于把字节压缩比接入自己的成本模型做进一步换算详见 docs/guide/analytics/gain.md。小结RTK 的节省叙事可以浓缩为一句话它只度量、也只控制 bash 输出字节。90% 的上限数字是字节压缩比经由输入 token → 账单两层稀释后对总成本的实际影响取决于你的命令输出在整体输入 token 中占多大比重。得益于同一估算器同时作用于 raw 与 filtered 两侧Save% 的比值可信而绝对 token 数因bytes / 4启发式无真实 tokenizer只能是近似值。理解这两点就能把rtk gain的数字准确放进自己的 token 与成本模型里而不是误读为账单折扣。相关文档What RTK Optimizes —— 各命令的 bash 输出压缩率明细Token Savings Analytics ——rtk gain仪表盘完整用法源码追踪系统 —— 追踪机制说明【免费下载链接】rtkCLI proxy that reduces LLM token consumption by 60-90% on common dev commands. Single Rust binary, zero dependencies项目地址: https://gitcode.com/GitHub_Trending/rtk4/rtk创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考