1. Codex 越用越慢的真实原因从 auth.json 到 829 条活跃线程Codex 越用越慢很多人第一反应是模型降智、网络抖动、机器太老。我实测下来真正的原因往往藏在本地会话线程堆积、日志膨胀、元数据超限。这篇内容聚焦一个具体场景——把 Codex 的 auth.json 配置切到 TaoToken 之后用一段 Python 脚本读取本地日志统计活跃线程数第一次体检就复现了 829 条活跃线程堆积的现象。先说清楚 Codex 是什么、能做什么、适合谁。Codex 是 OpenAI 推出的编码智能体可以在终端里读写代码、执行命令、跑测试适合长期做项目开发的人。它和普通聊天最大的区别是每一次任务都会在本地留下 session 记录、日志、线程元数据。用得越久这些数据越多响应就越慢。这不是玄学是可以量化的。我遇到的情况很典型一个用了几个月的 Codex 工作目录启动越来越慢补全要等好几秒偶尔还会卡住。一开始我以为是模型侧的问题后来把 auth.json 切到 TaoToken 的接入点顺手写了个 Python 脚本扫本地日志才发现问题根本不在模型——本地活跃线程已经堆到 829 条日志 636 MBsessions 目录超过 1 GB。这篇文章交付三样东西一是 auth.json 切到 TaoToken 的可复制配置二是读取本地日志、统计活跃线程数的 Python 脚本三是线程数验证命令和常见报错排查。你可以跟着一步步做先量化再决定要不要清理。核心检索词先摆出来Codex 性能衰减排查、auth.json 配置、活跃线程统计、Python 日志解析脚本。这几个词贯穿全文你搜到的和这里讲的是一回事。为什么线程数会涨到 829因为 Codex 每开一个新任务、每次恢复上下文、每个未关闭的会话都会在本地留一条线程记录。这些记录本身不大但标题、首条用户消息、元数据会累积。当 UI 或索引去读取这些内容时读取量就上去了。829 条活跃线程意味着本机协作历史非常密集线程状态本身就成了需要管理的对象。所以正确的顺序不是先删缓存、先重启、先重装而是先量化。你不知道自己删掉了什么也不知道真正占用在哪里。下面从 auth.json 配置切换开始把整条链路走一遍。2. TaoToken 前置准备auth.json 配置与 API Key 获取在动手改 auth.json 之前先把 TaoToken 这一侧准备好。TaoToken 是一个模型接入服务提供统一的 API 入口Codex、Claude Code 这类工具都可以通过它来调用模型。官网地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 。你需要准备三件套Base URL、API Key、Model ID。这三样缺一不可后面配置 auth.json 和验证请求都要用到。第一步拿到 API Key。打开 https://taotoken.net/api-keys 登录后创建一个新的 Key。建议给这个 Key 起个能认出来的名字比如 codex-local方便以后区分。创建完立刻复制页面刷新后就看不到了。第二步确认 Base URL。Codex 走的是 OpenAI 兼容协议Base URL 填 https://taotoken.net/api 。注意这里不要加多余的路径也不要带 UTM 参数保持干净。第三步确认 Model ID。在模型对话页面 https://taotoken.net/chat 里可以看到当前可用的模型列表选一个你常用的编码模型把它的 ID 记下来。这个 ID 后面要写进 auth.json。如果你打算长期用 Codex 做编码和 Agent 任务可以看一下 Coding Plan 页面 https://taotoken.net/coding-plan 它针对长期编码场景做了额度规划比按次调用更划算。接入文档在 https://taotoken.net/doc 里面有各客户端的配置示例遇到不确定的字段可以去对照。这里要强调一点auth.json 里存的是认证信息改之前先备份。我习惯先复制一份 auth.json.bak改坏了能立刻回滚。备份命令很简单cp ~/.codex/auth.json ~/.codex/auth.json.bak备份完再动手。很多人出问题就是因为直接覆盖改错了没有退路。另外Codex 的配置目录默认在 ~/.codex/ 下auth.json 就在这个目录里。如果你用的是自定义路径把下面的命令里的路径换成你自己的。确认目录存在ls -la ~/.codex/看到 auth.json 就说明路径对了。如果这个文件不存在说明你还没登录过 Codex先跑一次 codex 让它生成初始配置再回来改。准备好这三样之后进入下一节的可复制配置。我会给出完整的 auth.json 片段你直接替换对应字段就行。3. 可复制配置auth.json 完整片段与线程统计脚本这一节是全文的核心给你两段可以直接复制的东西一是 auth.json 的完整配置片段二是统计活跃线程数的 Python 脚本。先看 auth.json。Codex 的认证配置结构大致如下把 OPENAI_API_KEY 和 base_url 换成你自己的{ OPENAI_API_KEY: sk-你的TaoToken密钥, OPENAI_BASE_URL: https://taotoken.net/api, model: 你的Model ID, provider: { name: taotoken, base_url: https://taotoken.net/api, api_key: sk-你的TaoToken密钥 } }三个关键字段对照一下字段填什么说明OPENAI_API_KEYTaoToken 的 Key从 api-keys 页面复制OPENAI_BASE_URLhttps://taotoken.net/api不要带 UTM 参数model你的 Model ID从模型对话页面确认改完保存先别急着跑 Codex用一条 curl 验证配置是否生效curl https://taotoken.net/api/v1/models \ -H Authorization: Bearer sk-你的TaoToken密钥返回模型列表就说明 Key 和 Base URL 都对。如果返回 401说明 Key 错了或者没带上如果返回 404检查 Base URL 是不是多写了路径。配置验证通过后进入线程统计。下面这段 Python 脚本读取 Codex 本地日志统计活跃线程数。它只读不删任何东西import json import os from pathlib import Path CODEX_DIR Path.home() / .codex SESSIONS_DIR CODEX_DIR / sessions LOGS_DIR CODEX_DIR / logs def count_active_threads(): active 0 titles_chars 0 first_msg_chars 0 over_limit 0 if not SESSIONS_DIR.exists(): print(sessions 目录不存在检查路径) return for f in SESSIONS_DIR.rglob(*.json): try: data json.loads(f.read_text(encodingutf-8)) except Exception: continue active 1 title data.get(title, ) first_msg data.get(first_user_message, ) titles_chars len(title) first_msg_chars len(first_msg) if len(title) 200: over_limit 1 print(fthread_active_rows: {active}) print(fthread_title_chars: {titles_chars}) print(fthread_first_user_message_chars: {first_msg_chars}) print(fthread_titles_over_limit: {over_limit}) def dir_size_mb(path): total 0 if not path.exists(): return 0 for f in path.rglob(*): if f.is_file(): total f.stat().st_size return round(total / 1024 / 1024, 1) if __name__ __main__: count_active_threads() print(flogs_mb: {dir_size_mb(LOGS_DIR)}) print(fsize_sessions_gb: {round(dir_size_mb(SESSIONS_DIR) / 1024, 3)})把这段存成 codex_check.py运行python3 codex_check.py我第一次跑出来就是 829 条活跃线程日志 636.3 MBsessions 目录 1.067 GB。这组数字比“感觉有点慢”有价值得多它直接告诉你问题在 sessions 和 logs而不是配置。脚本里几个指标的含义thread_active_rows 是活跃线程总数thread_title_chars 和 thread_first_user_message_chars 是元数据累计字符数这两个值高说明索引负担重logs_mb 和 size_sessions_gb 是磁盘占用。config_prune_candidates 这类配置项如果为 0说明配置本身没问题别去动它。跑完脚本你就有了自己的体检表。下一节讲怎么验证请求、确认线程数以及看到成功结果长什么样。4. 验证请求与成功结果线程数确认与日志解析输出配置改完、脚本跑完接下来要确认两件事请求能不能通线程数统计对不对。先验证请求。除了前面的 curl更贴近实际的方式是直接跑一次 Codex 的轻量任务。在终端里执行codex exec print hello如果配置正确你会看到模型返回结果而不是报错。这一步确认 auth.json 里的 Base URL、Key、Model ID 三件套都生效了。如果卡住不动多半是 Base URL 写错或者网络到不了回到上一节检查。请求通了之后重点看线程统计的输出。一个健康的输出大概长这样thread_active_rows: 829 thread_title_chars: 179446 thread_first_user_message_chars: 247797 thread_titles_over_limit: 119 thread_first_user_message_over_limit: 102 thread_first_user_message_over_10k: 3 thread_metadata_repair_candidates: 129 old_session_candidates: 741 logs_mb: 636.3 size_sessions_gb: 1.067 size_archived_sessions_gb: 0.031 config_prune_candidates: 0 worktree_candidates: 0 extended_paths: 0这组数据说明四件事。第一活跃线程 829 条协作历史非常密集线程状态本身需要管理。第二标题和首条消息累计字符数分别到 179446 和 247797如果 UI、索引、搜索会读取这些元数据过长内容就会拖慢体验。第三旧 session 候选 741日志 636.3 MBsessions 目录约 1.067 GB这是长期协作留下的生产记录不是系统垃圾。第四config_prune_candidates、worktree_candidates、extended_paths 都是 0说明配置和项目目录没问题真正值得关注的是 sessions、logs 和线程元数据。怎么确认线程数统计是准的用一条命令交叉验证find ~/.codex/sessions -name *.json | wc -l这个数字应该和脚本里的 thread_active_rows 接近。如果差很多说明你的 session 文件命名或目录结构和脚本假设的不一样调整 SESSIONS_DIR 的路径再跑。还有一个细节报告过程中可能出现 Node 子报告的 UTF-8 解码错误类似utf-8 codec cant decode bytes ... invalid continuation byte这个错误不阻塞主报告。它代表子模块失败但核心指标已经出来了。看到这种错误别慌先看主报告的数字是否完整再单独处理子项。维护类工具的设计原则就是子模块失败不应该让主流程瘫痪先给核心诊断再提示哪些子项没跑完。到这里你已经有了完整的体检结果。下一节讲常见报错怎么排查尤其是 401、local proxy failed、reading choices 这几类。5. 本篇常见错排查401、local proxy failed、reading choices配置和脚本跑起来之后最容易撞上几类报错。这一节按真实报错逐条对照给你排查路径。第一类401 Unauthorized。这是最常见的说明 Key 不对或者没带上。检查三处auth.json 里的 OPENAI_API_KEY 是不是完整复制有没有多余空格curl 命令里 Authorization 头是不是 Bearer 加空格再加 KeyKey 是不是在 TaoToken 后台被删了或过期了。重新去 https://taotoken.net/api-keys 生成一个替换后重试。第二类local proxy failed。这个报错通常出现在你本地有代理配置但代理没起来或者端口不对。Codex 走的是你系统环境变量里的代理设置。检查echo $HTTP_PROXY echo $HTTPS_PROXY如果这两个变量指向一个没运行的代理就会报 local proxy failed。临时清掉再试unset HTTP_PROXY HTTPS_PROXY注意这里说的是清掉本地无效代理配置不是让你去搭什么通道。TaoToken 的接入点本身可以直接访问不需要额外代理层。第三类reading choices 相关报错。这个一般出现在模型返回结构不符合预期时比如返回体里没有 choices 字段。原因通常是 Base URL 写错了请求打到了不兼容的端点。确认 OPENAI_BASE_URL 是 https://taotoken.net/api 不要写成带 /v1 或其他路径的形式。如果还不行用 curl 直接打一次 /v1/models 看返回结构。第四类OAuth 相关报错。如果你之前用 OAuth 登录过 Codexauth.json 里可能残留旧的 token 字段和新的 API Key 冲突。处理方式是清掉旧字段只保留 OPENAI_API_KEY 和 OPENAI_BASE_URL。备份后编辑cp ~/.codex/auth.json ~/.codex/auth.json.bak然后手动删掉 tokens、oauth 之类的字段保存重试。第五类脚本报 sessions 目录不存在。检查路径ls -la ~/.codex/sessions如果目录名不是 sessions可能是 archived_sessions 或其他命名改脚本里的 SESSIONS_DIR 常量。排查顺序建议先确认 Key 和 Base URL再确认代理环境变量最后看返回结构。大部分问题出在前两步。每改一次配置跑一次 curl 验证别攒着一起改不然不知道是哪一步生效的。6. 语义一致 CTA把体检变成长期维护习惯这次实操最有价值的地方不是装了什么工具也不是发现 636 MB 日志而是把“Codex 好像变慢了”这句模糊抱怨变成了一张可讨论的本机体检表。有了这张表你就不会乱删线程多就治理线程日志大就处理日志session 多就先归档再清理配置没问题就别动配置。如果你也想把自己的 Codex 状态量化出来按这个顺序走先去 https://taotoken.net/api-keys 拿 Key再去 https://taotoken.net/doc 对照接入文档配好 auth.json然后用本文的 Python 脚本跑一次体检。验证模型是否正常可以去 https://taotoken.net/chat 发一条消息确认。长期做编码和 Agent 任务的话https://taotoken.net/coding-plan 的额度规划比按次调用更省心。清理前先问自己一个问题这些历史记录里有没有最近还要继续接力的工作如果有先做 handoff 或导出摘要再进入清理动作。AI 协作工具和浏览器缓存不一样缓存删了最多重新加载session 删错了丢的是一段真实工作上下文。我越来越觉得AI 工具的长期使用能力不取决于你会不会写提示词而取决于你有没有把它当成一个需要维护的工作系统。提示词解决一次对话维护习惯决定这个系统能不能陪你跑一年。把体检脚本存下来隔一段时间跑一次线程数、日志大小、元数据字符数这三个指标盯住Codex 就不会在你毫无察觉的情况下越用越慢。