efficient-dispatch

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

efficient-dispatch - routed, measured, verified

efficient-dispatch——可路由、可计量、可验证

The main model is the orchestrator and Q&A reviewer. Mechanical work runs on cheaper models - and unlike guidance-only approaches, every claim here is checkable against your own ax graph.

主模型作为编排者与问答审核方，机械性工作交由更廉价的模型处理——与仅提供指导的方案不同，这里的每一项成本优化都可通过你自己的ax图表进行核查。

The split

核心拆分

Two axes. First, main model vs subagent: the main model orchestrates and reviews; mechanical work goes to subagents. Second, and the one that actually controls spend - the tier of each subagent dispatch:

Implementer subagents (well-specified plan tasks, mechanical edits, search, bulk transforms) → dispatch with model: sonnet
(or haiku for pure search/locate, per the table).
Reviewer / judgment subagents (quality / PR / final / adversarial / code review, design, audit, architect, critique, judge) → keep the strong model: inherit the main model, or set
```
model: opus
```
/
```
fable
```
explicitly. Review is the catch-rate gate; a cheap reviewer misses real bugs.

Get this backwards and you pay twice: in one ax session implementers ran on the expensive inherited model while reviewers were sent to a cheap one - ~$130 over, weaker catch rate, three fix rounds (memory

feedback-review-gets-strong-model

). The default-inherit trap is implementers, not reviewers: a forgotten

model:

on an

implement …

dispatch silently runs expensive. Set it.

Main model keeps (never dispatched at all): decomposition, architecture and product tradeoffs, plan synthesis, judging conflicting subagent reports, final integration, taste-heavy design/copy.

核心分为两个维度：第一，主模型 vs 子Agent：主模型负责编排与审核，机械性工作交由子Agent处理；第二，也是真正控制成本的关键——子Agent调度的模型层级：

实现类子Agent（任务计划明确的工作、机械性编辑、搜索、批量转换）→ 调度时指定**
```
model: sonnet
```
**（纯搜索/定位任务可使用haiku，详见下方表格）。
审核/判断类子Agent（质量/PR/最终/对抗性/代码审核、设计、审计、架构设计、点评、判定）→ 保留高性能模型：继承主模型，或显式设置
```
model: opus
```
/
```
fable
```
。审核是错误拦截的关键环节，廉价模型作为审核方会遗漏真实问题。

若搞反两者的模型配置，你将付出双倍代价：某ax会话中，实现类任务使用了昂贵的继承模型，而审核类任务却被分配给廉价模型——额外花费约130美元，错误拦截能力更弱，还需要三轮修复（对应记忆项

feedback-review-gets-strong-model

）。默认继承模型的陷阱出现在实现类任务而非审核类：若在

implement …

调度中忘记设置

model:

，会默认使用昂贵模型运行。因此务必显式设置。

主模型保留的工作（绝不调度出去）：任务分解、架构与产品权衡、计划合成、对子Agent冲突报告的判定、最终集成、注重品味的设计/文案工作。

Isolate heavy context (the second reason to dispatch)

隔离大体积上下文（调度的第二个原因）

Cost-tier is one reason to dispatch. The other is context isolation - and it applies even when the work needs the strong model. A large input read into the main thread does not cost once: it sits in the context window and is re-sent as input on every later turn. A 0.5 MB screenshot Read on turn 5 of a 40-turn session is re-billed ~35 times and crowds out earlier reasoning.

The biggest offender is images. Reading screenshots for visual judgment (does this match the spec? rate this design, find the visual bug) floods the main context with vision tokens that persist for the rest of the session. Route it:

Dispatch a subagent that returns the judgment as text. The subagent pays the vision tokens in its own short-lived context and returns a verdict; the main thread keeps the cheap text, never the image bytes. Use the strong model for the subagent if the judgment is hard - the win here is isolation, not tier.
When to route: the image (or any large output) would otherwise persist across many later main-thread turns AND the question is a returnable verdict.
When NOT to: tightly iterative visual exploration (look, tweak, look again interleaved with main reasoning - the round-trips cost more than they save), read-once-then-done short sessions (no persistence tail), or when you cannot state the judgment criteria up front (the text verdict is lossy).

Same logic applies to any bulky tool output you only need a conclusion from: giant logs, large query dumps, full-file reads for one fact. If you need the answer, not the bytes, dispatch for it.

