ECC 按难度路由 Haiku/Sonnet/Opus:Agent 的 token 账单能省多少 ECC 按难度路由 Haiku/Sonnet/OpusAgent 的 token 账单能省多少【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC用 Claude Code、Codex、Cursor 这类 Agent 干活最常见的抱怨不是模型不够聪明而是账单跑得太快。不少人干脆全程锁死 Opus把简单任务也当架构题做也有人为了省钱全局降级到 Haiku结果复杂任务反复返工成本不降反升。问题不在模型而在路由什么时候该用哪个档位的模型应该由任务难度决定而不是靠手感。ECCEverything Claude Code把这件事做成了显式的基础设施内置/model-route命令负责按任务复杂度与预算推荐模型档位cost-aware-llm-pipeline技能给出可落地的选择器代码与预算护栏token-optimization指南则直接把推荐配置写进settings.json。本文从仓库源码出发拆解这套三层路由规则量化它能省下多少 token 账单并讨论路由误判的边界成本怎么控制。路由规则三层模型各司其职ECC 的路由哲学很朴素把最便宜且能完成任务的模型分配给当前任务。在 模型路由命令 中路由启发式被定义成三条明确规则haiku确定性、低风险的机械性变更sonnet实现和重构的默认选择opus架构设计、深度评审、模糊需求。性能优化规则 给出了对应的模型画像Haiku 4.5 具备 Sonnet 约 90% 的能力成本却只有三分之一适合频繁调用的轻量级子代理、结对编程和代码生成Sonnet 5 是最佳编码模型承担主要开发工作与多智能体编排Opus 5 只留给复杂架构决策、最高级别推理与研究分析。agentic-engineering 技能 把同一张映射表落到了工程流水线上模型适用任务Haiku分类、样板转换、狭窄编辑Sonnet实施和重构Opus架构、根因分析、多文件不变量这套规则不是静态配置而是可调用的决策命令。/model-route支持--budget low|med|high预算参数并要求输出四样东西推荐模型、置信度、选择理由、以及首轮失败时的回退模型——这条回退设计直接关系到后面要讲的降本边界。账单差距有多大按 ECC 价格参考实测估算空谈规则没用直接看数字。成本感知型 LLM 流水线技能 附了一张 2026 年价格参考表模型输入美元/百万令牌输出美元/百万令牌相对成本Haiku 4.5$1.00$5.001xSonnet 5$2.00$10.002xSonnet 4.6$3.00$15.003xOpus 4.8$5.00$25.005xOpus 4.0 / 4.1 (legacy)$15.00$75.0015x以最典型的实现一个带测试的功能模块工作流为例。一次实现任务大约消耗 50K 输入 5K 输出令牌一次子代理代码库探索约 30K 输入 1K 输出全 Opus实现任务50K×$5/M 5K×$25/M ≈$0.375/次探索任务 ≈$0.175/次路由策略探索走 Haiku、实现走 Sonnet实现任务 ≈$0.15/次探索任务 ≈$0.035/次按每天 20 次实现 40 次探索、每月 22 个工作日算全 Opus 月账单约$319路由后约$97降幅接近70%。这与仓库文档的两个关键数字互相印证model从 opus 切到 sonnet 可带来约60% 成本降低并覆盖 80% 编码任务子代理切到 Haiku 则约便宜 80%见 令牌优化指南。路由的另一半收益藏在隐藏成本里Claude 的扩展思考最多会为内部推理预留 31,999 个输出令牌。把MAX_THINKING_TOKENS从默认 31,999 压到 10,000单个请求的隐藏思考成本能降约 70%——这条与模型路由正交但叠加后效果更明显// ~/.claude/settings.json —— 摘自 docs/token-optimization.md { model: sonnet, env: { MAX_THINKING_TOKENS: 10000, CLAUDE_CODE_SUBAGENT_MODEL: haiku } }注意其中CLAUDE_CODE_SUBAGENT_MODEL: haiku主模型与子代理模型分离是 ECC 路由策略在配置层的落地——探索、读文件、跑测试这类低上下文敏感工作交给 Haiku主线程的深度推理仍留在 Sonnet。在 自主循环技能 中这套思路被写成可编排的管道# Research with Opus (deep reasoning) claude -p --model opus Analyze the codebase architecture and write a plan for adding caching... # Implement with Sonnet (fast, capable) claude -p Implement the caching layer according to the plan in docs/caching-plan.md... # Review with Opus (thorough) claude -p --model opus Review all changes for security issues, race conditions, and edge cases...同一份文档还给出了更激进的分层在简单循环中简单任务直接路由到 Haiku复杂任务才交给 Opus——不是所有任务都用最强模型而是每个任务用刚好够用的模型。从规则到流水线选择器代码与预算护栏规则说清楚后剩下的是工程化。cost-aware-llm-pipeline技能给出了一组可直接复用的实现核心是一个复杂度驱动的模型选择器源码见技能文档MODEL_SONNET claude-sonnet-5 MODEL_HAIKU claude-haiku-4-5-20251001 _SONNET_TEXT_THRESHOLD 10_000 # chars _SONNET_ITEM_THRESHOLD 30 # items def select_model( text_length: int, item_count: int, force_model: str | None None, ) - str: Select model based on task complexity. if force_model is not None: return force_model if text_length _SONNET_TEXT_THRESHOLD or item_count _SONNET_ITEM_THRESHOLD: return MODEL_SONNET # Complex task return MODEL_HAIKU # Simple task (3-4x cheaper)这段代码展示了路由判定的可度量性阈值10K 字符、30 个条目把任务难度从主观判断变成客观输入force_model则保留人工强制覆盖的出口。技能文档强调的最佳实践里有一条值得反复读从最便宜的模型开始仅在达到复杂度阈值时才路由到昂贵的模型记录模型选择决策以便根据实际数据调整阈值。单有路由还不够流水线还配了四件套不可变的成本跟踪CostTracker用 frozen dataclass 记录每次调用的model / input_tokens / output_tokens / cost_usd每笔调用返回新 tracker永不原地变更状态便于审计与调试窄范围重试只对APIConnectionError / RateLimitError / InternalServerError这类暂时性错误做指数退避重试认证错误、错误请求直接快速失败不在永久性故障上浪费预算提示词缓存对超过 1024 令牌的系统提示词加cache_control: ephemeral长提示词只付一次费用预算硬护栏over_budget时抛出BudgetExceededError——处理批次前先设预算上限宁可提前失败也不超支。这四者组合成一个process()流水线先路由模型再查预算然后带重试与缓存调用最后记账。路由省的是单价重试和缓存省的是浪费预算护栏兜底的是失控。降本的边界误判与返工成本怎么控路由省钱的前提是判得准。一旦 Haiku 接了本该交给 Opus 的任务结果就是产出质量不达标、返工重做——返工不仅抹平省下的差价还会多付一轮上下文积累的输入令牌。ECC 对这个问题有三道防线第一道只升级、不赌运气。agentic-engineering 技能 的成本纪律写得很克制仅当较低层级的模型失败且存在清晰的推理差距时才升级模型层级。 也就是说路由不是一次性的预测而是带反馈的迭代低档模型失败了记录失败原因再决定是否升级。同时/model-route命令强制输出回退模型从设计上承认首轮判断可能失败让失败路径变得可控而非随机。第二道把草率变成显式的清理环节。自主循环技能 里的去草率化模式De-sloppify是给路由误判兜底的经典做法任何实现步骤之后跟一个独立的清理步骤——Review all files changed by the previous commit. Remove any unnecessary type tests, overly defensive checks...Run the test suite after cleanup. 用低档模型省下的钱一部分预算被显式拨给质检环节把隐性返工转成可控成本。第三道控制并行与上下文消耗的隐形放大。仓库 README 的 令牌优化章节 明确警告代理团队会生成多个上下文窗口每个团队成员独立消耗令牌。仅用于并行性能提供明显价值的任务对于简单的顺序任务子代理更节省令牌。 同样的逻辑适用于 MCP每个 MCP 工具描述都会从 200K 上下文窗口里扣令牌可能把可用窗口压到约 70K——启用超过 10 个 MCP 本身就是一种隐性账单。路由省的是单价控制上下文和并行才是省总量。最后这一切都要有数据闭环。/cost-report命令命令定义从 ECC 的stop:cost-tracker钩子写入的~/.claude/metrics/costs.jsonl读取每会话快照按天、按模型、按会话聚合出今日/昨日/总计成本并支持 CSV 导出——按模型排名这一栏就是检验路由策略是否生效的仪表盘如果 Opus 的占比居高不下说明阈值判松了如果 Haiku 的返工率上升说明判严了。阈值、预算、回退模型全都该用真实账单数据去调而不是拍脑袋。模型路由的本质是把用哪个模型从一次性的感性决策变成可度量、可回退、可审计的工程决策。ECC 给出的不是一条省钱的捷径而是一套让省钱这件事本身可被验证的方法论规则定义分层阈值驱动选择护栏限制失控账单反馈校准。省下来的不只是那 70% 的美元符号更是把 Agent 从碰运气推向可预期的那一步。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考