Mỗi lần Anthropic ra lineup model mới, tôi đọc announcement, gật đầu, và vài ngày sau vẫn dùng Sonnet vì quen. Đó là vấn đề phổ biến. Không phải vì thiếu thông tin mà vì thông tin không được dịch thành quyết định thực tế: “task cụ thể này nên dùng model nào, effort level nào?”
Bài này là câu trả lời dựa trên dùng thật, không phải benchmark.
Bốn model hiện tại
Giá và giới hạn
| Model | ID | Giá (in/out, mỗi 1M token) | Context | Max output |
|---|---|---|---|---|
| Fable 5 | claude-fable-5 | $10 / $50 | 1M token | không công bố |
| Opus 4.8 | claude-opus-4-8 | $5 / $25 | 1M token | 128K |
| Sonnet 4.6 | claude-sonnet-4-6 | $3 / $15 | 1M token | 64K |
| Haiku 4.5 | claude-haiku-4-5-20251001 | $1 / $5 | 200K token | không công bố |
Số này là API pricing. Nếu bạn dùng Claude Code CLI với subscription, cost được tính khác (flat fee theo plan). Nếu bạn gọi API trực tiếp hoặc build agent, đây là số bạn cần.
Định vị thực tế
Haiku 4.5 là grunt model. Tốc độ nhanh nhất, rẻ nhất. Đưa vào các task không cần reasoning: đếm, rename hàng loạt, preprocessing text, summarize output để feed vào step tiếp theo. Dùng cho subagent làm việc cơ học trong một pipeline lớn. Đừng kỳ vọng nó giải thích kiến trúc hay debug concurrency.
Sonnet 4.6 là workhorse của tôi khi task đã có khuôn. Feature mới với acceptance criteria rõ ràng. Refactor trong phạm vi xác định. Bug có stack trace. Code với file scope được biết trước. Nó nhanh hơn Opus, đủ thông minh cho 80% công việc hằng ngày, và giá $3/$15 là điểm cân bằng tốt.
Opus 4.8 là model tôi reach cho khi task bắt đầu có dấu hiệu phức tạp thật sự. Cross-cutting design: thay đổi ảnh hưởng nhiều module không rõ ràng liên quan nhau như thế nào. Concurrency hoặc race condition không tái hiện được đơn giản. Requirement mơ hồ, chưa rõ “done” là gì. Agentic loop với nhiều tool call liên tiếp. Security audit. Giá $5/$25 so với Sonnet $3/$15 là đáng nếu task thực sự cần depth. Không đáng nếu task chỉ là “thêm một API endpoint CRUD”.
Tôi có pattern: bắt đầu với Opus 4.8 cho session phức tạp. Nếu trong quá trình làm thấy task đơn giản hơn nghĩ, chuyển về Sonnet. Không bao giờ bắt đầu Haiku rồi leo lên vì output Haiku thường cần nhiều lần redo hơn.
Fable 5 là model tôi ít chạm nhất. Đắt nhất, cap nhất, nên dùng có chủ đích. Tôi dùng khi bản thân nghĩ “đây là vấn đề khó nhất mình đang gặp và một sai lầm ở đây tốn nhiều hơn $50/1M token”. Production migration phức tạp. Thiết kế API sẽ khó thay đổi sau khi expose. Security model của một hệ thống mới. Đây không phải model cho mọi task, và dùng nó như default là waste.
Effort levels
API Anthropic cho phép set effort qua output_config: { effort: "..." }. Đây là năm level:
| Level | Mặc định ở đâu | Ý nghĩa thực tế |
|---|---|---|
low | Subagent, latency-critical | Token tối thiểu, nhanh, dùng cho task đơn giản trong pipeline |
medium | Cost-sensitive, balanced | Mid-ground giữa tốc độ và chất lượng |
high | API default | Cân bằng quality và token. Đủ cho hầu hết intelligent work |
xhigh | Claude Code CLI default | Tối ưu cho coding và agentic task: ít tool call thừa, ít preamble |
max | Khi đúng/sai rất quan trọng | Correctness over cost. Dùng cho production migrations, security, compliance |
Điều quan trọng: xhigh không chỉ là “nhiều hơn high”. Nó được tuned cụ thể cho coding workflow. Ở xhigh, model có xu hướng ít waste turn vào “để tôi giải thích trước khi làm” và đi thẳng vào tool call. Ít preamble là một tính năng khi bạn đang watch một agent làm việc trong terminal.
max khác xhigh ở chỗ: max dành cho khi cost of being wrong vượt qua cost of spending more tokens. Tôi dùng max cho migration schema database, cho code chạm vào auth/permission layer, và cho bất cứ thứ gì sẽ đi thẳng lên production mà không có staging run đầy đủ.
low tôi chỉ dùng trong subagent làm preprocessing. Cho một agent đọc 50 file và extract header để feed vào agent chính, low là hợp lý. Cho bất cứ thứ gì cần reasoning, low là recipe cho output cần redo.
Nếu bạn build API client từ đầu, xuất phát điểm: để high (API default), đừng set gì. Move lên xhigh khi bạn build coding assistant hay agentic tool. Move lên max chỉ khi task cụ thể warrant nó.
Adaptive thinking
Từ Opus 4.6 trở đi, parameter cũ budget_tokens trong thinking block đã bị deprecated. Cách mới:
{
"thinking": { "type": "adaptive" }
}Với adaptive, model tự quyết định khi nào cần think và think bao nhiêu dựa trên task. Task đơn giản thì không think, tiết kiệm token. Task phức tạp thì think nhiều hơn.
Một điểm không hiển nhiên: trên Fable 5, Opus 4.8, và Opus 4.7, nếu bạn set thinking: { type: "disabled" }, API trả về 400. Không phải “silently ignore”, mà là hard error. Nếu muốn không có thinking block, cách duy nhất là omit toàn bộ field thinking ra khỏi request body. Đây là breaking change về behavior so với Opus 4.5.
Trong thực tế: adaptive thinking kết hợp với effort level cho bạn khá nhiều control. Nếu bạn muốn model suy nghĩ kỹ ở effort max, bật adaptive. Nếu bạn muốn minimize token và latency, để effort low hoặc medium và omit thinking.
Quyết định nhanh: task X dùng gì?
Thay vì flowchart dài, tôi dùng bốn câu hỏi theo thứ tự:
1. Task có requirement rõ không?
Rõ là có acceptance criteria kiểm tra được, biết file nào cần sửa, input và output xác định. Nếu rõ: Sonnet 4.6 là default.
Không rõ là “tôi không biết nó sẽ ảnh hưởng những gì” hoặc “design còn mở”. Nếu không rõ: Opus 4.8.
2. Task có ảnh hưởng production không?
Nếu task sẽ ra live và khó rollback, effort lên max. Nếu là dev/staging và có test coverage, xhigh (khi dùng Claude Code) hoặc high (khi gọi API trực tiếp).
3. Task có mechanical không?
Rename 200 file theo rule. Extract danh sách từ 50 log file. Parse CSV thành JSON. Haiku 4.5 ở effort low. Đây là task bạn có thể verify bằng script, không cần reasoning model.
4. Task có phải một-trong-những-thứ-khó-nhất không?
Nếu bạn phải dừng lại và nghĩ “cái này tricky thật”, dùng Fable 5. Nếu bạn chỉ muốn an tâm, đó không phải lý do đủ. Fable 5 cho vấn đề khó, không phải cho tất cả vấn đề.
Một ví dụ cụ thể
Tôi đang refactor auth middleware trong một service Node. Đây là task:
Requirement rõ vì tôi có test suite existing: Sonnet 4.6. Nhưng middleware auth chạm vào session handling và permission check, tức là “ảnh hưởng production và khó rollback”. Effort: max.
Khi viết code gọi API:
const response = await client.messages.create({
model: "claude-sonnet-4-6",
max_tokens: 4096,
output_config: { effort: "max" },
messages: [
{ role: "user", content: systemPrompt }
]
});Nếu task là build UI component theo design có sẵn, không chạm auth layer: Sonnet 4.6 ở xhigh hoặc high.
Nếu task là search codebase để list tất cả nơi dùng deprecated API, feed vào step sau: Haiku 4.5 ở low.
Về task budget (advanced)
Một feature ít được nhắc: task_budget. Khác với max_tokens (là ceiling model không biết cho đến khi chạm), task_budget là số token cho toàn bộ agentic loop mà model được thông báo và tự điều chỉnh. Model thấy “còn X token” và tự moderate cách dùng.
{
"output_config": {
"task_budget": { "type": "tokens", "total": 50000 }
}
}Cần beta header: task-budgets-2026-03-13. Available trên Fable 5, Opus 4.7, và Opus 4.8.
Tôi chưa dùng production. Nhưng nó thú vị cho agentic loop dài mà bạn muốn model biết nó đang tiêu ngân sách.
Thực tế dùng Claude Code
Claude Code CLI dùng xhigh làm default cho tất cả model. Bạn không cần set gì thêm. Khi gọi /model để switch, effort vẫn giữ xhigh. Để đổi effort trong Claude Code, bạn cần làm qua custom workflow hoặc API call trực tiếp, không phải qua CLI interactively.
Model tôi để làm default trong Claude Code hiện tại: Opus 4.8. Lý do là tôi dùng Claude Code cho những task đủ phức tạp để cần interactive session, và depth của Opus 4.8 ít khi thừa trong context đó. Sonnet tôi dùng khi task cụ thể đủ bounded để không waste tiền.
Một điều tôi quan sát: đổi model trong một session dài không phải lúc nào cũng hiệu quả. Context đã build theo style của model đầu tiên. Nếu cần switch từ reasoning-heavy sang mechanical work, thường tốt hơn khi tách thành hai task rõ ràng.
Pricing thay đổi theo thời gian và Anthropic có thể ra model mới. Nhưng framework quyết định thì không: rõ ràng xuống Sonnet, phức tạp lên Opus, cơ học về Haiku, khó nhất mới dùng Fable. Effort theo rủi ro, không theo thói quen.