Kimi 官方免费额度实测（2026-10）：15 元跑 WPF 开发，TPD 限流换端口绕不开、靠换别家 K3 收尾

Kimi 开放平台注册送 15 元代金券，前提是实名认证。我拿这 15 块去做了下界面重构——一个 WPF 生图软件。

大概情况是：上午 10 点多动手，前后 23 分钟，手动发了 7 次「继续」，一头撞上每天 150 万 token 的日限流，重试没用，只能等第二天零点。

到 Kimi 官方后台看了一眼，这趟大概花了 3 块钱，额度还剩 12 块左右。

所以这篇不是「免费额度不够花」的故事。额度还有剩，是每天的 token 量不够。这 15 块拿来干一次性短任务没问题，拿去做长上下文的 agent 开发，会卡在动作做到一半的时候——而且卡住之后，客户端机制还可能埋着更阴的雷，这是后话。

得先把话说清楚：这次免费额度的会话被限流掐断时，任务还停在方案规划阶段——4 项改动一项都没落地，也没有编译验收、没有截图存证。钱没花完，活没干完，就停在那儿了。后来我不死心，第二天把 API 接口从 OpenAI 兼容端口换成 Claude 兼容端口复测了一遍，结果一样撞墙；这套界面最后是做完了，但靠的不是这 15 块。下面讲的都是额度机制，不是模型能力。

这 15 块，我拿它去改了个界面

任务不复杂，但也不是 Hello World。一个叫 SoloMedia Studio 的 WPF 生图软件，要改四处：

• 生图结果从角落挪到居中
• 属性菜单从左边挪到右边
• mask 制作从独立窗口改成弹框
• 手绘 mask 那段交互自动化掉

做过 WPF 界面的人知道，这类活的麻烦不在写代码，在「改完得编译、编译完得看效果、看完还得再改」，一轮一轮磨。

模型选的是 kimi-k2.7-code。它是思考模型，思考关不掉，每次请求都带一部分推理 token，这点后面算账会碰到。

选它没别的原因——15 块按 token 单价看能干不少活：输入 4 块/百万 token、输出 16 块/百万，一个中等规模的界面重构，理论上几块钱能下来。

理论上。

上午 10 点多，活停在半路

上午十点四十左右，会话报错。

报错原文的意思很直白：账户的每日 token 量到顶了，当前 1,565,743，上限 1,500,000。超了 6 万多，不到 5%。

我第一反应是抖动——网络、并发、服务端抽风，这种场面见得多了。等了几分钟，再发一次。

还是被拦。这次计数是 1,565,748，比上次多 5 个 token。

这个数字才是真正让人死心的地方。几分钟过去，账户计数几乎没动，说明不是「这一下请求太快」，而是这个账户当天的 token 配额用完了。日级额度按天重置，重试只会再撞一次。

限流分两种，体感完全不一样。每分钟请求数超了，等等再发、手动重试，一般能过去；TPD（每天 token 用量上限）超了，就是停工到第二天零点。等一等、退个避、换个姿势重发，全都没用。

那天我手动发了 7 次「继续」，撞墙后几次重试都还被挡着。一个本该一个会话干完的中等重构，被硬拆成了跨天。

147 万里，有 136.7 万是「重读」

被卡住之后我去翻了这次会话的 token 明细，才明白额度是怎么没的。

类别	token 数	占比
计费输入	7.99 万	5.43%
计费输出	0.9 万	0.61%
推理（思考）	1.56 万	1.06%
缓存读	136.7 万	92.90%
会话 tokens 合计	147.2 万	100%

真正被计费的 token 只有 10.45 万，占 7.1%。剩下 136.7 万全是缓存读。

缓存读可以理解成模型每一轮都要把前面的对话和代码重新看一遍。我做的是 agent 开发：读文件、改 XAML、编译、看报错、再改。每转一圈，整段上下文就要重放一次。手动发的这 7 次「继续」，等于把之前的内容多读了好几遍。

这里有个反直觉的点。缓存读的单价很便宜，大约 1 块/百万 token，是输入价的四分之一；按钱算，它确实不贵。但按配额算，它一分不少地计入每日 token 用量——官方口径里 TPD 算的是输入、输出、缓存读、推理加起来的总量。

省钱和省额度，在这个机制下是两件事。

三块钱的活，撞了 150 万的墙

按公开单价估算，这场会话的账是这样：

• 计费输入 7.99 万 token，约 0.32 元
• 输出 0.9 万 token，约 0.14 元
• 推理 1.56 万 token，约 0.25 元
• 缓存读 136.7 万 token，约 1.37 元

不含缓存 0.71 元，含缓存不到 2.08 元——这是按公开单价估的；到后台看实扣，大概 3 块，比估算略高一点，量级对得上。

也就是说，15 块的额度我用了大概 3 块。它没有「花完」，是被另一堵墙拦住的：每天 150 万 token 的量，一个会话吃掉了 147.2 万。

落到体感上就一句话：额度还剩 12 块左右，当天的活已经干不下去了。

免费额度的真相：能用的模型、有时限、最低档

翻官方文档的时候，有几条得一起看，不然容易只盯着「送 15 块」这几个字。

这 15 块用不了旗舰模型。 代金券覆盖的是 K2.7 Code、K2.6 这些老系列，K3.1 Pro 和 K3 用不了。想试最新的旗舰，得自己充钱。

它还有保质期。 K2 系列 2026 年 10 月 31 日起停止对新注册用户开放，12 月底全部下线。额度跟着模型走，模型下线，券也就没什么用了。

