1M token trong Claude có giá bao nhiêu?

1M token trong Claude có giá bao nhiêu?

1M token nghĩa là một triệu token. Đây là đơn vị được dùng để niêm yết giá của mọi Claude API (application programming interface). Không có một mức giá duy nhất, vì token đầu vào và đầu ra được tính theo các mức khác nhau, đồng thời mỗi model có một cặp mức giá riêng. Tính đến tháng 8 năm 2026, một triệu token đầu vào có giá 1 USD trên Claude Haiku 4.5, 2 USD trên Claude Sonnet 5 và 5 USD trên Claude Opus 5.

Đầu ra là phần tốn kém hơn. Trên mọi model hiện tại, giá đầu ra cao gấp 5 lần giá đầu vào. Vì vậy, tỷ lệ giữa hai loại token quyết định hóa đơn của bạn nhiều hơn con số giá niêm yết. Một app gửi các tài liệu dài và nhận về câu trả lời ngắn sẽ có chi phí rất khác một app tạo câu trả lời dài từ prompt ngắn.

Trang này tập trung vào kinh tế theo đơn vị: một token có giá bao nhiêu và cách ước tính hóa đơn trước khi xây dựng hệ thống. Để biết token thực sự được sử dụng vào đâu trong quá trình làm việc, hãy đọc token được sử dụng ở đâu trong một phiên Claude Code.

1M token tương đương với bao nhiêu

Token là một đoạn văn bản mà model đọc hoặc ghi. Hướng dẫn ước tính của Anthropic là 1 token cho mỗi 4 ký tự, hoặc khoảng 0.75 từ tiếng Anh. Vì vậy, 1 triệu token tương đương khoảng 750,000 từ, hoặc khoảng 4 MB văn bản thuần.

Các ước tính đã công bố cho những loại dữ liệu đầu vào phổ biến giúp hình dung rõ hơn về quy mô này.

[
  {
    "label": "Average web page (10 kB)",
    "tokens": "2,500"
  },
  {
    "label": "Documentation page (100 kB)",
    "tokens": "25,000"
  },
  {
    "label": "Research paper PDF (500 kB)",
    "tokens": "125,000"
  }
]

Với các tỷ lệ trên, 1M token tương đương khoảng 400 trang web trung bình được đọc một lần, hoặc 8 bài nghiên cứu có độ dài tương đương. Đây cũng là một lượt xử lý toàn bộ một codebase cỡ trung bình, hoặc một tháng sử dụng chat ở mức nhẹ cho một người.

Hãy xem tất cả các con số trên là ước tính. Code, JSON và văn bản bằng các ngôn ngữ khác tiếng Anh chứa ít từ hơn trong mỗi token, nên tỷ lệ 0.75 là mức lạc quan. Có thêm một yếu tố làm thay đổi số lượng: Claude Opus 4.7 trở lên, bao gồm Opus 5 và Sonnet 5, sử dụng tokenizer mới tạo ra số token nhiều hơn khoảng 30 phần trăm với cùng một văn bản so với Sonnet 4.6 trở xuống. Claude Haiku 4.5 sử dụng tokenizer cũ. Vì vậy, số lượng bạn đo trên Haiku 4.5 sẽ thấp hơn số lượng trên Sonnet 5 với cùng input. Điều này có nghĩa là so sánh trực tiếp giá trên mỗi triệu token qua mốc thay đổi tokenizer là không công bằng. Hãy đếm cùng một prompt trên cả hai model trước khi quyết định.

Claude tính phí bao nhiêu cho mỗi triệu token

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5
  },
  {
    "label": "Sonnet 5 (to 31 Aug 2026)",
    "input_usd": 2,
    "output_usd": 10
  },
  {
    "label": "Sonnet 5 (from 1 Sep 2026)",
    "input_usd": 3,
    "output_usd": 15
  },
  {
    "label": "Opus 5",
    "input_usd": 5,
    "output_usd": 25
  }
]

Claude Sonnet 5 áp dụng mức giá giới thiệu là $2 cho input và $10 cho output đến hết ngày 31 August 2026. Từ ngày 1 September 2026, mức giá tiêu chuẩn được áp dụng: $3 cho input và $15 cho output. Claude Opus 5 có mức giá $5 cho input và $25 cho output.

Mức giá có thể thay đổi. Hãy xem mọi con số trên trang này là ví dụ minh họa được lập vào August 2026, rồi xác nhận số liệu hiện tại trên trang giá chính thức trước khi duyệt ngân sách.

Độ dài context không làm thay đổi mức giá. Trên Claude 4.6 và các phiên bản mới hơn, toàn bộ context window 1M token được tính theo mức giá tiêu chuẩn. Vì vậy, request 900,000 token có cùng chi phí trên mỗi token như request 9,000 token. Prompt dài tốn nhiều tiền hơn vì có nhiều token hơn, không phải vì có mức giá riêng cho long context.

