1. 为什么你用 Codex 越用越费两种工作模式的额度逻辑先说我的真实经历。上个月我打算清理一个老项目的测试用例想着这种事顺手交给 Codex 就好。结果干了一天Codex 的额度肉眼可见地掉了一大截而实际改动就只有两个函数、三条测试。后来我仔细翻了一遍 Codex CLI 的登录方式和计费差异才发现问题出在一个非常隐蔽的地方我全程用的是 API Key 模式而且模型被调成了高阶试验模型每次交互都在真实计费。Codex CLI 本身支持两种身份登录这是理解“省额度”最核心的一步。1.1 两种登录方式对应的计费规则Codex CLI 在初始化时会让你选登录方式最常见的是这两类登录方式额度来源模型范围适合做什么ChatGPT 账号codex login 里选 ChatGPT走你 ChatGPT 订阅套餐内的用量逻辑只支持订阅账户可用的常规模型日常改文件、跑测试、读仓库API Keycodex login 里选 OpenAI API Key按 Codex credits 或 API 余额消耗全部模型包括 gpt-5.6-sol 这类试验模型复杂重构、跨仓库分析、批量任务很多人和我一样装完 Codex 之后顺手就把 API Key 填进去了然后所有任务都从这个入口走。API Key 模式的计费是实打实的每发起一次请求、每跑一段命令都可以换算成 credits。如果模型再选成高阶试验版本几次会话下来当天的额度就光了。而 ChatGPT 账号登录模式走的是另一套路径它先验证你的订阅身份再在订阅允许的范围内调用标准模型。日常操作完全可以用这个通道完成额度压力小得多。这也解释了为什么社区里常有人说“普通聊天也能改仓库”本质就是用订阅权益去顶替按量计费。1.2 模型选择是烧额度与否的分水岭另一个容易忽略的地方是模型名。Codex CLI 的模型不是随便写的它必须和你的登录身份匹配。比如热搜里那条报错the gpt-5.6-sol model is not supported when using codex with a chatgpt acc翻译过来就是你用了 ChatGPT 账号登录但配置里指定了 gpt-5.6-sol 这个模型而这个模型在 ChatGPT 账号模式下不允许使用。为什么不允许因为 gpt-5.6-sol 属于试验性高阶模型它的运行成本很高OpenAI 把它放到了按量计费的通道里。你要真想在 ChatGPT 账号模式下用系统直接拒绝防止你把高阶模型的成本转嫁到订阅服务上。反过来说如果你一直在 API Key 模式下工作config.toml 里写的是 gpt-5.6-sol那每次操作都会按这个模型的单价计费。省钱的第一步就是在 config.toml 里把模型名改成订阅可用的常规模型然后把日常会话切到 ChatGPT 账号模式。1.3 什么任务该走订阅会话什么任务该走 Codex 额度不是所有任务都适合切到 ChatGPT 账号模式。我自己总结了一个任务分流表你可以拿它当参考任务类型推荐通道原因修改单个函数、修复单条报错ChatGPT 账号模式轻量常规模型足够跑一遍测试并自动修复ChatGPT 账号模式流程固定不需要高阶推理跨多个文件的结构性重构API Key 模式需要更强的上下文理解从零搭建一个模块API Key 模式涉及架构判断常规模型容易跑偏批量处理几十个文件API Key 模式耗时长按量结算反而可控我的建议是百分之八十的任务都不需要 Codex 专属额度先用 ChatGPT 账号模式试一遍跑不通再升级通道。这样既保住了额度又不会因为节省而牺牲复杂任务的完成质量。2. 把普通 ChatGPT 会话真正接到 GitHub 仓库上很多人对“普通聊天连接 GitHub”有一个误解以为是在网页版 ChatGPT 聊天框里贴一个 GitHub 链接它就能直接改仓库。不是这样的。网页版聊天没有文件系统访问权限也执行不了测试命令。真正能实现这个效果的是 Codex CLI它相当于一座桥把 ChatGPT 的自然语言理解能力接到本地 git 仓库上。这里的“普通聊天”指的是使用你 ChatGPT 订阅账号登录 Codex CLI 后的交互式会话而不是网页聊天。下面我把整套流程拆开讲。2.1 准备一套最小的工具链要跑通这条路你需要三样东西Node.js、Codex CLI、GitHub CLI。Codex CLI 官方推荐用 npm 安装要求 Node 18 以上。安装命令很简单npm install -g openai/codex如果你在 macOS 上并且装了 Homebrew也可以用brew install codex接着安装并登录 GitHub CLICodex 操作远程仓库时会用到它的认证信息brew install gh gh auth logingh 登录的时候会让你选协议我建议选 HTTPS然后走浏览器授权。整个过程大概两分钟。装完之后在终端里确认一下版本都能正常输出版本号再继续。这里有个很容易忽略的细节Codex 操作的是你本地的 git 仓库它本身不直接对话 GitHub API而是靠 git 命令和本地凭证。所以只要你本地能正常 clone、push 仓库Codex 就能正常工作。2.2 用 ChatGPT 账号完成 Codex CLI 登录工具链准备好之后开始登录 Codex。在终端里执行codex login它会列出登录方式这时候选 ChatGPT 而不是 API Key。选完之后会弹出浏览器让你授权当前账号。授权成功后终端会显示登录成功并且在~/.codex/auth.json里写入凭证信息。之后每次启动 Codex它都会自动读取这个凭证不再要求重复登录。有一点要注意如果你之前已经用 API Key 登录过再次执行codex login时它会提示当前有活跃认证让你确认是否切换。我建议日常默认保留 ChatGPT 账号登录状态只在需要跑高阶模型的时候再临时切到 API Key。2.3 配置 config.toml别让它报错登录完成后Codex 会自动生成一个~/.codex/config.toml配置文件。很多报错都出在这个文件上比如热搜里的“chatgpt 无法加载 config.toml, 因此此对话串无法继续。请修复 config.toml:model”。我刚用的时候也踩过这个坑原因是配置文件里的 model 字段写了一个 ChatGPT 账号模式不支持的模型名。一个能稳定工作的最小配置长这样model gpt-5.3 sandbox_mode workspace-writemodel 字段指定会话使用的模型。在 ChatGPT 账号模式下只能填订阅可用的常规模型千万不要写 gpt-5.6-sol 这类高阶试验模型。sandbox_mode 字段控制 Codex 在什么权限范围内运行命令。workspace-write 表示它可以在当前工作区里写文件但不能动工作区之外的东西。我的经验是配置好后先启动一次codex确认能正常进入对话界面再继续。如果启动时报错优先看 model 字段十个报错里八个是这个导致的。2.4 让会话操作仓库改文件、跑测试的完整流程配置没问题之后就可以开始实际操作了。假设我要修一个叫devtools的仓库流程是这样的第一步把仓库克隆到本地并进入目录git clone gitgithub.com:yourname/devtools.git cd devtools第二步在仓库根目录启动 Codexcodex第三步用自然语言描述你要做的事。比如我想修改src/utils.py里的配置解析函数让它遇到配置文件缺失时返回默认配置而不是抛异常我直接输入请修改 src/utils.py 中的 parse_config 函数当配置文件不存在时返回默认配置对象不要抛异常。Codex 会先读这个文件分析现有实现然后给出修改方案。因为它处于交互式会话中改文件前它会先展示将要执行的写操作等你确认后才落地。第四步跑测试。改完文件之后继续输入请运行 pytest tests/test_utils.py -x如果失败就继续修复直到通过。Codex 会在沙箱里执行 pytest 命令把输出结果反馈到会话里。如果测试失败它会自动定位到报错点再次修改代码并重新跑测试。整个过程就像和一个懂代码的同事对话。第五步确认改动并提交git diff git add . git commit -m fix: parse_config returns default when config missing这里我强烈建议养成先看 diff 再提交的习惯。Codex 改完代码后不一定完全符合你的预期看一遍 diff 能避免把错误的改动合进去。3. 省钱的关键策略四个习惯让额度慢下来通道选对了额度消耗已经大幅下降。但如果你想让 Codex credits 彻底慢下来还需要在日常使用里养成几个习惯。这四条是我踩过不少坑之后总结出来的每条背后都有真实教训。3.1 固定模型、别轻易升级config.toml 里的 model 字段一旦配置好就尽量不要频繁改动。我见过太多人今天听说某个新模型很强立刻把 model 改成新模型然后跑一个日常小任务额度瞬间没了一片。正确做法是给日常会话固定一个常规模型只在确有必要时才切换到高阶模型。切换也要用完就切回来不要一直留在高位运行。我自己的操作是维护一份config.toml备份日常用常规模型配置做复杂任务时复制一份临时改名启用做完再换回来。3.2 用好 sandbox 规则别让自动执行失控sandbox 是 Codex 的安全机制也是省钱机制。它控制 Codex 能在什么范围内执行命令。我用过的几种模式区别很明显sandbox_mode含义典型用途read-only只能读文件不能写先让 Codex 分析问题、给方案workspace-write可以写当前工作目录日常改代码、跑测试danger-full-access无限制访问整个系统需要跨目录操作的复杂场景刚开始我图省事直接用 danger-full-access结果 Codex 在一个本不该修改的目录里自动生成了大量临时文件还反复执行了几十轮命令。虽然最终任务完成了但资源消耗非常夸张。现在我的习惯是先让 Codex 在 read-only 模式下分析代码并给出修改思路确认方案可行后再切换到 workspace-write 让它落地改动。测试命令也一样强制它只在工作区内跑别往系统其他目录乱伸爪子。3.3 断点续跑比开新会话省得多Codex 支持断点续跑也就是把之前那个会话继续下去。命令很简单codex resume如果你用codex exec模式跑单次任务想接续上一次的上下文可以加codex exec --continue 继续修复刚才失败的测试为什么要强调这个因为每次新开一个 Codex 会话它都要重新读取仓库结构、文件内容和之前的操作历史这些信息都会产生不小的消耗。而续跑延续上一次的上下文Codex 已经知道文件里有什么、改过什么不需要重新加载省下的就是这部分重复成本。我经历过一次特别肉的教训同一个测试问题我开了五个新会话去修每个会话都把仓库读一遍最后还不如第一个会话多聊几句来得快。从那之后只要任务没有彻底结束我都用 resume 继续。3.4 交互式确认优先full-auto 慎开Codex 提供了--full-auto模式在这个模式下它会自动执行所有操作不再等待用户确认一口气跑到任务结束。听起来很爽但对额度非常不友好。全自动意味着它会在缺少人工判断的情况下做很多多余操作比如不必要的文件读取、多余的测试执行、反复尝试失败的方案。交互式会话则不同每一步它都会停下来跟你确认比如“是否允许修改这个文件”“是否允许运行这条命令”。你可以在关键节点及时叫停省掉无谓的操作。我的建议只有在完全可信的 CI 场景下比如本地持续集成管道里自动修格式化问题才用 full-auto。日常开发一律交互式。4. 实操中经常踩的坑与排查实录无论配置多小心实操中总会碰上几个报错。我把最近几个月遇到的高频问题整理出来按“错误表现、原因、解决办法”的方式列清楚方便你直接速查。4.1 config.toml 加载失败的修复错误信息长这样chatgpt 无法加载 config.toml因此此对话串无法继续。请修复 config.toml:model。这个报错几乎是模型名导致的。可能的原因有三个模型名拼写错误、模型名在当前登录方式下不可用、配置文件里混入了手工编辑的非法字段。排查步骤我建议这样做先备份当前配置cp ~/.codex/config.toml ~/.codex/config.toml.bak把配置文件清空只留最基础的model和sandbox_mode两行重新启动codex如果正常说明是原来配置里某个字段写坏了恢复备份逐行注释掉可疑字段重启验证这个方法本质是二分定位比对着报错瞎猜快得多。合入新字段之前先想清楚它到底做什么很多配置项不是所有模型都支持。4.2 高阶模型在 ChatGPT 账号下报错原话是the gpt-5.6-sol model is not supported when using codex with a chatgpt acc。这个问题我在第一节已经解释过原理这里直接说解决办法。如果你确实要用 gpt-5.6-sol就需要切到 API Key 模式并把 config.toml 里的 model 改成 gpt-5.6-sol。如果你只是想省额度那就把 model 改回订阅可用的常规模型继续用 ChatGPT 账号模式。操作上不要只改模型名要连登录方式一起检查。很多时候你改了 model 还是报错是因为当前活跃的认证方式还是 ChatGPT 账号没有切换干净。切模式最稳妥的办法是删掉~/.codex/auth.json后重新执行codex login彻底刷新认证状态。4.3 本地代理报错怎么查排查实录里有一条常见的cc switch local proxy failed while handling codex endpoint /responses。这个报错出现在 Codex 需要经过本地代理访问 API 的时候。最常见的情况是代理端口切换了但 Codex 配置里还留着旧端口。比如你平时用 7890 端口某次换成 7891Codex 启动时按旧端口去连自然就失败了。处理思路分几步确认当前本地代理实际监听的端口是多少这个可以在对应工具的运行日志里看在启动 Codex 之前检查当前 shell 环境变量里有没有指定代理相关变量比如 HTTP_PROXY、HTTPS_PROXY如果配置里写死了代理地址改成当前实际端口清掉 Codex 的临时状态后重启我不建议在 Codex 的配置文件里长期写死代理端口因为开发环境端口经常漂移写死意味着每次切换都要手动改文件。更稳妥的做法是让代理工具固定端口或者在启动 Codex 时动态注入环境变量。4.4 GitHub 仓库拉取异常的处理思路还有一类问题跟 GitHub 访问相关比如 clone 仓库一直失败、Codex 在读远程仓库时超时。这类问题首先要确认的是本地 git 环境本身是否正常而不是急着怪 Codex。排查顺序我从上到下排一下检查项命令说明gh 认证是否有效gh auth status确认登录凭证没过期SSH key 是否加载ssh -T gitgithub.com如果走 SSH 协议确认能握手远程地址是否正确git remote -v确认 clone 用的是你自己的仓库地址网络能否稳定访问尝试git ls-remote gitgithub.com:yourname/devtools.git能列出来说明网络通大多数拉取异常都出在认证环节尤其是 SSH key 过期或者 gh 登录状态失效。还有一种情况是你尝试 clone 的仓库本身不存在或者你没有权限访问。这时候随便怎么等都不会成功。另外一个实用技巧是如果 clone 一直不稳定可以先把仓库以压缩包形式下载到本地解压然后执行git init和git remote add origin ...重新绑定远程地址。这样绕过了 clone 过程的网络开销Codex 照样能在本地仓库里工作。这个方法不算最优但确实能在环境受限时救急。最后分享一个我自己的配置模板说了这么多我把目前每天都在用的 config.toml 配置分享出来你可以直接参考model gpt-5.3 sandbox_mode workspace-write [chat] auto_send falseauto_send false的意思是每次会话不会自动把内容发送给模型需要你按确认键才发送。这个设置看似多了一步操作但能有效防止误触发尤其适合开着多个终端窗口干活的时候。我现在的日常流程已经固定成小改动和测试修复走 ChatGPT 账号模式gpt-5.6-sol 这类高阶模型留给真正复杂的重构任务。每周我会抽五分钟检查一次~/.codex/config.toml和认证状态确保没被之前临时切换的配置污染。这样坚持了一个月Codex credits 的消耗量降到了原来的四分之一左右日常工作效率反而更高了——因为不需要频繁纠结额度问题可以放心让 Codex 去改文件、跑测试。如果你也正在为 Codex 额度发愁先从改 config.toml 的 model 字段开始再慢慢调整自己的使用习惯这个路子基本不会错。