首页 · 我的窗口

我的窗口还剩多少，什么时候重置

把客户端里 /status 打印出来的那一整段贴进来，本页会读出两个窗口的剩余额度和重置时刻，再用你自己攒下的历史读数外推一件事：照这个花法，会不会在用满之前就先被限流。解析全部在你自己的浏览器里完成——不上传、不写 Cookie、不建账号。

解析不出来？手动填两个数

5 小时窗口剩余 % 重置时刻

周窗口剩余 % 重置时刻

用这几个数

手动输入只用于算你这一侧的倒计时与速度，不会写进本站的任何数据库。

这一页为什么把「怎么读的」摊开给你看

同一件事，各家客户端打印出来的排版并不统一，实测至少有五种：带进度条的、压成一行的 Remaining: 5h 96%, Weekly 94%、按请求数计的 Requests used: 38 / 50、按消息数计的 Messages remaining (5h window): 12 / 80，还有直接写 73% used 的。

麻烦在于百分比的方向会翻转。82% left 和 82% used 长得几乎一样，含义正好相反——读错一次，你以为还很宽裕，实际已经见底，或者反过来白白省着用。所以本页每读一个字段都会把原文片段和它的解读并排列出来，让你当场核对。凡是原文没写清方向的，一律标出来，不替你猜。

5 小时窗口和一个周窗口，是两套独立的东西

订阅制的额度通常同时受两层限制：一个是滚动的 5 小时窗口，从你当天第一次请求开始计时，5 小时后释放；另一个是 7 天的累计上限。任意一层触顶都会被限流。它们各算各的，重置也各重置各的。

开源社区还观察到部分账户会额外出现一条 Spark 之类的独立额度池，带自己的一套 5 小时与周窗口。它和通用池互不干扰：花掉它不影响通用额度，它重置也不会把你的通用池补满。本页会把它单独列出来——混在一起加总，数字就是错的。

「会不会先被限流」这一条是怎么算出来的

要算趋势，至少需要两个时间点上的读数。一次 /status 只给一个瞬间，凭它算出的任何斜率都是编的。所以本页把每次解析的结果存在你自己的浏览器里，攒到两次以上才开口，并且始终标出用了几个点、跨了多长时间。

速度取的是所有读数两两之间斜率的中位数，而不是最早和最新那两个点的连线。这个区别很实在：粘贴时少打一位数字（50 打成 5），首尾连线会算出两倍多的消耗速度，中位数斜率几乎不动。中途要是发生过重置、额度涨回去了，本页会就地切断序列，只用重置之后那一段——不切断的话连外推方向都是错的。

给出的时间不是一个点，是一段区间。区间的宽度不来自任何模型假设，而来自你自己的读数之间有多不一致：用得一快一慢，区间就宽；读数又密又稳，区间就窄。最后拿这段区间去和重置时刻比对，落成三句话之一——撑得到、撑不到、或者正卡在临界说不准。落在临界时本页不会硬给一个方向。

常见问题

• 我的数据会被上传吗？不会。解析、计时、速度全部在浏览器里跑，没有任何请求发往服务端。唯一会发请求的是你主动点「下载 .ics」时由浏览器本地生成文件，或你把订阅地址交给日历应用时。
• 换台电脑还能看到历史吗？不能。记录存在浏览器本地存储里，换设备或清缓存就没了。想留档可以用导出功能。
• 重置时间准吗？准到「按你粘贴的那一刻推算」。官方没有承诺固定时刻，实际以客户端提示为准。本页会把推断依据一并写出来，凡是靠猜的地方都会说明。
• 百分比和我看到的对不上？先看「我们是怎么读的」那一栏。如果方向标错了，卡片上有个按钮可以一键反过来。