kimi coding plan 价格

想给团队或个人开一个 Kimi 编程套餐，打开页面却只看到几个档位名和一堆额度数字，不知道哪个对应自己的用量。这篇不讲死数字，而是给你一套判断顺序：先分清套餐卖的到底是什么、再去哪里看当期价格、最后按日常调用量估出该选哪档。

想给团队或个人开一个 Kimi 编程套餐，打开页面看到的往往是几个档位名加一堆额度数字，很难一眼对上自己平时的用量。这篇不报死数字，只给判断顺序：先分清套餐卖的到底是什么，再去哪一页看当期价格和额度口径，最后按日常调用量反推该选哪档。

价格类信息变动快，任何截图和转述都不可靠。凡是涉及具体金额、额度、档位名的地方，都请到站内对应页面核对当时的数字；本文只负责把「看什么、怎么比、什么情况下不适用」讲清楚。

先搞清这个套餐卖的是什么

编程套餐通常不是单纯的模型调用额度，而是把编辑器插件或命令行客户端的用量打包计价。所以第一步不是看价格，而是确认你买的入口：你是从编辑器里用，还是从 CLI 里用，两者的额度是不是同一个池子，直接决定这个套餐对你有没有意义。

按量计费 API

用多少算多少，账单随调用量浮动，适合用量不稳定或前期试水

订阅制套餐

先把一个周期的额度买断，期间用多用少价格不变，超出后的处理方式要在套餐页确认

额度口径

指这个额度是按请求数、按 token 量还是按轮次计算，以及按周还是按月刷新

• 分清你买的是 API 还是订阅套餐，两者超出额度后的行为完全不同，一个继续扣费，一个可能直接限流
• 判断自己属于哪类用户：偶尔补全代码和每天整轮重构，消耗量差一个量级，别照搬别人的档位
• 确认客户端绑定关系：换客户端、换模型之后额度是否还共用，这件事比价格更影响体验
• 如果你只是偶尔试水，或者主要跑短任务批处理，按量 API 往往比订阅更划算，这条要提前想清楚

价格和额度去哪一页核对

当期档位和额度口径，以套餐页为准。同一个套餐在不同渠道标价可能不同，先对齐口径再比数字，否则你比的只是两个不同东西的标签。遇到拿不准的，去站内价格追踪页看历史波动，比盯一张截图靠谱。

额度不只看总量，还要看刷新周期。一个周期内用不完会不会清零、超出后是限流还是转按量扣费，这两点直接决定套餐在月底那几天还能不能干活。这些规则一般写在套餐页的说明里，别只扫一眼数字就走。

按自己的用量估档位，别按感觉选

1. 记一周真实消耗连续记录几天，每天几轮对话、每轮大概多长上下文、有没有整仓库级别的重构任务，先拿到自己的基线，再去看档位。
2. 折算到套餐周期把日均消耗乘以套餐的刷新周期，得到一个周期内的粗估需求，注意留出波动空间而不是按下限算。
3. 对照档位留余量把粗估需求往上抬一档对照套餐，长期贴着上限跑的人，一旦任务变重就会卡壳，这时候便宜的档位反而更贵。
4. 确认不适用的情况如果你用量很低且不连续，或者任务都是短平快的批处理，订阅制可能一直用不满，这种情况按量计费更合适。

「够用」应该定义成留出余量，而不是刚好卡住。估档位时最容易犯的错是拿最轻的一周当基准，而真实工作里总有几天要集中改代码、跑重构，那几天的消耗会明显高于平均。

下单前值得做的几个动作

在付钱之前，花十几分钟做几件小事，能省掉后面换套餐、迁客户端的麻烦。重点不是把每个细节都查清，而是确认自己不会被额度口径和客户端支持卡住。

• 去站内编程套餐目录横向比一圈同类套餐，先看额度口径能不能对齐，再谈价格
• 确认客户端支持情况：换编辑器或换模型之后额度是否还共用，这直接影响选哪档
• 留一条退路：先开低档用一段时间，再按实际不足决定是否升档，比直接上高档试错成本低
• 把套餐页的超出规则抄下来，遇到限流时知道该找谁、怎么处理

这套判断方法不适用于一种情况：如果你所在的团队有统一的采购和发票流程，个人订阅未必能报销，这时候应该先走内部流程确认可购买的渠道，再回来比档位。