5 小时额度占周额度多少？我用 CodexBar 历史数据算了 Claude、Codex 和 Antigravity

1. 起因与结论先行

我同时在用 Claude Pro、ChatGPT Plus 里的 Codex，以及 Google AI Pro 的 Antigravity。三家都是两层额度：一个每 5 小时重置的窗口，一个每周重置的总量。我想弄清两件事：用满一轮 5 小时，会吃掉多少周额度？怎么安排，才能把一周的额度用够？

CodexBar 会把这几家的用量百分比存成本地历史，我就让 Codex 读这些记录来算。10 月 22 日中午在对话里算了一遍，晚上又用整理好的脚本复跑了一次：

算完才发现，那天正好是 Claude 的周额度重置日。上午 11:54 周额度只用了 46%，就算之后每个窗口都用满，到晚上 22:00 重置前最多也只能用到 73% 左右。问题出在前几天用得太少，最后一天怎么补都来不及。

省流：别数窗口次数，每天看周额度涨了多少。一周 7 天都用的话，Claude 每天要用满一轮还多一点，Codex 每天用一轮的九成左右，Antigravity 每天半轮就够。

这是我自己账户在 2026 年 10 月的实测，官方没有承诺固定的换算比例。

2. 核心认知：为什么不能拿当前百分比直接相除

最直觉的算法，是把 CodexBar 上的两个数一除：Claude 5 小时 85%、周 46%。这样算没有意义，因为 46% 里还装着本周之前每个窗口的用量。

能用的是增量。同一个 5 小时窗口里，同一份消耗会同时计入两项额度，所以「周额度涨了多少」除以「5 小时额度涨了多少」，就是一整轮 5 小时折合的周额度。10 月 19 日 12:58 到 13:58，我的 Claude 5 小时用量从 48% 涨到 80%（+32），周用量从 8% 涨到 12%（+4），4 ÷ 32 = 12.5%。第二天晚上的另一段是 +48 和 +6，也是 12.5%。

还有两点要先说清楚：

• 「5 小时」是额度窗口，不是要连续工作 5 小时。任务密集时，可能提前用满。
• 换入口不会多出额度。Claude 帮助中心写明 claude.ai、Claude Code 和 Claude Desktop 计入同一份额度；OpenAI 定价页写明 ChatGPT Work 和 Codex 共用用量，另外 Codex 的 Pro 套餐目前没有 5 小时限制。消耗速度还受模型、上下文、推理和工具调用影响，所以这个比例只代表你自己的用法。

3. 完整复现步骤

Step 1：找到 CodexBar 的历史文件

codexbar --help | head -1
ls ~/Library/Application\ Support/com.steipete.codexbar/history/

我这里是 CodexBar 0.79.0，目录里有 antigravity.json、claude.json 和 codex.json。想看当前状态，就用 CLI 实时查。它会联网，要等几秒：

codexbar usage --provider claude --format json --pretty

Step 2：看懂文件结构

每个文件按账户分组，每个账户下有 session（windowMinutes: 300）和 weekly（windowMinutes: 10080）两个序列。每条记录只有三个字段：

{"capturedAt": "2026-10-19T04:58:37Z", "resetsAt": "2026-10-19T08:30:00Z", "usedPercent": 48}

时间是 UTC，大约每小时一条。它记的是百分比快照，不是每次请求的账单。一个文件里可能有多个账户，我的 codex.json 就有两个，preferredAccountKey 指向当前账户。

Step 3：挑出同一窗口的样本，算比例

把下面的脚本保存为 quota_ratio.py：

#!/usr/bin/env python3
"""用 CodexBar 本地历史估算：一整轮 5 小时额度约等于多少周额度。

用法：python3 quota_ratio.py <claude|codex|antigravity> [起始时间] [5 小时增量下限]
"""
import json
import sys
from datetime import datetime
from pathlib import Path

provider = sys.argv[1]
since = sys.argv[2] if len(sys.argv) > 2 else "1970-01-01"   # 只用这个时间之后的采样（UTC）
min_delta = float(sys.argv[3]) if len(sys.argv) > 3 else 15  # 整数百分比的产品建议 15

path = Path.home() / "Library/Application Support/com.steipete.codexbar/history" / f"{provider}.json"
data = json.loads(path.read_text())
series = data["accounts"][data["preferredAccountKey"]]       # 只取当前账户


def entries(name, minutes):
    return {e["capturedAt"]: e for s in series
            if s["name"] == name and s["windowMinutes"] == minutes for e in s["entries"]}


def ts(t):
    return datetime.fromisoformat(t.replace("Z", "+00:00"))


def close(a, b):                                             # resetsAt 会有 ±1 分钟抖动
    return abs((ts(a) - ts(b)).total_seconds()) <= 60


session, weekly = entries("session", 300), entries("weekly", 10080)
samples = [(t, session[t], weekly[t]) for t in sorted(session.keys() & weekly.keys()) if t >= since]


def same_window(a, b):
    (_, sa, wa), (tb, sb, wb) = a, b
    if not all(e.get("resetsAt") for e in (sa, sb, wa, wb)):  # 空闲条目可能没有 resetsAt
        return False
    return (close(sa["resetsAt"], sb["resetsAt"]) and close(wa["resetsAt"], wb["resetsAt"])
            and ts(sb["resetsAt"]) > ts(tb)                   # 后一条还没过 5 小时重置点
            and sb["usedPercent"] >= sa["usedPercent"]
            and wb["usedPercent"] >= wa["usedPercent"])


