Codex App 调优实战:从卡顿到丝滑,还能省一半 Token

一个 API 用户的真实配置优化全记录

如果你现在问我， Codex App 是否好用？

对于开发工作，我的答案是好用，我没有买OpenAI的订阅，完全用的第三方的订阅。

我只配置了两个模型，一个 gpt-5-mini 另外一个是 gpt-5.3-codex。两个模型一个跑轻量级的任务，一个跑复杂型的任务。对于开发来说，我是真觉得还不错。

主要原因是我前一段时间，写了一个产品方案，我拿到的只有一个产品规划说明书，还是别人用AI规划出来的，我本来想阅读一下，但是看到那些密密麻麻的字我放弃了。

从产品规划说明的总结，到架构设计图，再到架构实现方案，最后的代码demo实现。我完全在codex app里边实现的。

期间我也换过其他的产品做这个事情，最后还是那啥了......

主要还是不好用，给不了我想要的。

有一些配置或者说问题，也会影响使用体验，做个笔记记录。

这里补充一下，如果你真的想体验使用，建议购买支持Response API 的服务商的服务。Codex APP其实是有点依赖Codex CLI的配置，我没试给Chat API是否可用，因为 我在最早体验和翻阅 Response API 的文档的时候，我发现他在chat模版里边又增加了一个开发者的角色，我没有深究，只是觉得体验吧。

写在前面

如果你也在用 OpenAI Codex App 写代码，很可能遇到过这两个痛点：

1. UI 卡顿：切标签、滚动、打字都感觉不跟手
2. Token 烧得快：通用模型不稳定，专用模型又太贵

本文是我在实际使用中踩坑、分析、优化的一份完整记录，所有操作都亲测有效，希望能帮到你。

先搞清楚：你这卡顿到底是哪种？

在动手优化之前，先判断你的卡顿类型：

本文重点解决前两种。

第一步：降低 Reasoning Level（立竿见影）

每个 Thread 启动时，可以选择推理级别。级别越高，模型思考越久，首 token 延迟（TTFT）越高。

操作： 新建 Thread → 输入框上方找到 Reasoning 下拉菜单 → 选 Low

建议策略：

• Low：日常简单任务（修 bug、写注释、小重构）
• Medium：中等复杂度
• High / Extra High：只有架构设计、复杂调试时才开

我日常 90% 的情况下用 Low，体感响应速度提升非常明显。

第二步：选对模型，省钱又不卡

如果你用的是 API key 登录（像我一样），模型选择直接决定了体验和成本。

官方各模型对比

我的推荐

我日常用 gpt-5-mini，或者用官方推荐的 gpt-5.4-mini

配置方法（编辑 ~/.codex/config.toml）：

model ="gpt-5-mini"
model_reasoning_effort ="low"
[model_providers.cliproxyapi]
model ="gpt-5-mini"

动态切换：遇到复杂任务时，在 Codex 输入框里随时切换：

/model gpt-5.3-codex    # 切到强模型
/model gpt-5-mini     # 切回轻量模型

第三步：设置自动压缩阈值（最关键的一步）

这是很多人忽略但效果极佳的设置。

Codex 会在对话膨胀到一定 token 量后自动压缩历史。默认值通常偏高，意味着你要忍受很长时间的卡顿才触发压缩。

改这个值（编辑 ~/.codex/config.toml）：

[history]
compact_threshold =60000# 6万 token 就压缩，不要等到 18万

我一开始设的是 180000，改到 60000 后对话历史更轻量，UI 操作明显流畅了。

第四步：在 AGENTS.md 中加入压缩提醒习惯

~/.codex/AGENTS.md（全局生效）是 Codex 的"行为说明书"。我加了这条规则：

## 上下文管理
-当对话超过30轮仍未结束时，主动建议执行/compact 压缩历史
- shell 命令输出超过100行时，先 summarize 再决定是否全文读取
-优先用 grep/search 定位问题，不要一次性读整个文件
## 输出控制
-回答保持简洁，除非明确要求详细解释
-代码 diff 只展示改动部分，不要展示完整文件
-不要在同一个 session 里多次读取已读过的文件

效果： 这些规则能有效降低每次请求的上下文体积。社区反馈，加上这类 AGENTS.md 规则后，token 消耗可降低 30-50%。

第五步：关掉不需要的插件

打开 ~/.codex/config.toml，检查你的插件列表。如果你不用文档、表格、演示文稿生成，关掉它们：

[plugins."documents@openai-primary-runtime"]
enabled =false
[plugins."spreadsheets@openai-primary-runtime"]
enabled =false
[plugins."presentations@openai-primary-runtime"]
enabled =false
[plugins."browser@openai-bundled"]
enabled =false# 不用浏览器功能也关掉

每关一个插件就少一层后台开销。

第六步：限制 Project 范围 + 清理旧会话

缩小 Project 沙箱

Codex App 左侧的 Projects 管理你的工作目录。如果你的 Project 绑定了整个 monorepo，沙箱内的文件索引会很重。

建议： 每个 Project 只指向你正在工作的子模块。比如 packages/frontend、 packages/api 分开，不要整个仓库。

清理旧会话

会话文件和数据库日志会随着使用越积越大：

# 清理旧 session，sessions是安装年份保存，注意文件夹名字
rm -rf ~/.codex/sessions/2026/
# 清理存档的旧会话
rm -rf ~/.codex/archived_sessions/*
# 清理 SQLite 日志文件（退出 Codex 后执行）
rm -f ~/.codex/state_5.sqlite-wal ~/.codex/state_5.sqlite-shm
rm -f ~/.codex/logs_2.sqlite-wal ~/.codex/logs_2.sqlite-shm

这些文件会在重启 Codex 后自动重建，放心删。

第七步：检查你的 API 服务商是否支持 Prompt Caching

这是很多人忽略的隐形开销。如果你们用的 API 服务商不支持 Responses API 的 prompt caching，每次请求都要重复传 system prompt + tool definitions（约 3-5K token），累积下来非常可观。

直接问你的 API 提供商：

"你们的 Responses API 是否支持 prompt caching？"

不支持的话，考虑换一个支持的供应商。实在没有也没办法。

第八步：用好命令行技巧

日常使用中可以养成几个好习惯：

配置总览

优化完的 ~/.codex/config.toml 大概长这样：

model_provider ="cliproxyapi"
model ="gpt-5-mini"
model_reasoning_effort ="low"
personality ="pragmatic"
[model_providers.cliproxyapi]
name ="xxxx"
base_url ="http://xxxx/v1"
wire_api ="responses"
model ="gpt-5-mini"
[history]
compact_threshold =60000
# 关闭不需要的插件
[plugins."documents@openai-primary-runtime"]
enabled =false
[plugins."spreadsheets@openai-primary-runtime"]
enabled =false
[plugins."presentations@openai-primary-runtime"]
enabled =false
[plugins."browser@openai-bundled"]
enabled =false

总结

这次优化的核心思想其实就是三个字：减负担。

所有操作加起来不到 10 分钟，但日常使用的流畅感和钱包都能感受到变化。

如果你也有自己的优化心得，欢迎留言交流。