成本层级是调度的一个原因，另一个原因是上下文隔离——即使工作需要高性能模型也适用。大体积输入加载到主线程后，并非仅收取一次费用：它会留在上下文窗口中，后续每一轮交互都会重新作为输入发送。在一个40轮的会话中，第5轮读取的0.5MB截图会被重复计费约35次，还会挤占早期推理的空间。

最典型的场景是图片。读取截图进行视觉判断（是否符合规格？评价设计、查找视觉bug）会让主线程上下文充满视觉token，并在整个会话中持续存在。此时应进行路由处理：

调度子Agent返回文本形式的判断结果。子Agent在自身短生命周期的上下文中支付视觉token费用，返回判定结论；主线程仅保留低成本的文本，不会留存图片字节。若判断难度高，可为子Agent使用高性能模型——此处的优势在于隔离而非成本层级。
何时路由：图片（或任何大体积输出）会在后续多轮主线程交互中持续存在，且问题可转化为可返回的判定结论时。
何时不路由：紧密迭代的视觉探索（查看、调整、再查看，与主线程推理交替进行——往返开销大于节省的成本）、读取一次即结束的短会话（无持续计费的尾部开销），或无法预先明确判断标准时（文本结论会丢失信息）。

同样的逻辑适用于任何你只需要结论的大体积工具输出：庞大的日志、大型查询结果、为获取单个事实而读取的完整文件。若你只需要答案而非原始数据，就进行调度处理。

Routing table

路由表

Source of truth:

~/.ax/hooks/routing-table.json

(regenerate with

ax dispatches compile-routing

). Consult it when present; these built-ins mirror it:

class	description pattern	model
spec-review	`^spec review`	sonnet
search-locate	`^(pattern-find\|locate\|find\|map\|sweep\|grep)`	haiku
research	`^(research\|investigate docs\|study)`	sonnet
well-specified-impl	`^implement`	sonnet
bulk-mechanical	`^(write announcements\|regenerate\|standardize\|merge main)`	sonnet
task-N-impl	`^Task \d+:`	sonnet
bug-fix	`^Fix\s`	sonnet
feature-add	`^Add\s`	sonnet
agent types	Explore, codebase-locator, codebase-pattern-finder → haiku; codebase-analyzer → sonnet

Anything unmatched: leave the model unset only if the work genuinely needs main-model judgment - otherwise pick sonnet.

权威来源：

~/.ax/hooks/routing-table.json

（可通过

ax dispatches compile-routing

命令重新生成）。若该文件存在，请以其为准；以下内置规则与该文件内容一致：

类别	描述模式	模型
spec-review	`^spec review`	sonnet
search-locate	`^(pattern-find\|locate\|find\|map\|sweep\|grep)`	haiku
research	`^(research\|investigate docs\|study)`	sonnet
well-specified-impl	`^implement`	sonnet
bulk-mechanical	`^(write announcements\|regenerate\|standardize\|merge main)`	sonnet
task-N-impl	`^Task \d+:`	sonnet
bug-fix	`^Fix\s`	sonnet
feature-add	`^Add\s`	sonnet
agent types	Explore、codebase-locator、codebase-pattern-finder → haiku；codebase-analyzer → sonnet

未匹配到任何规则的情况：仅当工作确实需要主模型的判断能力时，才不设置模型；否则请选择sonnet。

Dispatch discipline

调度规范

Decompose into independent slices BEFORE reading everything yourself; run slices as parallel subagents in isolated worktrees when they edit files.
Every brief is self-contained: repo path, exact objective, in/out of scope, evidence format to return (files, line refs, commands, diffs, failures), verification commands, stop conditions.
Set
```
model:
```
explicitly on every mechanical dispatch. The route-dispatch hook is quota-aware and ADVISORY (Claude Code hooks cannot enforce model on subagent dispatches - they can only inject context via additionalContext): in conserve mode it advises re-dispatching a forgotten mechanical dispatch with
```
model:<cheaper>
```
; near a 7d quota reset (splurge) it stays quiet so work runs on the strong inherited model; it advises when judgment work (review/design/audit) is sent on a cheap model. Real enforcement is your discipline + setting
```
model:
```
explicitly on every dispatch. Treat the advisory as a re-dispatch signal, not noise.
Workflow scripts (
```
.claude/workflows/*.js
```
) run sandboxed and cannot import ax code. Set
```
model:
```
on every
```
agent(...)
```
call by hand, per
```
ax routing show
```
: mechanical stages →
```
model: 'sonnet'
```
; judgment/review stages → keep the strong model.
```
routing-tune.workflow.js
```
is the reference. In-tree Effect/axctl code that dispatches should call
```
resolveDispatchModel
```
(from
```
@ax/hooks-sdk
```
) instead of hardcoding.
Treat subagent reports as leads. Before acting on a high-impact finding or declaring done, reopen the cited files and re-run the key verification yourself. Expect to find one real bug per delegated phase.

