Ngày 24/07/2026, Anthropic phát hành Claude Opus 5. Điều đáng chú ý không nằm ở chỗ nó mạnh hơn — model nào ra sau chẳng mạnh hơn.
Thứ tạo ra khác biệt thực sự không phải model mạnh nhất — mà là đặt đúng model vào đúng vị trí.
Opus 5 giữ nguyên giá của Opus 4.8 trong khi tiệm cận năng lực của tier cao nhất. Với người làm sản phẩm như tôi, thay đổi đó có ý nghĩa thực tế hơn nhiều so với một con số benchmark — nó buộc phải viết lại toàn bộ cách phân bổ model trong quy trình làm việc. Bài này gồm hai phần: Opus 5 có gì, và tôi đã thiết lập quy tắc dự án ra sao để tận dụng nó.
Phần 1 — Opus 5 có gì đáng chú ý
Giá không đổi, năng lực nhảy bậc
Opus 5 có giá 5 USD / triệu input token và 25 USD / triệu output token — đúng bằng Opus 4.8. Model string trên API là claude-opus-5. Nó trở thành model mặc định trên gói Claude Max và là model mạnh nhất khả dụng trên Claude Pro.
Hệ quả trực tiếp: Opus 4.8 gần như không còn lý do tồn tại trong quy trình của bạn — cùng giá, kém hơn, chỉ còn vai trò dự phòng khi request bị bộ lọc an toàn chặn. Nếu cấu hình dự án còn dòng nào kiểu "việc quan trọng thì dùng Opus 4.8" — đó là di sản của thời điểm trước 24/07. Nên sửa.
Vài con số
- Frontier-Bench v0.1: vượt mọi model khác, kết quả hơn gấp đôi Opus 4.8 với chi phí mỗi tác vụ thấp hơn.
- CursorBench 3.2 (effort tối đa): chỉ kém đỉnh của Claude Fable 5 khoảng 0,5% — với một nửa chi phí.
- ARC-AGI 3: điểm cao gấp ba lần model đứng thứ hai.
- OSWorld 2.0 (điều khiển máy tính): vượt kết quả tốt nhất của Fable 5 với chỉ hơn một phần ba chi phí.
Con số CursorBench là quan trọng nhất: chênh 0,5% năng lực để đổi lấy một nửa chi phí — với công việc lập trình hằng ngày, đó là lựa chọn hiển nhiên.
Thứ tôi quan tâm hơn cả benchmark
Điểm mạnh đặc trưng của Opus 5 là khả năng tự kiểm chứng công việc của chính nó và kiên trì lặp lại đến khi thành công. Ví dụ Anthropic đưa ra: khi được giao dựng lại một chi tiết máy thành mô hình 3D trong FreeCAD mà không có cách nào xem trực tiếp bản vẽ, Opus 5 đã tự viết một pipeline thị giác máy tính để trích xuất hình học từ pixel thô, rồi dựng lại toàn bộ chi tiết. Không model cạnh tranh nào giải được sau năm lần thử.
Đặc tính này quan trọng với tôi hơn mọi điểm benchmark, vì nó quyết định model đó phù hợp với vai trò nào trong quy trình — chính là nội dung phần 2.
An toàn và bộ lọc
Anthropic nói kiểm toán hành vi tự động trước triển khai cho thấy Opus 5 là model "aligned" nhất từ trước tới nay của họ, với tỷ lệ hành vi lừa dối thấp nhất. Về an ninh mạng: bộ lọc cho phép tìm lỗ hổng trong mã nguồn, nhưng chặn quét lỗ hổng dạng binary, kiểm thử xâm nhập và tạo exploit. Mức can thiệp dự kiến ít hơn khoảng 85% so với Fable 5 — chi tiết này có ý nghĩa thực tế ở phần review.
Hai tính năng beta nên bật:
• Đổi tool giữa cuộc hội thoại mà không mất prompt cache — quan trọng với agent chạy dài.
• Automatic fallback — request bị bộ lọc gắn cờ sẽ tự chuyển sang model khác thay vì trả về lỗi cứng. Nếu chạy agent tự động, gần như là tính năng bắt buộc.
Phần 2 — Thiết lập quy tắc phân tầng cho dự án
Có bốn model trong tay không tự động làm việc tốt hơn. Ngược lại, nếu không có quy tắc, bạn sẽ mặc định dùng model mạnh nhất cho mọi thứ và đốt tiền vào những việc mà Haiku làm được. Nguyên tắc tôi rút ra rất đơn giản:
Model mạnh dùng ở chỗ ra quyết định, không dùng ở chỗ gõ code.
Vì một quyết định sai lan ra toàn bộ công việc phía sau, còn một dòng code sai thì test bắt được.
Bảng phân tầng
| Tier | Model | Dùng cho |
|---|---|---|
| Điều phối | claude-fable-5 |
Brief, lập kế hoạch, xác nhận huỷ kế hoạch, ghi memory |
| Rủi ro cao | claude-opus-5 |
Việc sai thì đắt, và toàn bộ khâu review |
| Mặc định code | claude-sonnet-5 |
Feature thường, sửa bug, viết test, API, UI |
| Việc cơ học | claude-haiku-4-5 |
Đổi tên, format, cập nhật doc, parse log |
"Việc sai thì đắt" với tôi có định nghĩa cụ thể: migration và đổi schema database, refactor kiến trúc, code liên quan tiền và thanh toán, xác thực và phân quyền, tối ưu hiệu năng, và bug đã thất bại từ hai lần trở lên.
Quy trình năm bước
Mỗi công việc đi theo vòng: PLAN → EXECUTE → GATE → REVIEW → MEMORY.
Bước 1 — Lập kế hoạch (Fable 5). Đầu ra là một file plan có: mục tiêu, tiêu chí nghiệm thu kiểm chứng được, phạm vi file được phép sửa, chia việc kèm tier model, và danh sách rủi ro. Ràng buộc quan trọng nhất: mọi tiêu chí nghiệm thu phải kiểm chứng được. "Code sạch hơn" không phải tiêu chí. "Chạy npm test thấy 12 test pass" mới là tiêu chí.
Bước 2 — Thi hành (subagent). Mỗi subtask giao đúng tier đã ghi trong plan. Subagent chỉ được sửa file trong phạm vi khai báo, và phải tự chạy test trước khi báo xong. Mẫu báo cáo có một mục giá trị bất ngờ: "Điều chưa chắc chắn" — bắt subagent tự nói ra chỗ nó không tự tin rẻ hơn nhiều so với để reviewer mò ra.
Bước 3 — Cổng tự động (không tốn model). Chạy tuần tự typecheck → lint → test → build. Fail ở đâu dừng ở đó và trả thẳng về subagent, không gọi model review. Đây là chi tiết cắt chi phí lớn nhất — gọi một model đắt tiền để phát hiện lỗi thiếu dấu chấm phẩy là lãng phí thuần tuý.
Bước 4 — Review (Opus 5, context sạch). Đây là chỗ tôi đổi ý so với thiết kế ban đầu. Reviewer là vị trí bị gọi nhiều nhất — mỗi task ít nhất một lần, task fail thì nhiều lần — nên là chỗ tiết kiệm có ý nghĩa nhất. Tự kiểm chứng và phát hiện lỗi logic ở tầng thiết kế chính là thế mạnh của Opus 5. Và reviewer phải đọc diff của code xác thực, xử lý input, mã hoá — Opus 5 bị bộ lọc can thiệp ít hơn Fable ~85%, rất hợp vai trò này.
Ràng buộc quan trọng hơn cả việc chọn model: reviewer không được đọc file plan. Nó chỉ nhận yêu cầu gốc, diff, và kết quả cổng tự động. Nếu chấm bài theo plan, nó sẽ không bao giờ phát hiện được lỗi nằm ở chính plan. Reviewer trả lời đúng bốn câu:
- Thay đổi này có đáp ứng yêu cầu gốc không, hay chỉ làm test xanh?
- Có lỗi logic, edge case, rủi ro bảo mật nào không?
- Có code thừa, code chết, thay đổi ngoài phạm vi không?
- Kế hoạch ban đầu có sai không? — câu quan trọng nhất và dễ bị bỏ qua nhất.
Bước 4b — Xác nhận huỷ kế hoạch (Fable 5). Khi reviewer kết luận kế hoạch sai từ gốc, nó không có quyền tự huỷ. Reviewer phải viết luận cứ, mấu chốt là câu: "khoảng cách này không thể vá bằng cách sửa code, vì...". Luận cứ được chuyển cho một agent riêng chạy Fable 5 để xác nhận hoặc bác bỏ. Nguyên tắc: lưỡng lự thì bác bỏ — huỷ kế hoạch nhầm một lần tốn hơn nhiều so với đi tiếp rồi sửa. Ngoại lệ: nếu vấn đề nằm ở kiến trúc hoặc mô hình dữ liệu thì thiên về xác nhận.
Bước 5 — Ghi memory (Fable 5). Xem phần kỷ luật ghi memory bên dưới.
Kết quả: đường đi bình thường của một task không chạm tới Fable 5 lần nào sau khi lập kế hoạch. Fable chỉ xuất hiện ở hai điểm — mở đầu, và khi có tranh chấp về kế hoạch.
Quy tắc leo thang
- Task mặc định giao Sonnet 5.
- Chạm vào bất kỳ mục nào trong danh sách rủi ro cao → giao thẳng Opus 5 ngay từ đầu.
- Sonnet 5 thất bại hai lần liên tiếp → chuyển lên Opus 5, kèm toàn bộ log lỗi của hai lần trước.
- Opus 5 thất bại một lần → dừng lại, báo cáo cho người dùng, không tự thử tiếp.
Điểm 4 quan trọng: khi model mạnh nhất trong chuỗi cũng không giải được, vấn đề thường không nằm ở chỗ chưa thử đủ nhiều — mà nằm ở chỗ đề bài sai.
Kỷ luật ghi memory
Đây là phần dễ làm hỏng nhất. Ai cũng nghĩ ghi nhớ càng nhiều càng tốt. Thực tế ngược lại: file memory phình to sẽ làm chất lượng tụt, không phải tăng.
✓ Chỉ ghi khi
Bài học tái sử dụng được ở task khác (quy ước codebase, cạm bẫy thư viện, lệnh build đặc thù) • Lỗi đã lặp lại từ hai lần trở lên • Quyết định kiến trúc kèm lý do.
✗ Không ghi
Diễn biến của một task cụ thể ("hôm nay sửa file X") • Thông tin đọc được từ code (code đã tự nói rồi) • Lỗi chỉ xảy ra một lần do nhầm lẫn ngẫu nhiên.
Bảo trì: mỗi mục tối đa hai dòng kèm lý do • mục mới mâu thuẫn mục cũ thì sửa mục cũ, không thêm mục mới • mỗi 20 mục thì rà lại, gộp trùng, xoá lỗi thời • trước khi lập kế hoạch, model điều phối phải đọc file memory và nêu rõ bài học nào đang áp dụng.
Một mẹo cắt chi phí input
Lập kế hoạch tốt đòi hỏi đọc nhiều codebase, mà input token của tier cao rất đắt. Cách xử lý: tách khâu khảo sát ra khỏi khâu quyết định. Cho một subagent Haiku hoặc Sonnet đọc codebase và viết ra một bản tóm tắt có cấu trúc — file nào liên quan, interface hiện có, ràng buộc gì. Model điều phối chỉ đọc bản tóm tắt đó rồi ra kế hoạch. Cùng chất lượng kế hoạch, input token giảm mạnh.
Cấu trúc file
├── CLAUDE.md # quy tắc định tuyến + quy trình
└── .claude/
├── LESSONS.md # memory tích luỹ
└── agents/
├── planner.md # Fable 5 — brief & plan
├── reviewer.md # Opus 5 — nghiệm thu, context sạch
├── plan-auditor.md # Fable 5 — chốt chặn huỷ kế hoạch
├── coder.md # Sonnet 5 — mặc định
├── high-risk.md # Opus 5 — sai là đắt
└── chore.md # Haiku — việc cơ học
📦 Tải cấu trúc định tuyến Model
Trọn bộ file cấu hình mẫu: CLAUDE.md + 6 agent (planner, reviewer, plan-auditor, coder, high-risk, chore) + LESSONS.md. Giải nén và đặt vào repo là chạy được.
⬇ Tải xuống opus-5.zipVài điều nên nhớ
🧪 Đừng tin bảng phân tầng của tôi một cách mặc định
Lấy ba feature thật, cho hai model lập kế hoạch trên cùng brief, so xem kế hoạch nào bắt được nhiều ràng buộc ẩn hơn và dẫn tới ít lần làm lại hơn. Sau ba lần bạn sẽ có câu trả lời chắc hơn mọi lập luận lý thuyết.
⚙️ Cổng tự động quan trọng hơn việc chọn model
Nếu chỉ làm được một thứ, hãy làm bước 3 — chạy typecheck, lint, test, build trước khi gọi bất kỳ model nào để review. Nó rẻ, dễ, và cắt được phần lớn chi phí review.
🧹 Context sạch quan trọng hơn năng lực model
Thứ giúp phát hiện lỗi ở tầng kế hoạch không phải model thông minh hơn, mà là một reviewer chưa bị kế hoạch đó thuyết phục.
🔁 Bật automatic fallback
Nếu chạy agent tự động qua API. Không có nó, một request bị gắn cờ giữa chừng sẽ làm gãy cả chuỗi.
Bài viết dựa trên thông tin công bố của Anthropic ngày 24/07/2026 và cấu hình thực tế tôi đang dùng. Giá và năng lực model có thể thay đổi — nên kiểm tra lại tài liệu chính thức trước khi áp dụng.