joycode 最新的免费限制是每天500万 tokens，超出后不会报错，而是降级处于排队，首token延迟高一点，因为官方服务端将所有 chunk块一次性响应，总体来说 joycode 的 glm-5 或 glm-5.1 作为子代理专门处理编码任务是非常不错的，毕竟是满血模型。
devecocode 的glm-5.1 是个 w4a8 的量化模型，170k上下文缩水30k，保持可接受范围的精度退化，但量化模型同时提升了吞吐量，作为glm-5.1本身能力毋庸置疑，吞吐量的提升进行代码调研任务是不错的，170k上下文也是足够的
codearts 的 glm-5 和 glm-5.1 都是满血模型，之前 codearts 有一个非常严重的问题，一旦上下文超过50k 模型请求会一进处于请求状态直到超时被OpenCode重试，最近使用感觉没有这个问题了，应该是官方修复了，这个插件项目更改了多次的授权登录流程，因为官方总是变更。
mimocode 只有一个 mimo-v2.5 模型本身能力不够，在国内处理垫底，可以看作笨笨的模型，但本身是个多模态模型，在处于图片识别方面有用（OMO放在 look_at 中），同时频繁的429限流错误也不能作为日常任务模型，只适合偶尔使用，我也将它作为 OpenCode 的自动压缩、摘要处理，毕竟它有1M上下文，可以单独作为自动压缩使用的模型
kiloccode 可以看作充值了$10的 openrouter 的 apikey，openrouter 的免费模型都可以定义在 kilocode-auth\src\constants.ts 中，需要自己实时修改，openrouter 的免费模型总是变化的，而且需要自己测，有些不能用，它里面有一个 nex-n2-pro 的模型是不错的，可能比较小众，大家没有听说过，它的能力甚至超越了 deepseek-v4-pro 将 glm-5.1 远远甩在身后（nex-n2-pro 基于 Qwen3.5 -397B-A17B 后训练）
响应速度 是很快的，大概是比较小众，大家都没有使用
我最近发了一些 more 结尾的 插件，比如 sensemore、agnesmore，是 多个 apikey 轮询使用的实现，为了减缓提供商对免费模型的速率限制，其中：
sensemore 的 deepseek-v4-flash 是我最常使用的主编排模型，1m上下文，没有上下文焦虑，商汤提供的这个模型最近响应也是变快了很多，尤其是晚上。白天 tps 输出速度可能会低一点。
agnesmore 提供了一个 agnes-2.0-flash 模型，虽然笨笨的，但毕竟是个多模态模型，可以用作图片理解，有时候截一个竞品页面某个组件的截图给OpenCode来实现组件样式，OMO是要调 look_at 来识别图片的，这个模型就这可以作为这个 look_at 角色。
longcatmore 是美团龙猫的，虽然每天有500万 tokens 的限制（两手机号就能注册两个美团，1天就是1000万），LongCat-2.0-Preview 这个模型本身大家目前也不看好，毕竟还是大厂出品，财力雄厚，现在缺的就是我们这些人给它输送训练数据。
像这些插件我都是开源的，毕竟不是逆向，是需要自己输入apikey的，可以关注下这个组织，这个组织下我都会不定时更新 新的more插件：opencode-plugin: OpenCode插件项目
最近更新了 zenmore 也就是 OpenCode Zen 的免费模型多key轮询插件，由于zen官方的免费模型会经常更新，因此也需要自己定时处理 src\constants.ts 免费模型列表。