Kể từ khi Claude Opus 5 ra mắt ngày 24/7 với giá $5/$25 mỗi triệu token — bằng nửa giá flagship của bản trước — Claude Code đã thêm một tính năng quan trọng hơn cả việc giảm giá: mỗi subagent giờ có thể tự khai modeleffort riêng trong frontmatter, độc lập với mặc định của session. Trường effort chạy từ low → medium → high → xhigh → max, và nó “ghi đè mức effort của session” cho từng subagent.

Tôi đã dành vài tuần qua chạy một setup Claude Code đa agent (fan-out các subagent chuyên biệt cho research, code review, và verification) và cấu hình lại xoay quanh tính năng này. Kết quả là một profile chi phí thực sự khác, không chỉ đơn thuần là được giảm giá. Đây là những gì tôi rút ra khi đấu nối nó.

Ý tưởng cốt lõi: effort không phải cùng một nút vặn với chọn model

Rất dễ nghĩ “chọn model nào” và “nên suy nghĩ kỹ đến mức nào” là cùng một đòn bẩy — chọn model rẻ hơn cho task rẻ. Nhưng tham số effort của Opus 5 là một trục thứ hai, độc lập: nó kiểm soát mức token chi cho mỗi request trong cùng một model, chứ không phải chạy model nào. Nghĩa là bạn có mức kiểm soát chi tiết hơn nhiều so với chỉ đổi model, và nó kết hợp được với việc chọn model chứ không thay thế nó.

Một bảng mặc định khả dụng, dựa trên hình dạng của task chứ không phải “độ quan trọng” mơ hồ:

Dạng taskEffortVì sao
Phân loại, trích xuất, routing, việc khối lượng lớn phạm vi rõlowAnthropic nêu rõ đây là trường hợp phù hợp
Sub-task phạm vi hẹp trong một plan lớn hơnlowAgent lập plan đã làm phần reasoning khó rồi
Việc agentic thông thường, knowledge taskmediumMặc định cho công việc subagent “bình thường”
Coding khó, phân tích tinh tếhighTier mặc định cho đa số subagent coding
Coding chạy dài, gọi tool lặp lại, khám phá sâuxhighDành cho vấn đề thực sự khó, nhiều bước
Vấn đề frontier hiếm gặpmaxDùng hạn chế — đây là tier đắt nhất

Ví dụ trong định nghĩa subagent

---
name: pr-triage
description: Phân loại PR mới theo mức rủi ro và route sang subagent reviewer phù hợp
model: claude-opus-5
effort: low
---
---
name: architecture-reviewer
description: Review sâu các thay đổi kiến trúc xuyên suốt trước khi merge
model: claude-opus-5
effort: xhigh
---

Hai subagent, cùng model, nhưng chi phí mỗi lần gọi khác nhau rất nhiều, vì hình dạng task khác nhau. Trước khi tính năng này ra mắt, đòn bẩy duy nhất là đổi hẳn model — nghĩa là hoặc trả dư tiền cho triage, hoặc thiếu sức cho architecture review.

Sai lầm tôi mắc phải lúc đầu: set effort theo vai trò agent, không theo hình dạng task

Lần đầu tôi map effort theo danh tính agent — “research agent” luôn chạy medium, “code review agent” luôn chạy high. Đó là trục sai. Một code review agent triage một lỗi typo một dòng không cần effort high hơn gì so với một research agent đang tổng hợp sâu từ nhiều nguồn cần giữ ở medium. Cách sửa là route effort động theo hình dạng của task, đánh giá cho từng lần gọi, thay vì cố định trong frontmatter tĩnh của subagent:

function selectEffort(task: SubagentTask): EffortLevel {
  if (task.isHighVolume && task.isWellScoped) return "low";
  if (task.isPartOfLargerPlan && task.scopeIsNarrow) return "low";
  if (task.isArchitectural || task.isLongHorizon) return "xhigh";
  if (task.requiresDeepAnalysis) return "high";
  return "medium";
}

Nghĩa là giá trị effort: trong frontmatter thực chất chỉ là mặc định, còn giá trị thật sự được set theo từng lần gọi khi tầng orchestration của bạn có nhiều ngữ cảnh hơn những gì định nghĩa tĩnh của subagent có thể mã hóa. Frontmatter tĩnh ổn với các subagent mục đích đơn (như ví dụ PR triage ở trên, nơi mọi lần gọi đều thực sự là low-effort). Nó sẽ gãy với các subagent được tái sử dụng trên nhiều mức độ khó khác nhau.

Khoản tiết kiệm thực sự nằm ở đâu

Chạy cách này trên một workflow fan-out thật (review có cấu trúc trên bốn chiều, mỗi chiều spawn subagent verification) trong hai tuần:

  • Các subagent triage và routing giảm từ medium xuống low — không thấy suy giảm chất lượng đo được, vì các task này thực sự mang tính máy móc.
  • Các subagent verification (những agent kiểm tra lại phát hiện của agent khác) vẫn giữ high, vì một verifier rẻ chỉ đóng dấu cho qua sẽ phá vỡ mục đích của việc verify đối kháng.
  • Subagent duy nhất tôi nâng lên, thành xhigh — một agent lập kế hoạch migrate codebase chạy dài — thực sự cho ra kế hoạch tốt hơn đo được, bắt được lỗi hỏng xuyên file mà effort high đã bỏ sót hai lần liên tiếp.

Hiệu ứng ròng: tổng chi phí token cho mỗi chu kỳ review đầy đủ giảm xuống, vì tầng triage khối lượng lớn rẻ hơn, trong khi tầng quan trọng về độ chính xác đắt hơn nhưng chạy ít hơn nhiều. Đó chính là hình dạng bạn muốn — chi phí bám theo hình dạng task, không phải số lượng agent.

Kết luận cho một hệ thống đa agent

Nếu bạn đang chạy Claude Code với bất kỳ hình thức fan-out subagent nào, hãy coi effort là một quyết định routing bạn đưa ra cho từng task, giống cách bạn route giữa các tier model. Cám dỗ là set một lần cho mỗi subagent rồi thôi — nhưng chính các subagent được tái sử dụng trên nhiều mức độ khó là nơi một effort tĩnh hoặc trả dư tiền cho case dễ, hoặc thiếu sức cho case khó. Cái nút vặn này chỉ đáng công đấu nối nếu bạn thực sự nối nó với hình dạng task, chứ không phải danh tính agent.

Nguồn: Claude Platform Docs — Prompting Claude Opus 5, Claude Opus 5 effort levels: cut token spend, Claude Code Model Selection Guide

Xuất nội dung

Bình luận