groups = []
for s in samples:
    if groups and same_window(groups[-1][-1], s):
        groups[-1].append(s)
    else:
        groups.append([s])

total_s = total_w = 0
for g in groups:
    (ta, sa, wa), (tb, sb, wb) = g[0], g[-1]
    ds = sb["usedPercent"] - sa["usedPercent"]
    dw = wb["usedPercent"] - wa["usedPercent"]
    if ds < min_delta or dw <= 0:
        continue
    total_s += ds
    total_w += dw
    print(f"{ta} → {tb}  5h +{ds:g}  周 +{dw:g}  比例 {dw / ds:.1%}")

if total_s:
    r = total_w / total_s
    print(f"合计：5h +{total_s:g}，周 +{total_w:g} → 一整轮 5h ≈ 周额度的 {r:.1%}，一周约 {1 / r:.1f} 轮")
else:
    print("没有符合条件的样本：放宽起始时间，或调低 5 小时增量下限")

运行：

python3 quota_ratio.py claude 2026-10-15

我在 10 月 22 日晚上的输出：

2026-10-19T03:59:15Z → 2026-10-19T07:59:31Z  5h +56  周 +8  比例 14.3%
2026-10-19T14:57:59Z → 2026-10-19T18:55:03Z  5h +19  周 +2  比例 10.5%
2026-10-20T10:56:43Z → 2026-10-20T14:57:51Z  5h +91  周 +11  比例 12.1%
2026-10-22T02:59:05Z → 2026-10-22T06:56:11Z  5h +64  周 +9  比例 14.1%
2026-10-22T07:56:59Z → 2026-10-22T11:52:47Z  5h +44  周 +6  比例 13.6%
合计：5h +274，周 +36 → 一整轮 5h ≈ 周额度的 13.1%，一周约 7.6 轮

脚本做了三件事：

1. 只取当前账户、起始时间之后的采样，session 和 weekly 按同一个采样时间配对。
2. 相邻两条的两个重置时间都在 60 秒内一致、后一条还没过重置点、两项都没有减少，才算同一个窗口。
3. 每个窗口用首尾两条算增量，丢掉 5 小时增量太小的窗口，最后先加总再相除。

单个窗口的比例在 10.5% 到 14.3% 之间跳，是整数取整造成的：周增量差 1 个点，比例就差好几个百分点。合并后是 13.1%，和中午挑出的两段 12.5% 都在误差范围内，所以我按 12.5%–13% 做预算。

另外两家换个参数：

python3 quota_ratio.py codex 2026-10-20T07:23:40Z   # 从本周周窗口开始的时间算起（UTC）
python3 quota_ratio.py antigravity 2026-10-14 2     # 百分比是小数，但会回落，下限设成 2

Codex 得到 15.6%，和中午在对话里算出的 15.7% 基本一致。Antigravity 得到 28.9%；中午挑出的三段样本都是 2/7（28.57%），两个结果接近，但它的数据比另外两家乱，后面单独说。

Step 4：把比例换算成每天的目标

公式只有两个：

• 一周约有 1 / r 轮。
• 每周用 D 天，每天要用掉一轮的 1 / (D × r)。

周中可以重新算：剩余周额度 ÷ 剩余天数 ÷ r，就是从今天起每天要用掉的轮数。也可以直接比较「周窗口已经过去的时间比例」和「已用的周额度」。CodexBar CLI 输出的 JSON 里有一个 pace 字段，其中的 expectedUsedPercent 和这个时间比例对得上。

10 月 22 日 12:54，我的 Codex 周额度用了 27%，本周时间也过去了约 27%，正好跟上。剩下 5.1 天、73% 的周额度，每天用掉一轮的九成左右，就能接近用满。

Step 5：临近周重置，先算还来不来得及

上限 = 当前周额度 +（当前窗口剩余 + 重置前还能开始并用满的窗口数 × 100%）× r

Claude 那天的情况：11:54 时周额度 46%，22:00 重置；5 小时窗口已用 85%，15:20 重置。用完剩下的 15%，15:20 之后用满一轮，约 20:20 再开一轮，并赶在 22:00 前用满：46% +（15 + 100 + 100）× 12.5% ≈ 73%。剩下四分之一多的周额度，这周已经用不上了。

4. 踩坑记录与排错清单

5. 小结与适用边界

如果你也在用 CodexBar，想给自己的订阅定一个每天的节奏，这个方法可以直接用。几条边界：

• 比例是单个账户、单个周期的实测。换套餐（比如 Claude Max），换主力模型，或者大量使用云端任务，都要重新跑一遍脚本。
• Codex 的周重置时间会变。这一周的历史里，它的周窗口三次提前归零并重新计时，原因我还没查。排期以 CodexBar 显示的重置时间为准。
• 免费重置另算。我的 Codex 账户有 3 次「Full reset (Weekly + 5 hr)」，每次发放 30 天后过期；Claude 的 limit reset 要在网页或 Claude Desktop 的 Settings > Usage 里使用。
• Antigravity 的 28.6% 把握最低，回落的原因还没查明，暂时只当预算参考。

后续测到新数据，会继续更新补充。