The thinking lever

• Alexander Bricken từ đội applied AI research của Anthropic giải thích cách Claude dùng test-time compute (tính toán lúc suy luận) để tiêu nhiều token hơn và giải bài khó hơn, cùng best practice về effort level và budget.
• Demo mô phỏng giao thông ở mức low, high và max trên Opus 4.7 cho thấy nhiều token cho kết quả tốt hơn rõ rệt, nhưng có lợi ích biên giảm dần (max dùng ~10x token chỉ để cải thiện chút ít).
• Bài nói trình bày sự tiến hóa từ interleaved thinking tới adaptive thinking (Claude tự quyết khi nào và có suy nghĩ hay không), lập luận rằng nút bật/tắt thinking là proxy kém cho effort, và đưa quy tắc: bật thinking bất cứ khi nào có thể, dùng eval để tìm effort phù hợp, ưu tiên model lớn khi cần trí tuệ, mặc định extra high.

• Hiểu test-time compute (tính toán lúc suy luận): tiêu nhiều token hơn lúc runtime để model suy luận trước khi trả lời; như train-time compute, nó tăng trí tuệ trên mọi lĩnh vực.
• Quan sát demo Opus 4.7 chạy cùng prompt (mô phỏng giao thông đường một chiều) ở low (~50s, ~4.600 token), high (~2x thời gian và token, chi tiết hơn) và max (~10x token, kết quả tốt nhất) — minh họa lợi ích biên giảm dần.
• Nhận ra test-time compute có ba dạng: thinking (không gian suy luận/nháp), tool calling (giao diện với thế giới ngoài) và text (output cho người dùng).
• Kiểm soát test-time compute theo hai cách: effort (núm xoay low đến max) và budget (giới hạn max-token hoặc task budget trong API).
• Theo dõi tiến hóa của thinking: từ luồng cố định nghĩ-rồi-làm, tới interleaved thinking (một bước nghĩ sau mỗi tool call), tới adaptive thinking — Claude tự chọn nghĩ/gọi tool/xuất text theo thứ tự bất kỳ, có thể không nghĩ; benchmark cho thấy adaptive thinking Pareto-efficient so với interleaved.
• Đừng coi nút bật/tắt thinking là cách biểu đạt effort: tắt extended thinking không nghĩa là "nghĩ ít hơn" mà là gỡ bỏ một năng lực cốt lõi — tốt hơn là để Claude biết nó có thể nghĩ và điều khiển độ dài qua effort, như cho Claude tool search thay vì ép luôn/không bao giờ search.
• Áp dụng quy tắc effort: max cho task khó nhất, cần trí tuệ (lợi ích biên giảm); extra high là mặc định của Claude Code và claude.ai (tradeoff tốt nhất); high nếu use case cần bất kỳ trí tuệ nào; medium/low cho task nhạy độ trễ như phân loại, tóm tắt, trích xuất dữ liệu (ví dụ Claude Plays Pokémon ở low tìm ra chiến lược đường tắt độc đáo).
• Chọn model lớn vs model nhỏ effort cao: nếu task cần bất kỳ trí tuệ nào, thường nên dùng model lớn dù effort thấp (mô phỏng Haiku 4.5 kém rõ rệt); dùng model nhỏ cho task ít trí tuệ, và dùng eval để tìm cân bằng lý tưởng.

• test-time compute — tiêu nhiều token lúc suy luận (runtime) để model suy luận trước khi trả lời
• train-time compute — tính toán lúc huấn luyện (model lớn hơn/nhiều tham số hơn)
• effort — núm xoay (low đến max) điều khiển Claude làm bao lâu và tiêu bao nhiêu token
• budget — ràng buộc chặt hơn cho công việc của Claude (max-token hoặc task budget trong API)
• thinking — không gian nháp/suy luận của Claude
• interleaved thinking — chế độ có một bước nghĩ sau mỗi tool call
• adaptive thinking — Claude tự quyết khi nào và có nghĩ/gọi tool/xuất text hay không, theo thứ tự bất kỳ
• lợi ích biên giảm dần — effort cao hơn cho thêm ít hiệu năng trên mỗi token thêm vào
• Claude Plays Pokémon — eval cho Claude chơi Pokémon Red bằng tool nút/vision

Reasoning model và Test-time compute

Một bước phát triển then chốt của LLM là reasoning model — dùng test-time compute để tiêu nhiều token hơn, giúp model trả lời hiệu quả hơn. Giống như mở rộng train-time compute (model lớn hơn, nhiều tham số hơn), test-time compute cũng cho kết quả trí tuệ cao hơn. Trên một benchmark agentic coding nội bộ, hiệu năng tăng khi model lớn hơn, và cũng tăng khi Claude tiêu nhiều token hơn (trục x logarit). Điều này đúng với mọi lĩnh vực: Deep Search QA, computer use qua OSWorld, hay Humanity's Last Exam (cấp tiến sĩ).

Demo: ba mức effort

Cùng prompt — "mô phỏng thực tế xe trên đường một chiều tại đèn giao thông" — chạy ở ba mức trên Opus 4.7:

• Low: ~50 giây, ~4.600 token. Mô phỏng khá ổn nhưng đơn giản — xe hai làn dừng ở đèn.
• High: gấp đôi thời gian và token, chi tiết hơn — nhiều loại xe, đèn không còn đặt giữa đường (vô lý), và tài xế "thông minh hơn" (xe phản ứng theo nhau).
• Max: ~10x token, chi tiết nhất — đèn treo lơ lửng theo luật vật lý, nền trời đẹp, chuyển động xe thông minh hơn.

