修改 API 基础 URL 不足以证明 Codex 正在使用您想要的提供者 。
Codex是一个代理客户端.
它需要的不仅仅是能够返回文本的模型.
提供者必须支持所依赖的响应API行为 Codex,API密钥必须达到发射Codex的过程,所选模型必须提供给该密钥,最终请求必须到达预期的终点.
本指南展示了一个自定义响应API提供者的保守设置,以Xiu Router为具体例子.
同样的核查方法适用于其他相容的网关.
配置有四个独立的决定 A工作编码提供者配置 回答四个问题: Codex应该要求哪种模式?
哪个命名的提供商应该使用 Codex ?
哪个基址应该收到请求?
哪些环境变量包含 API 密钥 ?
明确作出这些决定。
最小用户级配置是这样的: 使用当前可见于您的账户的模型 ID 。
不要从旧的截图或其他用户的配置中复制模型名称,并假设您的密钥可以访问它.
重要的一行是: Codex 使用Resolution API作为其本土代理工作流程.
仅接受"聊天补全"请求的提供商可能对其他客户端有用,但并非自动是滴入的Codex提供商.
OpenAI的 Codex 配置参考也定义了.,并作为一个单独的提供者设置.
调试时将它们作为单独的失败边界处理 。
从配置中保留 API 密钥应该命名一个环境变量, 而不是包含这个秘密 : 对于一个终端会话: 对于在 macOS 上的 Codex 桌面, 应用程序不能从您的终端外壳中继承变量 。
在发射环境中设置变量,然后完全退出并重新打开 Codex:这个区分很重要.
如果桌面应用程序是在外壳中发射的,其中的正确键仍然可以产生。
诊断时不要打印密钥 。
检查变量是否存在以及请求是否成功,而不是秘密值本身.
从可逆配置开始 在新路线通过真正任务之前, 不要覆盖工作供应商 。
在文件中保留上一个提供者块,只更改活动和行.
如果自定义路线在更长的代理运行中失败,那么你就会快速回滚。
在将新提供者推广到整个用户默认情况下, 在项目级别配置中对其进行测试也比较安全 。
OpenAI 文档工程配置在 .
而用户默认在 .
实用规则是:用于受限测试的项目配置;提供者通过后用户配置;旧提供者保留到不再需要回滚.
成功发射并不是在Codex开始后成功整合,运行一个需要工具使用的只读的小任务.
例如:检查此寄存器,识别测试命令,并总结主要模块.
不修改文件 。
这比请模特儿打个招呼更有用 纯文本回复仅证明有一个请求返回了文本 。
寄存器检查可以练习代理环路,工具指令,流出和后续转动而不会产生破坏性副作用.
然后在提供方核实请求.
对Xiu Router来说,使用记录应显示:预定的API密钥;预定的模型;响应路径;成功状态;请求的用法和记录成本.
预期路径是: 如果没有出现相应的记录, 请不要假设请求使用了新的提供者 。
Codex可能仍在使用更古老的活性配置,或者应用程序可能没有继承环境变量.
按边界分析失败, 请先检查进程环境 。
设定环境变量后是否启动代码( Codex) ?
变量名称是否完全吻合?
用于活期账户的密钥是否有效?
工程级配置是否凌驾于用户级提供者之上?
对于 Codex 桌面, 在更改启动后完全退出应用程序