不同模型和供应商对请求格式的要求并不相同。有些参数可以交给客户端决定，有些请求头或请求体字段则必须固定；一旦客户端缺少或覆盖这些值，请求就可能失败。
OctaFuse Gateway 2.10.0 为路由请求体和上游请求头增加独立的强制覆盖开关，同时让客户端从模型列表中识别可用请求入口，并完善永久额度变更记录与审计筛选。
一句话看懂 2.10.0：
关键路由参数可以由网关锁定，客户端更容易选择正确入口，管理员也能完整追溯额度变化。
01｜路由参数强制覆盖
2.9.0 将自定义上游请求头与请求体默认参数分开配置。2.10.0 在此基础上增加“强制覆盖（Force override）”开关：默认仍以客户端同名值为准，也可以分别将请求头或请求体改为路由值优先。
以请求体中的 max_tokens 为例。路由配置为 4096、客户端传入 8192 时：
- 未开启强制覆盖：最终使用客户端传入的
8192。 - 开启请求体强制覆盖：最终使用路由配置的
4096。
上游请求头遵循同样的规则。如果 HTTP-Referer、X-Title 或某个渠道 Header 必须由运维固定，可以只开启请求头强制覆盖，不影响请求体的合并方式。
例如，最近 OpenCode 会校验 x-opencode-session。一些客户端无法补充这个 Header，或者传入的值不符合上游要求，都会导致请求被拒绝。通过 OctaFuse，只需在路由中配置正确的 Header 并开启请求头强制覆盖，接入这条路由的客户端无需逐个修改，也无法再覆盖这个固定值。
通过 Admin API 管理路由时，custom_params 使用统一的信封结构：
{
"headers": {
"HTTP-Referer": "https://example.com",
"X-Title": "My App"
},
"body": {
"max_tokens": 4096,
"temperature": 0.7
},
"force_override": {
"headers": true,
"body": true
}
}
force_override 只需写入要开启的一侧；没有出现的开关视为关闭。两个开关只改变同名值的优先级，客户端与路由各自独有的字段仍会保留，messages 等请求内容也不会被整体替换。
鉴权与传输边界也没有放开。Authorization、X-API-Key、X-Goog-API-Key、Host、Content-Type、Content-Length、Cookie 以及连接管理类 Header 仍由 Gateway 控制，不能通过路由或客户端覆盖。没有在路由中配置的客户端 Header 也不会自动转发给上游。
历史扁平格式的 custom_params 可以继续运行，两侧都按“未强制覆盖”处理；路由在新版管理后台保存后，会自动整理为新的信封结构。
02｜模型入口一目了然
同一个模型可能同时开放 Chat Completions、Responses、Anthropic Messages 或 Gemini generateContent。过去客户端从 /v1/models 只能看到模型 ID，仍需另外约定应该调用哪个接口。
2.10.0 在 GET /v1/models 的 model_info 中增加 inbound，直接列出当前可用的请求入口：
{
"id": "example-model",
"model_info": {
"inbound": [
{ "protocol": "openai", "operation": "responses" },
{ "protocol": "openai", "operation": "chat" },
{ "protocol": "anthropic", "operation": "messages" }
]
}
}
inbound 来自当前用户可见路由组中的活跃请求入口。它描述的是客户端应该调用的协议与操作，不是供应商侧的上游协议，也不表示推荐顺序。客户端仍需根据自身能力选择 Chat、Responses 或其他入口。
当前该字段只汇总 LLM 文本入口，不包含图片生成和音频接口。通配入口会在没有同协议精确入口时展开为默认文本操作。
03｜额度变更可追溯
管理员直接修正永久额度时，2.10.0 会使用独立的 admin_patch_wallet 原因码，并记录调整前后的永久额度总额、已消费金额和当前余额。如果同一次操作还修改了周期额度，则仍归入周期额度调整，便于区分两类操作。
永久额度的发放与直接修改记录现在统一展示在用户审计日志中。管理员不必在用户详情的多个区域来回查找，就能直接看到额度从什么值调整到了什么值。
审计日志的事件类型、事件来源、事件原因、操作者和操作来源支持多选。排查某个用户的额度变化时，可以组合多个条件缩小范围，同时保留相关联的创建、加额和管理修改记录。
04｜其他更新
除上述重点能力外，2.10.0 还包含以下兼容性和模型目录更新：
| 场景 | 本次变化 |
|---|---|
| Responses 流式兼容 | 当上游 SSE 事件缺少顶层 sequence_number 时，Gateway 会按当前连接补充递增序号；上游已有序号保持不变，避免严格校验该字段的客户端中断。 |
| 新增模型 | 新增 claude-fable-5-1、gpt-6-astra 和 deepseek-v4.1-flash 预设。 |
| DeepSeek 价格 | 按最新目录价格调整 deepseek-v4-flash 的输入、输出与缓存读取价格，并保留工作日峰谷时段配置。 |
模型目录导入不会覆盖数据库中已经存在的同 ID 模型。需要使用新模型时仍需按需导入；已有 deepseek-v4-flash 如需采用新价格，应先核对实际供应商价格，再手动更新或重新配置。
升级到 2.10.0
本版本没有新增数据库迁移。如果数据库已经完成 2.9.0 的迁移 0028，可以直接升级 Proxy 和 Admin；从更早版本升级时，仍需先补齐对应迁移。
由于 2.10.0 管理后台会将路由自定义参数保存为新的信封结构，滚动升级时建议采用以下顺序：
- 先将所有 Proxy 升级至 2.10.0。
- 确认旧 Proxy 已全部退出流量。
- 再升级 Admin，并检查关键路由。
- 根据需要分别设置请求头与请求体的强制覆盖。
新版 Proxy 可以读取历史扁平配置，但旧版 Proxy 无法正确理解新版 Admin 保存的信封结构。因此，在所有 Proxy 完成升级之前，不要使用 2.10.0 Admin 保存路由。
升级后建议验证：
- 未开启强制覆盖时，客户端同名请求体参数和请求头仍然优先。
- 分别开启请求体或请求头强制覆盖时，只有对应一侧改为路由值优先。
GET /v1/models返回的model_info.inbound与实际开放入口一致。- Responses 流式事件都包含可解析的顶层
sequence_number。 - 永久额度调整能够生成审计记录，并可通过组合条件筛选。
升级前可查看 GitHub Release v2.10.0 和 完整更新记录。
小结
2.10.0 进一步明确了网关与客户端之间的配置边界：普通参数继续由客户端调整，关键请求体字段和上游请求头可以按路由锁定；模型列表能够告诉客户端有哪些可用入口，永久额度变化也更容易查询和核对。
如果 OctaFuse 对你的项目有帮助，欢迎在 GitHub 上点一个 Star。你的关注和反馈，会帮助我们继续完善路由治理、客户端接入与自托管体验。