Tác giả bài gốc: Thariq Shihipar (Member of Technical Staff). Đăng ngày 25/09/2026 trên claude.dev.
Một trong những điểm hay nhất của các model Claude mới nhất là cách chúng đáp ứng mức effort mà không làm mất hiệu lực prompt cache trong Claude Code, nhưng mình đã nhận được rất nhiều câu hỏi từ người dùng về điều này. Effort là gì thực sự, và khi nào bạn nên dùng mức effort nào? Tại sao chúng ta lại cần effort?
Để trả lời, mình quyết định đào sâu vào các eval và tự thử nghiệm effort trong những công việc thông thường.
Nhìn chung, mình thấy effort là một cách rất hay để điều chỉnh mức độ kiểm chứng, kiểm thử trường hợp biên (edge case) mà Claude thực hiện, cũng như mức độ nó sử dụng phán đoán của chính mình. Tăng effort cho kết quả tốt hơn trong những lĩnh vực mà kiểm chứng và kiểm thử trường hợp biên hữu ích hơn, như phần cứng, code review và bảo mật.
Với công việc kỹ thuật phần mềm thông thường, mình đang dùng một vòng lặp: để model phỏng vấn mình rồi triển khai ở mức low, review những gì nó xây dựng, sau đó kiểm chứng ở mức high.
Effort là gì?
Nhìn chung, effort cho model biết gần đúng lượng tài nguyên tính toán mà bạn muốn nó dành cho nhiệm vụ. Nó phần nào liên quan đến cách bạn hình dung độ khó của nhiệm vụ đó.
Hãy nghĩ thế này: nếu ai đó yêu cầu bạn làm một việc trong 12 giờ liên tục, bạn có thể cho rằng họ chỉ muốn bạn hoàn thành việc đó và cố gắng hết sức. Nếu ai đó yêu cầu bạn làm cùng việc đó trong 1 giờ, bạn sẽ cố đưa cho họ phiên bản tốt nhất đáp ứng yêu cầu, rồi chờ tiếp tục cải tiến từ đó.
Hoặc bạn có thể phản hồi rằng nhiệm vụ này cần ít nhất 3 giờ, rồi làm trong 3 giờ để bàn giao.
Bạn nên nghĩ về effort theo cách tương tự. Claude luôn cố gắng thực hiện nhiệm vụ của bạn một cách hợp lý, nhưng effort cao hơn sẽ khiến Claude chủ động làm nhiều hơn để đưa ra phán đoán và kiểm chứng.
Đường cong effort
Đường cong effort của Fable 5.1 và Opus 5.5 là những đường cong tốt nhất của chúng tôi từ trước đến nay: ở mỗi mức, điểm benchmark và lượng token tiêu thụ đều tăng lên.
Hình: Chỉ Terminal-Bench 3.0: tỷ lệ lượt thử thành công so với trung vị số token trên mỗi lượt thử, dùng thang log, cho Opus 5.5, Fable 5.1, Opus 5 và Fable 5, với một điểm cho mỗi mức effort từ low đến max. Opus 5.5 đạt điểm cao nhất ở mọi mức, từ 36.6% ở low đến 65.7% ở max, và Fable 5.1 đạt điểm cao hơn Opus 5 và Fable 5 ở mọi mức. Opus 5.5 ở high ngang với Fable 5.1 ở max (58.9% so với 58.0%) với lượng token chỉ bằng một nửa. Fable 5 chững lại ở 43.4% từ xhigh đến max.
Terminal-Bench 3.0, cùng 70 nhiệm vụ cho mọi model (loại 4 nhiệm vụ GPU). Opus 5.5 chạy sau khoảng ba tuần, với câu trả lời giới hạn ở 128k token và không có quyền truy cập GitHub hay PyPI; mức max của Opus 5 là lượt chạy effort-120 của model đó.
Nhưng trong thực tế, điều này có nghĩa gì? Để đánh giá, mình thử một số nhiệm vụ ở các mức effort khác nhau và xem xét kỹ các benchmark.
Xây dựng với effort
Cách tốt nhất để hiểu model hoạt động thế nào là làm thử nghiệm. Mình thử làm cùng những nhiệm vụ ở nhiều mức effort khác nhau trên Opus 5.5 để hiểu nó sẽ làm những gì. Mình thử trên nhiều loại công việc, nhưng ở đây sẽ minh họa bằng vài ví dụ đơn giản.
Nhiệm vụ xây dựng chưa được mô tả đầy đủ
Nếu mình yêu cầu Claude “xây dựng một ứng dụng theo dõi thể lực và tập luyện cá nhân”, effort làm thay đổi rất lớn mức độ hoàn thiện của ứng dụng, nhưng cũng khiến Claude đưa ra nhiều lựa chọn hơn trong quá trình làm. Ở mức low, ứng dụng thể lực chỉ có nhật ký và một biểu đồ đơn giản. Ở các mức effort cao hơn, ứng dụng phức tạp hơn và có thêm chi tiết. Ở mức max có một biểu đồ nhiệt.
Hình tương tác: ứng dụng thể lực Claude xây dựng từ prompt một dòng ở mức effort low, medium, high và max, mỗi bản tự trình diễn cách sử dụng. Khám phá trên trang: /blog/claude-dev/spending-your-effort
Nếu mình muốn một nền tảng đơn giản để tiếp tục cải tiến, mức low là đủ. Mức max dành cho lúc mình muốn Claude làm ra kết quả tốt nhất chỉ trong một lần.
Nhiệm vụ thiết kế với một số yêu cầu sơ bộ
Nếu mình có một nhiệm vụ đã được mô tả tương đối rõ nhưng vẫn muốn khám phá thêm cùng Claude thì sao? Chẳng hạn, mình thử yêu cầu nó thiết kế lại menu /config trong Claude Code. Mỗi lượt đều có ý tưởng gần giống nhau: dùng các menu con và cải thiện tìm kiếm.
Ở mức low (mất 1 phút), mình nhận được một bản phác thảo tương tác truyền tải được ý tưởng nhưng nhìn không giống Claude Code lắm.
Ở mức max (mất 28 phút), mình nhận được một mockup trông rất giống Claude Code, cùng một loạt phần trình diễn cho các luồng khác nhau.
Nếu mục tiêu của mình là lặp lại và đưa ra phản hồi, mức low giúp mình đạt được điều đó nhanh hơn nhiều. Nhưng mức max cho mình một thứ trau chuốt hơn nhiều ngay từ đầu. Với nhiệm vụ cụ thể này, mình nghĩ mình thích dùng low để hiểu ý tưởng của Claude hơn.
Hình tương tác: menu /config của Claude Code được thiết kế lại ở mức effort low, medium, high và max, mỗi lần hiển thị một màn hình hoạt động thực. Khám phá trên trang: /blog/claude-dev/spending-your-effort
Nhiệm vụ xây dựng được mô tả rất chi tiết
Nếu mình cung cấp cho Claude thật nhiều chi tiết thì sao? Mình thử yêu cầu Claude phỏng vấn mình thật kỹ về ứng dụng thể lực, rồi đưa bản đặc tả đó cho các model khác nhau triển khai ở các mức effort khác nhau.
Mình thấy rằng khi có bản đặc tả này, các model hành xử giống nhau hơn nhiều. Mình nhận được những thiết kế khá giống nhau và cách triển khai tương tự, nhưng khác ở một số chi tiết; ở mức max, Claude dành thời gian đơn giản hóa vài chi tiết.
Hình tương tác: ứng dụng thể lực được xây dựng từ bản đặc tả qua phỏng vấn ở mức effort low, medium, high và max, hiển thị trong điện thoại và chạy qua một bản demo. Khám phá trên trang: /blog/claude-dev/spending-your-effort
Những điều rút ra
Với công việc kỹ thuật phần mềm thông thường, nhất là làm tính năng mới, mức effort phụ thuộc nhiều vào việc mình muốn tham gia vào quá trình đến đâu. Mức low cho phép Claude phản hồi nhanh với một điểm khởi đầu; các mức effort cao hơn sẽ làm được nhiều việc hơn, nhưng Claude cũng sẽ tự đưa ra nhiều giả định thay mình hơn.
Một vòng lặp phát triển tính năng đặc biệt hiệu quả mà mình đang dùng là:
- Đưa cho Claude một bản đặc tả và yêu cầu nó phỏng vấn mình về bất kỳ chi tiết nào còn thiếu
- Triển khai ở mức low
- Review để bảo đảm nó đã hiểu đúng ý chính, tiếp tục chỉnh sửa ở mức low khi cần
- Kiểm chứng và kiểm thử ở mức high
Mức effort ảnh hưởng đến kết quả của nhiệm vụ khó như thế nào
Nhưng rõ ràng đây là những ví dụ đơn giản mà Claude hoàn toàn đủ khả năng hoàn thành. Còn khi khác biệt nằm ở việc Claude có hoàn thành được nhiệm vụ hay không thì sao?
Để tìm những bài toán khó này, bạn phải tìm đến benchmark, nên mình đào sâu vào một benchmark mình thích: Terminal-Bench 3.0, do cộng đồng đóng góp.
Các bài toán Terminal-Bench 3.0 có thể được chia thành những nhóm lớn như bảo mật, phần cứng, ML, khoa học, phần mềm, vận hành và truyền thông. Bạn có thể xem tất cả bài toán tại đây: https://github.com/harbor-framework/terminal-bench/releases/tag/v3.0.0. Chúng do cộng đồng đóng góp, nên ai cũng có thể tham gia.
Đáng để đọc qua nhằm hình dung loại bài toán mà những model này phải đối mặt. Mình thấy bất ngờ trước phạm vi và mức độ tham vọng của nhiều nhiệm vụ. Chúng phức tạp hơn nhiều so với nhiệm vụ thông thường mình gặp.
Ví dụ, một số nhiệm vụ gồm:
- Phần cứng (
retro-console-soc): xây dựng một máy chơi game 8-bit bằng Verilog, vừa với một FPGA nhỏ và render một ROM thử nghiệm. - Khoa học (
takens-embedding-lean): chứng minh hình thức định lý nhúng của Takens trong Lean 4. - ML (
mp-checkpoint-consolidation): hợp nhất 16 phần của một checkpoint mixture-of-experts thành một file tái tạo được các logits tham chiếu. - Vận hành (
intrastat-meldung): thực hiện trọn quy trình khai báo thống kê thương mại EU cuối tháng cho một công ty. - Truyền thông (
layout-config-recreation): dựng lại một hình ảnh poster dưới dạng file bố cục có thể chỉnh sửa.
Mức effort cao hơn hữu ích khi có nhiều trường hợp biên
Điều chính mình rút ra khi đọc kết quả Terminal-Bench 3.0 là effort cao hơn phù hợp nhất với những nhiệm vụ có nhiều trường hợp biên ẩn.
Một ví dụ rõ ràng là html-js-filter, nhiệm vụ Terminal-Bench 3.0 yêu cầu một bộ làm sạch HTML (HTML sanitizer) loại bỏ mọi cách lén đưa JavaScript vào trang. Fable 5.1 tăng từ 1/5 ở low lên 5/5 ở xhigh.¹
Một lượt thử điển hình ở mức low mất khoảng 2 phút. Mỗi lượt này viết bộ lọc gần như trong một lần, rồi kiểm thử với một trang viết tay duy nhất.
Một lượt chạy effort cao hoàn tất trong khoảng 33 phút. Ở lượt chạy mình lần theo, nó review bản nháp đầu tiên theo hướng tìm cách phá vỡ nó, rồi đọc source của parser đã cài để kiểm tra bug, chạy nhiều test case với dữ liệu sạch cho đến khi đầu ra giống đầu vào, chạy một bộ test XSS chuẩn, và cuối cùng viết một fuzzer tạo tài liệu ngẫu nhiên.
Với một thứ nhiều trường hợp biên như HTML sanitizer, lượng effort thêm này rất đáng. Dùng thêm token để làm kỹ cũng hợp lý với những nhiệm vụ phức tạp có yêu cầu cao khi chạy production, như tối ưu hiệu năng hay review bảo mật.
Nhưng bạn không cần mức effort này cho mọi nhiệm vụ.
Biểu đồ bên dưới cho thấy mọi kết quả Terminal-Bench 3.0 và cách từng lượt thất bại, trên các model và mức effort khác nhau. Nhìn chung, tăng effort có xu hướng giảm thất bại do bỏ sót trường hợp biên (các khối tím), nhưng không khắc phục được khi model chọn sai cách tiếp cận (các khối xanh dương).
Hình tương tác: mọi lượt thử Terminal-Bench 3.0 phân theo cách thất bại, cho từng model và mức effort. Khám phá trên trang: /blog/claude-dev/spending-your-effort
Những nhóm bài toán mà effort có ích
Một trong những điều thú vị nhất mình rút ra khi đánh giá các model này trên Terminal-Bench 3.0 là một số nhóm bài toán hưởng lợi từ effort nhiều hơn những nhóm khác. Bạn có thể xem chi tiết trong biểu đồ sau:
Hình tương tác: những lĩnh vực mà effort đem lại lợi ích, tỷ lệ thành công theo nhóm nhiệm vụ ở mức effort low và cao nhất, cho từng model. Khám phá trên trang: /blog/claude-dev/spending-your-effort
Để minh họa, mình chọn vài bài toán ở các nhóm khác nhau trong Terminal-Bench 3.0 mà Opus 5.5 thất bại ở mức low nhưng thành công ở mức high — chủ yếu nhờ nó kiểm thử và tính đến các trường hợp biên:
mvcc-lsm-compaction: một nhiệm vụ Terminal-Bench 3.0 yêu cầu sửa bug của storage engine từ báo cáo crash, mà không làm hỏng quá trình nén gộp dữ liệu (compaction). Opus 5.5 tăng từ 0/5 ở low lên 4/5 ở xhigh.
Ở mức low (khoảng một phút mỗi lượt thử), Claude chỉnh sửa code trước khi build hoặc chạy chương trình tái hiện lỗi, và không kiểm tra xem test mới có bắt được bug ban đầu hay không.
Ở mức xhigh (khoảng 11 phút), Claude tái hiện crash trước, viết một test ngẫu nhiên đối chiếu với bản tham chiếu không bao giờ thực hiện compaction, và kiểm tra rằng các test của nó thất bại trên những bản sửa chưa hoàn chỉnh.
cli-2ph-simplex: một nhiệm vụ Terminal-Bench 3.0 yêu cầu một CLI giải bài toán quy hoạch tuyến tính (linear programming), viết bằng Python. Opus 5.5 tăng từ 0/5 ở low lên 5/5 ở high.
Các lượt low viết bộ giải trong một lần, kiểm tra bằng vài bài toán nhỏ rồi dừng ở khoảng 10k token. Trong thông điệp cuối cùng, Claude cảnh báo nó có thể chậm với bài toán lớn, nhưng không kiểm tra.
Trong các lượt high, Claude kiểm thử bộ giải trên các bài toán ngẫu nhiên, đối chiếu với một bộ giải vét cạn riêng, rồi đo thời gian với những bài toán lớn hơn, gặp các trường hợp chạy quá lâu hoặc crash, và làm lại cách tìm kiếm.
gsea-proteomics: một nhiệm vụ Terminal-Bench 3.0 yêu cầu phân tích làm giàu tập hợp gene (gene set enrichment analysis, GSEA) trên dữ liệu proteomics để tìm xem phương pháp xử lý nào trong tám phương pháp tạo ra kết quả giống mô đích. Opus 5.5 tăng từ 0/5 ở low lên 4/5 ở high.
Ở mức low, Claude chọn một cách chuẩn bị dữ liệu nghe có vẻ hợp lý, chạy phân tích chỉ theo cách đó và báo cáo kết quả.
Ở mức high, Claude thử hai cách chuẩn bị dữ liệu, nhận thấy danh sách các phương pháp xử lý có ý nghĩa thống kê thay đổi, rồi đào sâu nguyên nhân trước khi chọn cách đúng.
Nếu có người dùng tham gia vào quá trình, Claude có thể đã hỏi người dùng về cách thiết lập bài toán, nhưng khi không có người dùng tham gia, mức high làm tốt hơn.
Khi nào nên dùng từng mức effort trong Claude Code
Đây là nguyên tắc kinh nghiệm của mình về lúc nên dùng từng mức effort:
- Low: khi mình muốn phản hồi nhanh và có tham gia vào quá trình, chẳng hạn brainstorm, phác thảo, thay đổi đơn giản
- Medium: cho phần lớn công việc kỹ thuật phần mềm thông thường của mình, chẳng hạn triển khai tính năng mới.
- High: cho công việc mà kiểm chứng quan trọng hoặc có các trường hợp biên, chẳng hạn sửa bug trong một codebase đã tồn tại (brownfield).
- Max: khi mình muốn Claude hoạt động hoàn toàn tự chủ để giải bài toán khó, chẳng hạn xây dựng và kiểm chứng một ứng dụng từ đầu đến cuối, tìm lỗ hổng bảo mật trong phần mềm trọng yếu.
Hãy thử thay đổi effort cho Opus 5.5 và Fable 5.1 tùy theo nhiệm vụ, hoặc ngay cả giữa cuộc trò chuyện bằng cách dùng /effort trong Claude Code, và cho mình biết liệu điều này có khớp với trực giác của bạn không.
¹ Lưu ý về các con số: chúng đến từ những lượt chạy nội bộ của chúng tôi, 5 lượt thử cho mỗi nhiệm vụ, với các biện pháp can thiệp an toàn của production được tắt cho Fable 5.1; trong các sản phẩm Claude, cơ chế bảo vệ của Fable 5.1 chuyển một số yêu cầu bảo mật cho Opus. Các nhiệm vụ bảo mật cũng chạy mà không có quyền truy cập internet, nên số lượt theo từng nhiệm vụ ở đây sẽ không khớp với bảng xếp hạng công khai hoặc bài viết ra mắt. Các ví dụ phân tích cụ thể đến từ những lượt chạy riêng lẻ, một số ở các mức effort trung gian.