「臭鸡蛋」是 LINUX DO 社区给 GLM 免费额度起的诨名。智谱隔三差五向账号发放 GLM-5.3-Flash 的免费 token：九月那轮是周一两亿、周二三亿；十月又断续来了几轮，从回帖看单轮五亿。额度当日有效，不留隔夜。额度是真发，窗口是真刁钻，于是得了「臭鸡蛋」的名号。这篇笔记把两份材料拼在一起：论坛里领蛋的实况，加上官方源码与文档里挖出的发放机制，看这颗蛋怎么发、为什么发得这么别扭。

蛋从哪来

九月二十一日的帖子给出了最早的路线图。周一周二各领一轮免费 GLM-5.3-Flash 额度：周一两亿 token，周二三亿，当日有效。领取必须先登录 AutoClaw 客户端，不装领不了。有人问能不能喂给 ZCode，可以：让 AutoClaw 自己动手改 ZCode 的 provider，以 API key 接入；又因 AutoClaw 重试频繁，再加挂一层中转代理垫着。十月二十六日新一轮开领，二十八日又来一轮，帖子标题干脆写上「加焚决」——领了蛋就开长任务，用 workflow 把额度烧掉。到十月三十日，有人领完发现用不了，ZCode 报错「没有 GLM Coding Plan，也没有免费的体验套餐」。楼下很快给出解释：当晚二十三点生效，领了不是立马能用。

蛋为什么臭

把几轮的领取时间线排开，问题就清楚了。额度当日有效，次日上午过期；生效却卡在晚上二十三点。晚上十一点前领到的蛋，只有当晚到次日清晨这一个窗口能吃。社区的抱怨很直接：这不是发福利，这是强制加班。也有人自嘲是「给洋大人的鸡蛋」——生效窗口对着的仿佛不是本地作息。发放时间同样刁钻：要么周末，要么大半夜；赶上人多，领取接口还慢。蛋还没入口，先排了半宿队。

机制内核：服务端说了算

官方源码和文档（docs/coding-plan-quota-reset-ui.md 及其引用的后端设计）把分工写死了：机会由服务端判定发放，客户端零资格判断。客户端手里只有三个动作：

1
2
3
4
5
6
7
客户端                          Z.ai 服务端
  ├─ GET /reset/status ──────→ 只读已发放的机会（不创建）
  ├─ POST /reset/opportunity → 触发一次服务端资格判断
  │                             按「用量 + 时间窗口 + 当日次数」裁决
  │                             发：{granted: true}（机会入账）
  │                             不发：code 3301 + next_try_at（下次可试时刻）
  └─ POST /reset/use ────────→ 核销一个机会（FIVE_HOUR / WEEK）

status 只读，不会替你创造机会；opportunity 才触发判定；use 负责核销。发或不发由服务端一锤定音，客户端连「用量还不到八成，先不问了」这类本地捷径都被文档明令禁止。

三个判据

服务端裁决看三条线索。一是用量：当前五小时窗或周窗消耗得越狠，越可能给。二是时间窗口：五小时包与周包各自独立计节奏；周重置之后，下一次重置时间按七天乐观改写。三是当日次数：每天有上限，请求太急还会吃 429 限流，附带 next_try_at 强制冷却。已发放未核销的机会各自带 expire_at。账上曾躺过两枚五小时包，就是历史判定发放后没花掉的存量，十二月底到期。

「随机」感的来源

很多人体感发放像抽奖。其实不是随机，是黑盒。判据不公开，防的就是刷。而且 opportunity 调用是客户端在没有有效机会时后台触发的，不等你点按钮。于是体验就成了「不知道什么时候就给了」。按官方设计，界面里甚至不该有「领取机会」这个按钮：opportunity 是后台自动触发的资格判断，不是用户交互；摆出来的只该有「立即重置」，加次数与倒计时。

正确的吃蛋姿势

把机制翻译成动作，只有三句。额度紧张时去点重置，有机会就生效，没机会等 next_try_at。别轮询，轮询换不来机会，只会换来 429。领到蛋先看生效与过期时刻：晚上十一点生效、明早过期的蛋，留给你的选项只有一个，就是熬夜。这篇笔记自己也是蛋的产物——起草它的 agent 跑在 GLM 的 coding plan 上，而社区领蛋的主要用途，恰恰是喂饱这类 agent。