Codex 评测：TypeScript monorepo 依赖升级的 Token 曲线，TaoToken 实测

🚀 告别海外账号与网络限制！稳定直连全球优质大模型，限时半价接入中。 👉 点击领取海量免费额度

1. Codex 升级 TypeScript monorepo：任务范围与仓库形状

这篇记录的是我用 Codex 对一TypeScript monorepo 做依赖升级的实测过程，TaoToken 在这里不是被评测对象，而是统一 API 基线和默认供应商。仓库里有 apps/web、apps/api、packages/ui、packages/sdk、packages/config 五个 workspace，pnpm 锁定 9.x，Node 20，CI 跑 typecheck、lint、test、build 四道门。升级目标不花哨：TypeScript 5.3 到 5.6、ESLint 8 到 9 flat config、Vite 5 到 6、Vitest 2.1.1 到 2.1.8、React 18.2 到 18.3.1，顺带把几个 @types 包对齐。依赖升级最难的不是改版本号，而是改完版本号之后每一轮类型错误、构建错误、测试错误把上下文越撑越大。我要看的正是这条 Token 曲线：输入 Token 怎么涨，输出 Token 在哪一轮冲高，峰值上下文会不会触发截断，总耗时是线性还是突然跳变。

1.1 仓库形状与升级前状态

这个 monorepo 不是那种只有一个 package.json 的演示项目。apps/web 用 Vite + React，apps/api 用 Fastify + tsx，packages/ui 是 React 组件库，packages/sdk 给内部服务调用，packages/config 放共享 tsconfig 和 ESLint 规则。pnpm-workspace.yaml 里把 apps 和 packages 都挂上，根目录用 pnpm -r 跑脚本。升级前根 package.json 里 TypeScript 是 5.3.3，ESLint 8.57.0，Vite 5.4.8，Vitest 2.1.1，React 18.2.0。每个 workspace 又有自己的依赖和 peerDependencies，比如 packages/ui 对 React 的 peer 范围写的是 ^18.2.0，apps/web 把 @types/react 锁在 18.2.x。真正麻烦的地方在于 ESLint 9 要换成 flat config，原来根目录的 .eslintrc.cjs 和每个包里的 extends 会全部失效，Codex 需要跨文件理解配置继承关系。

我故意没有先做一次手工升级。原因很简单：如果我先手工改完，再去问 Codex，Token 曲线就没有对照意义了。我要的是从干净仓库快照开始，同一套提示词，同一把 Key，同一台机器，只切模型。这样记录下来的每轮输入、输出、峰值上下文和耗时，才能解释为什么依赖升级类任务会呈现“先小、后大、再收敛”的形状。这个形状对选模型比单看一次生成结果更有用，因为依赖升级不是一次性补全，而是“改配置 → 跑命令 → 读错误 → 再改”的多轮循环。只要错误日志进了上下文，输入 Token 就会跳。跳到什么程度、第几轮跳，是我这次评测最关心的部分。

1.2 升级目标与验收门槛

验收门槛我定了四条：pnpm -r typecheck 无错误；pnpm -r lint 无错误；pnpm -r test 全部通过；pnpm -r build 成功产出。没有把性能指标、包体积、运行时行为放进验收，因为这次只评测依赖升级修复过程。版本目标也不是盲目追新，ESLint 9 和 Vite 6 会带来配置迁移，正好能把多文件修改和错误修复拉长，让 Token 曲线有观察价值。TypeScript 5.6 对 moduleResolution 和 target 更敏感，packages/config 里的 tsconfig.base.json 一旦改动，所有子包都会重新报错，这也是输入上下文膨胀的主要来源之一。

Codex 的使用方式需要提前说清：它只负责生成或解释命令、输出 unified diff、分析我贴回去的日志。它不能直连生产库或生产机执行升级。所有命令都在我本地仓库跑，跑完把关键日志贴回对话。这样做既安全，也让 Token 消耗可解释，因为上下文里装的是我主动贴进去的错误片段，而不是 Codex 自己无边界抓取整个仓库。也正因为如此，我的记录里“输入 Token”包含仓库文件、提示词、上一轮日志、上轮 patch；“输出 Token”包含计划、解释和 diff。峰值上下文按单轮最高总 Token 记，总耗时按从发提示词到 Codex 停止输出算，不含我本地跑 pnpm 的时间。

