最近探索出来使用 GLM 的正确姿势

[codingerj]

首先我是 GLM V1 版本套餐的老用户，不是这个套餐的可能不是很适用。

最近 Lite 版本的套餐也能用到 GLM5.3 了，说是完全还是 GLM5.2 的预训练基座，但是通过 RL 达到原 GLM5.2 超越 50% 的性能。

我周末高强度使用了一下，确实强多了。

主要是最近用 Godot 做一个自己爱玩的游戏，之前只敢用 GPT 5.6 Sol 来改。用 GLM5.2 改的话，报错频率很高，还得提醒它自己看编译报错，改得也不完全，总是会有遗漏。

5.3 强多了，基本不报错，而且意图理解也比之前强了很多。

那么问题来了。

V1 老套餐 Lite 只有 5h 限额，使用 ZCode 是 1.5x 限额，大概是 5000 万 token 。

这在高峰期（工作日 14:00-18:00 ）明显不够用。

而智谱的 5h 限额有个特点：下一个周期到来时，你得实际用一下，才开始计算新的周期。

也就是说，可以通过 ZCode 自带的定时任务，把下午的高峰期完美拆解成两个 5h 限额的上下半段。

我现在的配置是这样的：



通过这样的配置：

早上可以用一个完整的 5h 限额，一直到 10 点。

然后 10 点半到下午 3 点半，又是一个完整的 5h 限额。

下午 3 点半到 6 点，又是一个完整的 5h 限额。

这样基本就把工作时间覆盖掉了。

最后一个提醒，ZCode 的上下文上限很大，1000K ，实际上完全用不到。

可以手动 `/compact` 压缩上下文，频繁一点，也能有效减少 token 消耗。

这样完美压榨 GLM 的 token 后，还是不够用的话，就 Codex 。

现在 Codex 只有周限额，关键时刻也能顶一顶。

[duuu]

上下文的，应该可以自己修改上限，就不用手动 compact 了

[codingerj]

@duuu 哦，是的，我改成 400k 了 但是感觉好像也有点大，改成 200k 又体现不出来长上下文的优势了

[yangyaofei]

我也是这么用, 凌晨 5 点跑个你好, 晚上 1 点跑点定时任务生成点新闻日报什么的.

下午主要跑带 pipeline 需要等着然后修的那种代码, 然后并行整理需求和他讨论实现方案, 讨论好了写到 issue 上面, 晚上 12 点的时候点一下让他跑到 3 点.

但是依然不够用.....

[codingerj]

@yangyaofei 不够用是对的，现在好套餐都不够用，gpt plus 我都不舍得用，glm 解决卡顿的时候拿出来顶

[xxyzf]

主要还有周限额呢……

[codingerj]

@xxyzf glm 的 V1 老套餐 都是 只有 5h 限额 没有周限额

[codingerj]

@xxyzf 但是老号应该最多只能到明年的三四月份了吧 后面续费也都是新套餐了

[yangyaofei]

@codingerj #4 opencode-acp 推荐一下这个插件, 自动管理压缩 context, 设置得当的话可以控制在 400K~200K 的甜点区

[xxyzf]

@codingerj 竟然是这样，我还真不知道