1. AutoDL 新实例里为什么先配 Codex 再谈 ChatGPT 客户端
刚在 AutoDL 开好一台新实例，第一件事往往不是跑训练，而是想先把 AI 编码和对话能力接上。但新手最容易卡住的地方在于：ChatGPT 客户端和 VSCode 里的 Codex 扩展，默认都要求你登录官方账号，而服务器实例里既没有浏览器，也不方便走交互式登录。这时候用统一 Key 接入就是最省事的路径——一次拿到 Base URL 和 API Key，客户端和扩展共用同一套凭据，换实例时复制两个文件就能恢复。
这篇面向完全新手，目标很明确：在 AutoDL 新开的服务器实例里，用 TaoToken 统一 Key 快速完成 ChatGPT 客户端与 VSCode Codex 扩展的 API 登录配置。我会给出可以直接复制的config.toml、auth.json片段，以及连通性验证命令，让你在实例初始化阶段一次性跑通。
先说清楚两个概念，避免后面混淆。ChatGPT 客户端指的是桌面端对话程序，它读取的是用户目录下的.codex配置；VSCode Codex 扩展则是编辑器里的编码助手，它同样读取.codex目录下的config.toml和auth.json。两者共用同一套文件结构，所以配置逻辑是一致的：告诉它请求发往哪个 Base URL，用哪个 Key，调哪个模型。
适合谁看？三类人最合适。第一类是完全没配过 API 的新手，想跳过官方登录直接跑通；第二类是频繁更换 AutoDL 实例的人，每次重开都要重新配环境，手动点扩展等重启太慢；第三类是想把对话和编码统一到一个 Key 下管理的人，省得记多套凭据。
我试过在 AutoDL 上反复开实例，最深的体会是：扩展的图形化配置经常要等它自己生成文件，慢且不稳定。与其等，不如自己手动创建config.toml和auth.json，保存后直接生效，这是最快的方式。下面按「先拿 Key，再配客户端，再配扩展，最后验证」的顺序走。
2. TaoToken 统一 Key 的前置准备与 Base URL 确认
在动手改任何配置文件之前，先把两样东西拿到手：Base URL 和 API Key。这两个是后面所有配置的核心，缺一个都跑不通。
Base URL 是请求的入口地址，所有模型调用都发到这里，由它转发到具体模型。TaoToken 的 API 入口是https://taotoken.net/api，注意这个地址不带任何查询参数，直接用它作为base_url的值即可。API Key 则是你的身份凭据，一般以sk-开头，在控制台里创建。
获取 Key 的路径是这样的：先打开官网 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，注册并登录后进入控制台。控制台里找到 API Keys 管理页，新建一个 Key，复制出来保存好。这个 Key 只显示一次，丢了就得重建，所以复制后先贴到记事本里。
如果你还没决定用哪个模型，可以先在模型对话页面试一下，确认账号和额度正常。模型对话入口在这里：https://taotoken.net/api?utm_source=taotoken_aicg_blog_end&utm_content=model_chat&utm_campaign=rewrite 。在网页里发一条消息，能正常返回就说明 Key 和额度都没问题，再去配本地文件会更有底。
对于长期要在 AutoDL 上跑编码和 Agent 任务的人，建议直接看 Coding Plan，它更适合高频调用场景：https://taotoken.net/api?utm_source=taotoken_aicg_blog_end&utm_content=coding_plan&utm_campaign=rewrite 。控制台地址是 https://taotoken.net/api?utm_source=taotoken_aicg_blog_end&utm_content=console&utm_campaign=rewrite ，API Keys 管理页是 https://taotoken.net/api?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite ，接入文档在 https://taotoken.net/api?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite 。
这里要提醒一个新手常犯的错：把 Base URL 写成带/v1或带其他路径的形式。TaoToken 的入口就是https://taotoken.net/api，不要自己拼接。另外，Key 不要写进会提交到 Git 的文件里，AutoDL 实例虽然是临时的，但养成好习惯没坏处。
准备好这两样后，先确认实例能正常访问外网。在 AutoDL 的终端里执行一条最简单的连通性测试：
curl -s -o /dev/null -w "%{http_code}\n" https://taotoken.net/api如果返回 200 或 401 之类的 HTTP 状态码，说明网络通；如果卡住或报连接失败，先检查实例的网络配置。这一步很关键，因为后面所有配置都依赖网络可达。确认无误后，再进入文件配置环节。
3. 可复制的 config.toml 与 auth.json 配置片段
这一节是全文的核心，给出可以直接复制的配置。无论你是配 ChatGPT 客户端还是 VSCode Codex 扩展，用的都是同一套文件：config.toml和auth.json，放在.codex目录下。
先确认目录位置。在 Windows 上，路径是C:\Users\你的用户名\.codex，其中「你的用户名」每个人不同，比如示例里的Q。在 AutoDL 的 Linux 实例里，路径是~/.codex，也就是/root/.codex。VSCode Codex 扩展在远程连接 AutoDL 时，读取的是实例里的~/.codex目录。
如果目录不存在，手动创建：
mkdir -p ~/.codex然后创建config.toml，内容如下。注意把base_url换成 TaoToken 的入口地址，model换成你要用的模型 ID：
model_provider = "my_codex" model = "gpt-6.1-sol" [model_providers.my_codex] name = "my_codex" base_url = "https://taotoken.net/api" wire_api = "responses" requires_openai_auth = true这里逐项解释一下。model_provider指定用哪个 provider，名字要和下面[model_providers.my_codex]对应。model是默认调用的模型 ID，具体填什么以接入文档里的模型列表为准。base_url就是前面确认的 TaoToken 入口。wire_api = "responses"表示走 Responses 协议，Codex 扩展依赖这个。requires_openai_auth = true表示需要鉴权，配合auth.json里的 Key 使用。
接着创建auth.json，把sk-开头的 Key 填进去：
{ "OPENAI_API_KEY": "sk-你的实际Key" }保存这两个文件。在 Linux 下可以用cat写入，避免编辑器换行符问题：
cat > ~/.codex/config.toml <<'EOF' model_provider = "my_codex" model = "gpt-6.1-sol" [model_providers.my_codex] name = "my_codex" base_url = "https://taotoken.net/api" wire_api = "responses" requires_openai_auth = true EOF cat > ~/.codex/auth.json <<'EOF' { "OPENAI_API_KEY": "sk-你的实际Key" } EOF写完检查一下权限，避免其他用户读到 Key：
chmod 600 ~/.codex/auth.json如果你在 Windows 桌面端配 ChatGPT 客户端，操作一样，只是路径换成C:\Users\你的用户名\.codex，用记事本或 VSCode 编辑，改完记得 Ctrl+S 保存。保存这一步新手最容易漏，文件没存盘，后面怎么试都不生效。
配置完成后，Codex 扩展和 ChatGPT 客户端都会读取这两个文件。扩展那边不需要再点图形化登录，直接打开侧边栏就能用。这就是手动创建文件比等扩展自动生成更快的原因——省掉了重启和等待。
4. 连通性验证与成功结果确认
文件配好了，但还不能确定一定通。这一步用命令验证，把问题挡在打开客户端之前。
最直接的验证是发一条真实的模型请求。用curl调 TaoToken 的接口，确认 Key 和 Base URL 都正确：
curl https://taotoken.net/api/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer sk-你的实际Key" \ -d '{ "model": "gpt-6.1-sol", "messages": [{"role": "user", "content": "ping"}] }'如果返回一段 JSON，里面有choices字段和模型回复内容，说明 Key、Base URL、模型 ID 三者都对。如果返回 401，是 Key 的问题；返回 404，多半是模型 ID 写错或路径不对；返回连接超时，是网络问题。
对于 Codex 扩展，验证方式是打开 VSCode，连接 AutoDL 实例，点开侧边栏的 Codex 图标。如果配置正确，它会直接进入可用状态，输入框能正常发消息并收到回复。如果它提示登录或报错，先检查~/.codex/config.toml和~/.codex/auth.json是否存在、内容是否正确。
再给一个检查文件内容的命令，确认没写错：
cat ~/.codex/config.toml cat ~/.codex/auth.json重点看三处：base_url是不是https://taotoken.net/api，model是不是有效模型 ID，auth.json里的 Key 是不是sk-开头且完整。很多时候问题就出在多了一个空格、少了一个引号，或者 Key 复制时带了换行。
成功的结果长这样：curl返回带choices的 JSON；VSCode Codex 侧边栏能正常对话；ChatGPT 客户端打开后能直接发消息。三者都通，说明这套统一 Key 配置在 AutoDL 新实例上完全跑通了。整个过程从开实例到验证完成，熟练后五分钟内能搞定。
5. 常见报错排查：401、local proxy failed 与 reading choices
配置过程中有几类报错特别常见，这里逐个对照排查。先记住一个原则：报错先看是鉴权问题、网络问题还是文件格式问题，三类对应不同解法。
第一类，401 Unauthorized。这是 Key 的问题。可能原因有三个：Key 复制不完整，比如漏了尾部字符；Key 前后带了空格或换行；Key 已失效或被删除。排查方法是重新从控制台复制一次 Key，用cat ~/.codex/auth.json确认文件里只有一行合法的 JSON，没有多余字符。注意auth.json必须是合法 JSON，键名是OPENAI_API_KEY，值用双引号包住。
第二类，local proxy failed 或连接被拒绝。这通常是网络或 Base URL 的问题。先确认base_url写的是https://taotoken.net/api，没有多余路径。再用前面的curl命令测试网络可达性。如果curl也失败，说明实例网络有问题，检查 AutoDL 实例的网络设置。如果curl成功但扩展报这个错，多半是扩展缓存了旧配置，重启 VSCode 或重新加载窗口即可。
第三类，reading choices 相关报错，比如解析响应时找不到choices字段。这通常是模型 ID 写错，或者wire_api配置不匹配。Codex 扩展依赖wire_api = "responses"，如果写成别的值，响应格式对不上就会报这个错。检查config.toml里这一行是否存在且正确。另外确认model填的是接入文档里支持的模型 ID，拼错一个字符都会导致请求失败。
第四类，OAuth 相关报错，提示需要登录或授权。这说明扩展还在走官方登录流程，没读到你的auth.json。原因是文件位置不对或文件名不对。确认路径是~/.codex/auth.json（Linux）或C:\Users\你的用户名\.codex\auth.json（Windows），文件名大小写要完全一致。如果目录下同时存在旧的登录缓存，可以先备份再清理，让它重新读取。
第五类，配置文件不生效。最常见的原因是保存失败或路径写错。用ls -la ~/.codex/确认两个文件都在，且修改时间是刚才。如果用了 VSCode 远程编辑，注意保存的是实例里的文件，不是本地的。还有一个坑：Windows 记事本保存config.toml时可能加 BOM 头，导致解析失败，建议用 VSCode 编辑并确认编码是 UTF-8 无 BOM。
排查顺序建议固定下来：先curl验证 Key 和网络，再cat检查文件内容，最后重启扩展。按这个顺序，九成问题都能定位。如果都正常还是不通，去接入文档核对最新的 Base URL 和模型 ID，避免用了过时的信息。
6. 把统一 Key 固化进新实例初始化流程
配通一次不算完，AutoDL 的价值在于频繁开新实例。如果每次都要手动重配，效率就没了。这一节讲怎么把这套配置固化下来，让新实例开出来就能用。
最简单的做法是把两个配置文件存成模板，放在本地或对象存储里。新实例开好后，一条命令拉下来：
mkdir -p ~/.codex # 假设模板已上传到某处，用 scp 或 wget 拉取 # 然后修正 Key 和模型 ID更稳妥的方式是写一个初始化脚本，把创建目录、写入配置、设置权限三步打包：
#!/bin/bash mkdir -p ~/.codex cat > ~/.codex/config.toml <<'EOF' model_provider = "my_codex" model = "gpt-6.1-sol" [model_providers.my_codex] name = "my_codex" base_url = "https://taotoken.net/api" wire_api = "responses" requires_openai_auth = true EOF cat > ~/.codex/auth.json <<EOF { "OPENAI_API_KEY": "${TAOTOKEN_API_KEY}" } EOF chmod 600 ~/.codex/auth.json echo "Codex 配置完成"注意这里用环境变量TAOTOKEN_API_KEY注入 Key，避免把 Key 硬编码进脚本。在 AutoDL 实例里可以先export TAOTOKEN_API_KEY=sk-你的Key，再执行脚本。这样脚本本身可以安全地复用和分享。
对于 VSCode Codex 扩展，配置文件和 ChatGPT 客户端共用，所以脚本跑完，扩展也就配好了。打开 VSCode 连接实例，侧边栏直接可用，不需要再点登录。这就是「一次配置，两端通用」的好处。
如果你用的是 Claude Code 这类工具，配置逻辑类似，也是通过 Base URL 加 Key 的方式接入，具体参数看接入文档：https://taotoken.net/api?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite 。文档里有各客户端的配置示例，照着改 Base URL 和 Key 即可。
最后给一个实用技巧：把初始化脚本和模板文件放在实例的数据盘或持久化目录里，AutoDL 重开实例时如果挂载了同一块盘，配置能直接复用。这样从开实例到 AI 功能可用，基本就是执行一条脚本的事。验证方式还是老规矩，curl发一条请求，返回choices就说明一切正常。整套流程跑顺之后，换实例不再是负担，反而成了几分钟就能完成的常规操作。
