阿里云 CodingPlan 计划太坑了吧

逻辑不会是月份加一日期不变吧

乐死了，是因为 2 月份只有 28 天，2 月份买就只给 28 天么。 是不是 vibe codeing 出来的代码

而且据说还是量化模型

我昨天缴停车费包月也是这个逻辑，无语

我买的时候看到这个也挺无语的

一样一样的

你反馈给经理, 会补偿的

可以了，毕竟给 18000 次请求，给 deepseek 买 8 个 lite 套餐，都可以直接蒸馏 claude 了 （狗头

晚两天在下手

@drainlin +1

他选择二月运营这个活动，还少给两天，不知道是故意还是不小心的。太小气了。

我昨天又买了试了一下，就是在 chrome 里写个扩展，让他读取余量信息显示。
结果搞了好几个小时 k2.5 搞不定，M2.5 也不行，glm5 更白搭，他自己的 qwen3.5 也不行，感觉这些模型都是阉割版的，最后用 codex 搞出来的。
分别用他们几个尝试读 html 解析，读那个 zeldaEasy.broadscope-bailian.codingPlan.queryCodingPlanInstanceInfoV2 接口，尝试失败后让他们自己定方案，都没完成。要么是接口参数没存对，要么是 html 处理有问题（那个用量弹窗要鼠标经过才会出现）。

总之试下来，国产也就跑分强点，实际用起来都白搭啊，劝各位生产力还是直接上 claude 或 codex 。

还真是 ...

这还真是一个值得仔细思考的问题，我之前还好奇为什么腾讯视频开通一年会有 372 天,多了一周，原来每个月都按 31 天来算的

每个月 30 天计算，1 年是 360 天
每个月按照实际天数计算，1 年是 365 天或者 366 天

minimax 的 coding plan 是按照 30 天一个月来计算的，而不是按照自然月的对日。这种 28 天的月计划确实不公平。

无所谓，你就差那几天么，没到时间早就用完了

其实它可能是按自然月的一种算法，也没错，不然会出现一些反直觉的东西：
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 日

2 月份买，就给 28 ，太抠了。

我还去问了我的客服，他说这是个好问题。
然后没有下文了

@selca #19 准确来说，是客服给我说了就是因为 2 月只有 28 天后，咱就没聊后续内容了。
https://imgur.com/a/qC1fUWV

火山和阿里云都买了，火山多一天，是 29 天 [哈哈]

@LMark 这个应该大概率是吧。否则 GLM KIMI2.5 参数还挺多的。算力需求挺大。

CodingPlan 不是主要看限额的吗，限额用完了，不是早点重置更好？如果限额都用不完……不如考虑按量付费的 api 吧

除了上面说的那个问题，还有其他坑
它宣传支持 minimax 、glm 、kimi ，看着挺全，但实际体验真的不行，实际上只能用 qwen3 。最大的问题是不是阿里的模型，完全吃不到 cache 。
本质上它就是把各家厂商的 API 聚合在一起，然后用多个 token 做负载均衡。
问题来了 缓存是按 token 维度算的。
一请求，它随机用不同 token 去打后端：
每个 token 都是“新用户”
每次都是全量重算
根本没有历史 cache 命中
用那种大上下文模型（比如 claude-code 这种动不动几十 k context 的）基本直接起飞。
没 cache 的情况下，全量推理一次，30 秒起步都算客气的。
体验就是：又慢，又贵，还不稳定。
还有一个更骚的操作 它会额外做一层敏感词检测。
只要触发，它直接给你 403 。
我就在 openclaw 问了一句 polymarket 上美伊战争的赔率是多少，结果直接给我禁了。
后面啥都问不了，一直 403 。

作为一个程序员，不得不说，按月订阅使用自然月而不是固定的 30/31 天去计算这样子最方便省事，直接使用编程语言的标准库去计算下一个周期的开始日期就好了。毕竟如果按照固定 30 天，一年下来用户还是少了几天；如果固定 31 天那么一年下来又给用户多了几天。前提是得说清楚，明确告知用户。

阿里的逻辑应该是这样的，
你 2 月 26 日买一个月，那他就给你开到 3 月 26 日，
但是 2 月份只有 28 天，那就感觉比 30 天少 2 天了。

阿里基操是这样子的，连续包月，一年后发现实际只给了 360 天，5 年能多出来一个月。

发现这个事也挺巧的，习惯性记账，然后发现每个月的实际扣款日慢慢提前了。

@LMark 客服说他们接的智谱官方 API ，不是自己部署的...

隔壁实测，套路云 的 GLM-5 上下文只有 73728 tokens 。这种长度根本没法干活

有些国内的模型是看起来单价便宜，但实际消耗很多 token ，去年买过一次 kimi 的模型用在 claude code 测试了一下，一个 BUG 跑了 30 多块钱还没搞定，换成 claude 模型 5 分钟就解决了

我觉得 kimi 好像更坑，我买了一个月的，一会小时限制，一会频率限制，一会周限制到期。改成 qwen3.5 还是可以用的。

还是腾讯系到位, 记得以前就他家的给的足, 按月就 31 天 按年就 366 天.

cursor 这个月也是 28 天吧

AI 变现，也是应该的

@dassh #17 都没毛病，问题出在他不是显示下个月几号到期，而是显示剩余 XX 天，导致这种感觉加重。这是典型的靠信息输出和设计就能解决的问题，他非要选一个最得罪人的方式。

我买完在 opencode 里面没办法用，不知道咋回事，明天再看看

有很多都是按自然月算的，腾讯云 cloudbase 也是自然月

其实理论上按自然月算挺合理的，，，

