kimi免费额度如何查看

很多人用 Kimi 用到一半开始心虚：这个月免费额度还剩多少？是不是马上要开始花钱了？网页版、App、开放平台控制台、编程工具里的额度根本不是一回事，入口藏的位置也不一样。这篇按「你在哪个入口用」分头走一遍，把每一步点哪里、看哪个数字、什么情况下这个数字会骗人都讲清。

很多人用 Kimi 用到一半开始心虚：这个月免费额度还剩多少？是不是马上要开始花钱了？网页版、App、开放平台控制台、编程工具里的额度根本不是一回事，入口藏的位置也不一样。同一句「免费额度」，在四个地方说的是四种不同的东西。

这篇按「你在哪个入口用」分头走一遍，把每一步点哪里、看哪个数字、什么情况下这个数字会骗人都讲清。看完你至少能判断：我该去哪儿查，以及查不到的时候该怎么记账。

先搞清一件事：Kimi 的免费额度不止一套

你查不到额度，八成不是系统故意隐藏，而是你在 A 入口用、却在 B 入口找。对话页给的免费聊天次数、开放平台账号里的赠送额度、编程套餐里附带的调用量，是三套独立的账，互不顶替也不互相扣减。先把身份对上号，后面每一步才不会白点。

对话入口

网页版和 App，看的是聊天这件事本身有没有被限制，一般不给精确数字

开放平台账号

拿了 API Key 跑程序，赠送额度和自充余额分开记，这里有相对明确的数字

编程套餐

订阅制工具里附带的调用量，额度按周期刷新，口径和 API 不一定一样

• 只是偶尔聊天、没碰过 API Key：你属于对话用户，重点看网页和 App 里的账号状态
• 已经申请 Key 并在跑脚本或接第三方客户端：你属于开放平台用户，去控制台看余额和用量
• 买了订阅制编程工具：额度在套餐专属页面或客户端设置里，不在通用控制台
• 用中转站而不是官方 Key：官方那边根本没有你的账，得去中转站后台看

网页版和 App：能看到的往往只是「有没有被限制」

对话入口的免费使用通常不按「剩余 X 次」这种形式展示，而是给一个状态。登录后进个人中心或账号设置，找与用量、额度、订阅状态相关的条目，重点看它显示的是具体数字还是一个标签。如果只看到状态标签，说明产品没打算让你精确掌握剩余量，只能靠体感和限制提示来判断。

什么情况下这里看不到额度：纯免费账号、未登录状态，或者产品把额度信息收进了订阅页。这几种情况就别在原地反复刷新了，直接从付费页的权益说明反推你当前能用什么、不能用什么，比找数字有效。

开放平台控制台：真正有数字可查的地方

如果你手上有 API Key，控制台是唯一能给你相对明确数字的地方。用拿到 Key 的同一个账号登录官方平台，进控制台首页或账号总览，找余额、额度、赠送额度这类卡片。注意赠送额度和自充余额经常分两栏显示，别把其中一栏当成全部。

1. 确认账号一致用申请 Key 时的账号登录控制台，看账号 ID 或绑定方式是否和 Key 对得上；对不上就换账号再登。
2. 看总览卡片首页通常有余额或额度概览，先记下这个数字，包括它是赠送额度还是自充余额。
3. 进用量明细页把「已用量」和「可用额度」分开看，别只看其中一栏；有账单页的话对照一下近期消耗曲线。
4. 核对有效期与适用范围确认赠送额度什么时候过期、能用在哪些模型和接口上，过期或范围外的调用会直接吃掉付费余额。

编程套餐／订阅里附带的额度

这类额度通常不在通用控制台，而在对应套餐的专属页面或客户端设置里看，按周期刷新。最容易踩的坑是口径：有的按请求次数算，有的按 token 算，两种口径下「还剩多少」的含义完全不同。按次算的额度，一次长上下文请求和一次短问答占的份额可能一样，按 token 算则差很多。

• 先确认口径：这个套餐是按次数、按 token，还是按时长窗口内的调用频率
• 再看刷新周期：是按自然月、按订阅日，还是滚动窗口，三者对不上的时候数字会显得很怪
• 对照权益说明：套餐里写的是「包含多少」还是「不限量但有速率限制」，这两句差别很大
• 跨端核对：客户端里显示的额度和网页端套餐页不一致时，以官方套餐页说明为准

想先弄清自己这个档位大概给了什么，可以到 Kimi 编程套餐价格与额度（/coding-plans/kimi-coding-plan-allegro） 对一下口径说明，再回客户端核对实际剩余。数字会随活动调整，以页面当时显示为准。

用中转站或第三方客户端时，额度归谁管

官方额度只跟官方账号绑定。走中转站时，你消耗的是中转站自己的池子，官方那边看不到你的用量，也管不着你剩多少。能查的地方只有中转站后台的用量页和余额页；查不到就问对方要口径：按 token 还是按次、什么时候扣、失败请求扣不扣。这些问题不问清楚，后面吵架都没依据。

不适用的情况也要说清：有些中转站刻意不提供实时用量，只给一个余额数字，这种就只能自己记账。要是连余额都不给，那已经不只是「查不到额度」的问题，而是这笔账你根本没法核。

查不到就自己记：一份最低成本的用量台账

既然有些入口天生不给数字，自己记就是最实在的办法。不用搞复杂工具，一个表格四个字段就够：时间、入口、模型、当次大致消耗。程序调用优先在代码里打日志，把响应里的用量字段落盘，比事后翻后台准得多，也不依赖对方页面给不给明细。

# 每次调用后把用量字段追加到日志，一行一条
# 字段顺序：时间 入口 模型 输入tokens 输出tokens 备注
echo "$(date -Iseconds) api kimi x x ok" >> ~/kimi-usage.log
# 每周统计一次总消耗
awk '{in+=$4; out+=$5} END {print in, out}' ~/kimi-usage.log

1. 固定记录字段时间、入口、模型、消耗量四项，少填一项对账时就说不清。
2. 程序调用走日志在代码里读取响应的用量字段并落盘，别靠人工回忆。
3. 每周对一次账把自记数据和后台用量页比一比，差得离谱就先怀疑有没有别的 Key 或别人在共用。
4. 稳定后降频调用量稳定后改成每月复盘一次，做法的思路可参考站内月度用量复盘类内容。

看到数字也别全信：三种会误导你的情况

就算你找到了用量页，那个数字也有它的脾气。下面三种情况会让「已用量」和你的实际感受对不上，看到跳变先别慌，按顺序排查一遍再说。

• 缓存命中：命中部分可能不计费或按另一套规则计价，用量页会突然跳变，不代表你真的花了那么多
• 异步任务与重试：提交了但失败、或者自动重试的请求，可能已经产生消耗，用量页会先于你的感知涨上去
• 额度刷新周期：不同入口的刷新时间点不一样，月初查到的数字和月底可能压根不属于同一个周期
• 多端共用：同账号在网页、客户端、脚本里同时用，用量是合并计的，单独看一个入口会觉得异常
• 时区差异：控制台按哪个时区切周期，会直接影响「本周期用了多少」这个判断

判断顺序建议是：先确认是不是缓存或重试造成的跳变，再确认周期和时区，最后才怀疑是不是有人共用账号。多数「额度不对劲」都停在前两步。真要评估不同渠道划不划算，去 价格追踪（/price-watch） 看当时的实际数字，别拿记忆里的旧数据做决定。