1. 先搞清楚Chat、Work、Codex 里的 GPT-6 不是同一个东西很多人第一次看到 GPT-6 的发布消息第一反应是打开自己的 API 后台想确认是不是所有入口都换成了同一个模型。我一开始也这么想结果发现完全不是一回事。核心检索词先摆出来GPT-6 Sol 与 Luna 怎么选以及Chat、Work、Codex 的版本差异。这两个问题其实是同一个问题的两面——你得先知道每个入口背后跑的是什么才能谈选型。OpenAI 在 10 月 7 日的公告里说得很清楚这次 GPT-6 with Intelligent UI 的 rollout 主要发生在 ChatGPT 的 Chat 标签页。Plus、Pro、Business、Enterprise 从当天开始Free 和 Go 随后扩展。公告同时明确写到这次更新适用于 ChatGPT 的 Chat 体验Work 和 Codex 背后的模型不会因为这次发布而改变。这句话是整个选型逻辑的起点。Chat 里看到 GPT-6不等于 Work 和 Codex 也同步变成同一批 Chat 版本。它们是不同的产品入口有不同的模型选择器和不同的帮助文档。那 Sol 和 Luna 的区别在哪按官方公告在 ChatGPT 的 Chat 里Plus、Pro、Business、Enterprise 使用 GPT-6 SolFree 和 Go 使用 GPT-6 Luna。两者都面向日常对话调校但分层逻辑是按套餐走的。如果你只是在 Chat 里问问题、做解释、写方案、看 Intelligent UI那可以按套餐理解付费层级主要看 SolFree 和 Go 主要看 Luna。但如果你是在 Work、Codex 或其他 Agent 执行环境里做任务就不能只套用这个 Chat 规则而要看当前产品自己的模型选择器和帮助文档。Intelligent UI 又是什么官方说法是GPT-6 可以根据问题把文字、视觉和交互元素组合成更适合当前任务的回答。回答里可能出现图形、按钮、表单、图表或者一个能直接在对话里使用的小工具。对普通用户来说很直观问复杂概念时可能给可交互图解问行程、计划、计算时可能给一个更像工具的回答。但对开发者来说重点不是它会不会生成漂亮界面而是要区分两个层Chat 层用户在 ChatGPT Chat 里和 GPT-6 对话可能看到 Intelligent UI。Agent / Workspace 层用户在 Work、Codex 或 agent.space Workspace 里让 Agent 读文件、跑任务、改代码、整理资料。这两层不是同一个入口也不应该混写成一个 API 教程。我见过不少文章把 Chat 的发布公告直接推导成API 也换了这是典型的误读。实际选型可以这样看如果你要解释一个概念、做对比、生成一个临时交互工具优先在 Chat 里测试 GPT-6 的 Intelligent UI。如果你要处理代码库、文件、长任务、团队协作和可交付结果应该进入 Work、Codex 或 agent.space Workspace看当前实际可选的 Agent 和模型组合。如果你想比较 Sol 和 Luna 的差异不要只看名字。要把同一个任务拆成输入、目标、验收标准再分别记录速度、可读性、是否需要人工修改、是否能完成交付。这才是可复现的对比方法。做技术文章时建议避免这几种写法不要写免费用户已经稳定拥有 GPT-6只能说 Free 和 Go rollout 从官方公告所述时间开始扩展是否看到取决于账号和 rollout。不要写Work 和 Codex 已自动换成这次 Chat 版本官方公告说这次发布不改变 Work 和 Codex 背后的模型。不要写agent.space 已上线 GPT-6 Intelligent UI除非页面实际显示了对应选项。不要写未经官方确认的价格、额度、SDK 参数或隐藏模型 ID。对开发者最实用的做法是把任务分成三类第一类Chat 解释型任务概念解释、方案对比、轻量工具生成。适合测试 GPT-6 Chat 和 Intelligent UI。第二类Agent 执行型任务改文件、查仓库、整理长资料、生成可交付物。适合在 Work、Codex 或 agent.space Workspace 当前可选 Agent/模型里测。第三类产品接入型任务API 参数、模型 ID、额度、价格、地区限制。这一类必须等官方 API 或帮助文档明确不能靠发布公告推导。所以这次 GPT-6 rollout 的关键不是所有入口都换代了而是Chat 体验先获得 GPT-6 和 Intelligent UISol 与 Luna 在 Chat 里按套餐分层Work、Codex 的版本要单独看当前产品说明Agent 工作流要以实际可选模型和可验证任务结果为准。2. TaoToken 前置统一 Key 与 API 通道怎么准备在讲具体配置之前先把 TaoToken 的接入逻辑说清楚。你可以把它理解成一个统一的 API 通道不管你要调的是 Chat 类模型、Codex 类编码模型还是 Work 类 Agent 任务都可以通过同一套 Base URL 和 Key 来管理。官网入口在这里https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI 地址是https://taotoken.net/api注意 API 地址不加 UTM 参数直接写就行。你需要准备的东西其实就三样第一一个可用的 API Key。去控制台创建路径是 console 页面。创建完之后复制出来后面配置里要用。第二确认你要调的模型 ID。这一步最容易出错。不同入口对应的模型 ID 可能不一样Chat 类、Codex 类、Work 类各有各的标识。不要凭猜测填要去文档里查当前可用的模型列表。第三选一个客户端或工具来发请求。你可以用 curl 直接测也可以用 Codex、Cline、Claude Code 这类工具来接入。下面我会分别给配置示例。这里有个关键点TaoToken 的 Base URL 是统一的但模型 ID 是分场景的。你不能拿 Chat 的模型 ID 去填 Codex 的配置反过来也一样。这就是为什么第一篇要先讲清楚 Chat、Work、Codex 的版本差异——配置之前先搞清楚你要调的是哪一类。如果你还没创建 Key先去 API Keys 页面生成一个。路径是 api-keys。生成的时候注意权限范围如果你只是测试给最小权限就行。文档入口在这里doc。里面有完整的模型列表和参数说明配置前建议先扫一遍。另外如果你打算长期做编码或 Agent 任务可以看一下 Coding Plan 页面。它针对的是持续性的编码场景和单次 API 调用是两种用法。模型对话入口在这里模型对话。如果你想先在网页里试一下模型效果再决定要不要接入 API可以从这里开始。Claude Code 相关的接入说明在 ClaudeCodeAnthropic 页面如果你用的是 Claude Code 做编码配置方式会稍有不同后面我会单独讲。总结一下前置准备一个 Key、一个确认过的模型 ID、一个客户端。三样齐了就能开始配。3. 可复制配置Base URL、auth.json 与 settings 片段这一节是全文最核心的部分所有配置都可以直接复制。我会按工具类型分开写你按自己用的工具选对应的片段。3.1 通用 Base URL 与 Key 配置不管你用什么工具Base URL 都是https://taotoken.net/apiKey 从你的控制台复制格式通常是一串以特定前缀开头的字符串。不要把它提交到 Git 仓库里用环境变量管理。如果你用 curl 测试命令是这样的curl https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -d { model: 你的模型ID, messages: [ {role: user, content: 用一句话解释什么是统一 API 通道} ] }把$TAOTOKEN_API_KEY换成你实际的 Key你的模型ID换成文档里确认过的 ID。3.2 Codex auth.json 配置如果你用 Codex 类工具配置文件通常在~/.codex/auth.json。内容结构是这样的{ base_url: https://taotoken.net/api, api_key: 你的Key, model: 你的模型ID }三件套齐了Base URL、Key、Model ID。缺一个都跑不起来。注意base_url不要带末尾斜杠有些客户端对斜杠敏感带了会拼出双斜杠导致 404。3.3 Cline MCP 配置如果你用 Cline 并且走 MCP 通道配置片段是这样的{ mcpServers: { taotoken: { command: npx, args: [-y, 你的MCP包名], env: { TAOTOKEN_BASE_URL: https://taotoken.net/api, TAOTOKEN_API_KEY: 你的Key, TAOTOKEN_MODEL: 你的模型ID } } } }同样三件套Base URL、Key、Model ID。MCP 配置里这三个值必须和文档一致不要自己改路径。3.4 Claude Code settings 片段如果你用 Claude Codesettings 文件通常在~/.claude/settings.json或项目级的.claude/settings.json。配置片段{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: 你的Key, ANTHROPIC_MODEL: 你的模型ID } }Claude Code 用的是 Anthropic 兼容格式所以环境变量前缀是ANTHROPIC_。这一点和 Codex 不一样别搞混。3.5 CC Switch 配置如果你用 CC Switch 做多配置切换配置结构大概是[[profiles]] name taotoken base_url https://taotoken.net/api api_key 你的Key model 你的模型IDTOML 格式注意引号字符串值都要用双引号包起来。所有配置的共同点Base URL 统一是https://taotoken.net/apiKey 从控制台拿Model ID 从文档查。三个值填对基本就能通。4. 验证请求与返回对比各端点怎么测配置写完不代表能用必须发一次真实请求验证。这一节我按端点类型分别给验证方法。4.1 Chat 类端点验证Chat 类请求走/v1/chat/completions这是最通用的格式。验证命令curl -s https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -d { model: 你的Chat模型ID, messages: [{role: user, content: 回复OK两个字母}], max_tokens: 10 } | jq .成功返回的结构里会有choices数组第一个元素的message.content就是模型回复。如果你看到choices是空数组或者报错说明配置有问题。4.2 Codex 类端点验证Codex 类请求通常也走 chat completions 格式但模型 ID 不同。验证时把 model 换成 Codex 对应的 IDcurl -s https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -d { model: 你的Codex模型ID, messages: [{role: user, content: 写一个 Python 的 hello world}], max_tokens: 50 } | jq .choices[0].message.content返回应该是一段 Python 代码。如果返回的是普通对话而不是代码说明模型 ID 填错了你调到的可能是 Chat 类模型。4.3 Work / Agent 类端点验证Work 类任务通常需要多轮交互或工具调用验证时可以先发一个简单任务curl -s https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -d { model: 你的Work模型ID, messages: [{role: user, content: 把这句话拆成三个待办项整理文档、写测试、发版本}], max_tokens: 100 } | jq .choices[0].message.content返回应该是一个结构化的待办列表。如果返回的是泛泛而谈的对话说明模型选择不对。4.4 返回对比要点验证的时候重点看三个东西第一choices数组是否非空。空数组通常意味着请求格式有问题或者模型 ID 不存在。第二message.content是否符合预期。Chat 类应该给对话式回答Codex 类应该给代码Work 类应该给结构化输出。第三HTTP 状态码。200 是成功401 是 Key 问题404 是路径或模型 ID 问题429 是限流。我实测下来最常见的失败是模型 ID 填错。因为不同入口的模型 ID 长得像但不一样复制的时候容易拿错。建议每次配置完都发一次验证请求确认返回符合预期再往下走。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth这一节列的都是真实会遇到的报错按报错信息对照排查。5.1 401 Unauthorized报错原文通常是{error:{message:Invalid API key,type:invalid_request_error}}原因就一个Key 不对。可能是复制的时候带了空格可能是 Key 过期了也可能是环境变量没生效。排查步骤先echo $TAOTOKEN_API_KEY看环境变量有没有值。如果没有说明没 export 成功。如果有值检查前后有没有空格。还不行就去控制台重新生成一个 Key。5.2 local proxy failed报错原文local proxy failed: dial tcp 127.0.0.1:xxxx: connect: connection refused这个报错说明你的客户端在尝试连本地代理但本地没有服务在跑。常见于客户端配置里写了http://127.0.0.1:端口但代理没启动。排查检查客户端配置里的 Base URL 是不是写成了本地地址。应该写https://taotoken.net/api不要写 localhost。5.3 reading choices 相关报错报错原文error reading choices: unexpected end of JSON input或者cannot read property choices of undefined这个通常是返回体不是合法 JSON或者返回结构里没有choices字段。原因可能是请求路径写错了比如少写了/v1或者模型 ID 不存在导致返回了错误结构。排查先用 curl 直接发一次看原始返回是什么。如果返回的是 HTML 而不是 JSON说明路径错了。如果返回的 JSON 里没有choices看error字段写了什么。5.4 OAuth 相关报错报错原文OAuth token expired或者failed to refresh OAuth token这个出现在用 OAuth 方式认证的客户端里。如果你用的是 API Key 方式不应该出现这个报错。出现了说明客户端还在走 OAuth 流程没切到 Key 认证。排查检查客户端配置里是不是同时存在 OAuth 配置和 Key 配置。把 OAuth 相关的字段删掉只保留 Base URL、Key、Model ID 三件套。5.5 模型 ID 不存在报错原文model not found: xxx这个最直接你填的模型 ID 不在可用列表里。去文档页面查当前可用的模型 ID复制准确的字符串。注意大小写敏感gpt-6-sol和GPT-6-Sol可能被当成两个不同的 ID。5.6 排查通用流程遇到任何报错按这个顺序走第一步确认 Base URL 是https://taotoken.net/api没有多余斜杠没有 localhost。第二步确认 Key 有效用 curl 直接测一次。第三步确认模型 ID 从文档复制没有拼写错误。第四步看 HTTP 状态码401 查 Key404 查路径和模型429 查限流。第五步如果还不行把原始请求和原始返回都打出来对照文档逐字段检查。6. 按场景定版Chat、Work、Codex 的选型建议与接入入口回到最初的问题GPT-6 Sol 与 Luna 怎么选Chat、Work、Codex 的版本差异怎么处理。我的建议是按任务类型定版而不是按模型名字定版。Chat 解释型任务概念解释、方案对比、轻量工具生成。这类任务优先在 Chat 里测 GPT-6 的 Intelligent UI。付费层级看 SolFree 和 Go 看 Luna。如果你要接入 API 做类似任务用 Chat 类模型 ID。Agent 执行型任务改文件、查仓库、整理长资料、生成可交付物。这类任务不要套用 Chat 的模型规则要看 Work、Codex 或 agent.space Workspace 当前实际可选的 Agent 和模型组合。接入时用对应的 Codex 或 Work 类模型 ID。产品接入型任务API 参数、模型 ID、额度、价格、地区限制。这一类必须等官方 API 或帮助文档明确不能靠发布公告推导。接入前先去文档页面确认当前可用的模型列表和参数。具体接入入口排障和接入相关去 API Keys 页面拿 Key去接入文档页面查参数。验证模型效果去模型对话页面先试再接。长期编码或 Agent 任务去 Coding Plan 页面看持续性方案。Claude Code 用户去 ClaudeCodeAnthropic 页面看专用配置说明。配置的时候记住三件套Base URL 是https://taotoken.net/apiKey 从控制台拿Model ID 从文档查。三个值填对请求就能通。最后说一个我踩过的坑不要拿 Chat 的模型 ID 去填 Codex 的配置。这两个入口的模型是分开的填错了不会报错但返回的结果类型不对——你以为是 Codex 在写代码其实是 Chat 在聊天。验证的时候一定要看返回内容是否符合预期不要只看 HTTP 200 就以为成功了。