Bảng Giá Claude Opus 4.8: Chi Phí Chi Tiết

Claude Opus 4.8 có giá 5 đô la cho mỗi triệu token đầu vào và 25 đô la cho mỗi triệu token đầu ra ở chế độ tiêu chuẩn. Mức giá này tương đương Opus 4.7, nên nếu ngân sách của bạn đã được tính cho 4.7 thì khi nâng cấp lên 4.8, chi phí cơ bản không đổi. Phần cần tối ưu nằm ở cách bạn dùng model: chế độ nhanh, tham số effort, prompt caching, Batch API và giới hạn đầu ra có thể làm hóa đơn thực tế thay đổi đáng kể.

Dùng thử Apidog ngay hôm nay

Hướng dẫn này tập trung vào cách tính chi phí và các điểm cần cấu hình trước khi đưa Opus 4.8 vào production. Nếu bạn cần phần tổng quan về model, xem Claude Opus 4.8 là gì. Nếu bạn muốn bắt đầu gọi API, xem hướng dẫn API.

Bảng giá Claude Opus 4.8

Chế độ	Đầu vào mỗi 1M token	Đầu ra mỗi 1M token	Tốc độ
Tiêu chuẩn	$5	$25	Cơ bản
Nhanh	$10	$50	Đầu ra nhanh hơn 2,5 lần

Có hai điểm cần nhớ khi ước tính chi phí:

1. Token đầu ra đắt gấp 5 lần token đầu vào. Vì vậy, độ dài phản hồi thường ảnh hưởng đến chi phí nhiều hơn kích thước prompt.
2. Chế độ nhanh tăng gấp đôi giá token. Bạn trả thêm để nhận đầu ra nhanh hơn khoảng 2,5 lần.

Bạn có thể kiểm tra mức giá hiện tại trong tài liệu giá của Anthropic.

Khi nào nên dùng chế độ nhanh

Dùng standard mode làm mặc định cho phần lớn workload.

Chỉ dùng fast mode khi độ trễ ảnh hưởng trực tiếp đến trải nghiệm người dùng, ví dụ:

• Trợ lý lập trình tương tác
• Agent có người dùng đang chờ kết quả
• UI streaming phản hồi theo thời gian thực
• Tác vụ mà từng giây phản hồi đều quan trọng

Không nên dùng fast mode cho:

• Job chạy nền
• Batch job qua đêm
• Pipeline xử lý dữ liệu
• Eval tự động
• Agent loop không cần phản hồi ngay

Quy tắc triển khai đơn giản:

Nếu người dùng đang chờ trực tiếp → cân nhắc fast mode
Nếu job chạy nền hoặc không khẩn cấp → dùng standard mode

Tham số effort ảnh hưởng trực tiếp đến chi phí

Tham số effort kiểm soát lượng token model sử dụng trong toàn bộ phản hồi, bao gồm cả tool calls. Vì token đầu ra là phần đắt nhất, chọn sai effort có thể làm chi phí tăng mạnh mà không cần thiết.

Các mức effort, từ tiết kiệm nhất đến tốn kém nhất:

Effort	Khi nên dùng
low	Phân loại, trích xuất ngắn, trả lời đơn giản
medium	Tác vụ thông thường cần cân bằng chất lượng và chi phí
high	Mặc định, cần phân tích kỹ hơn
xhigh	Tác vụ lập trình, suy luận sâu, nhiều bước
max	Không giới hạn, chỉ dùng khi thật sự cần

Ví dụ cách chọn:

Phân loại ticket hỗ trợ khách hàng → low
Tóm tắt tài liệu ngắn → low hoặc medium
Giải thích lỗi trong code → high
Refactor nhiều file hoặc agentic coding → xhigh
Tác vụ nghiên cứu/suy luận rất sâu → max

Một tác vụ phân loại ở low có thể dùng ít token đầu ra hơn nhiều so với high. Cùng một model, cùng giá mỗi token, nhưng tổng chi phí có thể thấp hơn đáng kể.

Xem thêm hướng dẫn về tham số effort của Anthropic.

Công thức tính chi phí

Bạn có thể ước tính chi phí mỗi request bằng công thức:

Chi phí đầu vào = input_tokens / 1,000,000 × giá đầu vào
Chi phí đầu ra = output_tokens / 1,000,000 × giá đầu ra
Tổng chi phí = chi phí đầu vào + chi phí đầu ra

Với Opus 4.8 standard mode:

Chi phí = input_tokens / 1,000,000 × 5
        + output_tokens / 1,000,000 × 25

Ví dụ JavaScript đơn giản:

function estimateOpusCost(inputTokens, outputTokens, mode = "standard") {
  const pricing = {
    standard: { input: 5, output: 25 },
    fast: { input: 10, output: 50 },
  };

  const rate = pricing[mode];

  return {
    inputCost: (inputTokens / 1_000_000) * rate.input,
    outputCost: (outputTokens / 1_000_000) * rate.output,
    totalCost:
      (inputTokens / 1_000_000) * rate.input +
      (outputTokens / 1_000_000) * rate.output,
  };
}

console.log(estimateOpusCost(1000, 500));
// { inputCost: 0.005, outputCost: 0.0125, totalCost: 0.0175 }

Các kịch bản chi phí thực tế

Các ví dụ dưới đây dùng giá standard mode: $5 cho 1M token đầu vào và $25 cho 1M token đầu ra. Số token thực tế của bạn sẽ phụ thuộc prompt, tool calls và cấu hình effort.

Kịch bản 1: Một lượt chatbot

Giả sử:

• 1.000 token đầu vào
• 500 token đầu ra

Tính toán:

Đầu vào: 1.000 / 1.000.000 × $5 = $0.005
Đầu ra: 500 / 1.000.000 × $25 = $0.0125
Tổng: khoảng $0.018 mỗi lượt

Nếu tác vụ chỉ cần phản hồi ngắn và dùng low effort, chi phí mỗi lượt có thể giảm xuống dưới một xu.

Kịch bản 2: Agentic coding task

Giả sử:

• 50.000 token đầu vào từ repo context
• 8.000 token đầu ra ở mức xhigh

Tính toán:

Đầu vào: 50.000 / 1.000.000 × $5 = $0.25
Đầu ra: 8.000 / 1.000.000 × $25 = $0.20
Tổng: khoảng $0.45 mỗi tác vụ

Nếu phần context 50K token được dùng lại qua nhiều request, prompt caching có thể giảm chi phí đầu vào lặp lại xuống khoảng $0.025. Khi đó tổng chi phí có thể còn khoảng $0.23 mỗi tác vụ.

Kịch bản 3: Batch job qua đêm

Giả sử:

• 1.000.000 token đầu vào
• 200.000 token đầu ra
• Chạy qua Batch API với chiết khấu 50%

Tính toán:

Đầu vào: 1.000.000 / 1.000.000 × $5 × 0.5 = $2.50
Đầu ra: 200.000 / 1.000.000 × $25 × 0.5 = $2.50
Tổng: khoảng $5.00 cho toàn bộ batch

Nếu bạn đang so sánh với các model rẻ hơn, xem thêm phân tích giá Gemini 3.5 Flash và chi phí API Xiaomi MiMo v2.5.

Prompt caching: nơi tiết kiệm chi phí lớn nhất

Nếu mỗi request đều gửi lại cùng một system prompt, tài liệu hoặc codebase, bạn đang trả lại toàn bộ chi phí đầu vào cho nội dung lặp lại.

Prompt caching giúp giảm chi phí này. Sau lần ghi cache đầu tiên, các lần đọc lại phần prompt đã cache được tính phí thấp hơn đáng kể, khoảng một phần mười so với giá đầu vào thông thường.

Các trường hợp nên dùng prompt caching:

• System prompt dài và ổn định
• Tài liệu sản phẩm được gửi kèm nhiều lần
• Repo context dùng lại trong nhiều coding task
• Agent cần long-context qua nhiều bước
• Bộ quy tắc hoặc policy cố định

Mô hình triển khai:

Request đầu tiên:
  - Gửi prompt/context đầy đủ
  - Ghi phần lặp lại vào cache

Các request tiếp theo:
  - Tái sử dụng phần đã cache
  - Chỉ gửi phần input mới
  - Trả ít hơn cho token đầu vào lặp lại

Với long-context agents, prompt caching thường là tối ưu chi phí quan trọng nhất.

Batch API cho workload không cần realtime

Batch API phù hợp khi bạn không cần nhận kết quả ngay lập tức. Bạn gửi một tập hợp request, chờ hệ thống xử lý theo batch, rồi nhận kết quả với chi phí thấp hơn mỗi token.

Nên dùng Batch API cho:

• Evals
• Bulk summarization
• Data labeling
• Chấm điểm hoặc phân loại dữ liệu hàng loạt
• Pipeline xử lý nội dung
• Job chạy ban đêm

Opus 4.8 hỗ trợ tối đa 300K token đầu ra qua Batch API với beta header:

output-300k-2026-03-24

Trong khi đó, endpoint đồng bộ hỗ trợ tối đa 128K token đầu ra.

Quy tắc chọn endpoint:

Cần phản hồi ngay → Messages API đồng bộ
Không cần phản hồi ngay → Batch API
Cần output rất dài → Batch API với beta header phù hợp

Giá Opus qua các thế hệ

Opus 4.8 giữ nguyên mức giá so với các phiên bản gần đây. Điểm đáng chú ý là giá đã giảm mạnh từ thế hệ 4.5.

Mô hình	Đầu vào mỗi 1M token	Đầu ra mỗi 1M token
Opus 4.1	$15	$75
Opus 4.5	$5	$25
Opus 4.6	$5	$25
Opus 4.7	$5	$25
Opus 4.8	$5	$25

Opus giảm từ $15/$75 xuống $5/$25 ở thế hệ 4.5 và giữ mức đó đến 4.8. Bạn đang dùng chất lượng của 4.8 với mức giá đã ổn định từ 4.5.

Để so sánh trực tiếp với các model chủ lực khác, xem Opus 4.8 vs GPT-5.5 vs Gemini 3.5.

Checklist tối ưu chi phí trước khi scale

Trước khi đưa Opus 4.8 vào production hoặc tăng traffic, hãy kiểm tra các điểm sau:

• Đặt effort theo từng loại tác vụ. Không dùng high hoặc xhigh cho mọi request.
• Giới hạn max_tokens. Đây là chặn trên cho chi phí đầu ra trong trường hợp xấu nhất.
• Cache phần prompt lặp lại. System prompts, tài liệu và codebase nên được cache nếu dùng nhiều lần.
• Dùng Batch API cho job không khẩn cấp. Evals và bulk jobs không nên chạy realtime nếu không cần.
• Giữ standard mode làm mặc định. Chỉ bật fast mode khi có người dùng đang chờ trực tiếp.
• Theo dõi token usage theo request. Đừng chỉ ước tính bằng prompt; hãy đo từ response thực tế.
• Theo dõi hạn mức sử dụng. Rate limit và chi tiêu thường tăng cùng nhau; thay đổi giới hạn hàng tuần của Claude Code là lời nhắc nên giám sát quota thường xuyên.

Theo dõi chi phí thực tế với Apidog

Ước tính chi phí thường khác chi phí thực tế khi vào production, vì response có độ dài khác nhau và tool calls có thể làm số token tăng. Cách chắc chắn nhất là đọc đối tượng usage trong mỗi response của Messages API.

Apidog giúp bạn kiểm tra chi phí thực tế theo request:

• Gửi request Opus 4.8 thật và đọc khối usage trong response
• So sánh token usage giữa các mức effort trên cùng một prompt
• Lưu request cho từng workload và chạy lại khi prompt thay đổi
• Mock endpoint để xây dựng và kiểm thử luồng tích hợp mà không tiêu tốn token

Một workflow thực tế:

1. Tạo request đến Messages endpoint
2. Chạy prompt với effort = low
3. Ghi lại input_tokens và output_tokens
4. Chạy lại với effort = high
5. Chạy lại với effort = xhigh
6. So sánh chi phí và chất lượng
7. Chọn mức effort thấp nhất vẫn đạt yêu cầu

Bạn nên làm bước này trước khi đưa prompt vào production, đặc biệt với các workload có traffic lớn.

Câu hỏi thường gặp

Claude Opus 4.8 có giá bao nhiêu?

Ở standard mode, Opus 4.8 có giá $5 cho mỗi triệu token đầu vào và $25 cho mỗi triệu token đầu ra. Fast mode có giá $10 đầu vào và $50 đầu ra để có tốc độ output nhanh hơn khoảng 2,5 lần.

Opus 4.8 có đắt hơn Opus 4.7 không?

Không. Giá mỗi token giống nhau, nên nâng cấp từ 4.7 lên 4.8 không làm thay đổi chi phí cơ bản.

Khi nào nên dùng fast mode?

Dùng fast mode khi người dùng đang chờ phản hồi realtime và độ trễ là yếu tố quan trọng. Với job nền, batch job hoặc pipeline không khẩn cấp, dùng standard mode để tiết kiệm chi phí.

Cách giảm chi phí Opus 4.8 hiệu quả nhất là gì?

Giảm effort cho tác vụ đơn giản, cache prompt lặp lại, dùng Batch API cho job không khẩn cấp, và đặt max_tokens hợp lý. Token đầu ra là phần cần kiểm soát chặt nhất.

Prompt caching có thật sự tiết kiệm tiền không?

Có. Sau lần ghi cache đầu tiên, phần input lặp lại được đọc với giá thấp hơn nhiều, khoảng một phần mười so với giá đầu vào thông thường. Long-context agents thường hưởng lợi nhiều nhất.

Opus 4.8 có thể tạo tối đa bao nhiêu token đầu ra?

Tối đa 128K token đầu ra trên Messages API đồng bộ, và tối đa 300K token qua Batch API với beta header output-300k-2026-03-24.

Tôi xem token usage ở đâu?

Trong đối tượng usage của mỗi response từ Messages API. Công cụ như Apidog giúp bạn xem và so sánh usage giữa các cấu hình effort.