基于 Jev 做了一个给 Agent 省钱的项目 —— TokenCut

yaphetsyan 2026-09-29 17:27 1

最近自己折腾了一个项目,叫 TokenCut:


https://www.tokencut.lol


起因其实挺简单。


前段时间一直在做 AI 相关的东西,接的模型越来越多,OpenAI 、Claude 、Gemini ,还有一些便宜的小模型。


用久了之后有一个感觉:


很多请求其实根本没必要用那么贵的模型。


比如翻译一句话、提取 JSON 、做个分类、改一下标题、总结一小段文本。


这些事情用便宜模型基本都能做。


但实际写项目的时候,为了省事,通常还是会固定一个模型。


比如整个项目默认都走某个比较强的模型。


这样写起来最简单,也不用管那么多。


问题就是账单也会比较简单粗暴。


用户问一个很复杂的代码问题,用这个模型。


用户只发一句“hello”,还是这个模型。


慢慢我就在想,能不能在真正调用模型之前,先判断一下这个请求到底难不难。


简单的就交给便宜模型。


复杂的再上强模型。


所以就做了 TokenCut 。


现在的思路是,在用户请求和真正的模型之间加一层。


请求进来以后,先让 Jev 判断这是个什么任务,大概需要什么能力,然后再决定后面调用哪个模型。


比如简单的翻译、分类、信息提取,可能就没必要上特别贵的模型。


如果是复杂代码、长上下文或者 reasoning 比较重的任务,再切到更强的模型。


大概就是:


Prompt
↓
Jev
↓
判断任务
↓
选择模型
↓
实际模型返回结果

我自己比较在意的一点是,这个项目不是为了“永远选最便宜的模型”。


因为那样很容易把体验搞坏。


我想做的是:


不要为一个只需要 60 分能力的任务,付 100 分模型的钱。


当然这里最难的也正是这一点。


到底怎么判断一个任务需要多强的模型?


一开始很容易想到按照 Prompt 长度判断,但后来发现基本不靠谱。


比如:


证明黎曼猜想

没几个字,但显然不是简单任务。


反过来一篇几千字的文章,让模型做个摘要,可能并不需要特别强的 reasoning 。


所以现在更多还是从任务类型、复杂度、上下文、是否需要代码能力、是否需要推理这些维度去判断。


这部分我还在不断调。


另外我也不太想把它做成另一个单纯的模型聚合平台。


现在已经有很多平台解决“我要调用某个模型”的问题了。


我更想解决的是:


我根本不想天天研究这个请求应该用哪个模型。


开发者只管正常调接口,后面具体选谁,让 Router 自己决定。


理想情况下,接入以后你不需要每隔几个月重新研究一遍:


这个模型现在是不是降价了?


那个 mini 模型是不是已经够用了?


这个任务应该走 Claude 还是 GPT ?


哪些请求可以降级?


这些东西如果能自动化,我觉得还是能省不少事情的。


目前项目已经能用了,接口也尽量做成 OpenAI Compatible 的方式,减少接入成本。


地址还是这个:


https://www.tokencut.lol


现在项目还比较早期,所以发出来主要也是想看看有没有人真的有这类需求。


我自己目前最关心的是一个问题:


自动路由模型这件事,大家能接受到什么程度?


比如为了省 30%~ 50% 的模型成本,如果偶尔会出现模型选择没那么理想,你能接受吗?


还是说稳定性比成本重要得多,宁愿固定用一个强模型?


另外如果大家自己也在做 AI 产品,也挺想知道你们现在是怎么处理模型选择的。


是固定一个模型用到底,还是已经自己做了一套路由?


欢迎拍砖。

最新回复 (0)
    没有回复
* 帖子来源V2EX
返回