不同模型和供应商对请求格式的要求并不相同。有些参数可以交给客户端决定，有些请求头或请求体字段则必须固定；一旦客户端缺少或覆盖这些值，请求就可能失败。

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 并开启请求头强制覆盖，接入这条路由的客户端无需逐个修改，也无法再覆盖这个固定值。

OctaFuse 路由编辑器为 x-opencode-session 开启请求头强制覆盖

通过 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 管理后台会将路由自定义参数保存为新的信封结构，滚动升级时建议采用以下顺序：

  1. 先将所有 Proxy 升级至 2.10.0。

  2. 确认旧 Proxy 已全部退出流量。

  3. 再升级 Admin，并检查关键路由。

  4. 根据需要分别设置请求头与请求体的强制覆盖。

新版 Proxy 可以读取历史扁平配置，但旧版 Proxy 无法正确理解新版 Admin 保存的信封结构。因此，在所有 Proxy 完成升级之前，不要使用 2.10.0 Admin 保存路由。

升级后建议验证：

  1. 未开启强制覆盖时，客户端同名请求体参数和请求头仍然优先。

  2. 分别开启请求体或请求头强制覆盖时，只有对应一侧改为路由值优先。

  3. GET /v1/models 返回的 model_info.inbound 与实际开放入口一致。

  4. Responses 流式事件都包含可解析的顶层 sequence_number。

  5. 永久额度调整能够生成审计记录，并可通过组合条件筛选。

升级前可查看 GitHub Release v2.10.0 和 完整更新记录。

小结

2.10.0 进一步明确了网关与客户端之间的配置边界：普通参数继续由客户端调整，关键请求体字段和上游请求头可以按路由锁定；模型列表能够告诉客户端有哪些可用入口，永久额度变化也更容易查询和核对。

如果 OctaFuse 对你的项目有帮助，欢迎在 GitHub 上点一个 Star。你的关注和反馈，会帮助我们继续完善路由治理、客户端接入与自托管体验。