【开源推广】OSW 本地 AI 网关，支持故障转移和请求重写

我渠道比较多，官方的、中转的、本地跑的都有。以前是每个工具配一套 Base URL 和 Key，哪个渠道限流了、额度跑完了、服务挂了等等，就得挨个工具进去改配置。太影响我 Coding 了！！

OSW 是个托盘应用，本机跑一个 HTTP 代理。所有客户端统一填 http://127.0.0.1:9300，渠道在它里面配、拖顺序。匹配请求并在合适的时候自动转移。

和 cc-switch 的区别

L 站用 cc-switch 的佬友应该不少，说清楚免得装完发现不是想要的。

cc-switch 是配置管家，切供应商是往 Claude Code、Codex、Gemini CLI 的 JSON / TOML / .env 等配置文件里更新

OSW 完全不碰你的客户端配置。不读、不写、不备份、不接管，一个字节都不动。它只提供一个本地地址，你要改的是客户端里那个 Base URL 字段，所以「工具把我配置写坏了或者丢配置」这种事在它这儿不存在

另外 cc-switch 是围着 Agent CLI 工具做的，MCP、Skills、会话历史这些都管；OSW 是纯网关，客户端只要能填 Base URL 就能接，Cursor、桌面端聊天工具都行。两边真正重叠的只有本地代理那一块。

以下是我认为比较好的设计和功能

超级详细的请求日志！我真的经常用。

每个请求查得到。这次走了几个渠道、每次分别什么结果、第几次才成功、总耗时、首字延迟、TPS、缓存命中多少、上游返回的原始 usage，都在请求日志里。

请求重写

说两个我实际在用的场景。

改 User-Agent。 上游判断「你用的是不是官方客户端」基本就看这个字段，不少渠道的 plan 就是拿它来放行或拒绝工具调用的。在 OSW 里直接设置一条全局请求重写规则就行。

给思考开关兜底。 用 Codex 接开源模型应该都踩过这个坑：Codex 走 OpenAI Responses，请求里带 reasoning，但开源模型那边的开关叫 enable_thinking 或者 thinking，客户端里根本没有配的地方。用重写规则往上游请求里塞一个字段就行，路径不存在会自动创建；反过来把客户端带上来的 reasoning 删掉也可以。一家一个写法，配一次就完事。

路由编排

两个模式，一个工作流和一个规则，规则简单好用，工作流可以实现复杂的设计。

接口兼容

这个功能是在模型上手动打开的，因为接口的兼容这块确实复杂，所以不敢说 100% 好用，但是基本上没什么问题，有一些小问题也可以用请求重写自助解决。

最后

目前所有发布都是 beta 预发布版（最新 1.2.0-pre.1）。release notes 里写明了不承诺数据兼容和自动迁移，升级前建议先在模型管理里导出一份备份。介意这个的佬友可以再等等正式版。

有问题或者想法欢迎开 Issue，附版本号、系统、协议和脱敏后的日志会好定位很多。