很多人配置完 Codex，转头又打开 WorkBuddy。
又是 Base URL，又是 API Key，又是 Model Name。三组输入框看起来眼熟得像复制粘贴大赛。
但这里最危险的，恰恰是复制得太顺手。
AI Code With 文档提供了 WorkBuddy AI 的明确接入步骤，也提供了 Codex 的独立接入教程。两者都属于已确认的接入生态。能复用的是模型账户、Key 管理与调用后台，不是工具本身的功能。
WorkBuddy 的办公和 Agent 能力属于 WorkBuddy。Codex 的编码、文件与命令能力属于 Codex。AI Code With 在中间提供已确认的 API、模型入口与用量记录。
三层东西不要写成一个产品
Codex 使用：
https://api.aicodewith.ai/chatgpt/v1
并按 Responses Provider 配置。
WorkBuddy 的自定义模型入口则填写 AI Code With 的 OpenAI 风格 Base URL、Key 和当前 Model Name：
https://api.aicodewith.ai/v1
模型名必须从当前模型页面或对应教程获取。不要看见后台卡片写着一个自然语言名称，就直接猜调用 ID。
少重复，不等于一个 Key 走天下
经常同时使用两个工具，可以创建两个容易识别的 Key，例如 codex-daily 和 workbuddy-daily。AI Code With 已确认支持对单 Key 设置额度、渠道和模型限制，Usage Records 也可以看到 Key、模型、渠道、Token 与费用。
这样成本突然变化时，先按 Key 过滤，就能知道来自哪个工具。
一次只验证一条链
先在 Codex 发一个只读小任务，确认后台出现记录。再到 WorkBuddy 发一个最小请求，确认第二条记录。
WorkBuddy 保存配置但请求没有记录，先查自定义模型是否真的被选中。Codex 没有记录，先查 Provider 是否生效。不要因为一边失败，就把两个工具的 Key 一起重置。
如果你只是偶尔用一次 WorkBuddy，也没必要搭一套复杂的多 Key 体系。一个低额度测试 Key，用完停用，可能更合适。
好的统一入口，不是让用户分不清产品边界。
是让工具各做各的事，而你少做一点重复配置。