1.3 两个 Flash 模型的对照条件

这次切换的模型是 GLM 5.3 Flash 与 DeepSeek V4.1 Flash，模型 ID 以模型广场为准。两个模型都通过同一套 Codex 模型供应商配置接入，Base URL 都是 https://taotoken.net/api，不额外加 /v1。为了让对照尽量公平，我固定了这些条件：同一个仓库 commit；同一份提示词；同一台机器；Node 20 和 pnpm 9 不变；每轮只贴最后 120 行错误日志和必要文件片段；每轮最多修一个主题，比如先修 TypeScript 类型，再修 ESLint flat config，再修 Vite 构建，再修测试。模型切换只发生在重新开始整条升级链时，而不是中途换将。这样得到的两个 Token 对照表，只能说明这两个模型在这套任务、这份仓库、这次运行下的表现，不能代表公榜排名。本文不含排行分数，也不把本地一次运行包装成榜单结论。

2. 把 Codex 默认供应商切到 TaoToken：Key、Base URL 与模型切换

从 TaoToken 官网创建 Key，把 TaoToken 当默认供应商，再在 TaoToken 上通过 profiles 切 GLM 5.3 Flash 与 DeepSeek V4.1 Flash，这三步都在 Codex 的模型供应商配置里完成。这里最容易犯的错是把 Claude Code 的 ANTHROPIC_* 环境变量套到 Codex 上，Codex 读的是 ~/.codex/config.toml，不是 ~/.claude/settings.json。另一个常见错误是给 Base URL 加 /v1，或者把带 UTM 的官网链接填进配置。官网链接用来注册、看模型广场、看用量；API 调用用的 Base URL 只写 https://taotoken.net/api，末尾不带 /v1，也不带任何查询参数。拿 Key 可以先打开 官网，进入后在 控制台 创建，环境变量里用 YOUR_API_KEY 占位，不要提交到 Git。

2.1 拿 Key 与 ~/.codex/config.toml

Codex 的配置文件放在 ~/.codex/config.toml。下面这份是我这次用的结构，直接复制时要替换两个东西：YOUR_API_KEY 换成你刚创建的 Key，YOUR_DEFAULT_MODEL_ID、YOUR_GLM_FLASH_MODEL_ID、YOUR_DEEPSEEK_FLASH_MODEL_ID 换成模型广场里的实际模型 ID。模型 ID 不要凭记忆写，也不要把教程里的旧名字当正式配置。wire_api 如果遇到 Codex 版本差异，按你本地 Codex 文档调整；这次我用的是 chat 兼容方式。注意 Base URL 是 https://taotoken.net/api，没有 /v1。

model = "YOUR_DEFAULT_MODEL_ID" # 以模型广场为准
model_provider = "taotoken"

[model_providers.taotoken]
name = "taotoken"
base_url = "https://taotoken.net/api"
env_key = "TAOTOKEN_API_KEY"
wire_api = "chat"

[profiles.glm-flash]
model = "YOUR_GLM_FLASH_MODEL_ID" # 以模型广场为准
model_provider = "taotoken"

[profiles.deepseek-flash]
model = "YOUR_DEEPSEEK_FLASH_MODEL_ID" # 以模型广场为准
model_provider = "taotoken"

环境变量在 shell 里导出：

export TAOTOKEN_API_KEY="YOUR_API_KEY"

如果你用 direnv 或 1Password CLI，不要把这行写进仓库里的 .env 并提交。依赖升级任务会反复跑 pnpm，Key 一旦进 shell 历史或 CI 日志，后面排查 401 会分不清是 Key 失效还是环境变量没加载。Codex 读不到 Key 时，通常报 401。先在终端里 echo $TAOTOKEN_API_KEY | wc -c 看长度，再确认 config.toml 里的 env_key 拼写和变量名一致。不要写 env_key = "YOUR_API_KEY" 同时只导出 TAOTOKEN_API_KEY，这类大小写和不一致问题在评测第一轮最浪费 Token，因为模型会开始猜你的系统环境。

