我渠道比较多，官方的、中转的、本地跑的都有。以前是每个工具配一套 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，附版本号、系统、协议和脱敏后的日志会好定位很多。 2 个帖子 - 1 位参与者 阅读完整话题

  • 情报分类：服务器与云资源
  • 分类依据：内容涉及服务器、云资源或网络线路
  • 信息来源：服务器 / LINUX DO - 最新话题
  • 发布时间：2026/9/22 18:04:01