新号拿的是最低限速档。 限速按累计充值金额分档，代金券不计入累计充值——注册送的钱不会把你抬到更高的速率档位。限速还是账户级的，四个维度同时管：并发数、每分钟请求数、每分钟 token 数、每天 token 数，哪个先到算哪个。

思考关不掉。 kimi-k2.7-code 是思考模型，单次输出上限默认 3.2 万 token，思考产生的 token 单独计费，也单独吃额度。短任务也有这笔固定开销。

撞线前没什么预警。 至少这次，我是在报错里才知道自己超了，事前没看到「今天还剩多少 token」的读数。做任务规划的时候，这种不确定性挺难受。

比 TPD 更阴的坑：服务端说 1 秒后重试，客户端就按此机制重试

撞 TPD 墙至少还有个明确报错，知道今天是干不动了、等明天。但 kimi 官方 API 在 agent 工具里，还藏着一个更隐蔽的坑。

官方对 kimi-k2.7-code 的限流档是 3 RPM——每分钟只放 3 个请求，差不多 20 秒才能发一个。可我抓了 14 条 HTTP 429，14 条响应头全写着 retry-after: 1——服务端让客户端 1 秒后就重试。

按 3 RPM 掐着，20 秒才轮到一个请求；服务端却让 1 秒后就重试——两边对不上。

客户端拿到这个头，就按字面只等 1 秒重试，也不做指数退避；而且我用的那个 agent 客户端（opencode）这个版本没开放重试延迟的配置项，用户改不了。结果就是：3 RPM 限流下，客户端按 1 秒间隔疯狂重试，一分钟能发约 60 次，每次都撞墙——429 死循环、空耗调用、任务永远不往前走。

这是 Kimi 官方 API 和 agent 客户端之间的一次交互 bug。它比 TPD 墙更难缠：TPD 撞了你会知道、能算日子；这个看起来在「重试」，实际纯空转，你还关不掉。

换 API 端口格式绕不开限流，活最后靠换别家的 Kimi K3 收尾

先补个首测的后续：那 4 项界面改动最后是做完了的，界面长这样——

但有个细节必须摆清楚：这套界面不是这 15 块干的。官方 Kimi K2.7 Code 那次会话只做到方案规划、当天额度就撞线了；主体开发是我后来换其他家的免费 Kimi K3 接力完成的——这 15 块用不了旗舰，但别的渠道能拿到 K3，跟官方这张券没关系。

首测栽了，我不信邪，第二天（10-25）又换了个思路测：这次把 API 接口从 OpenAI 兼容端口换成 Claude 兼容端口——之前在 GLM 上试过，Claude 兼容端口的缓存命中率明显更高（实测 95.8%），想着 Kimi 换过来是不是也能多吃缓存、少吃点 TPD。

结果更狠。kimi 官方阶段只撑了 12 分钟，比昨天的 23 分钟还短；期间 6 轮 RPM 突发、每轮连续 6 条 429 拒绝，09:59 还是撞同一堵 150 万/天的 TPD 墙。12 分钟只做了 48 次工具调用、4 次编辑，就被掐断了。

这印证了两件事：换 API 端口格式绕不开限流 —— TPD 是账户级共享的，不分你走 OpenAI 还是 Claude 的端口。而且想靠提高缓存命中来省 TPD 也行不通：缓存读不管命中不命中，都全额计入每天的 token 用量。加上它每天零点会重置——昨天撞完、今天额度又回来了，又被撞一遍。

这个复测任务最后也是换其他家的免费 Kimi K3 才收尾的，第二阶段设置功能完善并验证完，最终界面长这样——

一个中等任务，官方免费额度开了个头，剩下的全在绕限流、换供应商、硬等重试上耗掉了——试错的真实成本，全在这些时间上。

不过得说下：Kimi 这个品牌的免费额度坑归坑，但 K3 本身的开发能力，是我目前用过的几家国产模型里最顺手的，就是 token 烧得真凶。也正因如此，我宁可折腾这一圈，也没舍得把它换掉。

适合谁，不适合谁

这次是三层都在卡：钱不是瓶颈（这趟约 3 块、额度剩 12 块左右），token 量才是（每天 150 万，一个会话就吃掉大半），而且客户端机制还埋雷（限流让客户端空转死循环）。

不适合的：长上下文的 agent 编程、需要反复迭代的重构、一个会话要跑几十轮工具调用的活。这类任务的 token 消耗跟会话长度成正比，而额度是固定的一天的量，撞上是早晚的事。

适合的：单轮问答、写一段短文、改一段提示词、让它解释一段代码。单次请求几千 token 的量级，150 万一天够你问很多次，还能剩下。

真要连续干长活，指望这 15 块不现实。要么按实际用量付费——官方口径里限速档位跟累计充值挂钩，充值能抬档位；要么换个不按日限 token 量的渠道。这个选择跟「哪家模型更聪明」没关系，是额度机制的问题。

顺带说一句，这次实测对我自己也算个教训。本来想着用免费额度跑长任务能省一笔，现在看是想多了。免费额度适合试水、适合短活，不适合当生产主力。

至于 Kimi K2.7 Code 写代码的能力到底行不行，这次没法判断——它只在方案规划阶段就被掐断了，没到验收那一步。

我能确定的只有一件事：这 15 块的问题从来不是钱——额度还有剩，是 token 量卡你，客户端机制还埋雷。 一个中等任务，最后耗了三个多小时才收尾，大半时间都花在绕限流、换供应商、硬等重试上。