Bởi Input và output token: Vì sao Claude lệch giá 5 lần
Output token Claude đắt gấp 5 lần input token. Hiểu prefill và decoding để tính đúng hóa đơn agent theo tỷ lệ token đọc và ghi mỗi tháng.
Vì sao output token đắt hơn input token
Output token có giá cao gấp 5 lần input token trên mọi model Claude trong bảng giá hiện tại. Nguyên nhân nằm ở cách thực hiện phép tính. Model chỉ cần một lượt để đọc prompt. Nhưng khi viết câu trả lời, model phải thực hiện một lượt cho từng token, và mỗi lượt phải chờ lượt trước hoàn tất.
Tỷ lệ này giống nhau ở mọi dòng trong bảng giá. Vì vậy, model bạn chọn không quyết định phần output chiếm bao nhiêu trong hóa đơn. Hình dạng workload mới quyết định điều đó. Một bước của agent đọc 60,000 token và trả lời bằng 800 token sẽ tốn gần như không đáng kể cho output. Một tác vụ soạn thảo đọc 2,000 token và ghi 12,000 token sẽ tốn gần như không đáng kể cho input. Cả hai trường hợp được tính bên dưới theo mức giá Anthropic công bố vào tháng 8 năm 2026.
Prefill chạy một lần, decoding chạy một lần cho mỗi token
Inference server xử lý một request qua 2 giai đoạn có chi phí rất khác nhau. Prefill đọc prompt. Decoding tạo câu trả lời.
Prefill xử lý toàn bộ prompt cùng lúc. Mọi token trong prompt đi qua network trong cùng một forward pass, nên phần tính attention và feed-forward trở thành một số ít phép nhân ma trận lớn, mỗi phép bao phủ hàng nghìn token. Chỉ cần đọc một lần model weights từ memory là đủ xử lý toàn bộ prompt. Các matrix unit của accelerator luôn bận, nên prefill bị giới hạn bởi năng lực tính toán: giới hạn nằm ở tốc độ chip thực hiện phép nhân.
Decoding không thể hoạt động như vậy vì token 2 phụ thuộc vào token 1. Token model vừa tạo ra trở thành một phần input của bước tiếp theo, nên các bước không thể chạy đồng thời. Mỗi output token cần một forward pass riêng, và mỗi pass phải đọc toàn bộ model weights từ high-bandwidth memory để tạo ra một token. Vì vậy decoding bị giới hạn bởi memory: giới hạn nằm ở tốc độ di chuyển weights, không phải tốc độ thực hiện phép nhân. Cùng lượng lưu chuyển weights đó xử lý được cả một prompt trong prefill, nhưng chỉ tạo được 1 token trong decoding.
Serving system khắc phục bằng cách batching. Nhiều request cùng decode, nên 1 lần đọc weights tạo ra 1 token cho mỗi request trong batch. Vì vậy decoding mới có chi phí chấp nhận được. Giới hạn vẫn nằm ở memory. Mỗi request đang được xử lý giữ một KV cache (key/value cache, trạng thái attention đã lưu cho từng token tính đến thời điểm hiện tại). Cache này tăng theo mỗi token được tạo ra. Khi cache lấp đầy accelerator, batch không thể tăng thêm.
Không điều nào trong số đó cho bạn một con số chính xác, và bạn không nên xem 5x là tỷ lệ phần cứng được đo trực tiếp. Đây là mức giá do Anthropic đặt ra, dựa trên sự bất đối xứng đó. Điều bạn có thể tự kiểm tra là hướng chênh lệch, và việc này mất khoảng 1 phút.
Tự đo khoảng cách giữa input và output
Cài các công cụ trên bất kỳ máy Ubuntu nào:
sudo apt update && sudo apt install -y curl jq moreutilsBây giờ stream một prompt ngắn yêu cầu câu trả lời dài, rồi ghi thời điểm nhận được từng dòng.
curl -sN https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{"model":"claude-sonnet-5","max_tokens":1000,"stream":true,
"messages":[{"role":"user","content":"Count from 1 to 300, one number per line."}]}' \
| ts -s '%.s'ts -s thêm số giây đã trôi qua kể từ khi command bắt đầu vào đầu mỗi dòng. Có 2 điểm đáng đọc từ output này. Dòng content_block_delta đầu tiên là thời gian đến token đầu tiên của bạn; toàn bộ quá trình prefill diễn ra trong dòng đó. Mỗi dòng sau là một bước decoding nhỏ, và các mốc thời gian tiếp tục tăng cho đến khi message_stop xuất hiện.
Bây giờ đảo ngược hình dạng này. Đưa một tài liệu dài vào prompt và giới hạn câu trả lời ở vài token.
curl -sN https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d "$(jq -n --rawfile doc ./long-document.txt \
'{model:"claude-sonnet-5", max_tokens:16, stream:true,
messages:[{role:"user", content:("Answer in one word. Is this document about networking?\n\n" + $doc)}]}')" \
| ts -s '%.s'Delta đầu tiên lâu hơn so với prompt ngắn, vì prefill phải đọc nhiều văn bản hơn. Sau khi delta đó xuất hiện, response gần như kết thúc ngay lập tức vì chỉ còn vài token cần decode. Hàng chục nghìn token được đưa vào nhưng đồng hồ hầu như không nhích. Vài trăm token được tạo ra nhưng đồng hồ chạy trong suốt quá trình đó.
Mọi response không stream đều kết thúc bằng các con số được dùng để tính phí.
{
"usage": {
"input_tokens": 41283,
"output_tokens": 6,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 0
}
}Ghi lại cả 4 trường cho mỗi request. output_tokens bao gồm extended thinking, nên model suy nghĩ trước khi trả lời sẽ tính phí phần suy nghĩ đó theo mức giá của output. Để định giá prompt trước khi gửi, POST /v1/messages/count_tokens nhận cùng request body, trả về {"input_tokens": N} mà không chạy model và không tính phí.
Chi phí Claude trên mỗi triệu token tính đến tháng 8 năm 2026
The data behind this chart
[
{
"label": "Haiku 4.5",
"input_usd": 1,
"output_usd": 5,
"output_multiple": 5
},
{
"label": "Sonnet 5 (to 31 Aug)",
"input_usd": 2,
"output_usd": 10,
"output_multiple": 5
},
{
"label": "Sonnet 5 (from 1 Sep)",
"input_usd": 3,
"output_usd": 15,
"output_multiple": 5
},
{
"label": "Opus 5",
"input_usd": 5,
"output_usd": 25,
"output_multiple": 5
},
{
"label": "Fable 5",
"input_usd": 10,
"output_usd": 50,
"output_multiple": 5
}
]Cột cuối là output chia cho input và có giá trị 5 trên mọi dòng. Haiku 4.5 tính phí $1 cho input và $5 cho output. Opus 5 tính phí $5 và $25. Fable 5 là model đắt nhất, tính phí $10 và $50; mức phí Fable 5 mang lại những gì đáng đọc trước khi bạn bỏ qua dòng trên cùng. Khi chuyển lên mức cao hơn, cả hai phía đều tăng theo cùng một hệ số. Vì vậy, tổng chi phí thay đổi nhưng tỷ lệ input trên output vẫn giữ nguyên.
Sonnet 5 xuất hiện 2 lần vì mức phí giới thiệu sẽ hết hạn. Đến hết ngày 31 tháng 8 năm 2026, model này tính phí $2 và $10. Từ ngày 1 tháng 9 năm 2026, mức phí tiêu chuẩn $3 và $15 sẽ được áp dụng, cao hơn 50% ở cả hai phía. Mọi ví dụ bên dưới đều dùng mức phí tháng 8.
Mức phí có thể thay đổi, và bạn không nên kiểm tra chúng trên trang này. claude.com/pricing là nguồn thông tin chính thức. Phương pháp tính vẫn có giá trị ngay cả khi giá thay đổi.
Có một điểm cần lưu ý nhưng bảng giá không thể hiện. Tài liệu của Anthropic cho biết Claude 4.7 và các model mới hơn dùng tokenizer mới, tạo ra nhiều hơn khoảng 30% token cho cùng một văn bản so với tokenizer trong Sonnet 4.6 và các phiên bản cũ hơn. Nếu chỉ so sánh giá trên mỗi triệu token, bạn sẽ đánh giá model mới có lợi hơn thực tế, vì cùng một tài liệu tạo ra nhiều token hơn trên model đó. Hãy so sánh theo chi phí cho mỗi tác vụ hoàn chỉnh và đếm prompt thực tế trên model bạn định dùng. giá trị thực tế của một triệu token Claude trong văn bản giải thích khối lượng đó trông như thế nào khi sử dụng thực tế.
Khi nào output bắt đầu chiếm phần lớn chi phí?
Với output có giá bằng 5 lần input, điểm hòa vốn rất dễ tính nhẩm. Gọi số token input là I và số token output là O. Chi phí input là I. Chi phí output là 5 lần O. Output chiếm hơn một nửa tổng chi phí khi 5 lần O lớn hơn I, tương đương tỷ lệ 5 token input trên 1 token output.
Vì vậy, nếu prompt dài hơn câu trả lời trên 5 lần, input là khoản chi lớn hơn. Dưới tỷ lệ đó, output là khoản chi lớn hơn.
The data behind this chart
[
{
"label": "100:1",
"input_share_pct": 95.2,
"output_share_pct": 4.8
},
{
"label": "75:1",
"input_share_pct": 93.75,
"output_share_pct": 6.25
},
{
"label": "20:1",
"input_share_pct": 80,
"output_share_pct": 20
},
{
"label": "10:1",
"input_share_pct": 66.7,
"output_share_pct": 33.3
},
{
"label": "5:1",
"input_share_pct": 50,
"output_share_pct": 50
},
{
"label": "1:1",
"input_share_pct": 16.7,
"output_share_pct": 83.3
},
{
"label": "1:6",
"input_share_pct": 3.2,
"output_share_pct": 96.8
}
]Ở tỷ lệ 100 trên 1, output chiếm 4.8% chi phí, và rút ngắn prompt là việc duy nhất đáng làm. Ở tỷ lệ 5 trên 1, hai bên có chi phí bằng nhau. Ở tỷ lệ 1 trên 6, output chiếm 96.8% và prompt chỉ tạo ra sai số làm tròn. Hầu hết mọi người đều đoán sai tỷ lệ của mình, vì vậy hãy lấy tỷ lệ đó từ log trước khi tối ưu bất cứ thứ gì.
Một workload của agent: context dài, câu trả lời ngắn
Thực hiện một bước của retrieval agent: 60,000 input token từ tài liệu được truy xuất và lịch sử hội thoại, rồi tạo câu trả lời 800 token. Tỷ lệ là 75 trên 1. Đây là mức bình thường với mọi hệ thống đọc trước rồi mới ghi.
The data behind this chart
[
{
"label": "Haiku 4.5",
"input_cost": 0.06,
"output_cost": 0.004,
"total_cost": 0.064
},
{
"label": "Sonnet 5 (Aug)",
"input_cost": 0.12,
"output_cost": 0.008,
"total_cost": 0.128
},
{
"label": "Opus 5",
"input_cost": 0.3,
"output_cost": 0.02,
"total_cost": 0.32
},
{
"label": "Fable 5",
"input_cost": 0.6,
"output_cost": 0.04,
"total_cost": 0.64
}
]Output chiếm 6.25% chi phí của mỗi lần gọi trên mọi model, vì tỷ lệ này cố định trong toàn bộ bảng giá. Mỗi lần gọi có chi phí $0.32 trên Opus 5, $0.128 trên Sonnet 5 theo mức giá tháng 8, và $0.064 trên Haiku 4.5. Thực hiện 200 bước như vậy mỗi ngày trên Opus 5 sẽ tốn $64 mỗi ngày.
Khi thấy rõ tỷ trọng này, yếu tố cần tối ưu khá rõ ràng. Giảm câu trả lời từ 800 token xuống 400 token chỉ tiết kiệm khoảng 3% chi phí của lần gọi. Loại bỏ 20,000 token context cũ khỏi prompt tiết kiệm khoảng một phần ba chi phí. Việc siết độ dài output của một agent thiên về đọc gần như không đem lại hiệu quả. token của coding agent thực sự được dùng vào đâu phân tích những nội dung tạo nên prompt đó ngay từ đầu.
Một workload tạo nội dung: prompt ngắn, bản nháp dài
Bây giờ đổi tỷ lệ. Brief 2,000 token, bản nháp 12,000 token, tỷ lệ 1 trên 6.
The data behind this chart
[
{
"label": "Haiku 4.5",
"input_cost": 0.002,
"output_cost": 0.06,
"total_cost": 0.062,
"batch_total_cost": 0.031
},
{
"label": "Sonnet 5 (Aug)",
"input_cost": 0.004,
"output_cost": 0.12,
"total_cost": 0.124,
"batch_total_cost": 0.062
},
{
"label": "Opus 5",
"input_cost": 0.01,
"output_cost": 0.3,
"total_cost": 0.31,
"batch_total_cost": 0.155
},
{
"label": "Fable 5",
"input_cost": 0.02,
"output_cost": 0.6,
"total_cost": 0.62,
"batch_total_cost": 0.31
}
]Output chiếm 96.8% hóa đơn này. Opus 5 có giá $0.31 cho mỗi bản nháp, so với $0.062 trên Haiku 4.5. Chênh lệch gấp 5 lần này gần như hoàn toàn đến từ phía output. Đây chính là phần mà model rẻ hơn giúp bạn tiết kiệm nhiều nhất.
Cột cuối là cùng workload này khi chạy qua Batch API, được giảm 50% cho cả input và output. Opus 5 giảm còn $0.155 cho mỗi bản nháp. Batch trả kết quả trong vòng 24 giờ thay vì ngay lập tức, nên phù hợp để tạo báo cáo qua đêm và phân loại hàng loạt. Nó 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ả.
Model routing phát huy hiệu quả ở đây, khác với bước agent. Nếu phần dài của workload mang tính cơ học, chẳng hạn định dạng lại văn bản hoặc mở rộng một outline đã được bạn phê duyệt, model rẻ hơn có thể tạo các token đó với chi phí bằng một phần năm. chọn giữa Opus, Sonnet và Haiku giải thích chất lượng thực tế nằm ở đâu.
Cache chỉ giảm giá input, và chỉ input
Prompt caching lưu một prefix của prompt trên server và tính phí một phần giá input khi đọc lại prefix đó. Tính đến tháng 08 năm 2026, các hệ số là 1.25x giá input cơ bản để ghi cache 5 phút, 2x để ghi cache 1 giờ và 0.1x để đọc một cache hit.
Output không nằm trong cơ chế này. Không có output được cache. Mỗi token model tạo ra đều bị tính theo toàn bộ giá output trong mọi lần gọi, bất kể bao nhiêu token của prompt được trả về từ cache hit.
Xét cùng một bước của agent trên Opus 5, với 55,000 trong tổng số 60,000 input token được phục vụ từ warm cache.
The data behind this chart
[
{
"label": "No cache",
"input_cost": 0.3,
"output_cost": 0.02,
"total_cost": 0.32
},
{
"label": "55k prefix cache read",
"input_cost": 0.0525,
"output_cost": 0.02,
"total_cost": 0.0725
}
]Chi phí của lần gọi giảm từ $0.32 xuống còn $0.0725. Dòng output không thay đổi: $0.02 trước và $0.02 sau. Caching giảm hóa đơn và thay đổi cơ cấu chi phí. Output chiếm 6.25% chi phí của lần gọi đó. Hiện output chiếm hơn một phần tư tổng chi phí, nên yếu tố cần tối ưu tiếp theo có thể đã thay đổi.
Lần gọi đầu tiên phải trả phí ghi cache. Ghi cache 5 phút có giá bằng 1.25x input cơ bản, nên hoàn vốn sau một cache hit. Ghi cache 1 giờ có giá bằng 2x, nên cần hai cache hit. hệ số ghi và đọc cache, cùng thời điểm caching không còn hiệu quả về chi phí trình bày phép tính đó.
Bốn đòn bẩy bạn có thể kiểm soát
- Đặt
max_tokensở độ dài output p95, không đặt theo mức tối đa của model. - Chuyển các bước dài dòng sang model rẻ hơn.
- Batch mọi việc không có ai chờ kết quả.
- Xóa các instruction làm reply dài hơn.
max_tokens là giới hạn cứng. Đặt giá trị cao không tự làm phát sinh chi phí, vì bạn chỉ bị tính phí cho số token được tạo ra, không bao giờ bị tính phí cho giới hạn này. Tác dụng của cap rộng là loại bỏ giới hạn đối với một reply bị xử lý sai. Lấy phân phối output_tokens từ log, đặt cap cao hơn một chút so với phân vị 95, rồi xử lý stop_reason: "max_tokens" trong code bằng cách tiếp tục response hoặc retry. Một lần bị cắt mà bạn phát hiện được sẽ rẻ hơn một đoạn lan man 4,000 token mà bạn phải trả tiền rồi bỏ đi. Extended thinking cũng tính vào output_tokens, nên hãy đặt ngân sách cho phần này dựa trên cùng dữ liệu.
Routing có hiệu quả khi phần tốn kém của một bước nằm ở khối lượng thay vì khả năng phán đoán. Giữ model mạnh để đưa ra quyết định, rồi giao phần nhập nội dung cho model rẻ hơn. Trước tiên hãy đo phiên bản đã route trên evaluation set của chính bạn, vì một model rẻ cần chạy hai lần sẽ tốn hơn một lần chạy model đắt.
Batching là đòn bẩy duy nhất giúp giảm giá output. Giảm 50% cho cả hai phía, nhận kết quả trong vòng 24 giờ, và mọi việc chạy theo lịch đều đủ điều kiện.
Đòn bẩy cuối cùng là thứ mọi người thường bỏ qua. Những câu như "hãy thật kỹ" và "hãy giải thích suy luận của bạn" làm tăng độ dài output trong mọi call sau đó. Thay chúng bằng định dạng bạn muốn: "Trả lời trong tối đa ba câu", hoặc "Chỉ trả về object JSON, không có phần mở đầu". Một system prompt thêm 300 token vào mỗi reply sẽ tốn gấp năm lần so với cùng 300 token nằm trong prompt. kiểm soát chi phí của agent chạy liên tục trình bày phần monitoring, còn API hay subscription cố định rẻ hơn cho kiểu sử dụng của bạn là vấn đề nên giải quyết trước khi bạn mất một tuần tinh chỉnh chi phí theo từng token mà subscription đã có thể bao gồm.
FAQ
Vì sao output token có giá cao hơn input token?
Việc sinh output token cần nhiều thời gian accelerator hơn cho mỗi token. Prompt được xử lý trong một forward pass trên toàn bộ nội dung, nên một lần đọc model weights đã bao phủ hàng nghìn token và phần cứng bị giới hạn bởi thông lượng phép nhân. Reply được tạo từng token một. Mỗi token cần một forward pass riêng, đọc lại toàn bộ model weights. Vì vậy, phần cứng bị giới hạn bởi memory bandwidth. Anthropic tính giá output cao gấp 5 lần input trên toàn bộ catalogue hiện tại, từ Haiku 4.5 đến Fable 5.
Prompt caching có làm output token rẻ hơn không?
Không. Prompt caching chỉ áp dụng cho input. Tính đến August 2026, cache read có giá bằng 0.1x mức giá input cơ bản. Cache write có giá 1.25x với thời lượng 5 minute hoặc 2x với thời lượng 1 hour. Output luôn được tính theo mức giá đầy đủ trong mỗi call, bất kể cache hoạt động thế nào. Vì vậy, caching làm thay đổi cả cơ cấu lẫn quy mô hóa đơn: khi phần input giảm mạnh, output trở thành khoản đáng tối ưu nhất.
max_tokens cao có khiến tôi mất tiền nếu reply trả về ngắn không?
Không. Bạn chỉ bị tính phí cho số token model thực sự tạo ra, nên max_tokens là mức trần chứ không phải số lượng được giữ chỗ. Tuy vậy, tham số này vẫn quan trọng vì đây là giới hạn cứng duy nhất đối với reply chạy quá dài. Đặt nó cao hơn một chút so với percentile 95 của output_tokens mà bạn quan sát được. Sau đó xử lý stop_reason: "max_tokens" trong code thay vì phát hành một câu trả lời bị cắt mà không có thông báo.
Làm cách nào để tìm tỷ lệ input so với output token của riêng tôi?
Ghi log input_tokens, output_tokens, cache_read_input_tokens và cache_creation_input_tokens từ object usage của mọi response, rồi chia tổng số liệu trong một tuần. Nếu tỷ lệ cao hơn 5 input trên 1 output, chi phí của bạn nằm ở prompt. Hãy cache phần ổn định và rút gọn phần còn lại. Nếu tỷ lệ thấp hơn mức đó, chi phí của bạn nằm ở reply. Hãy giới hạn độ dài reply và chuyển các bước tạo ra nhiều output nhất sang model rẻ hơn hoặc Batch API.