Phép tính vẫn đúng khi giá thay đổi

Mỗi hóa đơn gồm hai phép nhân và một phép cộng.

cost = (input_tokens  / 1,000,000) * input_rate
     + (output_tokens / 1,000,000) * output_rate

Viết dưới dạng code có thể chạy được:

INPUT_RATE = 2.00    # USD per million input tokens, Sonnet 5, August 2026
OUTPUT_RATE = 10.00  # USD per million output tokens

def cost(input_tokens, output_tokens):
    return (input_tokens * INPUT_RATE + output_tokens * OUTPUT_RATE) / 1_000_000

print(f"{cost(4300, 400):.4f}")

Kết quả in ra là 0.0126. Một request gửi 4,300 input token và nhận lại 400 output token có chi phí khoảng 1.3 cent trên Sonnet 5. Đặt hai mức giá ở cùng một chỗ trong code. Khi giá thay đổi, bạn chỉ cần sửa hai dòng, và mọi ước tính trong hệ thống sẽ tự cập nhật theo.

Một ước tính thực tế cho một ứng dụng

Hãy lấy một trợ lý hỗ trợ làm ví dụ. System prompt và tài liệu sản phẩm của ứng dụng có tổng cộng 4,000 token. Chúng được gửi trong mọi request vì Messages API không lưu trạng thái và model không ghi nhớ gì giữa các lần gọi. Câu hỏi của người dùng thêm khoảng 300 token. Một câu trả lời dài khoảng 400 token. Như vậy, mỗi request có 4,300 token input và 400 token output.

Một triệu token input đủ cho khoảng 232 request có cấu trúc như trên. Với 1,000 request mỗi ngày, ứng dụng tiêu thụ 4.3 triệu token input mỗi ngày. Vì vậy, "1M token" chỉ tương đương chưa đến 6 giờ lưu lượng.

[
  {
    "label": "Opus 5, list rates",
    "cost_per_1k_usd": "31.50"
  },
  {
    "label": "Sonnet 5, list rates",
    "cost_per_1k_usd": "12.60"
  },
  {
    "label": "Sonnet 5, Batch API",
    "cost_per_1k_usd": "6.30"
  },
  {
    "label": "Haiku 4.5, list rates",
    "cost_per_1k_usd": "6.30"
  },
  {
    "label": "Sonnet 5, warm prompt cache",
    "cost_per_1k_usd": "5.40"
  }
]

Với Claude Opus 5, lưu lượng đó có chi phí $31.50 cho mỗi 1,000 request. Với Sonnet 5, chi phí là $12.60. Chuyển xuống Claude Haiku 4.5 giảm chi phí còn $6.30, còn prompt cache đang warm trên Sonnet 5 giúp giảm thêm, xuống $5.40.

Nhân với 30 để tính cho một tháng có mức lưu lượng đó. Sonnet 5 theo giá niêm yết có chi phí khoảng $378 mỗi tháng. Cùng ứng dụng đó với cache đang warm có chi phí khoảng $162. Lựa chọn model và quyết định dùng cache của bạn đều có giá trị lớn hơn bất kỳ mức giảm giá nào bạn có thể thương lượng ở quy mô này. Chọn model nào để chạy là một vấn đề riêng. Model rẻ nhất vượt qua được các bài đánh giá của bạn sẽ là lựa chọn phù hợp: cách chọn giữa Opus, Sonnet và Haiku trình bày cách kiểm thử đúng cách.

Prompt caching giảm chi phí phần lặp lại

Tiền tố 4,000 token đó giống hệt nhau trong mọi request, nhưng bạn vẫn trả toàn bộ giá input cho nó mỗi lần. Prompt caching lưu tiền tố đã xử lý và áp dụng mức giá thấp hơn khi tái sử dụng.

Đọc cache có giá bằng 0.1 lần mức input cơ bản. Ghi cache có giá bằng 1.25 lần mức cơ bản với thời hạn 5 phút, hoặc 2 lần mức cơ bản với thời hạn 1 giờ. Vì vậy, cache 5 phút hoàn vốn sau một lần đọc: ghi cache tốn thêm 0.25, còn mỗi lần đọc tiết kiệm 0.9. Cache 1 giờ cần hai lần đọc để hoàn vốn.

Cách đơn giản nhất để bật tính năng này là thêm một field ở cấp cao nhất:

curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5",
    "max_tokens": 1024,
    "cache_control": {"type": "ephemeral"},
    "system": "You are a helpful assistant.",
    "messages": [
      {"role": "user", "content": "What are the key themes in Pride and Prejudice?"}
    ]
  }'

Sau đó đọc block usage được trả về:

