1. Kimi K3 开源解禁后，Codex 里怎么真正跑起来

Kimi K3 开源解禁这件事，对天天泡在 Codex 里写代码的人来说，最直接的问题不是“它有多强”，而是“我能不能在现有工作流里用上”。K3 是 2.8 万亿参数的 MoE 架构，1M 上下文，原生多模态 agentic 能力，权重一放出，vLLM、SGLang 当天就上了 Day-0 支持。但落到 Codex 这个具体工具上，事情没那么顺——Codex 走的是 Responses API，而 K3 对外给的是 OpenAI 兼容的 Chat Completions API，两套协议对不上，直接填个 Base URL 是跑不通的。

我试过直接在 Codex 的 auth.json 里改 base_url 指向 K3 的兼容端点，结果请求发出去就报reading choices相关的解析错误，因为 Codex 期望的响应结构跟 Chat Completions 返回的格式不一致。这不是配置写错了，是协议层面对不上。所以核心思路是：要么在中间加一层协议转换，要么用支持 Responses API 的聚合层来承接。

这篇要解决的就是这个场景：Kimi K3 开源解禁后，开发者希望在 Codex 中调用 K3 的 MoE 能力，把开源最强模型稳定接进日常编码工作流。我会给出 auth.json 与 Base URL 的可复制配置片段，演示一次对话请求验证接入是否生效，并把常见的报错排查路径写清楚。适合已经在用 Codex、想低成本切换模型、又不想被单一订阅绑死的人。

TaoToken 在这里的角色是一个 OpenAI 兼容的聚合接入层，它对外暴露的 Base URL 是https://taotoken.net/api，支持 Chat Completions 协议，同时也能承接 Codex 这类需要 Responses 风格的工具。你不需要自己搭转换器，也不用改 Codex 的源码，改一个 auth.json 就能把请求路由过去。下面从配置到验证一步步来。

2. TaoToken 前置准备：Key、Base URL 与模型 ID

在动 Codex 的配置文件之前，先把三样东西拿到手：API Key、Base URL、Model ID。这三件套是后面所有配置的基础，缺一个都会在请求阶段报 401 或者 model not found。

先说 Base URL。TaoToken 的 API 入口是https://taotoken.net/api，注意这里不带任何查询参数，就是干净的 API 根路径。Codex 的 auth.json 里填的 base_url 要写到这个层级，后面 Codex 会自己拼接/chat/completions或/responses这样的路径。如果你填成带/v1的地址，有些工具会重复拼接导致 404，所以按官方给的根路径来最稳。

再说 API Key。你需要到 TaoToken 的控制台里创建一个 Key。创建入口在控制台的 API Keys 页面，点新建，给它起个名字比如codex-k3，然后复制出来。这个 Key 只显示一次，复制完存到安全的地方。Key 的格式通常是一串以sk-开头的字符串，长度比较长，别手动截断。

Model ID 这块要特别注意。K3 在 TaoToken 上的模型标识不是随便写的，你要用平台文档里给出的准确 ID。一般来说 Moonshot 系的模型 ID 会带kimi或moonshot前缀，具体以你控制台模型列表里显示的为准。填错 Model ID 的典型报错是model_not_found或者invalid model，这时候回去核对一下大小写和连字符。

提示：如果你同时想用 K3 和其他模型做对比，可以在 TaoToken 控制台里把常用模型都加到收藏，切换的时候直接选，不用每次翻列表。

拿到这三样之后，建议先别急着改 Codex，用 curl 单独测一次，确认 Key 和 Base URL 本身是通的。这一步能帮你把“配置问题”和“网络问题”分开。测试命令在下一节给，先记住三件套的对应关系：Base URL 是https://taotoken.net/api，Key 是你刚创建的那串，Model ID 是 K3 的准确标识。

另外提一句，TaoToken 的接入文档里有针对不同工具的配置示例，Codex 的 auth.json 写法在里面有专门一节。如果你用的不是 Codex 而是 Cline、CC Switch 这类工具，文档里也有对应的 MCP 或 settings 片段，思路是一样的：Base URL 指向 TaoToken，Key 填进去，Model ID 选 K3。

3. 可复制配置：auth.json 与 settings 片段

这一节是整篇的核心，直接给可复制的配置。Codex 的配置文件位置按操作系统不同：

