1. 21 组复跑前先把 TaoToken Key、Base URL 和 harness 配置分开如果你正在用 Claude Code、Codex 或 Pi 复跑 7 个模型 × 3 种 harness 的 21 组编码评测先别改 prompt。先去 TaoToken 官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentintro21 获取 Key再把 Base URL 固定为 https://taotoken.net/api。这样做的原因很直接这次复跑的核心变量是 harness而不是供应商入口。如果每个 harness 走不同入口、不同 Key、不同 Base URL最后看到的成功率差异和成本差异就分不清是 harness 造成的还是配置漂移造成的。公开评测里常见的设定是 7 个模型分别跑 Claude Code、Codex、Pi 三种 harness共 21 个模型-harness 组合。原始结论大致是harness 选择对成功率影响小但对成本影响显著。作为二次验证者我不应该直接把这句话抄一遍而要把 21 组重新跑成可复现记录每个组合用同一套任务、同一套成功判定、同一套 Token 统计口径。TaoToken 在这里扮演的是统一模型入口Key 从官网控制台创建Base URL 填 https://taotoken.net/apiClaude Code、Codex、Pi 分别按自己的配置文件接入。先建一个本地目录把配置、任务和结果分开arena-rerun/ configs/ claude-code/ settings.json codex/ config.toml pi/ .env tasks/ task-01/ task-02/ ... runs.csv scripts/ summarize.py这个目录结构不复杂但能避免一个常见问题把 Key 写进仓库。Key 占位符统一用YOUR_API_KEY真实 Key 放在本机环境变量或本地 settings 文件里。TaoToken 的 Key 创建入口在官网控制台不要从旧笔记、聊天记录或第三方脚本里复制来源不明的 Key。你可以在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentconfig21 进入官网后找到控制台入口再创建自己的 Key。复跑 21 组时建议把“模型 ID”和“harness 配置”也拆开记录。模型 ID 是模型侧变量harness 配置是调用侧变量。谁在消耗 Token答案不是 harness 本身而是三种 harness 调用 7 个模型时模型推理消耗 Token。Harness 决定了每次请求发送多少上下文、是否重试、工具结果回传多少所以它间接影响成本。把这两层拆开后面看成本表才不会乱。2. Claude Code 配置settings.json 与 ANTHROPIC_* 的最小闭环Claude Code 的接入重点是settings.json和ANTHROPIC_*环境变量。不要把 Codex 的config.toml混进来也不要把 OpenAI 风格变量套到 Claude Code。一个最小可复制配置如下路径可以放在用户级~/.claude/settings.json也可以放在项目级.claude/settings.json{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: YOUR_MODEL_ID, ANTHROPIC_SMALL_FAST_MODEL: YOUR_SMALL_MODEL_ID } }如果你更习惯用 shell 环境变量也可以这样临时验证export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_AUTH_TOKENYOUR_API_KEY export ANTHROPIC_MODELYOUR_MODEL_ID export ANTHROPIC_SMALL_FAST_MODELYOUR_SMALL_MODEL_ID这里有两个细节容易出错。第一ANTHROPIC_BASE_URL应填https://taotoken.net/api不要自己在末尾加/v1也不要拼成完整对话路径。第二ANTHROPIC_AUTH_TOKEN用你在 TaoToken 创建的 Key占位符写YOUR_API_KEY不要把真实 Key 提交到 Git。Claude Code 启动后先跑一个很小的本地任务比如读取一个文件并生成摘要确认请求确实走了 TaoToken再开始 21 组复跑。Claude Code 在 21 组里的特点是工具调用链比较长。它可能多次读取文件、执行本地命令、回传工具结果。成功率通常不会因为换 harness 就大幅波动但输入 Token 会随着文件读取和工具回传增加。成本记录时不要只记总 Token要把输入 Token、输出 Token、重试次数分开。因为 Claude Code 的成本差异往往来自输入侧而不是输出侧。如果遇到 401优先检查ANTHROPIC_AUTH_TOKEN是否被 shell 里旧变量覆盖如果遇到 404优先检查ANTHROPIC_BASE_URL是否被写成了带/v1的地址。TaoToken 官网的 Claude Code 文档入口在文末 CTA 中给出配置前可以先对照官方字段名。3. Codex 配置config.toml 不要复用 ANTHROPIC_*Codex 的配置方式和 Claude Code 完全不同。这里再强调一次不要把ANTHROPIC_*套到 Codex。Codex 使用config.toml常见位置是~/.codex/config.toml。一个接入 TaoToken 的示例model YOUR_MODEL_ID model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat然后在 shell 里提供 Keyexport TAOTOKEN_API_KEYYOUR_API_KEY如果你的 Codex 版本对wire_api的取值要求不同以实际报错和模型支持为准在chat与responses之间切换测试。但不要因为报错就把 Claude Code 的ANTHROPIC_BASE_URL写进 Codex 配置这不会生效还会让排障方向跑偏。Codex 的供应商配置核心是model_provider、base_url、env_key三件事。在 21 组复跑里Codex 的成本表现通常和它的工具回传策略有关。它可能把命令输出、diff、错误日志回传给模型输入 Token 会上升如果失败后自动重试成本还会叠加。成功率方面Codex 对模型本身的依赖更大harness 更多影响的是“失败后怎么恢复”和“每次请求塞多少上下文”。所以复跑记录里要加一列retry_count否则你只会看到总成本看不到成本为什么高。建议在跑正式任务前用 Codex 执行一个最小本地命令例如列出当前目录并解释一个文件。确认config.toml生效后再跑 21 组。不要把 Codex 指向生产数据库或线上服务所有命令都在本地或隔离环境执行。4. Pi 与通用 OpenAI 兼容 harness只改 Base URL 和 Key 的边界Pi 的接入方式取决于你使用的版本和 provider 配置。本文不编造未验证的插件名或私有 API只保留能核实的通用做法如果该 harness 支持 OpenAI 兼容环境变量就把 Base URL 指向 TaoTokenKey 用YOUR_API_KEY。示例.envexport OPENAI_BASE_URLhttps://taotoken.net/api export OPENAI_API_KEYYOUR_API_KEY如果 Pi 使用自己的 provider 配置文件就把 provider 的baseURL填https://taotoken.net/apiapiKey填YOUR_API_KEY。不要同时设置多个供应商的环境变量否则很容易出现“以为改了实际读的是旧变量”的情况。复跑 21 组时Pi 这一列要额外记录它的上下文策略是否自动压缩历史、工具输出截断多少、失败重试几次。因为这些策略会直接影响模型推理消耗的 Token。Pi 在三种 harness 中往往是成本波动最大的一个原因不是它本身更贵而是它可能把长文件、长日志或长工具结果注入上下文。成功率上只要模型能力够用Pi 和另外两种 harness 的差距通常不会像成本差距那样明显。二次验证时我会把 Pi 的请求次数、平均输入 Token、平均输出 Token 单独聚合避免被总成本平均值掩盖。如果你不确定当前 Pi 版本支持哪种变量先用最小任务验证只让它读取一个短文件并返回一句话。成功后再增加工具调用和长上下文任务。不要一上来就跑完整 21 组否则排障成本会比 Token 成本更高。5. 复跑 21 组任务集、成功判定与 Token/成本记录表要复现“harness 对成功率影响小但显著影响成本”这个结论任务集必须固定。建议准备 8 到 12 个本地编码任务覆盖单文件修改、多文件重构、测试修复、依赖配置、脚本补全、错误日志定位。每个任务保存初始快照每个模型-harness 组合跑同一套任务至少重复 3 轮。21 个组合 × 3 轮可以观察噪声而不是只看单轮排名。成功判定不要靠肉眼。可以统一为# 在任务目录内由读者本地执行 git diff --check pytest -q npm test -- --runInBand具体命令按任务技术栈替换。成功条件建议包含测试退出码为 0、没有新增高危变更、diff 能解释、没有跳过关键测试。失败也要分类编译失败、测试失败、超时、上下文超限、工具调用错误、模型拒绝。分类后成功率才有意义。记录表建议用 CSVrun_id,model_id,harness,task_id,round,status,input_tokens,output_tokens,cache_read_tokens,retry_count,duration_ms,cost 1,model-a,claude-code,task-01,1,ok,12000,1800,0,0,45000,0.012 2,model-a,codex,task-01,1,ok,9800,1600,0,0,38000,0.009 3,model-a,pi,task-01,1,fail,26000,900,0,2,92000,0.021成本公式cost input_tokens / 1000000 * input_price output_tokens / 1000000 * output_price具体单价以 TaoToken 模型详情或控制台显示为准。你可以在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentcost21 进入官网查看模型与计费信息。不要用旧价格表硬算否则 21 组复跑的成本结论会失真。聚合脚本可以这样写import csv rows list(csv.DictReader(open(runs.csv, encodingutf-8))) summary {} for r in rows: key (r[model_id], r[harness]) s summary.setdefault(key, { runs: 0, ok: 0, input: 0, output: 0, retry: 0, cost: 0.0, }) s[runs] 1 s[ok] 1 if r[status] ok else 0 s[input] int(r[input_tokens]) s[output] int(r[output_tokens]) s[retry] int(r[retry_count]) s[cost] float(r[cost]) for key, s in sorted(summary.items()): rate s[ok] / s[runs] avg_input s[input] / s[runs] avg_output s[output] / s[runs] avg_cost s[cost] / s[runs] print(key, rate, avg_input, avg_output, s[retry], avg_cost)这个脚本只做本地统计不连接任何生产库。跑完 21 组后你会得到按模型和 harness 聚合的成功率、平均输入 Token、平均输出 Token、重试次数和平均成本。6. 二次验证结论成功率差异被噪声吃掉成本差异被上下文放大复跑后最值得关注的不是“哪个 harness 绝对第一”而是三个现象。第一同一模型换 harness成功率差异通常小于任务难度带来的差异。简单任务上Claude Code、Codex、Pi 都可能通过复杂任务上失败原因更多是模型推理边界、工具调用格式、上下文丢失而不是 harness 名字本身。把 21 组混在一起看总成功率会掩盖任务分层。建议按任务类型再看一遍。第二成本差异比成功率差异更稳定。同一个模型在 Claude Code、Codex、Pi 下的平均成本可能明显不同原因主要是输入 Token 和重试次数。输出 Token 反而差异没那么大因为最终补丁长度受任务限制。Harness 决定的是“每次请求送多少上下文”和“失败后重试几轮”这两个变量直接放大成本。第三缓存和重复运行会影响结论。如果你不随机化任务顺序、不清空会话、不记录缓存命中第二轮可能因为缓存而变便宜第三轮又因为上下文累积而变贵。21 组复跑如果要作为成本基线至少要记录cache_read_tokens和retry_count。可以用一个聚合模板来看harness成功次数/总次数成功率平均输入 Token平均输出 Token平均重试平均成本Claude Code填入填入填入填入填入填入Codex填入填入填入填入填入填入Pi填入填入填入填入填入填入这张表填完后结论通常会变成harness 选择还重要但它重要在成本控制和失败恢复而不是直接决定模型能不能做对。对团队来说这比“哪个 harness 排名第一”更有用。7. 谁在消耗 Token三种 harness 的输入膨胀、重试和工具回传谁在消耗 Token三种 harness 调用 7 个模型时模型推理消耗 Token。Harness 本身不按 Token 计费但它决定了每次发给模型的请求长什么样。一次请求通常包含系统提示、用户任务、工具定义、历史消息、文件内容、命令输出、错误日志、当前补丁、模型输出。这里面除了模型输出其余大部分都会作为输入 Token 进入计费。Claude Code 的典型开销是工具链长。它可能多次读取文件、执行命令、回传结果再让模型继续推理。输入 Token 会随文件读取次数上升。如果它支持历史压缩成本会被压下来如果压缩不充分长会话会持续膨胀。Codex 的典型开销在命令回传和重试。config.toml把 provider 固定后模型选择更清晰但如果失败重试策略激进成本会叠加。尤其是测试失败后它可能把完整日志再次注入输入 Token 会明显增加。Pi 的典型开销取决于实现。如果它把大文件、长日志或完整工具结果放入上下文成本会快速上升。成功率不一定变差但成本表会很难看。复跑时要专门看 Pi 的平均输入 Token而不是只看总成本。降低 Token 消耗的通用方法限制单次读取文件大小优先用搜索定位再读片段。工具输出超过阈值就截断只保留错误行和上下文。失败重试设置上限避免无限循环。对长历史做摘要不要每次全量回传。小任务用小模型做预处理大模型只做最终推理。记录retry_count重试是隐藏成本大户。这些方法不改变 harness 的成功率上限但会改变成本曲线。二次验证的价值就在这里你能看到同一模型在不同 harness 下的成本差异也能看到差异来自哪一类请求。8. CC Switch 三件套与排障清单401、404、上下文超限怎么查如果你同时使用 Claude Code、Codex 和其他 CLI建议用 CC Switch 的思路管理配置。这里说的三件套是供应商配置Base URL 固定为https://taotoken.net/apiKey 使用YOUR_API_KEY。模型映射把 Claude Code 的默认模型、小模型映射到 TaoToken 可用模型 IDCodex 在config.toml里单独写model和model_provider。环境注入确认 shell、settings.json、config.toml之间没有互相覆盖切换后重启 CLI。不要把这些配置混在一起。Claude Code 用ANTHROPIC_*Codex 用config.toml和TAOTOKEN_API_KEYPi 按它自己的 provider 配置读取。混用的结果是 401 和 404 反复出现。排障清单可以按下面顺序查# 1. 检查 Claude Code 相关变量 env | grep ANTHROPIC # 2. 检查 Codex 相关变量 env | grep TAOTOKEN # 3. 检查是否有多余的 BASE_URL env | grep -E OPENAI|BASE_URL|API_KEY常见问题401 UnauthorizedKey 错误、Key 被旧变量覆盖、请求没有带认证头、Key 已被删除。重新从 TaoToken 控制台创建 Key并确认本地变量已刷新。404 Not FoundBase URL 写成了带/v1或完整路径的地址。Claude Code 和 Codex 都应先尝试https://taotoken.net/api。如果工具要求 OpenAI 兼容路径按工具文档处理不要自己拼接。模型不存在YOUR_MODEL_ID与 TaoToken 当前可用模型不一致。去模型对话或控制台确认模型 ID不要在配置里写猜测值。上下文超限harness 没有压缩历史或工具回传太长。减少文件读取、截断日志、开启摘要。复跑 21 组时这类失败要单独标记不要算成模型能力失败。Codex 报 wire API 不匹配不要用ANTHROPIC_*回到config.toml调整wire_api并确认模型支持对应协议。成本突然升高先看输入 Token 和重试次数再看模型单价。多数情况下是输入膨胀不是输出变长。9. 把 21 组复跑固化成基线文末 CTA 与执行顺序再用 TaoToken 跑 21 组之后我的结论是harness 选择仍然重要但它重要在成本、重试和上下文管理而不是直接决定成功率排名。对于团队最实用的做法不是争论哪个 harness 最强而是把 21 组复跑固化成自己的成本基线同一任务集、同一成功判定、同一 Token 统计口径按模型和 harness 聚合。执行顺序建议如下。第一步先到模型对话确认当前可用模型和模型 ID避免配置里写错模型名https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentcta_chat21第二步如果你准备长期跑多轮评测先看 Coding Plan评估调用量和成本https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcta_plan21第三步创建并管理 API Key把 Key 占位符替换为YOUR_API_KEY不要写进仓库https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentcta_keys21第四步如果你主要用 Claude Code 复跑对照 Claude Code 文档检查settings.json和ANTHROPIC_*字段https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentcta_doc21最后所有配置都指向同一个 Base URLhttps://taotoken.net/api。Claude Code 用settings.json或ANTHROPIC_*Codex 用config.tomlPi 按自身 provider 配置读取。跑完 21 组后把成功率、输入 Token、输出 Token、重试次数和成本写进同一张表。这样你得到的不是一条转述结论而是一套能继续复跑的本地基线。 
长河君 · 2026/9/18 6:34:26 · 阅读 1.2k 再用 TaoToken 跑 21 组，harness 选择还重要吗
1. 21 组复跑前先把 TaoToken Key、Base URL 和 harness 配置分开如果你正在用 Claude Code、Codex 或 Pi 复跑 7 个模型 × 3 种 harness 的 21 组编码评测先别改 prompt。先去 TaoToken 官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentintro21 获取 Key再把 Base URL 固定为 https://taotoken.net/api。这样做的原因很直接这次复跑的核心变量是 harness而不是供应商入口。如果每个 harness 走不同入口、不同 Key、不同 Base URL最后看到的成功率差异和成本差异就分不清是 harness 造成的还是配置漂移造成的。公开评测里常见的设定是 7 个模型分别跑 Claude Code、Codex、Pi 三种 harness共 21 个模型-harness 组合。原始结论大致是harness 选择对成功率影响小但对成本影响显著。作为二次验证者我不应该直接把这句话抄一遍而要把 21 组重新跑成可复现记录每个组合用同一套任务、同一套成功判定、同一套 Token 统计口径。TaoToken 在这里扮演的是统一模型入口Key 从官网控制台创建Base URL 填 https://taotoken.net/apiClaude Code、Codex、Pi 分别按自己的配置文件接入。先建一个本地目录把配置、任务和结果分开arena-rerun/ configs/ claude-code/ settings.json codex/ config.toml pi/ .env tasks/ task-01/ task-02/ ... runs.csv scripts/ summarize.py这个目录结构不复杂但能避免一个常见问题把 Key 写进仓库。Key 占位符统一用YOUR_API_KEY真实 Key 放在本机环境变量或本地 settings 文件里。TaoToken 的 Key 创建入口在官网控制台不要从旧笔记、聊天记录或第三方脚本里复制来源不明的 Key。你可以在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentconfig21 进入官网后找到控制台入口再创建自己的 Key。复跑 21 组时建议把“模型 ID”和“harness 配置”也拆开记录。模型 ID 是模型侧变量harness 配置是调用侧变量。谁在消耗 Token答案不是 harness 本身而是三种 harness 调用 7 个模型时模型推理消耗 Token。Harness 决定了每次请求发送多少上下文、是否重试、工具结果回传多少所以它间接影响成本。把这两层拆开后面看成本表才不会乱。2. Claude Code 配置settings.json 与 ANTHROPIC_* 的最小闭环Claude Code 的接入重点是settings.json和ANTHROPIC_*环境变量。不要把 Codex 的config.toml混进来也不要把 OpenAI 风格变量套到 Claude Code。一个最小可复制配置如下路径可以放在用户级~/.claude/settings.json也可以放在项目级.claude/settings.json{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: YOUR_MODEL_ID, ANTHROPIC_SMALL_FAST_MODEL: YOUR_SMALL_MODEL_ID } }如果你更习惯用 shell 环境变量也可以这样临时验证export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_AUTH_TOKENYOUR_API_KEY export ANTHROPIC_MODELYOUR_MODEL_ID export ANTHROPIC_SMALL_FAST_MODELYOUR_SMALL_MODEL_ID这里有两个细节容易出错。第一ANTHROPIC_BASE_URL应填https://taotoken.net/api不要自己在末尾加/v1也不要拼成完整对话路径。第二ANTHROPIC_AUTH_TOKEN用你在 TaoToken 创建的 Key占位符写YOUR_API_KEY不要把真实 Key 提交到 Git。Claude Code 启动后先跑一个很小的本地任务比如读取一个文件并生成摘要确认请求确实走了 TaoToken再开始 21 组复跑。Claude Code 在 21 组里的特点是工具调用链比较长。它可能多次读取文件、执行本地命令、回传工具结果。成功率通常不会因为换 harness 就大幅波动但输入 Token 会随着文件读取和工具回传增加。成本记录时不要只记总 Token要把输入 Token、输出 Token、重试次数分开。因为 Claude Code 的成本差异往往来自输入侧而不是输出侧。如果遇到 401优先检查ANTHROPIC_AUTH_TOKEN是否被 shell 里旧变量覆盖如果遇到 404优先检查ANTHROPIC_BASE_URL是否被写成了带/v1的地址。TaoToken 官网的 Claude Code 文档入口在文末 CTA 中给出配置前可以先对照官方字段名。3. Codex 配置config.toml 不要复用 ANTHROPIC_*Codex 的配置方式和 Claude Code 完全不同。这里再强调一次不要把ANTHROPIC_*套到 Codex。Codex 使用config.toml常见位置是~/.codex/config.toml。一个接入 TaoToken 的示例model YOUR_MODEL_ID model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat然后在 shell 里提供 Keyexport TAOTOKEN_API_KEYYOUR_API_KEY如果你的 Codex 版本对wire_api的取值要求不同以实际报错和模型支持为准在chat与responses之间切换测试。但不要因为报错就把 Claude Code 的ANTHROPIC_BASE_URL写进 Codex 配置这不会生效还会让排障方向跑偏。Codex 的供应商配置核心是model_provider、base_url、env_key三件事。在 21 组复跑里Codex 的成本表现通常和它的工具回传策略有关。它可能把命令输出、diff、错误日志回传给模型输入 Token 会上升如果失败后自动重试成本还会叠加。成功率方面Codex 对模型本身的依赖更大harness 更多影响的是“失败后怎么恢复”和“每次请求塞多少上下文”。所以复跑记录里要加一列retry_count否则你只会看到总成本看不到成本为什么高。建议在跑正式任务前用 Codex 执行一个最小本地命令例如列出当前目录并解释一个文件。确认config.toml生效后再跑 21 组。不要把 Codex 指向生产数据库或线上服务所有命令都在本地或隔离环境执行。4. Pi 与通用 OpenAI 兼容 harness只改 Base URL 和 Key 的边界Pi 的接入方式取决于你使用的版本和 provider 配置。本文不编造未验证的插件名或私有 API只保留能核实的通用做法如果该 harness 支持 OpenAI 兼容环境变量就把 Base URL 指向 TaoTokenKey 用YOUR_API_KEY。示例.envexport OPENAI_BASE_URLhttps://taotoken.net/api export OPENAI_API_KEYYOUR_API_KEY如果 Pi 使用自己的 provider 配置文件就把 provider 的baseURL填https://taotoken.net/apiapiKey填YOUR_API_KEY。不要同时设置多个供应商的环境变量否则很容易出现“以为改了实际读的是旧变量”的情况。复跑 21 组时Pi 这一列要额外记录它的上下文策略是否自动压缩历史、工具输出截断多少、失败重试几次。因为这些策略会直接影响模型推理消耗的 Token。Pi 在三种 harness 中往往是成本波动最大的一个原因不是它本身更贵而是它可能把长文件、长日志或长工具结果注入上下文。成功率上只要模型能力够用Pi 和另外两种 harness 的差距通常不会像成本差距那样明显。二次验证时我会把 Pi 的请求次数、平均输入 Token、平均输出 Token 单独聚合避免被总成本平均值掩盖。如果你不确定当前 Pi 版本支持哪种变量先用最小任务验证只让它读取一个短文件并返回一句话。成功后再增加工具调用和长上下文任务。不要一上来就跑完整 21 组否则排障成本会比 Token 成本更高。5. 复跑 21 组任务集、成功判定与 Token/成本记录表要复现“harness 对成功率影响小但显著影响成本”这个结论任务集必须固定。建议准备 8 到 12 个本地编码任务覆盖单文件修改、多文件重构、测试修复、依赖配置、脚本补全、错误日志定位。每个任务保存初始快照每个模型-harness 组合跑同一套任务至少重复 3 轮。21 个组合 × 3 轮可以观察噪声而不是只看单轮排名。成功判定不要靠肉眼。可以统一为# 在任务目录内由读者本地执行 git diff --check pytest -q npm test -- --runInBand具体命令按任务技术栈替换。成功条件建议包含测试退出码为 0、没有新增高危变更、diff 能解释、没有跳过关键测试。失败也要分类编译失败、测试失败、超时、上下文超限、工具调用错误、模型拒绝。分类后成功率才有意义。记录表建议用 CSVrun_id,model_id,harness,task_id,round,status,input_tokens,output_tokens,cache_read_tokens,retry_count,duration_ms,cost 1,model-a,claude-code,task-01,1,ok,12000,1800,0,0,45000,0.012 2,model-a,codex,task-01,1,ok,9800,1600,0,0,38000,0.009 3,model-a,pi,task-01,1,fail,26000,900,0,2,92000,0.021成本公式cost input_tokens / 1000000 * input_price output_tokens / 1000000 * output_price具体单价以 TaoToken 模型详情或控制台显示为准。你可以在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentcost21 进入官网查看模型与计费信息。不要用旧价格表硬算否则 21 组复跑的成本结论会失真。聚合脚本可以这样写import csv rows list(csv.DictReader(open(runs.csv, encodingutf-8))) summary {} for r in rows: key (r[model_id], r[harness]) s summary.setdefault(key, { runs: 0, ok: 0, input: 0, output: 0, retry: 0, cost: 0.0, }) s[runs] 1 s[ok] 1 if r[status] ok else 0 s[input] int(r[input_tokens]) s[output] int(r[output_tokens]) s[retry] int(r[retry_count]) s[cost] float(r[cost]) for key, s in sorted(summary.items()): rate s[ok] / s[runs] avg_input s[input] / s[runs] avg_output s[output] / s[runs] avg_cost s[cost] / s[runs] print(key, rate, avg_input, avg_output, s[retry], avg_cost)这个脚本只做本地统计不连接任何生产库。跑完 21 组后你会得到按模型和 harness 聚合的成功率、平均输入 Token、平均输出 Token、重试次数和平均成本。6. 二次验证结论成功率差异被噪声吃掉成本差异被上下文放大复跑后最值得关注的不是“哪个 harness 绝对第一”而是三个现象。第一同一模型换 harness成功率差异通常小于任务难度带来的差异。简单任务上Claude Code、Codex、Pi 都可能通过复杂任务上失败原因更多是模型推理边界、工具调用格式、上下文丢失而不是 harness 名字本身。把 21 组混在一起看总成功率会掩盖任务分层。建议按任务类型再看一遍。第二成本差异比成功率差异更稳定。同一个模型在 Claude Code、Codex、Pi 下的平均成本可能明显不同原因主要是输入 Token 和重试次数。输出 Token 反而差异没那么大因为最终补丁长度受任务限制。Harness 决定的是“每次请求送多少上下文”和“失败后重试几轮”这两个变量直接放大成本。第三缓存和重复运行会影响结论。如果你不随机化任务顺序、不清空会话、不记录缓存命中第二轮可能因为缓存而变便宜第三轮又因为上下文累积而变贵。21 组复跑如果要作为成本基线至少要记录cache_read_tokens和retry_count。可以用一个聚合模板来看harness成功次数/总次数成功率平均输入 Token平均输出 Token平均重试平均成本Claude Code填入填入填入填入填入填入Codex填入填入填入填入填入填入Pi填入填入填入填入填入填入这张表填完后结论通常会变成harness 选择还重要但它重要在成本控制和失败恢复而不是直接决定模型能不能做对。对团队来说这比“哪个 harness 排名第一”更有用。7. 谁在消耗 Token三种 harness 的输入膨胀、重试和工具回传谁在消耗 Token三种 harness 调用 7 个模型时模型推理消耗 Token。Harness 本身不按 Token 计费但它决定了每次发给模型的请求长什么样。一次请求通常包含系统提示、用户任务、工具定义、历史消息、文件内容、命令输出、错误日志、当前补丁、模型输出。这里面除了模型输出其余大部分都会作为输入 Token 进入计费。Claude Code 的典型开销是工具链长。它可能多次读取文件、执行命令、回传结果再让模型继续推理。输入 Token 会随文件读取次数上升。如果它支持历史压缩成本会被压下来如果压缩不充分长会话会持续膨胀。Codex 的典型开销在命令回传和重试。config.toml把 provider 固定后模型选择更清晰但如果失败重试策略激进成本会叠加。尤其是测试失败后它可能把完整日志再次注入输入 Token 会明显增加。Pi 的典型开销取决于实现。如果它把大文件、长日志或完整工具结果放入上下文成本会快速上升。成功率不一定变差但成本表会很难看。复跑时要专门看 Pi 的平均输入 Token而不是只看总成本。降低 Token 消耗的通用方法限制单次读取文件大小优先用搜索定位再读片段。工具输出超过阈值就截断只保留错误行和上下文。失败重试设置上限避免无限循环。对长历史做摘要不要每次全量回传。小任务用小模型做预处理大模型只做最终推理。记录retry_count重试是隐藏成本大户。这些方法不改变 harness 的成功率上限但会改变成本曲线。二次验证的价值就在这里你能看到同一模型在不同 harness 下的成本差异也能看到差异来自哪一类请求。8. CC Switch 三件套与排障清单401、404、上下文超限怎么查如果你同时使用 Claude Code、Codex 和其他 CLI建议用 CC Switch 的思路管理配置。这里说的三件套是供应商配置Base URL 固定为https://taotoken.net/apiKey 使用YOUR_API_KEY。模型映射把 Claude Code 的默认模型、小模型映射到 TaoToken 可用模型 IDCodex 在config.toml里单独写model和model_provider。环境注入确认 shell、settings.json、config.toml之间没有互相覆盖切换后重启 CLI。不要把这些配置混在一起。Claude Code 用ANTHROPIC_*Codex 用config.toml和TAOTOKEN_API_KEYPi 按它自己的 provider 配置读取。混用的结果是 401 和 404 反复出现。排障清单可以按下面顺序查# 1. 检查 Claude Code 相关变量 env | grep ANTHROPIC # 2. 检查 Codex 相关变量 env | grep TAOTOKEN # 3. 检查是否有多余的 BASE_URL env | grep -E OPENAI|BASE_URL|API_KEY常见问题401 UnauthorizedKey 错误、Key 被旧变量覆盖、请求没有带认证头、Key 已被删除。重新从 TaoToken 控制台创建 Key并确认本地变量已刷新。404 Not FoundBase URL 写成了带/v1或完整路径的地址。Claude Code 和 Codex 都应先尝试https://taotoken.net/api。如果工具要求 OpenAI 兼容路径按工具文档处理不要自己拼接。模型不存在YOUR_MODEL_ID与 TaoToken 当前可用模型不一致。去模型对话或控制台确认模型 ID不要在配置里写猜测值。上下文超限harness 没有压缩历史或工具回传太长。减少文件读取、截断日志、开启摘要。复跑 21 组时这类失败要单独标记不要算成模型能力失败。Codex 报 wire API 不匹配不要用ANTHROPIC_*回到config.toml调整wire_api并确认模型支持对应协议。成本突然升高先看输入 Token 和重试次数再看模型单价。多数情况下是输入膨胀不是输出变长。9. 把 21 组复跑固化成基线文末 CTA 与执行顺序再用 TaoToken 跑 21 组之后我的结论是harness 选择仍然重要但它重要在成本、重试和上下文管理而不是直接决定成功率排名。对于团队最实用的做法不是争论哪个 harness 最强而是把 21 组复跑固化成自己的成本基线同一任务集、同一成功判定、同一 Token 统计口径按模型和 harness 聚合。执行顺序建议如下。第一步先到模型对话确认当前可用模型和模型 ID避免配置里写错模型名https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentcta_chat21第二步如果你准备长期跑多轮评测先看 Coding Plan评估调用量和成本https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcta_plan21第三步创建并管理 API Key把 Key 占位符替换为YOUR_API_KEY不要写进仓库https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentcta_keys21第四步如果你主要用 Claude Code 复跑对照 Claude Code 文档检查settings.json和ANTHROPIC_*字段https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentcta_doc21最后所有配置都指向同一个 Base URLhttps://taotoken.net/api。Claude Code 用settings.json或ANTHROPIC_*Codex 用config.tomlPi 按自身 provider 配置读取。跑完 21 组后把成功率、输入 Token、输出 Token、重试次数和成本写进同一张表。这样你得到的不是一条转述结论而是一套能继续复跑的本地基线。