{
  "usage": {
    "cache_creation_input_tokens": 5120,
    "cache_read_input_tokens": 1800,
    "input_tokens": 50,
    "output_tokens": 503
  }
}

Ba bộ đếm input đó được tính phí theo ba mức khác nhau và cộng lại thành tổng input thực tế của bạn: total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens. Ước tính chi phí chỉ đọc input_tokens sẽ sai lệch lớn sau khi bật caching.

Có hai nguyên nhân khiến cache không hoàn vốn. Cả hai đều không trả về lỗi.

Tiền tố phải giống hệt từng byte. Cache lookup khớp theo tiền tố, nên timestamp hoặc tên người dùng ở đầu system prompt sẽ làm tiền tố thay đổi trong mọi request. Khi đó, bạn luôn trả 1.25 lần mức input cơ bản và không đọc cache lần nào. Dấu hiệu là cache_creation_input_tokens luôn cao còn cache_read_input_tokens luôn bằng 0. Đặt cache_control ở block cuối cùng có nội dung giống nhau giữa các request, rồi đặt mọi phần thay đổi sau block đó. Khi thay đổi các định nghĩa tools, toàn bộ cache bên dưới chúng sẽ mất hiệu lực, vì quá trình invalidation chạy theo thứ tự tools, rồi system, rồi messages.

Tiền tố phải đủ dài. Độ dài tối thiểu để cache là 512 token trên Opus 5, 1,024 trên Sonnet 5 và 4,096 trên Haiku 4.5. Prompt ngắn hơn sẽ không được cache và cũng không trả về lỗi. Tiền tố 4,000 token trong ví dụ trên được cache trên Sonnet 5 nhưng không được cache trên Haiku 4.5, vì 4,000 thấp hơn ngưỡng của model đó. Khi cả hai bộ đếm đều bằng 0, không có nội dung nào được cache.

Xử lý theo lô giảm một nửa chi phí

Batch API xử lý request không đồng bộ và giảm 50 percent cho cả input lẫn output. Trong ví dụ trên, mức giá $12.60 cho mỗi 1,000 request giảm còn $6.30. Mức giảm giá này được cộng dồn với prompt caching, vì vậy batch job có cache là cách rẻ nhất để xử lý khối lượng công việc lớn.

Đổi lại, bạn phải chấp nhận độ trễ cao hơn. Vì vậy, batch không phù hợp với các tác vụ mà người dùng phải ngồi chờ kết quả. Batch phù hợp để phân loại qua đêm và backfill tài liệu.

Vì sao chi phí chat tăng trong một cuộc hội thoại

Vì API không lưu trạng thái, client của bạn phải gửi lại toàn bộ cuộc hội thoại trong mỗi lượt. Do đó, lượng token được sử dụng trong một chat tăng theo bình phương độ dài cuộc hội thoại, không tăng tuyến tính.

Giả sử mỗi lượt trung bình có 500 token. Lượt 1 gửi 500 input token. Lượt 2 gửi 1,000. Lượt 20 gửi 10,000. Tính tổng theo công thức n(n+1)/2, một cuộc hội thoại 20 lượt đã gửi khoảng 105,000 input token, trong khi bản ghi hội thoại chỉ dài 10,000 token.

Đó là lý do một tính năng chat có chi phí cao hơn con số thể hiện trong bản ghi hội thoại, và vì sao việc cache phần prefix ổn định hoặc tóm tắt các lượt cũ có thể giúp tiết kiệm chi phí trong các thread dài. Một agent lặp qua các tool call cũng có dạng tăng tương tự, thậm chí tệ hơn: mọi kết quả từ tool vẫn nằm trong lịch sử và được gửi lại trong mỗi lượt tiếp theo. Đặt giới hạn chi tiêu cứng cho agent bạn tự chạy đặc biệt quan trọng trong trường hợp này, vì mức tăng đó diễn ra tự động và không có ai theo dõi.

Đếm token trước khi đoán

Không nên suy ra số token từ số từ. API đếm token cho bạn miễn phí, với rate limit riêng và không dùng chung với việc tạo message.

curl https://api.anthropic.com/v1/messages/count_tokens \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "content-type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5",
    "system": "You are a scientist",
    "messages": [{
      "role": "user",
      "content": "Hello, Claude"
    }]
  }'

Response chứa một field:

{ "input_tokens": 14 }

Gửi system prompt và các tool definitions thực tế của bạn, cùng một user message đại diện, rồi đưa con số này vào cost function ở trên. Endpoint nhận cùng body như một message request, nên hình ảnh và PDF cũng được đếm chính xác. Có hai điểm cần lưu ý. Đây là con số ước tính và có thể chênh lệch nhẹ so với con số được tính phí. Kết quả cũng được đo bằng tokenizer của model bạn truyền vào, vì vậy hãy truyền đúng model bạn sẽ chạy.