macOS 和 Linux 下在~/.codex/auth.json，Windows 下在%USERPROFILE%\.codex\auth.json。如果这个文件不存在，手动创建一个，注意目录要先建好。

先给 auth.json 的完整片段。这个文件同时承载认证信息和模型路由信息，所以 Key 和 Base URL 都写在这里：

{ "OPENAI_API_KEY": "sk-你的TaoToken密钥", "OPENAI_BASE_URL": "https://taotoken.net/api", "model": "kimi-k3", "provider": "openai" }

这里有几个点要说明。OPENAI_API_KEY字段名是 Codex 约定的，即使你接的不是 OpenAI 官方，也沿用这个字段名，Codex 读的就是它。OPENAI_BASE_URL填 TaoToken 的 API 根路径，不要带尾斜杠。model填 K3 的准确 Model ID，我上面写的是kimi-k3作为示例，你以控制台实际显示为准。provider保持openai，因为 TaoToken 对外是 OpenAI 兼容协议。

如果你用的是 Codex CLI 而不是客户端，配置方式略有不同，CLI 会读~/.codex/config.toml。对应的 TOML 片段：

model = "kimi-k3" model_provider = "taotoken" [model_providers.taotoken] name = "TaoToken" base_url = "https://taotoken.net/api" env_key = "TAOTOKEN_API_KEY" wire_api = "chat"

注意wire_api这个字段。Codex 默认走 Responses API，但 K3 给的是 Chat Completions，所以这里要显式设成chat，让 Codex 用 Chat Completions 协议发请求。这是解决协议对不上的关键一行，漏了它就会报reading choices之类的解析错误。env_key指定从哪个环境变量读 Key，你需要在 shell 里 export 一下：

export TAOTOKEN_API_KEY="sk-你的TaoToken密钥"

Windows PowerShell 下用：

$env:TAOTOKEN_API_KEY="sk-你的TaoToken密钥"

如果你用的是 Cline 或者带 MCP 的工具，配置形态是 settings 片段。以 Cline 的 MCP 配置为例，在cline_mcp_settings.json里加：

{ "mcpServers": { "taotoken": { "command": "npx", "args": ["-y", "@taotoken/mcp-server"], "env": { "TAOTOKEN_API_KEY": "sk-你的TaoToken密钥", "TAOTOKEN_BASE_URL": "https://taotoken.net/api", "TAOTOKEN_MODEL": "kimi-k3" } } } }

三件套在这里同样齐全：Base URL、Key、Model ID。不管你是 auth.json、config.toml 还是 MCP settings，这三个值都是必须的，缺一个就跑不起来。

改完配置后，Codex 客户端要完整退出再打开。macOS 在菜单栏退出，Windows 确认任务管理器里进程关掉，只关窗口不算，否则它读的还是旧配置。这是最容易忽略的一步，很多人改完发现没生效，就是没重启。

4. 验证请求：一次对话确认 K3 是否生效

配置写完，下一步是验证。验证分两层：先用 curl 确认 TaoToken 这一层通，再在 Codex 里确认端到端通。

先跑 curl。这条命令直接打 TaoToken 的 Chat Completions 端点：

curl https://taotoken.net/api/chat/completions \ -H "Authorization: Bearer sk-你的TaoToken密钥" \ -H "Content-Type: application/json" \ -d '{ "model": "kimi-k3", "messages": [ {"role": "user", "content": "用一句话说明你是什么模型"} ] }'

如果返回的 JSON 里有choices数组，且message.content里是模型的自述，说明 Key、Base URL、Model ID 三件套都是对的。如果返回 401，是 Key 的问题；返回 404，多半是 Base URL 多写了/v1或者 Model ID 拼错；返回model_not_found，回去核对 Model ID。

curl 通了之后，打开 Codex 客户端，直接问一句“你是什么模型”。正常情况下它会回答自己是 Kimi，由 Moonshot AI 开发，当前在 Codex 环境中运行。界面还是 Codex 的界面，但底层跑的已经是 K3 了。

我实测下来，K3 在前端生成上的表现确实突出。接通之后我让它生成一个矿物晶体交互图鉴的静态页面，几分钟出来的结果配色和质感都到位，右侧圆点点击切换的交互效果也正常。这种任务以前要来回调好几轮，K3 一次给的结构就比较完整。

