他选择二月运营这个活动，还少给两天，不知道是故意还是不小心的。太小气了。我昨天又买了试了一下，就是在 chrome 里写个扩展，让他读取余量信息显示。结果搞了好几个小时 k2.5 搞不定，M2.5 也不行，glm5 更白搭，他自己的 qwen3.5 也不行，感觉这些模型都是阉割版的，最后用 codex 搞出来的。
闽公网安备 35020302035485号
发现这个事也挺巧的，习惯性记账，然后发现每个月的实际扣款日慢慢提前了。
它宣传支持 minimax 、glm 、kimi ，看着挺全，但实际体验真的不行，实际上只能用 qwen3 。最大的问题是不是阿里的模型，完全吃不到 cache 。
本质上它就是把各家厂商的 API 聚合在一起，然后用多个 token 做负载均衡。
问题来了 —— 缓存是按 token 维度算的。
一请求，它随机用不同 token 去打后端：
每个 token 都是“新用户”
每次都是全量重算
根本没有历史 cache 命中
用那种大上下文模型（比如 claude-code 这种动不动几十 k context 的）基本直接起飞。
没 cache 的情况下，全量推理一次，30 秒起步都算客气的。
体验就是：又慢，又贵，还不稳定。
还有一个更骚的操作 —— 它会额外做一层敏感词检测。
只要触发，它直接给你 403 。
我就在 openclaw 问了一句 polymarket 上美伊战争的赔率是多少，结果直接给我禁了。
后面啥都问不了，一直 403 。
1. 这个月 5 号买的，下月 5 号过期，很直觉
2. 2026 年 2 月 26 号买的一年，2027 年 2 月 26 号到期
（如果按 30/月，31/月这种写死的方法，就难做到了）
与下是 AI 回复的：
Stripe 按月订阅的自然月逻辑是：以订阅创建日为锚点（ billing cycle anchor ），后续每个月都取该月中最接近锚点日的那一天；当月没有该日时，自动取当月最后一天 Stripe 。
你的例子（ 1 月 31 日订阅）
订阅创建日：1 月 31 日（锚点日 = 31 日）
下一个周期：2 月 28 日（ 2026 年为平年，2 月只有 28 天） Stripe
下下个周期：3 月 31 日（ 3 月有 31 天，回到 31 日） Stripe
通用规则（按月订阅）
锚点日 = 订阅创建日（默认） Stripe
后续每个月：
若当月天数 ≥ 锚点日 → 按锚点日扣费 Stripe
若当月天数 < 锚点日 → 按当月最后一天扣费 Stripe
其他常见示例
3 月 31 日订阅 → 4 月 30 日 → 5 月 31 日 → 6 月 30 日
2 月 29 日（闰年）订阅 → 3 月 29 日 → 4 月 29 日 → 5 月 29 日
他选择二月运营这个活动，还少给两天，不知道是故意还是不小心的。太小气了。我昨天又买了试了一下，就是在 chrome 里写个扩展，让他读取余量信息显示。结果搞了好几个小时 k2.5 搞不定，M2.5 也不行，glm5 更白搭，他自己的 qwen3.5 也不行，感觉这些模型都是阉割版的，最后用 codex 搞出来的。
分别用他们几个尝试读 html 解析，读那个 zeldaEasy.broadscope-bailian.codingPlan.queryCodingPlanInstanceInfoV2 接口，尝试失败后让他们自己定方案，都没完成。要么是接口参数没存对，要么是 html 处理有问题（那个用量弹窗要鼠标经过才会出现）。总之试下来，国产也就跑分强点，实际用起来都白搭啊，劝各位生产力还是直接上 claude 或 codex 。