Không thể đếm trước output token vì chúng chưa tồn tại. Giới hạn chúng bằng max_tokens, sau đó đo phân bố thực tế từ usage.output_tokens trên traffic thực tế.

Các khoản nào khác được tính vào hóa đơn

Token chiếm phần lớn hóa đơn. Một số khoản không phải token và thường khiến người dùng bất ngờ.

• Định nghĩa tool trở thành input token trong mọi request. Chỉ riêng system prompt cho cơ chế sử dụng tool đã thêm 286 đến 406 token trên Opus 5, chưa tính schema của bạn. Mười mô tả tool dài dòng có thể làm prompt nhỏ tăng gấp đôi.
• Web search có giá $10 cho mỗi 1,000 lượt tìm kiếm, chưa tính số token mà kết quả tiêu thụ khi được đưa vào context.
• Web fetch không có phí riêng, nhưng trang được fetch sẽ trở thành input token. Một trang tài liệu 100 kB có khoảng 25,000 token.
• Yêu cầu inference chỉ chạy tại Mỹ bằng inference_geo trên Claude 4.6 trở lên áp dụng hệ số 1.1 cho mọi nhóm token, bao gồm cả cache read và cache write.

API có phải là lựa chọn nên mua hay không còn phụ thuộc vào khối lượng sử dụng của bạn. Dưới một mức sử dụng nhất định, gói tháng cố định sẽ có lợi hơn hẳn, và phần so sánh API với gói Claude thực hiện phép so sánh đó bằng các con số thực tế.

FAQ

1M token trong Claude có giá bao nhiêu?

Mức giá phụ thuộc vào model và token là input hay output. Tính đến tháng 8 năm 2026, một triệu token input có giá $1 trên Claude Haiku 4.5, $2 trên Claude Sonnet 5 theo mức giá giới thiệu, và $5 trên Claude Opus 5. Output có giá gấp 5 lần mức input trên mỗi model này. Sonnet 5 sẽ chuyển sang mức giá $3 cho input và $15 cho output vào ngày 1 tháng 9 năm 2026. Mức giá có thể thay đổi, vì vậy hãy xác nhận trên trang giá chính thức trước khi đưa một con số cụ thể vào ngân sách.

1M token có giống 1M từ không?

Không. Một token tương đương khoảng 4 ký tự tiếng Anh, hoặc khoảng 0.75 từ, nên một triệu token tương đương khoảng 750,000 từ. Đây chỉ là tỷ lệ ước tính. Code, JSON và các ngôn ngữ khác tiếng Anh sử dụng nhiều token hơn trên mỗi từ. Claude Opus 4.7 và các phiên bản sau đó cũng dùng tokenizer mới, tạo ra nhiều hơn khoảng 30 phần trăm token cho cùng một nội dung so với Claude Sonnet 4.6 và các phiên bản trước đó. Vì vậy, không thể dùng trực tiếp số liệu giữa các thế hệ model. Hãy đo bằng endpoint miễn phí /v1/messages/count_tokens và truyền vào model bạn dự định chạy.

Prompt caching có luôn giúp tiết kiệm chi phí không?

Không. Ghi cache trong 5 phút có giá bằng 1.25 lần mức input cơ bản. Vì vậy, một prefix được ghi nhưng không bao giờ được đọc sẽ tốn nhiều hơn 25 phần trăm so với gửi trực tiếp. Chi phí này được bù lại ngay từ lần đọc đầu tiên. Cơ chế này có thể thất bại theo 2 cách và cả hai đều không tạo lỗi. Nếu prefix được cache thay đổi giữa các request, việc tra cứu không bao giờ khớp vì đây là phép so khớp prefix chính xác. Nếu prefix ngắn hơn độ dài tối thiểu có thể cache của model, là 1,024 token trên Sonnet 5 và 4,096 token trên Haiku 4.5, thì không có gì được cache và cũng không có lỗi nào được trả về. Khi cả cache_creation_input_tokens và cache_read_input_tokens đều có giá trị 0, cache không hoạt động.

Vì sao hóa đơn của tôi tăng nhanh hơn số lượng tin nhắn?

Vì toàn bộ cuộc hội thoại được gửi lại trong mỗi lượt. Messages API không lưu state, nên lượt 20 của một cuộc trò chuyện gửi lại toàn bộ 19 lượt trước đó dưới dạng input. Nếu mỗi lượt trung bình có 500 token, một cuộc trò chuyện 20 lượt sẽ gửi khoảng 105,000 token input, trong khi transcript chỉ dài 10,000 token. Agent loop cũng hoạt động tương tự vì mọi kết quả tool vẫn nằm trong history. Hãy cache prefix ổn định, hoặc tóm tắt các lượt cũ rồi loại chúng khỏi request.