如果你也用 Codex 干活大概率经历过这种场景一个很小的改动模型却半天憋不出一个字光标在那转圈你刚接上的思路直接被掐断。慢是这类智能编程工具使用中绕不开的痛点。这篇不是官方文档的复述是我把 Codex 真正当成主力工具高强度使用一段时间后沉淀下来的性能调优笔记——从网络配置、上下文控制、模型选型到几个真实报错的完整排查过程基本覆盖了日常遇到的主要延迟来源和应对方案。已经跑通 Codex、但觉得响应总是拖泥带水的人认真看完应该能解决大部分卡顿问题。1. 慢在哪Codex请求链路上的三个延迟来源1.1 一次请求背后到底发生了什么先说一个很多人忽略的事实Codex 处理一个请求不是简单地把你的问题发给模型、等回复。它背后是一条完整的链路本地会话管理进程读取当前项目上下文 → 把历史消息、文件内容、工具输出组装成请求 → 网络传输到 API 服务 → 鉴权与路由 → 模型推理 → 结果流式返回 → 本地工具执行读文件、跑命令、改代码→ 工具输出再次回流给模型 → 模型生成下一轮结果。我在实际使用中见过不少伪慢场景有人在终端里输入问题后干等十几秒以为是模型推理慢打开日志一看请求根本没发出去卡在本地某个中间环节。也有人反过来网络和本地都很快但模型生成结果就是慢这时候去调网络参数就是白费劲。用叫外卖来类比会更好理解你下单后要等商家接单、后厨做菜、骑手配送。Codex 的做菜就是模型推理通常是最大的时间开销但很多被误认为做菜慢的情况其实卡在了接单和配送环节——也就是网络和本地处理。调优的第一步永远是定位瓶颈而不是凭感觉乱调参数。1.2 三类延迟来源与排查优先级我把 Codex 的延迟来源分成三类日常排查按这个顺序走基本能把问题收敛到最小范围延迟类型典型表现常见原因排查手段IO 延迟发送后长时间无响应或频繁报错重试网络往返、DNS 解析、鉴权失败、服务端限流查看日志中的请求耗时、HTTP 状态码、重试记录推理延迟请求正常发出但模型生成很慢模型规模大、上下文过长、问题过于复杂缩短上下文、换用快速模型、拆分问题本地执行延迟模型回复很快但执行命令时卡住Codex 自己跑的命令耗时长、工具输出巨量限制命令输出、忽略无关文件、减少盲目的全量搜索我的经验是九成以上的越用越慢都出在上下文膨胀不是网络问题。很多用户上来就折腾网络配置其实先把会话管理好效果立竿见影。但这不代表网络配置不重要——对于接入第三方服务、或网络环境本身不稳定的用户网络环节往往是第一个被卡死的点。所以下面先讲网络和 endpoint 配置再讲模型与上下文。2. 网络与endpoint配置响应慢的第一排查现场2.1 endpoint怎么配连接建造成本有多高Codex 默认走 OpenAI 官方接口但也支持通过配置文件自定义模型提供方指向任何兼容 OpenAI 协议的 API 服务。我见过很多把 Codex 接到其他模型服务上的做法比如接入 DeepSeek 这类第三方模型这时候 endpoint 配置就成了响应速度的直接影响因素。一个常见的自定义 provider 配置长这样具体字段以你所用版本的文档为准[model_providers.deepseek] name DeepSeek base_url https://api.deepseek.com/v1 env_key DEEPSEEK_API_KEY wire_api chat注意base_url决定了所有请求的去向。配置里最容易踩的坑是 base_url 地址写错或者指向的服务并不兼容 Codex 使用的端点格式。我在排查问题时就见过有人把 base_url 配成网站首页地址请求直接打到 HTML 页面表现就是反复超时、报 404、或者返回一堆看不懂的乱码。另一个容易被忽略的点是连接建造成本。每次请求如果都要重新做 DNS 解析、TCP 握手、TLS 加密协商、鉴权校验光这些开销就是几百毫秒起步。对于每次只问一问的小请求网络往返甚至可能超过推理本身耗时。CLI 工具里我们能直接控制的连接参数不多但有一个原则尽量保持 Codex 会话进程长期存活别频繁退出重启。会话存活期间底层连接大概率是复用的反复重启等于主动放弃连接池带来的性能收益。2.2 超时、重试与限流别让网络策略拖后腿Codex 的网络请求策略里超时和重试是调优的关键。超时设置太短模型稍一思考就触发超时然后反复重试整体时间反而更长设置太长请求真卡住时你只能干等体验同样糟糕。我自己的做法是从实际日志看耗时分布再去定超时阈值。先用默认配置跑一段时间观察慢请求的耗时集中在哪个区间然后在这个区间上浮 30% 到 50% 作为超时时间。如果发现某些请求经常需要 60 秒以上才返回说明问题不在超时而在上下文或模型本身。限流HTTP 429是另一个高频问题。第三方服务通常都有每分钟请求数限制RPM和每分钟 token 数限制TPM并发一高就触发 429。如果日志里频繁出现 429单纯调超时解决不了需要降低并发、减少请求频率。很多服务的 429 响应头里会带Retry-After字段告诉你要等多久再试。Codex 遇到 429 时会按照退避策略等待但如果等待时间过长整体响应体验就很差这时候需要从源头减少请求量——比如合并问题、精简上下文而不是坐等重试。2.3 本地服务转发报错时的排查思路用 Codex 的朋友应该见过这类报错cc switch local proxy failed while handling codex endpoint /responses.我第一次遇到时也懵了表面看是请求都发出去了但 Codex 就是拿不到响应。这个报错的本质是当前环境启用了某个本地中间层服务负责把 Codex 的请求转发给真正的模型服务但在处理/responses这个端点时转发失败。这类本地中间层真实存在的形态很多但只要是同一类转发模式排查路径就是一样的。我把它当成一次标准排障来演示你以后遇到类似报错可以直接照做确认本地服务进程还活着。报错里已经提示了本地服务先检查进程是否在运行、端口是否有监听。很多时候不是 Codex 的锅是那个本地服务崩了或没启动。用 curl 直接打一下目标端点。比如本地服务监听在某个端口就手动模拟 Codex 发一个最小请求过去看返回是否正常。这一步能把Codex 本身出问题和本地服务出问题区分开。检查 Codex 配置里的 base_url 是否指向了正确的服务地址。端口号、路径前缀写错都会导致转发失败。检查鉴权相关环境变量。本地服务通常需要透传 API 密钥密钥缺失或过期会导致上游校验失败表现为转发链路末端返回 401本地服务再把错误传给 Codex。开启 debug 模式看详细日志。如果以上都排查完还没定位打开 Codex 的 debug 日志看请求在哪一步断开、上游返回了什么错误码。我在真实环境里遇到的一次情况是本地服务版本太老还不支持 Codex 新版使用的/responses端点格式升级服务版本就解决了。这种报错的关键点在于它不是网络不通而是路径处理不匹配。搞清楚这一点排查方向就对了。3. 模型选型与上下文控制降低单次请求的时间成本3.1 模型推理是最大变量网络配置正常之后最大的延迟来源就是模型推理。不同模型的速度差异非常大用同一个问题测试快的模型可能 2 秒出结果重的模型可能要 20 秒以上。这不是玄学是模型参数量、推理复杂度、服务端负载共同决定的结果。Codex 支持在配置里指定模型也可以随时切换。实际使用中我的策略是简单任务用快速模型复杂任务用重模型。比如重命名变量、写一个独立的小函数、解释一段代码这类任务对推理深度要求不高用快速模型能省下一大截等待时间而涉及跨文件的架构调整、需要理解大量业务逻辑的任务再切到更强的模型。还有一个特别容易被忽视的坑模型名必须真实存在于你接入的服务中。我看到有人直接从网上复制了某个模型名配进 config.toml结果请求直接被服务端拒绝报错类似the gpt-5.6-sol model is not supported when using codex with a...。这种错误不是调优能解决的而是配置前提就不成立。改配置之前先查一下目标服务实际支持的模型列表别在错误的前提上调半天参数。3.2 上下文膨胀是越用越慢的隐形原因这是整篇内容里我最想强调的一点Codex 用着用着就变慢绝大多数情况下不是网络问题而是上下文膨胀。模型每次推理时都要处理全部输入内容包括历史对话、文件快照、工具输出。上下文越长预填充prefill阶段的时间就越长直接导致首字返回时间TTFT飙升。打个比方你让一个老师做一道题只给他题目他很快就能开口回答你让他先把一本 500 页的书读完再做题他光是读的时间就足够让你等得崩溃。上下文膨胀的典型场景是一个会话连续用了一整天中间穿插了大量cat大文件、grep搜索结果、测试输出这些内容全部累积在历史里。到后期每次请求 Codex 都要把这堆历史重新过一遍速度自然断崖式下降。治理方案我从有效到无效排个序一事一会话。每个任务独立开新会话完成后就关掉别让一个会话承载所有需求。这是最有效也最容易被忽略的方法。用 /compact 压缩历史。Codex 支持压缩当前会话的上下文把冗长的中间过程浓缩成摘要能显著减轻后续请求的预填充负担。用 ignore 规则屏蔽无关目录。在配置中加入.gitignore之外的忽略项避免 Codex 反复扫描 node_modules、dist、build 这类大目录。合理设置权限控制。减少 Codex 盲目执行命令的机会只开放必要的权限防止它反复运行耗时操作。3.3 隔离工具输出别让中间步骤撑爆上下文Codex 最大的特点是它会自己执行命令、读写文件这也带来了另一个性能杀手工具输出泛滥。一个cat打印 2000 行的配置文件一个测试命令输出几十屏日志这些内容会全部塞进上下文成为后续请求的沉重负担。我自己踩过的坑是让 Codex 分析一个大型前端项目时它反复执行find、grep把大量文件内容一次性读进来。前期还流畅跑了几轮之后就明显感觉到速度下降最后一看日志上下文里已经堆了几十万字符的中间输出。解决方案有几个一是明确告诉 Codex 哪些文件不要读、哪些命令不要执行让它优先使用目录结构和局部搜索来做判断二是要求它输出精简摘要当需要读取大文件时让 Codex 用 head、tail、行号定位等方式只读取必要部分不要在日志阶段就输出全文三是及时清理会话历史一旦发现上下文开始膨胀立刻 compact 或者直接开新会话。这里有一个判断指标当单次请求的耗时随会话时长明显上升时90% 的可能是上下文膨胀而不是模型变慢了。把上下文清理掉响应速度通常立竿见影地恢复。4. 请求策略调整用工程手段降低等待感4.1 流式输出与感知延迟有时候模型并不慢但用户体感还是卡这涉及一个概念感知延迟。它由三个指标共同决定TTFTTime To First Token从发出请求到收到第一个字符的时间也就是等待感的主要来源。生成速度首字之后后续内容的输出速率。总时长整个请求从发出到完成的时间。Codex 默认是流式输出也就是边生成边显示一旦首字返回后面的内容会不停地流动出来这时候用户不会觉得卡。但如果你关闭了流式输出就变成了模型全部生成完再一次性显示等待感会被拉长数倍——哪怕总时长一模一样体验也完全不同。我在实际使用中确认过确保流式输出开启是性价比最高的一项调优。它不改变任何后端耗时但能极大改善交互体验。如果你的 Codex 输出是一段一段蹦出来的说明流式已经生效如果半天没动静然后突然整段出现检查一下配置里是不是把流式关掉了。4.2 把大任务拆开把重复推理变脚本模型处理问题的耗时和问题的复杂度强相关。一个笼统的大需求帮我重构整个模块会让模型进入长时间深度思考期间用户只能干等。而把一个复杂需求拆成多个小任务每次只解决一个具体问题虽然请求总数变多但每次单请求的响应速度更快整体体验反而更顺。实际操作上我会在 prompt 里主动限定范围。比如不写优化这个函数的性能而是写先分析 hot_path 函数的耗时分布定位到行级别再给出优化方案。前者模型要自己决定从哪里开始分析后者它可以直接执行分析动作省去大量无效推理。另一个容易被忽略的手段是把重复劳动固化成脚本。如果你发现自己经常问 Codex 同一类问题比如这个目录下哪些文件超过 500 行与其每次让模型重新理解、重新执行不如把这类操作写成脚本需要时直接运行。让模型做模型擅长的事让脚本做脚本擅长的事能显著减少每天的无效请求量。4.3 会话生命周期管理带来的额外收益Codex 的会话不是越多越好也不是开得越久越好。会话太短频繁冷启动会有额外开销会话太长上下文膨胀又拖慢速度。我总结了一套适合自己工作流的会话管理方式一个功能一个会话开发新功能时开新会话功能完成立即归档。复用研究型会话只做代码阅读、逻辑分析、方案对比的会话可以持续较长时间但要注意定期 compact。不留垃圾会话跑偏的、内容混乱的会话尽早关闭重新开一个比在烂会话里硬撑高效得多。有些版本还支持会话恢复功能也就是中断后重新打开历史会话继续工作。效果取决于实现是否保留了服务端的中间状态如果每次恢复都要重新加载和预填充大量上下文那频繁恢复长会话反而会增加响应延迟。我的实践体会是任务边界清晰的情况下新开会话往往比恢复旧会话更快——旧会话的历史本身就是一个沉重的包袱。5. 实战排错token失效与endpoint报错的完整排查记录5.1 先学会看日志调优和排错的前提是能看到发生了什么。Codex 的日志通常位于用户目录下的.codex/log/文件夹里面有按时间排序的日志文件也可以运行时带 debug 参数输出更详细的请求信息。日志里最值得关注的信息有几类请求耗时分布、HTTP 状态码、重试次数、错误信息。检查响应慢的问题时先看日志里的时间戳确认慢在请求发出之前还是请求发出之后检查报错时先看对应的 HTTP 状态码——401 是鉴权问题、404 是路径问题、429 是限流、5xx 是服务端异常。这一步能把问题的范围缩小到具体环节后面排查才有方向。5.2 auth token is unavailable 的排查顺序auth token is unavailable是 Codex 使用中非常高频的一个报错。复杂程度不高但很多人绕了远路我按排查顺序列一下先确认登录态。执行登录命令重新完成认证很多时候是 token 过期了重新登录即可解决。检查环境变量。Codex 会读取 API 密钥相关环境变量如果这些变量没设、设错了值、或者设成了空字符串就会报 token unavailable。直接在终端打印一下这个变量的值确认非空且格式正确。检查配置文件里的认证字段。自定义 provider 的场景下token 可能配置在 config.toml 中确认字段名正确、值有效。检查 token 是否有权限访问你配置的 base_url 指向的服务。有些服务要求 token 具备特定的 model 访问权限token 有效但权限不足也会报这个错。重启 Codex 会话。某些情况下token 在进程启动时被加载更新 token 后不重启不会生效。我见过最离谱的案例是用户把 API 密钥配置里的值复制时多了一个空格肉眼根本看不出来但请求就是一直失败。配置类问题排查先看值再看格式最后才怀疑系统问题。这个顺序能省下大量时间。5.3 endpoint /responses失败与模型名不被支持的定位前面提到过cc switch local proxy failed while handling codex endpoint /responses这类报错再展开讲一下定位思路。它的排查起点是搞清楚 Codex 实际请求了哪个地址、哪个路径。开启 debug 日志后能看到完整的请求 URL 和响应状态码据此判断失败发生在哪一环如果 curl 直接打本地服务是通的但 Codex 打不通问题很可能出在 Codex 服务发现机制与本地服务的接口约定不一致。如果本地服务返回了上游的错误比如 401、404说明本地服务本身正常工作是上游鉴权或路径配置有误。如果本地服务直接崩溃或没有返回问题就在本地服务自身的稳定性和版本兼容性上。另一类我常遇到的问题与/responses有关模型名不被服务端支持。请求还没有进入推理阶段就被服务端直接拒绝报错类似the gpt-5.6-sol model is not supported when using codex with a...。这类问题的解法非常直接去服务商官方文档查一下它支持哪些模型把配置里的模型名改成正确的。别相信网上流传的旧配置模板模型列表会随版本更新频繁变化。为了便于对照我把几个高频报错的排查路径整理成了表格报错现象可能原因第一排查动作auth token is unavailable未登录、token 过期、环境变量缺失或格式错误重新登录检查环境变量endpoint /responses 失败本地服务未启动、base_url 指向错误、版本不兼容检查进程、curl 直连验证model is not supported模型名配置错误、服务商不支持该模型查服务商支持的模型列表反复 429并发过高、TPM/RPM 超限降低并发、减少请求量请求发出后长时间无响应上下文膨胀、模型过重、超时设置不合理开新会话、compact、切快速模型6. 调优清单与我的实测体会6.1 一份可以直接抄的自检清单结合前面的内容我整理了一份可以直接对照执行的自检清单。每次觉得 Codex 变慢时按顺序过一遍基本能覆盖 95% 的常见问题优先级检查项操作建议P0上下文是否膨胀开新会话或 /compact观察速度是否恢复P0模型名是否有效与服务商支持的模型列表逐一比对P1模型是否过重简单任务换快速模型P1base_url 是否指向正确用 curl 直连验证P1鉴权信息是否有效检查登录态、环境变量、token 权限P2限流是否触发降低并发检查 429 日志P2是否在频繁重启会话保持会话存活利用连接复用P3工具输出是否泛滥限制读取范围、减少无关命令执行P3任务是否过于笼统拆分为多个小任务限定边界这套清单不是理论推演是我在实际使用过程中一步步验证过的。它最大的价值在于让你在遇到慢的时候有一个明确的操作顺序而不是病急乱投医。6.2 实测效果与个人体会按这套方案调整后我这边常用的请求首字返回时间大约从 6 到 10 秒降到了 2 到 3 秒主要贡献来自上下文压缩和模型选型网络环节的稳定性提升则来自确认了 base_url 和鉴权配置的正确性。这个效果在不同网络环境、不同服务商之间会有明显差异但方法论是一致的先量化再优化一次只改一个变量。我在实际使用中最深的一个体会是Codex 性能问题九成不是单点故障而是上下文管理失控。很多人一觉得慢就开始怀疑网络、换模型、调参数其实先把会话变短、把无关输出挡在上下文之外效果立竿见影。另一个朴素但重要的教训是调优没有银弹但一定有瓶颈。花十分钟看日志定位瓶颈比花一个小时盲调参数有用得多。从一个变量开始改改完就测确认有效再动下一个否则多个改动混在一起出了问题你根本不知道是谁的锅。