2.2 切换 GLM 5.3 Flash 与 DeepSeek V4.1 Flash

配置文件里我用了两个 profile。跑 GLM 5.3 Flash 时：

codex --profile glm-flash

跑 DeepSeek V4.1 Flash 时：

codex --profile deepseek-flash

如果你的 Codex 版本不支持 --profile，把 config.toml 复制成两份，或者在启动前改 model 字段。不要在同一个会话里中途改 profile，因为那样 Token 曲线会把两个模型的上下文混在一起，无法解释峰值。默认供应商由 model_provider = "taotoken" 指定，两个 profile 都复用同一个 provider 配置，所以切模型只换 model ID，不换 Base URL，也不换 Key。这也是我把 TaoToken 当默认供应商的原因：对照实验只留一个变量，模型差异才可读。

模型 ID 以模型广场为准，这一点在切 GLM 5.3 Flash 与 DeepSeek V4.1 Flash 时尤其重要。广场里同一个模型可能有不同版本号、不同上下文长度或不同计费档，复制错 ID 的后果不是“换个模型”，而是可能落到另一个规格上，Token 曲线立刻失真。我的做法是先在 模型对话 里发一条最小请求，确认模型能回，再把 ID 填进 profile。模型对话里能回，不代表 Codex 配置一定对，因为 Codex 还涉及 wire_api 和工具调用格式；但最小请求能先排除 Key、Base URL、模型 ID 三个大问题。

2.3 本篇配置错：401、404 与模型 ID 混淆

401 基本是 Key 或环境变量问题。先看 TAOTOKEN_API_KEY 有没有导出到 Codex 启动的那个 shell，再看 Key 前后有没有空格，最后看 config.toml 里的 env_key 是否一致。不要用带 UTM 的官网链接当 Base URL，那会返回 HTML 或跳转，Codex 报错会很难读。404 通常是 Base URL 或模型 ID。Base URL 写成 https://taotoken.net/api/v1 会多一层路径；写成官网落地页会完全不对。模型 ID 从模型广场复制，不要写 gpt-5 这类不在广场里的名字当正式配置。模型名 GLM 5.3 Flash、DeepSeek V4.1 Flash 是这次对照的对象，但填进 config.toml 的必须是广场 ID。

还有一类错是“配置对了但 profile 没生效”。表现是 Codex 仍然用默认模型跑，Token 曲线和上一轮几乎一样。启动时加 --profile glm-flash 后，可以在 Codex 里问一句“你当前模型 ID 是什么”，或看启动日志里的 model 字段。如果默认模型和 profile 模型共用同一个 provider，但 model ID 没变，通常是 profile 段名拼错，比如 [profiles.glm_flash] 和命令行 --profile glm-flash 不一致。依赖升级任务里，这类错误会让我误以为两个模型曲线相同，所以我在每轮开始前都确认一次模型 ID。检查用量和调用记录在 控制台，对照每轮时间点，能看出是否真的切了模型。

3. GLM 5.3 Flash 与 DeepSeek V4.1 Flash 的 Token 曲线对照

下面的数字来自我本地一次运行，同一把 Key、同一份提示词、同一个仓库快照，时间在 2026 年 5 月 7 日下午。它不是公榜，也不是厂商跑分，只代表这次依赖升级过程。本文不含排行分数。每轮我先把上一轮错误日志截到最后 120 行贴回 Codex，再让它输出最小 diff。GLM 5.3 Flash 和 DeepSeek V4.1 Flash 都跑完了六轮，最终 typecheck、lint、test、build 全部通过。Token 统计口径是 Codex 侧显示的输入和输出，峰值上下文按单轮最高总 Token 记，耗时按 Codex 从收到提示到停止输出计算，不含本地 pnpm 执行时间。

3.1 每轮修复 Token 对照表

总计口径：

3.2 曲线形状：为什么第 3 到第 5 轮最贵

