🔶 为什么我的开源项目没能做得更好
英文标题：🔶 Why My Open-Source Project Hasn't Done Better
自 2026 年初以来，RTK、Caveman、Ponytail 等项目宣称可减少 80% 至 90% 的 token 用量，并迅速获得大量 GitHub stars。作者将此前电商聊天机器人 Agent 的架构封装为 SDK，利用状态机和确定性执行序列，在相同任务中减少约 80% 的 LLM 服务商往返调用。作者援引自己与 JetBrains 的报告称，RTK、Caveman 等 token 节省插件在真实的长时间运行任务中几乎没有效果。尽管其项目具备针对长任务实现超过 80% token 节省的能力，作者认为技术传播困难主要源于用户对 token 消耗机制认知不足，以及自己过度强调评测与基准测试所带来的推广障碍。
315 B
43 B
中文
自 2026 年初以来，RTK、Caveman 和 Ponytail 等许多项目都宣称能够减少 80% 至 90% 的 token 用量。其中一些项目在极短时间内就获得了数万 GitHub stars。
我之前创办的公司在开发一款电商聊天机器人。事实上，该产品与 Universal Commerce Protocol（UCP）几乎完全相同。在 UCP 发布后，我决定不再继续推进这一方向。
今年早些时候，我开始将我们为电商聊天机器人 Agent 构建的架构转化为一个 SDK。简单来说，它的核心思路是利用状态机和确定性执行序列，在完成相同任务时将与 LLM 服务商之间的往返调用次数减少约 80%，从而显著降低 token 消耗。
问题在于：我非常清楚，为什么 RTK 这类工具在真正的长时间运行任务中并不有效。
我在 7 月 18 日发布了一份报告，JetBrains 则在 7 月 20 日发布了一份得出几乎相同结论的报告：RTK 和 Caveman 等 token 节省插件，对于真实世界中的长时间运行任务几乎没有效果，甚至完全没有效果。
- JetBrains：https://blog.jetbrains.com/ai/2026/07/rtk-claude-code-token-savings/
- 我的报告：https://turaai.net/blog#token-saving-plugins-are-mostly-stupid-idea
我也知道如何在长时间运行任务中真正实现超过 80% 的 token 消耗降低。然而，在推广我的开源项目时，我遇到了很大困难。
我将主要问题概括如下。
1. 大多数 coding-agent 用户并不关心 token 消耗究竟由什么驱动
无论是接受过正规软件工程训练的人，还是自学成才的“vibe coder”，coding-agent 用户之间都存在巨大的认知差距。
一篇系统解释流程、并挑战人们既有假设的长文，在已经充斥着 AI 生成帖子和声称可减少 95% token 用量的 vibe-coded 插件的论坛中，几乎没有传播机会。
简单的想法更容易传播。人并非完全理性；人们往往倾向于相信那些自己最容易理解的东西。
这也是为什么，建立在错误因果解释之上的伪科学内容，在社交媒体上往往比那些认真讲解底层数学原理的频道获得更多关注。
2. 作者的傲慢
这其实是两个问题的结合。
从一个坚信科学测试方法、评测和基准测试的人的角度来看，没有 eval 或 benchmark 支撑的软件工程主张，可能显得毫无意义。
但也许是我自己的傲慢，以及我对 RTK 等工具的轻视，甚至嫉妒，让我不太愿意以实际上更有效的方式推广自己的工作。
如果你已经读到这里，我会真诚地感谢你的建议：在继续尊重评测和基准测试严谨性的同时，我该如何更有效地推广我的项目？
我知道，使用 Codex 或 Claude 构建一个 coding agent 相对容易。但我也相信，始终会有人理解 benchmark 和评测框架的价值。
该项目于 7 月 16 日发布，目前拥有略多于 400 个 GitHub stars。现阶段，它仍是一个相对不为人知的项目：
English / 原文
Since the beginning of 2026, many projects such as RTK, Caveman, and Ponytail have claimed that they can reduce token usage by 80–90%. Some of them gained tens of thousands of GitHub stars in a very short time.
My previous startup was building an e-commerce chatbot. In fact, the product was almost identical to the Universal Commerce Protocol (UCP). After UCP was released, I decided not to continue pursuing that direction.
Earlier this year, I started turning the architecture we had built for e-commerce chatbot agents into an SDK. Put simply, its core idea is to use state machines and deterministic execution sequences to reduce the number of round trips to LLM providers by around 80% for the same task, thereby significantly reducing token consumption.
Here is the problem: I understand very clearly why tools such as RTK are ineffective in genuinely long-running tasks.
I published a report on July 18, and JetBrains published a report on July 20 that reached essentially the same conclusion: token-saving plugins such as RTK and Caveman have little to no effect on real-world, long-running tasks.
- JetBrains: https://blog.jetbrains.com/ai/2026/07/rtk-claude-code-token-savings/ - My report: https://turaai.net/blog#token-saving-plugins-are-mostly-stupid-idea
I also know how to achieve a real reduction of more than 80% in token consumption during long-running tasks. However, I have encountered significant difficulties promoting my open-source project.
I would summarize the main problems as follows.
1. Most coding-agent users do not care what actually drives token consumption
There is a huge gap in understanding among coding-agent users, regardless of whether they have formal software-engineering training or are self-taught "vibe coders."
A long article that systematically explains the process and challenges people's existing assumptions has very little chance of spreading in forums already flooded with AI-written posts and vibe-coded plugins claiming to reduce token usage by 95%.
Simple ideas are easier to spread. People are not purely rational; they tend to believe the things they can understand most easily.
That is also why pseudoscientific content built on incorrect causal explanations often attracts far more attention on social media than channels that carefully explain the underlying mathematics.
2. The author's arrogance
This is really a combination of two problems.
From the perspective of someone who believes strongly in scientific testing methods, evaluations, and benchmarks, software-engineering claims without an eval or benchmark can feel meaningless.
But perhaps my own arrogance and my contempt for, or even jealousy of, tools such as RTK has made me less willing to promote my work in ways that would actually be more effective.
If you have read this far, I would genuinely appreciate your advice: how can I promote my project more effectively while continuing to respect the rigor of evaluations and benchmarks?
I know that building a coding agent with Codex or Claude is relatively easy. But I also believe that there will always be people who understand the value of benchmarks and evaluation harnesses.
The project was released on July 16 and currently has a little over 400 GitHub stars. For now, it is still a relatively unknown project: