Tổng quan các model của Claude

Bộ ba model: Opus, Sonnet, Haiku

Claude có 3 dòng model chính, đặt tên theo 3 thể thơ với độ dài khác nhau — ẩn dụ cho "độ sâu suy nghĩ" của model.

♠ Opus — Model lớn nhất, thông minh nhất

Dùng khi:

Không dùng khi:

Phiên bản hiện tại (04/2026): claude-opus-4-8

♣ Sonnet — Workhorse cân bằng

Dùng khi:

Không dùng khi:

Phiên bản hiện tại (04/2026): claude-sonnet-5

♦ Haiku — Nhanh, rẻ, cho volume lớn

Dùng khi:

Không dùng khi:

Phiên bản hiện tại (04/2026): claude-haiku-4-5

• Giải bài toán chưa từng có template
• Viết code phức tạp, refactor hệ thống lớn
• Phân tích chuyên sâu (financial modeling, legal reasoning)
• Agentic tasks dài (chạy 30+ phút tự động)
• Cần output siêu nhanh (Opus chậm hơn Sonnet 2-3x)
• Khối lượng lớn (cost > 5x Sonnet)
• Tác vụ đơn giản (lãng phí, Sonnet/Haiku làm được)
• 80% tác vụ coding hàng ngày
• Tool use, function calling
• Chatbot sản phẩm với chất lượng tốt
• RAG q&a trên knowledge base
• Bài toán quá khó (lên Opus)
• Tác vụ classification đơn giản, volume lớn (xuống Haiku)
• Phân loại text (sentiment, topic, intent)
• Trích xuất dữ liệu có cấu trúc (structured extraction)
• Bước đầu của pipeline (Haiku sàng lọc → Sonnet xử lý)
• Chatbot real-time cần latency thấp
• Cần creative writing chất lượng cao
• Agentic tasks phức tạp với nhiều tool
• Bài toán đòi hỏi "suy nghĩ" dài

┌─────────────────────────────────────────────────────────────┐
│                                                             │
│  ♠ OPUS                   ♣ SONNET                ♦ HAIKU  │
│  ┌────────────┐           ┌────────────┐    ┌────────────┐ │
│  │ Thông minh │           │  Cân bằng  │    │   Nhanh    │ │
│  │   nhất     │           │            │    │   + rẻ     │ │
│  │            │           │            │    │            │ │
│  │  Tác vụ    │           │  Workhorse │    │  Volume    │ │
│  │  phức tạp  │           │  hàng ngày │    │  lớn       │ │
│  │            │           │            │    │            │ │
│  │ Suy luận   │           │ Tool use,  │    │ Phân loại, │ │
│  │ nhiều bước │           │ agentic    │    │ trích xuất │ │
│  │            │           │            │    │            │ │
│  │  $$$$      │           │   $$       │    │    $       │ │
│  │  chậm      │           │  trung     │    │   nhanh    │ │
│  └────────────┘           └────────────┘    └────────────┘ │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Đọc tên model

Anthropic dùng naming convention chuẩn:

Alias vs snapshot

Best practice:

• Alias (ví dụ claude-sonnet-4-0): luôn trỏ về phiên bản mới nhất của dòng 4.x. Tiện nhưng nguy hiểm — Anthropic có thể update → behavior thay đổi.
• Snapshot (ví dụ claude-sonnet-5-20260205): pin cứng một phiên bản cụ thể theo ngày. An toàn cho production — behavior không đổi cho đến khi bạn chủ động upgrade.
• Dev / exploration: dùng alias để luôn có model mới nhất
• Production: pin snapshot, migrate có kiểm soát khi model mới ra

claude-<tier>-<major>-<minor>[-<date>]

Ví dụ:
  claude-sonnet-5-20260205
  └─────┘ └────┘ └─┘ └──────┘
    │       │     │     │
    │       │     │     └─ Snapshot date (optional)
    │       │     └─────── Version (4.6)
    │       └───────────── Tier (sonnet)
    └───────────────────── Family (claude)

# ❌ Không nên cho production
model = "claude-sonnet-4-0"

# ✅ Production
model = "claude-sonnet-5-20260205"

So sánh 3 tier

(Số liệu ước tính, check docs chính thức để có số chính xác tại thời điểm đọc.)

Quy tắc 10x

Mỗi "nấc thang" tier có hệ số ~5x:

Hệ quả: Đi từ Haiku lên Sonnet thường đáng tiền. Đi từ Sonnet lên Opus chỉ đáng khi task thực sự khó.

• Haiku → Sonnet: chất lượng +25%, giá x4, tốc độ /2.5
• Sonnet → Opus: chất lượng +10%, giá x5, tốc độ /2.3

Khi nào dùng model nào?

Ma trận quyết định

Flow chart chọn model

┌──────────────────────────────────┐
│  Task là gì?                     │
└──────────────┬───────────────────┘
               │
               ▼
┌──────────────────────────────────┐
│  Có cần classification /         │
│  extraction đơn giản?            │
└───┬──────────────────────────────┘
    │ Có                ├─ Không
    ▼                   ▼
┌──────────┐   ┌─────────────────┐
│  HAIKU   │   │ Cần agentic /   │
└──────────┘   │ tool use phức   │
               │ tạp / multi-step│
               │ reasoning?      │
               └────┬────────────┘
                    │ Có  ├─ Không
                    ▼     ▼
              ┌──────────┐ ┌──────────┐
              │  OPUS    │ │ SONNET   │
              └──────────┘ └──────────┘

Ví dụ thực chiến: Ước tính chi phí cho chatbot HR

Tình huống

Bạn xây chatbot HR internal cho 200 nhân viên. Mỗi nhân viên hỏi trung bình 3 câu/tuần. Input prompt (system + RAG context) ~2000 tokens. Output ~500 tokens.

Bước 1: Tính traffic

Bước 2: Tính token/tháng

Bước 3: Tính chi phí (3 scenario)

Scenario A — Opus:

Scenario B — Sonnet:

Scenario C — Haiku:

Bước 4: Quyết định

Sếp cho budget $500/tháng — rộng rãi cho cả 3. Nhưng:

Thêm prompt caching cho system prompt (bài 6.47-6.49) có thể giảm chi phí Sonnet thêm ~50% → ~$16/tháng.

Kết quả: Sonnet 5 + prompt caching, $16-20/tháng.

• 200 users × 3 câu/tuần × 4 tuần = 2,400 request/tháng
• Input: 2,400 × 2,000 = 4.8M input tokens
• Output: 2,400 × 500 = 1.2M output tokens
• Input: 4.8M × $15 = $72
• Output: 1.2M × $75 = $90
• Tổng: ~$162/tháng
• Input: 4.8M × $3 = $14.4
• Output: 1.2M × $15 = $18
• Tổng: ~$32.4/tháng
• Input: 4.8M × $0.80 = $3.84
• Output: 1.2M × $4 = $4.8
• Tổng: ~$8.6/tháng
• Haiku có thể hallucination khi RAG context dài → rủi ro cho HR policy
• Opus quá đắt so với độ khó task này
• Sonnet là sweet spot

Case studies theo ngành

💰 Finance — Investment Analyst

Task: Phân tích báo cáo tài chính 10-K dài 300 trang, tổng hợp thành investment memo.

Trước: Dùng Opus cho tất cả, tốn $8/report. Mỗi ngày ~50 report = $400/ngày.

Sau khi tối ưu:

📝 Publishing — Content moderation

Task: Kiểm duyệt 100,000 comment/ngày, phân loại toxic/safe.

Chọn model: Haiku. Volume lớn, task đơn giản (classification), cần latency thấp (< 500ms).

Sonnet không phù hợp: quá đắt ($50/ngày với Sonnet, $13/ngày với Haiku). Chất lượng Haiku đủ tốt cho task binary classification.

Opus tuyệt đối không: overkill, $400/ngày.

⚖️ Legal — Contract review

Task: So sánh 2 phiên bản contract 50 trang, flag điều khoản khác biệt, suy luận tác động pháp lý.

Chọn model: Opus. Đây là lúc Opus tỏa sáng — task khó, volume thấp (~20 contracts/ngày), stakes cao (sai = kiện tụng).

Sonnet không đủ: miss nuance trong 5-10% cases, với legal stakes, tỷ lệ đó không chấp nhận được.

🎧 Customer Support — First response

Task: Trả lời tin nhắn khách hàng đầu tiên, handle 70% case đơn giản, escalate 30% khó lên human.

Pipeline 2 tier:

Chi phí giảm 90% so với "dùng Sonnet cho tất cả".

🔍 Research — Literature review

Task: Đọc 80 paper academic, tổng hợp thành literature review.

Pipeline:

Chi phí cho toàn literature review: ~$15, thời gian 2 giờ thay vì 2 tuần của researcher.

• Haiku chunking + tiền xử lý (extract tables, remove boilerplate) — 5c/report
• Sonnet tổng hợp từng section (parallelization) — $0.50/report
• Opus chỉ cho phần "investment thesis" cuối (cần suy luận sâu) — $1/report
• Tổng: $1.55/report, giảm 80%
• Haiku classify: có phải câu hỏi FAQ không? → trả lời từ template
• Sonnet handle 30% còn lại với RAG
• Human chỉ xử lý 5-10% phức tạp nhất
• Sonnet với context window 1M token → đọc đồng thời 10 paper/request
• Multi-pass: extract → cluster themes → synthesize
• Opus chỉ cho final synthesis step

Context window — Yếu tố ít được chú ý

Context window = số token tối đa model xử lý trong 1 request (input + output).

Lưu ý: Sonnet 5 có 1M context — lớn hơn Opus. Đây là lý do Sonnet thường được chọn cho coding agents (đọc toàn bộ codebase) và long-form document analysis.

Quy tắc ngón cái

Khi nào cần context lớn?

Cảnh báo: Context dài ≠ performance tốt. Model thường "quên" giữa context dài. Đó là lý do RAG (chunking → retrieve top-k) vẫn tồn tại dù context 1M.

• 1 token ≈ 0.75 từ tiếng Anh
• 1,000 token ≈ 750 từ ≈ 1.5 trang sách A4
• 200K context = 150K từ = ~300 trang
• 1M context = 750K từ = ~1,500 trang
• Đọc toàn bộ codebase (Sonnet 1M)
• Phân tích báo cáo tài chính dày
• Long conversation (hàng trăm turn) không muốn summarize
• Multi-document RAG khi không muốn chunking

Roadmap upgrade

Anthropic release model mới trung bình 6-9 tháng/lần. Từ khi xuất bản khóa này (4/2026):

Model cũ (3.5, 4.0) vẫn chạy được nhưng sẽ bị deprecate trong 12-18 tháng sau khi có version mới.

Quy trình migration khi có model mới

Đây là lúc bạn cảm ơn mình đã build eval suite ở Module 4 — không có eval, migrate là mò kim đáy bể.

• Sonnet 5 — flagship hiện tại (2/2026)
• Opus 4.8 — released 4/2026
• Haiku 4.5 — released 10/2025

1. Pin snapshot hiện tại (đang production)
2. Chạy eval suite (Module 4) với model mới trên dev environment
3. So sánh: quality metric, cost, latency
4. Nếu model mới >= chất lượng cũ và <= cost/latency → rollout
5. Canary rollout 10% traffic → monitor 1 tuần
6. Full rollout

Anti-patterns — Sai lầm chọn model

❌ "Luôn dùng model tốt nhất cho an toàn"

Hiểu hiện: Dùng Opus cho mọi task vì "sợ Sonnet không đủ tốt".

Tại sao tệ: Đốt tiền gấp 5x, slow down UX 2x. Với 90% task, Sonnet đủ.

Cách đúng: Default Sonnet. Thử Haiku cho task đơn giản. Lên Opus chỉ khi eval cho thấy Sonnet không đủ.

❌ "Dùng alias claude-sonnet-4-0 cho production"

Hiểu hiện: Model ID không có ngày snapshot.

Tại sao tệ: Anthropic update model → behavior thay đổi → app của bạn có thể hỏng mà không warning.

Cách đúng: Pin snapshot (claude-sonnet-5-20260205). Upgrade có kế hoạch.

❌ "Không chạy eval khi switch model"

Hiểu hiện: "Model mới là tốt hơn chắc rồi, deploy luôn."

Tại sao tệ: Model mới có thể tốt trung bình nhưng tệ trên use case cụ thể của bạn. Có case khách quan Opus 4.8 dở hơn Opus 4.8 cho một pattern cụ thể.

Cách đúng: Có eval suite. Chạy eval khi switch. Rollback nếu metric tệ.

❌ "Dùng Haiku cho agentic multi-step"

Hiểu hiện: Cho Haiku chạy tool loop 10+ bước.

Tại sao tệ: Haiku tốt cho 1-shot classification, nhưng multi-step reasoning dễ lạc hướng. Loop thất bại.

Cách đúng: Sonnet cho agentic. Haiku cho 1 bước riêng lẻ trong pipeline.

❌ "Chọn model theo giá, không theo use case"

Hiểu hiện: "Tôi chỉ có $50 budget, dùng Haiku cho tất cả."

Tại sao tệ: Haiku hỏng task khó → user complain → bạn debug → tốn thời gian > tiết kiệm được tiền.

Cách đúng: Chọn model theo use case trước. Nếu quá đắt, optimize bằng: caching, shorter prompt, pipeline Haiku → Sonnet.

Áp dụng ngay

Bài tập 1: Lập mapping cho app của bạn (15 phút)

Trong file my-goals.md (tạo ở bài 6.1), thêm section:

Bài tập 2: Ước tính chi phí (10 phút)

Cho app dự kiến của bạn:

Dùng calculator: anthropic.com/pricing

• Dự kiến traffic/tháng (số request): ___________
• Dự kiến input token / request (prompt + context): ___________
• Dự kiến output token / request: ___________
• Model chọn: ___________
• Chi phí ước tính/tháng: ___________

## Model mapping dự kiến

| Tác vụ của app | Model chọn | Lý do |
|---------------|-----------|-------|
| Ví dụ: phân loại ý định câu hỏi | Haiku 4.5 | Classification đơn giản, cần nhanh |
| Ví dụ: trả lời câu hỏi HR | Sonnet 5 | Cần RAG, quality cao, volume vừa |
| Ví dụ: summarize meeting 1 giờ | Sonnet 5 | Long context, quality cao |
| [Task của bạn] | ? | ? |

Mẹo nâng cao

Mẹo 1: Dùng Haiku để "tiền xử lý" cho Sonnet

Thay vì Sonnet đọc 100 trang, bạn có thể:

Mẹo 2: Tier based on confidence

Mẹo 3: Batch API cho Haiku

Với Haiku, Anthropic có Batch API giảm giá 50% (trả kết quả trong 24h thay vì realtime). Phù hợp cho:

• Haiku extract 10 đoạn relevant
• Sonnet chỉ phân tích 10 đoạn đó
• Giảm input token 90%, giảm chi phí 70%
• Haiku trả lời, kèm confidence score (0-1)
• Nếu confidence < 0.7 → escalate lên Sonnet
• Khoảng 70% request dừng ở Haiku → cost giảm 60%
• Mass content moderation offline
• Batch labeling dữ liệu training
• Overnight report generation

Tóm tắt bài học

🎯 3 tier — Opus, Sonnet, Haiku — 3 vai trò khác nhau. Phó cả, thợ lành nghề, thợ phụ. Dùng đúng người đúng việc.

🎯 Pin snapshot cho production, dùng alias cho dev. Naming convention: claude-<tier>-<version>[-<date>].

🎯 Sonnet là workhorse mặc định cho 80% use case. Default Sonnet, chỉ move khi có lý do rõ.

🎯 Tính chi phí bằng công thức: traffic × (input_tok × input_price + output_tok × output_price). Pipeline đa tier thường tiết kiệm 60-90%.

🎯 Migration model = eval suite + canary rollout. Không có eval = không biết đổi model cải thiện hay làm tệ đi.