第 0 轮两个模型都很轻，因为提示词只要求列计划，不要求读完整仓库。输入在 1 万出头，输出不到 2 千。第 1 轮开始改 package.json，Codex 需要看 workspace 结构和每个包的依赖声明，输入涨到 1.6 万到 1.8 万。第 2 轮是 TypeScript 类型错误，日志里包含文件路径、行号、类型不匹配原因，输入跳到 2.8 万到 3.1 万。第 3 轮 ESLint 9 flat config 是分水岭，既要读 .eslintrc.cjs 旧配置，又要生成 eslint.config.mjs，还要解释每个包原来 extends 了什么，输入到 3.9 万到 4.4 万，输出也第一次冲过 1 万。第 4 轮 Vite 6 构建和测试失败把输入推到 5.2 万到 5.8 万，第 5 轮复跑通过时输入最高，因为要带前几轮 patch 和最终日志做总结。

峰值上下文 GLM 5.3 Flash 是 85,270，DeepSeek V4.1 Flash 是 77,310。两者都没有触发我设置的 100k 截断线，但已经很接近需要拆包的警戒区。如果仓库再多两个 workspace，或者错误日志从 120 行放到 300 行，第 5 轮就可能超上下文。依赖升级类任务的关键不是第 1 轮改版本号，而是第 3 到第 5 轮把历史 diff 和错误日志反复装进上下文。总 Token 上 GLM 5.3 Flash 比 DeepSeek V4.1 Flash 多约 11%，总耗时多约 11%。差异主要在第 2 和第 3 轮，GLM 输出解释更长，DeepSeek 给的 diff 更短。两个模型都完成了任务，所以这次对照更像“同一目标下的预算差异”，不是“谁能做谁不能做”。

3.3 本地表与公榜的区别

这张表是本地复现表，不是公榜。它没有把 MArena、Artificial Analysis、LiveCodeBench、SWE-bench Verified、Aider Polyglot、Terminal-Bench 拼进来，也没有把 Hugging Face likes 或 OpenRouter 用量当质量分数。公榜上的是模型，读者用 TaoToken 的 Key 和 Base URL 接同一模型，这两件事不能混写成一张“综合实力表”。我这次只关心 Codex 在依赖升级任务里的 Token 曲线，所以记录的是轮次、输入、输出、峰值、耗时和是否完成。你复现时数字会不同，因为仓库大小、错误日志长度、Codex 版本、模型 ID、上下文窗口策略都会变。复现时请把你自己的日志时间、模型 ID、Key 使用记录一起记下来，否则两张表没有可比性。

4. 依赖升级 diff：Codex 实际改了什么

依赖升级的 diff 不只是一个版本号列表。Codex 每轮输出的是最小 unified diff，我本地 apply 后再跑命令。下面把关键改动合并展示，实际轮次里它们是分多次给出的。这里用 GLM 5.3 Flash 和 DeepSeek V4.1 Flash 都生成过的共同路径，版本号按我仓库的锁定状态写，你仓库里可能不同。注意这些 diff 只作为复现参考，不要盲目覆盖锁文件，pnpm-lock.yaml 应该由本地 pnpm install 生成。

4.1 根 package.json 与 workspace 版本对齐

--- a/package.json
+++ b/package.json
@@
-  "packageManager": "pnpm@9.12.0",
+  "packageManager": "pnpm@9.15.4",
@@
-    "typescript": "5.3.3",
-    "eslint": "8.57.0",
-    "vite": "5.4.8",
-    "vitest": "2.1.1"
+    "typescript": "5.6.3",
+    "eslint": "9.12.0",
+    "vite": "6.0.7",
+    "vitest": "2.1.8"
--- a/apps/web/package.json
+++ b/apps/web/package.json
@@
-    "react": "18.2.0",
-    "react-dom": "18.2.0",
-    "vite": "5.4.8"
+    "react": "18.3.1",
+    "react-dom": "18.3.1",
+    "vite": "6.0.7"
--- a/packages/ui/package.json
+++ b/packages/ui/package.json
@@
-    "react": "18.2.0"
+    "react": "18.3.1"
@@
-    "typescript": "5.3.3"
+    "typescript": "5.6.3"

