模型多了之后，我在 CPA 上把常用模型统一接入，作为所有请求的网关。之后用 opencode 调 minimax-m3 时，最开始走的是 anthropic 兼容接口（和上游官方接口一致），结果发现缓存命中率几乎等于零，每次对话模型都要重新计算，成本直线上升。

换思路试了一下 openai 兼容接口（同样和官方接口一致），缓存命中率立刻上来了，稳定在 90% 左右。但随之而来一个新问题：返回正文里多了 <think>...</think> 包裹的思考内容。用起来其实没毛病，opencode 能正常接收，但思考内容混在正文里终究不太对劲。

查了一下 minimax 官方文档，发现有个 reasoning_split 字段，设为 True 之后，思考内容会单独放进 reason_content，不再占正文，opencode 也能正常解析。问题在于每次请求都得手动加这个字段，太麻烦。opencode 又没有自定义请求格式的入口（至少我没找到），改请求只能自己写插件，不划算。好在 CPA 有插件系统，装一个官方的 JSHandler 插件，写段脚本在请求前自动判断并加字段，一劳永逸。

插件装好后，在配置里指定脚本文件，脚本逻辑如下：先判断协议是不是 OpenAI 格式，再判断模型名是否命中 minimax-m3，命中且请求体里还没加过 reasoning_split 就补上 true，全程只用了几行代码：```
function on_before_request(ctx) {
try {
// 1. 使用 protocol 判断是否为 OpenAI 格式
if (ctx.protocol !== "openai" && ctx.source_format !== "openai") {
return ctx;
}

// 2. 检查模型名称是否命中 minimax-m3
var model = ctx.model || "";
if (!model.toLowerCase().includes("minimax-m3")) {
return ctx;
}

// 3. 解析请求体并添加 reasoning_split
var req = JSON.parse(ctx.body);
if (req.reasoning_split === undefined) {
req.reasoning_split = true;
ctx.body = JSON.stringify(req);
console.log("[" + ctx.id + "] Added reasoning_split=true");
}
} catch (e) {
console.log("[" + ctx.id + "] Error: " + e.message);
}
return ctx;
}
```配置的时候有一点要注意：脚本路径务必填绝对路径，用相对路径的话插件会找不到文件，直接报错。我的配置长这样：

至此调用链变成：opencode → CPA → JSHandler 自动补 reasoning_split → minimax-m3。缓存命中率保持在 90% 左右，思考内容与正文各归各位，问题彻底解决。如果你也遇到同样的"不缓存"问题，可以按这个思路排查一遍：先对比两种兼容接口的缓存表现，再检查是否被思考内容污染了正文，最后用网关插件统一处理。