在自行读取所有内容之前，将任务分解为独立模块；当模块涉及文件编辑时，在独立工作树中以并行子Agent的方式运行。
每个任务说明必须自包含：仓库路径、明确目标、范围边界、需返回的证据格式（文件、行引用、命令、差异、失败信息）、验证命令、停止条件。
对每一次机械性调度都显式设置
```
model:
```
。route-dispatch钩子具备配额感知能力，仅提供建议（Claude Code钩子无法强制子Agent使用指定模型——只能通过additionalContext注入上下文）：在节约模式下，它会建议将遗漏设置模型的机械性调度重新指定为
```
model:<cheaper>
```
；临近7天配额重置时（宽松模式），它会保持静默，让工作在高性能继承模型上运行；当判断类工作（审核/设计/审计）被分配给廉价模型时，它会给出建议。真正的强制约束来自你的规范执行——对每一次调度都显式设置
```
model:
```
。请将该建议视为重新调度的信号，而非干扰信息。
工作流脚本（
```
.claude/workflows/*.js
```
）运行在沙箱环境中，无法导入ax代码。请手动为每一次
```
agent(...)
```
调用设置
```
model:
```
，遵循
```
ax routing show
```
的结果：机械性阶段 →
```
model: 'sonnet'
```
；判断/审核阶段 → 保留高性能模型。
```
routing-tune.workflow.js
```
是参考示例。项目内的Effect/axctl调度代码应调用
```
resolveDispatchModel
```
（来自
```
@ax/hooks-sdk
```
）而非硬编码模型。
将子Agent的报告视为线索。在采取高影响的行动或宣布任务完成前，请重新打开引用的文件并自行运行关键验证步骤。预计每个委托阶段会发现至少一个真实问题。

Measure (what guidance-only skills can't do)

计量（仅提供指导的技能无法实现）

```
ax dispatches --days=7
```
- your inherit rate (target: explicit model on all mechanical classes)
```
ax dispatches --candidates
```
- missed routings + est savings, repriced from real token buckets
```
ax cost split --days=7
```
- main vs subagent spend by model; the dominant cost is usually main-loop cache reads, so move tool-heavy loops (build/test cycles, browser QA) into subagents entirely
```
ax cost images --days=7
```
- image-read context per session, main vs subagent. High main-thread MB = screenshots persisting in the main window; route that visual judgment to a subagent (see "Isolate heavy context" above)
```
ax improve recommend
```
- surfaces a routing proposal automatically when missed savings accumulate

```
ax dispatches --days=7
```
- 查看你的模型继承率（目标：所有机械性任务类都显式指定模型）
```
ax dispatches --candidates
```
- 查看遗漏的路由机会及预估节省成本，基于真实token桶重新计算价格
```
ax cost split --days=7
```
- 按模型统计主模型与子Agent的成本占比；主要成本通常来自主循环的缓存读取，因此请将工具密集型循环（构建/测试周期、浏览器QA）完全迁移到子Agent中
```
ax cost images --days=7
```
- 按会话统计主线程与子Agent的图片读取上下文体积。主线程MB数值高意味着截图持续留在主上下文窗口中；应将此类视觉判断任务路由到子Agent（详见上文「隔离大体积上下文」部分）
```
ax improve recommend
```
- 当遗漏的成本节省累积到一定程度时，自动给出路由优化建议

Verify

验证

After adopting this skill, compare windows:

ax cost split

+ inherit rate before vs after. If the inherit rate doesn't drop, the routing isn't happening - check

ax hooks backtest ~/.ax/hooks/route-dispatch.ts --days=7

and whether dispatches are bypassing the table.

采用该技能后，对比前后周期的数据：

ax cost split

结果 + 模型继承率。若继承率未下降，说明路由未生效——请检查

ax hooks backtest ~/.ax/hooks/route-dispatch.ts --days=7

的结果，以及调度是否绕过了路由表。