Bài học: càng nhiều token, càng tốt nhưng càng tốn thời gian. Theo benchmark METR, qua các thế hệ model (kết hợp train-time và test-time compute), Claude làm tự chủ tới mức bao phủ tác vụ cấp con người với số giờ ngày càng lớn — một model gần đây đạt ~16 giờ công việc người ở mức chính xác 50%.

Ba dạng Test-time compute

• Thinking: không gian nháp/suy luận, nơi Claude cân nhắc câu hỏi và lên bước tiếp theo.
• Tool calling: giao diện với thế giới ngoài (web search, Salesforce, MCP server, ghi file...).
• Text: output trả về người dùng (tóm tắt công việc hoặc câu hỏi để thu thêm thông tin).

Hai cần điều khiển: Effort và Budget

Test-time compute tốn token và thời gian, nên người dùng muốn kiểm soát. Có hai cách:

• Effort: núm xoay từ low đến max; effort cao thì làm lâu hơn và tiêu nhiều token hơn (đánh đổi trí tuệ lấy tốc độ).
• Budget: ràng buộc chặt hơn — giới hạn max-token hoặc task budget trong API.

Tiến hóa của Thinking

• Ban đầu: nghĩ một khối trước (theo số token cấp), rồi thực thi loạt tool call, rồi trả lời.
• Interleaved thinking: như cách con người làm — làm gì đó, nghĩ về nó, làm tiếp, nghĩ tiếp; Claude có bước nghĩ sau mỗi tool call.
• Adaptive thinking: tiến hóa tiếp, trao thêm quyền cho model tự quyết khi nào và vì sao nghĩ. Claude chọn gọi tool, xuất text hoặc nghĩ theo thứ tự bất kỳ, và có thể không nghĩ chút nào (ví dụ "10 + 10" thì trả lời ngay 20). Đây không phải model router (không phân loại request); chỉ là nói với Claude "bạn có tool thinking, dùng khi cần". Benchmark cho thấy adaptive thinking Pareto-efficient so với interleaved.

Nút Thinking là proxy kém cho Effort

Nhiều người coi thinking như núm effort. Nhưng bật/tắt thinking không biểu đạt "muốn Claude nghĩ kỹ thế nào" — tắt extended thinking là gỡ bỏ một năng lực cốt lõi (một trong ba: thinking, tool calling, text). Tốt hơn là để Claude biết nó có thể nghĩ, và điều khiển độ dài qua effort — giống như ta cho Claude tool search và để nó tự suy luận khi nào nên search, thay vì ép luôn/không bao giờ search. Như khi làm việc với đồng nghiệp: ta nêu ràng buộc bài toán, họ tự thực thi theo bối cảnh rồi quay lại với câu trả lời.

Best practice về Effort

Đánh giá hiệu năng bằng một test set tốt với các thử thách khó, chạy ở nhiều mức effort để biết nên bắt đầu ở đâu. Lưu ý lợi ích biên giảm dần: max gấp đôi token so với extra high nhưng chỉ cải thiện chút ít. Low đạt được nhiều thứ nhưng đánh đổi trí tuệ lấy tốc độ — hợp với task không bị giới hạn bởi trí tuệ.

Mẹo: trong Claude Plays Pokémon (cho Claude chơi Pokémon Red bằng tool nút và vision để đánh bại Elite Four), khi để low effort, Claude lại tìm ra giải pháp độc đáo — dùng repel, potion, escape rope, chạy khỏi trận đấu — để đi nhanh hơn. Ràng buộc mức nghĩ đôi khi đẩy model vào các "attractor state" độc đáo.

Quy tắc nhanh:

• Max: cho task khó nhất, chắc chắn cần trí tuệ (lợi ích biên giảm); đừng bắt đầu ở đây trừ khi biết rõ cần.
• Extra high: mặc định của Claude Code và claude.ai — tradeoff tốt nhất giữa trí tuệ, tốc độ, token.
• High: nếu use case cần bất kỳ trí tuệ nào thì nên dừng ở đây; nhanh hơn hai mức trên.
• Medium/Low: giảm token; low cho use case nhạy độ trễ như phân loại, tóm tắt, trích xuất dữ liệu.

Model lớn vs model nhỏ effort cao

So sánh mô phỏng Opus và Haiku 4.5: Haiku dùng nửa thời gian nhưng cùng số token và kết quả kém rõ rệt ("không chắc đó có phải xe không"). Kết luận: nếu câu hỏi cần bất kỳ trí tuệ nào, thường nên dùng model lớn — kể cả khi để effort thấp. Dùng model nhỏ cho use case ít trí tuệ, nơi kết quả đơn giản đến mức Claude làm đúng hầu hết. Khi có thể, dùng eval (chạy Haiku và Opus trên toàn dải effort) để tìm cách tốt nhất.

Tóm tắt hành động

• Bật thinking bất cứ khi nào có thể — cho Claude không gian nháp để dùng tool thinking khi cần.
• Điều khiển độ dài qua các mức effort.
• Eval thường là cách tốt nhất tìm cân bằng lý tưởng; tìm eval khó nhất để đại diện cho việc thực tế.
• Khi phân vân, chọn extra high — mặc định Pareto-efficient giữa độ trễ, token và trí tuệ.

Thế giới lý tưởng: bạn đặt mức và budget (ví dụ "chỉ tiêu ngần này" hoặc "chỉ mất một tuần") cho task dài hạn, và Claude tự biết phân bổ compute phù hợp. Mục tiêu lâu dài là cải thiện khả năng Claude nhận ra task nào quan trọng và phân bổ tài nguyên hợp lý để giải.