如果你想更严谨地确认请求确实走了 TaoToken，可以到 TaoToken 控制台的账单明细里看。来源会标着 Codex，模型是 kimi-k3，输入输出 token 数、cache 命中、扣费金额都列在上面。看到这条记录，就说明请求确实经过 TaoToken 路由到了 K3，不是本地缓存或者别的模型在回答。

注意：验证的时候不要用太复杂的 prompt，先用一句话问答确认链路通，再上真实任务。链路没通就上复杂任务，报错信息会混在一起，不好定位。

端到端验证通过后，你就可以把 K3 当成 Codex 的默认模型来用了。想换回 GPT 系列或者切别的模型，改 auth.json 里的model字段，或者用工具提供的切换入口，重启 Codex 即可。

5. 常见报错排查：401、local proxy failed 与 reading choices

接入过程中最容易撞上的几个报错，我按出现频率排一下，每个都给排查路径。

401 Unauthorized。这个最直接，Key 不对或者没带上。先检查 auth.json 里的OPENAI_API_KEY是不是完整复制了，有没有多余空格。如果你用的是 config.toml 加环境变量的方式，确认export是在当前 shell 会话里执行的，换个终端窗口就没了。还有一种情况是 Key 被删了或者过期了，回 TaoToken 控制台重新创建一个。

local proxy failed。这个报错通常出现在你本地挂了转换器或者代理层的时候。Codex 尝试连本地某个端口，但那个服务没起来。如果你是按官方文档挂了 CC Switch 或 codeproxy 这类转换器，先确认转换器进程在跑，端口对得上。如果你走的是 TaoToken 直连，不应该出现这个错，出现了就检查 auth.json 里是不是还残留着指向 localhost 的 base_url。

reading choices 相关解析错误。这个是我最开始踩的坑。Codex 默认按 Responses API 的响应结构去解析，期望的字段跟 Chat Completions 返回的choices对不上，于是在读取choices的时候报错。解决办法就是在配置里显式声明用 chat 协议。config.toml 里加wire_api = "chat"，auth.json 方式下确认 provider 是 openai 兼容模式。如果工具不支持协议声明，就需要中间加一层转换，把 Chat Completions 的响应转成 Responses 格式。

OAuth 相关报错。Codex 客户端有时会尝试走 OAuth 登录流程，如果你之前登录过 OpenAI 官方账号，它可能还在用旧的 token。表现是请求发出去但认证失败，或者提示 token 过期。处理方式是清掉本地的 OAuth 缓存，通常在~/.codex/目录下有相关的 token 文件，删掉后重启，让它走 auth.json 里的 Key 认证。

模型切换后没反应。这个不算报错，但很常见。改完配置或者切换模型后，Codex 必须完整退出再打开。只关窗口进程还在，读的还是旧配置。macOS 在菜单栏退出，Windows 在任务管理器里确认进程结束。

排查顺序建议是：先 curl 确认 TaoToken 层通，再确认 Codex 配置里的三件套齐全，再看协议声明对不对，最后看进程有没有重启。按这个顺序走，大部分问题都能定位到具体哪一层。

6. 把 K3 稳定接进 Codex 工作流

走到这里，配置和验证都完成了。回到最开始的问题：Kimi K3 开源解禁后，怎么在 Codex 里用上它。答案就是通过 TaoToken 这样的 OpenAI 兼容聚合层，把 Base URL 指向https://taotoken.net/api，Key 填进去，Model ID 选 K3，协议声明用 chat，然后重启 Codex。全程改一个 auth.json 或者 config.toml，不用自己搭转换器。

这套配置的好处是切换成本低。哪天你想换回 GPT 系列，或者试试别的开源模型，改一个字段重启就行。不用重新订阅，不用绑卡，也不用被单一模型绑死。K3 强的时候用 K3，别的模型有更适合的任务就切过去，主动权在自己手里。

如果你还没拿到 Key，先去 TaoToken 控制台创建一个，然后按第 3 节的片段改配置。改完用第 4 节的 curl 命令测一次，通了再开 Codex。撞上报错就翻第 5 节，按顺序排查。接入文档里有更多工具的配置示例，遇到 auth.json 之外的场景可以去那里找对应片段。

最后留一个实用习惯：每次改完配置，先跑 curl 再开 Codex。curl 通了说明链路没问题，Codex 里再出问题就是客户端配置的事，两层分开排查，比混在一起猜要快得多。