shukebeta我买了MiniMax的max套餐，因为它量大便宜，服务相对稳定。一开始只是让它做一些简单的活，因为它能力跟一线模型有肉眼可见的差距。
然而最近我开始给它一些难题，没想到表现超出我的预期。而且因为没有token焦虑，我也不用着急清context window。这类题目让Claude来做，很快就会把五小时限额烧完。MiniMax可能会多走一些弯路，多做一些尝试，但最终也能解决问题。这样我就可以让那些好模型去做那些清晰定义了的规模较小的issue。
從高處墜落的馮霍亨法尔🇺🇦🇹🇼🇵🇸 
@shukebeta 这么好的吗？我1月份的时候试用过感觉蠢蠢的。
@iklein Minimax-M3 1M上下文，差距当然是有的，但也确实能干活。max订阅，一个月给17亿token的量。一些难缠的问题，它兜兜转转居然也能解决。我有个bash 测试集（三万行）在gitbash上有很多失败，舍不得拿opus去修，就让Minimax去干。一个指令，吭哧吭哧干了2个小时，解决了1/3（当然我还要检查它修好的这三分之是不是真修好了哈哈哈），（也许是觉得上下文有点大了？）它还主动停下来写了个follow-up ticket。
@shukebeta 看来我还是用的太狠了，我一周能干3B+的token，下个月好日子过去了要节衣缩食过苦日子了。
@iklein 一周3B+，你好厉害。这是两条路线的差异，我还试图理解和掌控开发过程，能烧多少token依赖我的精力。我还拿不准的issue不会交给agent实施。不过也是受限于我的claude基础Pro订阅，要是issue多，三个Pro全用OPus也撑不了5小时。国产订阅最近表现拉垮，api error得我都麻了，干脆弃之不用。Minimax高峰时间也很慢，虽然模型差点，稳定性比z.ai和火山引擎表现好。
@shukebeta 理解，我是定义了一套loop然后让llm不断迭代，上次说的那个项目就是这么跑完的，我估计这里面有大概50%的浪费，一方面是模型理解错上下文导致工作的方向错了浪费了不少时间，另一方面是模型写unit test太疯狂了，从test plan开始就不断抠细节，最后给我搞出两千多个test来，过程中还反复修改重构。如果上面两个问题改进的话，我估计节省一半问题不大。
@shukebeta 说起来你搞三个pro为啥不干脆直接上100的max呢？
@shukebeta 理解，看起来我也得强迫自己戒断了，不然浪费钱还浪费生命。真真是一种电子毒品。