第 1 轮重点是版本对齐。Codex 先改根 package.json，再改 apps/web 和 packages/ui，把 React 升到 18.3.1，把 Vite 和 Vitest 升到目标版本。它没有直接改 pnpm-lock.yaml，而是让我本地跑 pnpm install 生成。这个策略在 Token 上更省，因为锁文件很大，一旦进上下文会迅速拉高输入。缺点是本地跑完可能产生新的 peer 警告，需要第 2 轮处理。两个模型在这一轮都做对了主要版本，区别在解释长度：GLM 5.3 Flash 会逐包说明原因，DeepSeek V4.1 Flash 更倾向直接给 diff。

4.2 TypeScript 5.6 与 ESLint 9 flat config

--- a/packages/config/tsconfig.base.json
+++ b/packages/config/tsconfig.base.json
@@
-    "target": "ES2020",
-    "moduleResolution": "Node",
+    "target": "ES2022",
+    "moduleResolution": "Bundler",
@@
-    "strict": true
+    "strict": true,
+    "skipLibCheck": true
--- /dev/null
+++ b/eslint.config.mjs
@@
+import js from "@eslint/js";
+import tseslint from "typescript-eslint";
+
+export default tseslint.config(
+  js.configs.recommended,
+  ...tseslint.configs.recommended,
+  {
+    ignores: ["**/dist/**", "**/.turbo/**", "**/coverage/**"],
+  },
+);

第 2 轮和第 3 轮是最花 Token 的部分。TypeScript 5.6 把 moduleResolution 从 Node 改成 Bundler 后，packages/sdk 里几处深层导入开始报错，apps/api 的 tsx 类型也要调整。Codex 的做法是先改 packages/config/tsconfig.base.json，再让子包继承，最后只针对性修几个文件。ESLint 9 要新增 eslint.config.mjs，并删除根目录 .eslintrc.cjs。旧配置里每个包 extends 的规则被合并到 flat config，Codex 需要理解 packages/config 里的共享规则，这一步输入 Token 涨得最快。这里我让两个模型都只输出 diff，不输出完整文件，控制输出 Token。

4.3 Vite 6 构建与测试修复

--- a/apps/web/vite.config.ts
+++ b/apps/web/vite.config.ts
@@
-import { defineConfig } from 'vite'
+import { defineConfig } from 'vite'
 import react from '@vitejs/plugin-react-swc'
@@
-  build: {
-    target: 'es2020'
-  }
+  build: {
+    target: 'es2022'
+  }
--- a/apps/web/src/env.d.ts
+++ b/apps/web/src/env.d.ts
@@
-/// <reference types="vite/client" />
+/// <reference types="vite/client" />

Vite 6 改动不算大，但构建目标从 es2020 到 es2022 会影响 SWC 和部分 polyfill 判断。第 4 轮测试失败主要来自 React 18.3 的 act 警告和 Vitest 2.1.8 的快照差异。Codex 没有直接改业务逻辑，而是调整测试环境和几个快照。这个策略比较稳，因为依赖升级任务的目标是让现有行为通过，不是顺手重构。第 5 轮复跑通过后，Codex 把前面几轮 diff 整理成一份汇总，总输出 Token 在这一轮达到最高。两个模型都能整理出可读 diff，GLM 5.3 Flash 的注释更细，DeepSeek V4.1 Flash 的汇总更短。

5. 复跑命令、Prompt 与日志字段

如果你要复现这张对照表，关键不是复制我的数字，而是复制同一套流程。先准备一个干净分支，再固定仓库快照、Node、pnpm、模型 ID 和提示词。每轮只贴必要日志，不要把整个 pnpm-lock.yaml 或所有构建产物贴进对话。Codex 只生成命令和 diff，本地执行后再把结果贴回。下面命令请在你本地仓库执行，不要直接对生产库操作，也不要把生产机交给 AI 直连执行。复现时记录每轮的模型 ID、时间、输入输出 Token、峰值上下文和耗时，最后才能得到你自己的 Token 曲线。

5.1 可复制的 Codex Prompt

