我 2 月 26 日买一个月都 pro 套餐，只给了 28 天。
我记得以前买的会员服务，最低按月是 30 天的，我同样的价格，不同月份居然得到的东西还不一样。
 | 1 lzoje 6 小时 47 分钟前 逻辑不会是月份加一日期不变吧 |
 | 2 malusama 6 小时 46 分钟前 乐死了，是因为 2 月份只有 28 天，2 月份买就只给 28 天么。 是不是 vibe codeing 出来的代码 |
 | 3 LMark 6 小时 42 分钟前 而且据说还是量化模型 |
 | 4 drainlin 6 小时 39 分钟前 我昨天缴停车费包月也是这个逻辑，无语 |
 | 5 viking602 6 小时 25 分钟前 我买的时候看到这个也挺无语的  |
 | 6 zw2019 6 小时 24 分钟前 一样一样的 |
 | 7 Inn0Vat10n 6 小时 22 分钟前 你反馈给经理, 会补偿的 | /tr>
 | 8 subpo 6 小时 20 分钟前 可以了，毕竟给 18000 次请求，给 deepseek 买 8 个 lite 套餐，都可以直接蒸馏 claude 了 （狗头 |
 | 9 280303 6 小时 17 分钟前 晚两天在下手 |
 | 11 mogutouer 6 小时 9 分钟前 他选择二月运营这个活动，还少给两天，不知道是故意还是不小心的。太小气了。 我昨天又买了试了一下，就是在 chrome 里写个扩展，让他读取余量信息显示。 结果搞了好几个小时 k2.5 搞不定，M2.5 也不行，glm5 更白搭，他自己的 qwen3.5 也不行，感觉这些模型都是阉割版的，最后用 codex 搞出来的。 分别用他们几个尝试读 html 解析，读那个 zeldaEasy.broadscope-bailian.codingPlan.queryCodingPlanInstanceInfoV2 接口，尝试失败后让他们自己定方案，都没完成。要么是接口参数没存对，要么是 html 处理有问题（那个用量弹窗要鼠标经过才会出现）。 总之试下来，国产也就跑分强点，实际用起来都白搭啊，劝各位生产力还是直接上 claude 或 codex 。 |
 | 12 urlk 5 小时 51 分钟前 还真是 ... |
 | 13 Curtion 5 小时 46 分钟前 这还真是一个值得仔细思考的问题，我之前还好奇为什么腾讯视频开通一年会有 372 天,多了一周，原来每个月都按 31 天来算的 |
 | 14 xiaoxiaomingming 5 小时 27 分钟前 每个月 30 天计算，1 年是 360 天 每个月按照实际天数计算，1 年是 365 天或者 366 天 |
 | 15 surfwave 5 小时 17 分钟前 minimax 的 coding plan 是按照 30 天一个月来计算的，而不是按照自然月的对日。这种 28 天的月计划确实不公平。 |
 | 16 crytis 5 小时 16 分钟前 无所谓，你就差那几天么，没到时间早就用完了 |
 | 17 dassh 5 小时 8 分钟前  2 其实它可能是按自然月的一种算法，也没错，不然会出现一些反直觉的东西： 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 日 |
 | 18 SkywalkerJi 4 小时 43 分钟前 2 月份买，就给 28 ，太抠了。 |
 | 19 selca 4 小时 42 分钟前 我还去问了我的客服，他说这是个好问题。 然后没有下文了 |
| 20 selca 4 小时 40 分钟前 |
 | 21 rmrf 4 小时 35 分钟前 火山和阿里云都买了，火山多一天，是 29 天 [哈哈] |
 | 23 fcten 4 小时 19 分钟前 CodingPlan 不是主要看限额的吗，限额用完了，不是早点重置更好？如果限额都用不完……不如考虑按量付费的 api 吧 |
 | 24 w169q169 4 小时 10 分钟前 2 除了上面说的那个问题，还有其他坑  它宣传支持 minimax 、glm 、kimi ，看着挺全，但实际体验真的不行，实际上只能用 qwen3 。最大的问题是不是阿里的模型，完全吃不到 cache 。 本质上它就是把各家厂商的 API 聚合在一起，然后用多个 token 做负载均衡。 问题来了 缓存是按 token 维度算的。 一请求，它随机用不同 token 去打后端： 每个 token 都是“新用户” 每次都是全量重算 根本没有历史 cache 命中 用那种大上下文模型（比如 claude-code 这种动不动几十 k context 的）基本直接起飞。 没 cache 的情况下，全量推理一次，30 秒起步都算客气的。 体验就是：又慢，又贵，还不稳定。 还有一个更骚的操作 它会额外做一层敏感词检测。 只要触发，它直接给你 403 。 我就在 openclaw 问了一句 polymarket 上美伊战争的赔率是多少，结果直接给我禁了。 后面啥都问不了，一直 403 。 |
 | 25 Breacher 3 小时 48 分钟前 作为一个程序员，不得不说，按月订阅使用自然月而不是固定的 30/31 天去计算这样子最方便省事，直接使用编程语言的标准库去计算下一个周期的开始日期就好了。毕竟如果按照固定 30 天，一年下来用户还是少了几天；如果固定 31 天那么一年下来又给用户多了几天。前提是得说清楚，明确告知用户。 |
 | 26 zerovoid 3 小时 30 分钟前 阿里的逻辑应该是这样的， 你 2 月 26 日买一个月，那他就给你开到 3 月 26 日， 但是 2 月份只有 28 天，那就感觉比 30 天少 2 天了。 |
 | 27 yeh 3 小时 1 分钟前 阿里基操是这样子的，连续包月，一年后发现实际只给了 360 天，5 年能多出来一个月。 发现这个事也挺巧的，习惯性记账，然后发现每个月的实际扣款日慢慢提前了。 |
 | 29 Semantic 2 小时 35 分钟前 隔壁实测，套路云 的 GLM-5 上下文只有 73728 tokens 。这种长度根本没法干活 |
 | 30 jobives2023 2 小时 30 分钟前 有些国内的模型是看起来单价便宜，但实际消耗很多 token ，去年买过一次 kimi 的模型用在 claude code 测试了一下，一个 BUG 跑了 30 多块钱还没搞定，换成 claude 模型 5 分钟就解决了 |
 | 31 lijunjieone 2 小时 8 分钟前 我觉得 kimi 好像更坑，我买了一个月的，一会小时限制，一会频率限制，一会周限制到期。改成 qwen3.5 还是可以用的。 |
 | 32 realpg PRO 还是腾讯系到位, 记得以前就他家的给的足, 按月就 31 天 按年就 366 天. |
 | 33 cloverzrg2 1 小时 11 分钟前 cursor 这个月也是 28 天吧 |
 | 34 yean 1 小时 3 分钟前 AI 变现，也是应该的 |
| 35 mogutouer 57 分钟前 @dassh #17 都没毛病，问题出在他不是显示下个月几号到期，而是显示剩余 XX 天，导致这种感觉加重。这是典型的靠信息输出和设计就能解决的问题，他非要选一个最得罪人的方式。 |
 | 36 win8en 53 分钟前 via Android 我买完在 opencode 里面没办法用，不知道咋回事，明天再看看 |
 | 37 liuliuliuliu PRO 有很多都是按自然月算的，腾讯云 cloudbase 也是自然月 |
Select Language