今天通过阿里云的 coding plan 调用 glm-5; 结果报了个上游额度用满了（大概的意思，当时在办公室跑 cc ）。
我心想阿里的 coding plan 在 bigmodel 的下游？

这里体现出一个有意思的细节，腾讯是算 31 天的，它是做游戏的，阿里是做电商的，按照自然月算。

因为做游戏如果你按照自然月算，那玩家就要跳起来了

@wang93wei #38 不合理，产品这么设计容易引起用户反感，因为与心理预期不一致

@dassh 这个处理就很简单啊，对于按月订阅，非 2 月份按自然月来跟之前一样，2 月份订阅直接补 1 天或者 2 天就完事儿了（考虑闰年，补到最低 30 天别让用户觉得自己吃亏了就行了），用户要是觉得这里有漏洞可以占便宜了，非要一个月一个月的续也行，但是通常按年付费本身就自带了很大力度的折扣足以抵消没有必要这样折腾算下来并不划算，所以对于年付用户来说并没有吃亏，月付和年付都可以平衡，核心利益点在于厂商愿不愿意让渡这个利益来换取更多的用户支持（火山引擎好像已经在让渡这几天了缺的在补了），按自然月这个出发点很有道理很有逻辑，但是做生意更多的是考虑人的角度，就是要让客户觉得占到便宜了他才乐意屁颠屁颠长长久久持续支持你的产品

这算不上坑，月的算法不同，当你写这块代码的时候产品经理也给你模模糊糊的

@Semantic 太扯了吧，我用 opencode 两天了，几乎都是 5 轮的对话 coding ，如果只有 70k token 早就超出了,都不知道这谣言哪来的

建议换其他的就行了，你不是他的目标用户。我就觉得挺合适的，整月，好记简单。

对这几天差别，一点不在意，只要它性价比高就行。

你这么一说我也发现了，阿里小程序云，我每月续费，但是每次到期都是月初 4 号。。。

这几天不是问题，问题是到底好不好用啊。。。之前 GLM 上当上怕了，如果好用我很乐意付费。

@ktyang 我现在在 cursor 中使用一直提示：We're experiencing high demand for the selected model right now. Please upgrade to Pro, switch to Auto, another model, or try again in a few moments.

@joynvda 接的 bigmodel 呗

@w169q169 #24 难怪当年傻卵百炼千问 2.5 ，我就/init 了一下烧了我 20 多块钱给我烧成欠费了，都还没吐出一个字儿
这辣鸡平台真不能用，它们完全不知道应该怎么做 AI 产品。

按自然月也算合理吧，就是会出现顾客喷的情况...所以我自己写代码都是加 31 天

闰年买会给 29 天吗

火山那边是不是量化模型

我其实不太理解这种所谓的“包年包月”，换个情景，如果阿里云 ECS 包年包月一台 4h8g 后，如果“内存占用量*时间”超出限制，就立马停机，这还合理吗？

还有一个坑点，他的 coding plan 和普通推理服务的 API 和 Key 是不同的，但页面上没有明显提示。
我被坑了十块钱之后，找了客服才知道这一点

当前时间，按照订阅月数，乘以固定的 30 或者 31 ，往前加完事
写出不同月不同天数的，属于啥呢？没有意义呢

支付宝、阿里云好像都是这种“一期”的方式算一个月？

@zhangkai1024 劝退了劝退了

当时配置是参考文档中的 openclaw 配置的，默认用的 qwen3-max-2026-01-23 ，TMD 这个模型只有少量免费额度，结果用完了还额外欠费 10+元，后来才看到 codeplan 的文档，改成 qwen3.5

@jokcylou

貌似是今天才有 200K ，今天以前确实很难用，我自己实测上下文一长就截断

@freesoul 同样被坑

都挑花眼了，特意做了一个站，方便对比 https://codingplan.org/

@junbaor #63 你这对比一点都不详细啊，很多详细用量要求在文档里有，你这都没写上去，比如：GLM 的 5 小时用量限制，周用量限制等； Kimi 的好像文档里面也有写，比较难找。

@dassh 这算法我之前用过。。。我说固定 31 天简单 方便。。产品一定坚持用这个方法
考虑边界都头疼 下个月没有那几号（比如 31 号买的 下个月只有 30 号）还得特殊处理 唉。。

@Semantic 现在 glm5 有 200k 了？

@bbbblue 各有各的好处。
以前写麻烦，现在交给 AI ，测试用例都给你设计好。
自然月逻辑外国用得比较多
另外：要是自动续费，又没有支付牌照，就得按支付商支持的来

@junbaor #63 智普也不是免费 mcp 啊，智谱调用 mcp 是每个月刷新的，哪里免费了，上限到了就不让用了

他这种算法，我想知道 31 号订阅，下个月没有 31 号了咋整……

@opeth 就往前挪一天呗，这个的好处就是一年能用用户身上多扣 5 天时间，他会省钱

@opeth 正经的自然月算法是这样的：如果当前是月底最后一天，则每次续费 1 个月都续到下个月的最后一天，比如 2 月 28 日（平年）-3 月 31 日-4 月 30 日-5 月 31 日

如果不是当月最后一天，则平移到下个月的同一天；如果超出了下个月的最后一天，则同样应用前面的“吸附月末最后一天”的逻辑

这样无论用户在几号开通，只要持续续费 12 个月，都是和续费 1 年等同

唯一的不足是每次按月续费时长时短

@dawnvivid 当然更简单而且用户疑惑更少的做法就是固定视 1 个月为 30 天这样。。。

@junbaor 很清晰，能把国外的加入一起对比就更好了

@junbaor #63 百度千帆？快手 KwaiKAT ？ X-AIO ？
可以看看这个全一点
https://jqknono.github.io/coding-plans-for-copilot/

难怪。。。我说怎么就 26 天了。。