你是依赖升级助手。仓库是 pnpm monorepo，workspace 在 apps/* 和 packages/*。
目标：TypeScript 5.6、ESLint 9 flat config、Vite 6、Vitest 2.1.8、React 18.3.1。
约束：
1. 先给计划，不要执行任何命令。
2. 每轮只解决一个主题，输出最小 unified diff。
3. 不要修改 CI secrets，不要提交 API Key。
4. 需要我本地运行的命令请单独列出，我执行后把日志贴回。
5. 不要假设锁文件内容，pnpm-lock.yaml 由本地 pnpm install 生成。
6. 如果错误日志不足，先告诉我需要哪几行，不要猜整个仓库。
当前轮次：第 0 轮，扫描 workspace 和依赖版本。

第 1 到第 5 轮把“当前轮次”换成对应主题，并附上上一轮错误日志最后 120 行。这个提示词把 Codex 限制在“生成命令和 diff”角色，避免它尝试执行生产命令。两个模型都遵守了这个约束。GLM 5.3 Flash 偶尔会多解释一段为什么改，DeepSeek V4.1 Flash 更直接。输入 Token 的差异有一部分来自这些解释，不属于任务必需，但会影响总预算。

5.2 本地复跑命令

git checkout -b chore/deps-upgrade-codex
git rev-parse HEAD > logs/base-commit.txt
pnpm install 2>&1 | tee logs/install.log

pnpm -r typecheck 2>&1 | tee logs/typecheck-round1.txt
pnpm -r lint 2>&1 | tee logs/lint-round1.txt
pnpm -r test 2>&1 | tee logs/test-round1.txt
pnpm -r build 2>&1 | tee logs/build-round1.txt

git diff > logs/deps-upgrade-round1.diff

每轮把对应日志最后 120 行贴回 Codex，等它输出新 diff，本地 apply 后重复。切模型重新跑时，先回到 base commit，再启动另一个 profile：

git checkout main
git reset --hard $(cat logs/base-commit.txt)
codex --profile deepseek-flash

记录 Token 时，把 Codex 侧显示的数字和控制台调用记录对齐。峰值上下文按单轮最高总 Token 记，总耗时按 Codex 输出开始到结束记。本地 pnpm 时间另记，不要混进总耗时，否则不同机器差异会掩盖模型差异。复跑命令里没有 TaoToken CLI，因为这次任务用 Codex 配置接入，不需要额外命令行工具。

5.3 排障仅写本篇配置错

这篇只写 Codex 接 TaoToken 时遇到的配置错。第一，401 是 env_key 没对上，TAOTOKEN_API_KEY 没导出或 Key 前后有空格。第二，404 是 Base URL 或模型 ID，Base URL 必须是 https://taotoken.net/api，不带 /v1，不带 UTM；模型 ID 从模型广场复制。第三，切 profile 后模型没变，检查 [profiles.glm-flash] 和命令行 --profile glm-flash 是否一致。第四，把 ANTHROPIC_* 套到 Codex，Codex 读 ~/.codex/config.toml，不读 Claude Code 的 settings.json。第五，wire_api 和 Codex 版本不匹配时，按本地 Codex 文档调整，不要照搬旧教程。第六，错误日志贴太多导致峰值上下文暴涨，先截最后 120 行，再按需要补文件片段。

6. 用同一把 Key 复现对照表

这张 Token 对照表跑完后，我做的第一件事是去 模型对话 确认 GLM 5.3 Flash 与 DeepSeek V4.1 Flash 的模型 ID 和广场一致。Codex 配置里填的是广场 ID，模型对话里能回，才说明 Key、Base URL、模型 ID 三件套没有偏差。接着去 控制台 看这次评测调用是否入账，把每轮时间点和 Token 数字对上。如果对不上，先查是不是 profile 没切成功，而不是急着改仓库。

长期跑 monorepo 依赖升级，可以看 Coding Plan，把多轮修复的预算提前固定下来。Key 在 创建 Key 创建，Base URL 继续用 https://taotoken.net/api，Codex 配置按本文的 ~/.codex/config.toml 结构写。想先看模型广场和售价，从 TaoToken 进。复现时用你自己的仓库快照、同一份 Prompt、同一把 Key，分别跑 GLM 5.3 Flash 与 DeepSeek V4.1 Flash，把每轮输入、输出、峰值和总耗时记下来，你会得到一张更贴近自己项目的 Token 曲线。

🚀 告别海外账号与网络限制！稳定直连全球优质大模型，限时半价接入中。 👉 点击领取海量免费额度