k3 和 k3-256k 额度消耗对比实测，有图有真相

佬，Kimi是不是至少99的会员才能用Kimi k啊

对的，而且基本上用的飞快，得再升一级才能勉强用用

这确实是一个优势 我明后天也会补充一下实验 不过要说的是 Kimi订阅的缓存命中优惠幅度非常大 命中输入单价是未命中的1% 而官方API是10% 那么如果项目比较复杂 1M更加实惠 可以减少压缩上下文次数和冷启动的巨额消耗（1M缓存命中的消耗也比Claude Code系统提示词冷启动的消耗少） 如果问题比较简单 那就交给256k

关键是，他家的模型切换非常良心

如果是手动跑任务的话，起手用256k，然后看上下文差不多了再切1m，缓存是保持的

哦？那这样的话更好了 社区应该写个自动路由的工具

感谢实测数据，这么看来，young说的有点问题。256下的模型确实消耗更少了。

佬友实测下来智商大概对比哪一个模型呢？有点想加价搞一个号了，太难买了 ^-^

我个人感觉和GPT5.6sol是同级的，用K3来做交叉验证经常能给GPT5.6sol写出的代码找出来真实存在的P0，P1。但是用grok4.5基本上什么都找不出来

体感在90%的任务上，特别是agent能力上，k3和gpt5.6-sol差不多。在复杂编码和各种corner case（非前端）上，5.6-sol还是思考的更全面

竟然不是”因为context缩短了“所以消耗降低了？！这moonshot也是稍微良心了点

那就是这个客服在乱说了？

很奇怪 负责人在飞书群里说，使用kimi k3[1m],在256k上下文内和使用kimi k3[256k]消耗是一样的。
那不是做分段计费就好了吗，为什么还要单独出一个模型.是不是因为很多人都是一个对话持续用，导致每次请求几百k然后就消耗快？然后就有很多人投诉？
[Screenshot_2026-07-26-00-45-21-264_com.ss.android.lark_178499801…

我怀疑这个客服是ai吧，要不然就是新模型端上来没有培训客服新的东西

这肯定是个真人，你看他“您好”前面有个空格

不太明白，这样做跟直接用1m的区别是什么？

区别是，小于256k部分，如果使用k3-256k，消耗减半

你要不手动选k3-256k，哪怕小于256k，价格还是按照原价的，而且可能还慢一些

谢谢，也就是说k3 256k确实是api单价减半了对吗？

是的，我测试的结果看，就是计费减半了。没有套路

真人，而且群里的群主young也是这么说。

不过体感上，256k是节省了一些而且下午也不429了

其实A​^-^的模型+claude code也是这个逻辑，模型名的 [1m] 也只是控制cc的上下文长度，并不传给服务端