Token input và output: Vì sao Claude lệch chi phí?

Chi phí token output cao hơn token input

Token output có giá cao gấp 5 lần token input trên mọi Claude model trong danh mục hiện tại. Nguyên nhân nằm ở cách tính toán. Model chỉ cần một lượt chạy để đọc prompt. Khi viết câu trả lời, model phải chạy 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 trên mọi dòng trong bảng giá, vì vậy model bạn chọn không thay đổi tỷ lệ chi phí dành cho output trong tổng hóa đơn. Tỷ lệ input và output của workload mới là yếu tố quyết định. 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. Hai trường hợp này được tính chi tiết bên dưới theo bảng 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 xử lý hàng nghìn token. Một lần đọc model weights từ memory đã đủ phục vụ 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ể làm 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ó một forward pass riêng. 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 weight traffic xử lý toàn bộ prompt trong prefill chỉ tạo ra 1 token trong decoding.

Các hệ thống serving khắc phục vấn đề này bằng cách batching. Nhiều request được decode cùng nhau, nên một lần đọc weights tạo ra 1 token cho mỗi request trong batch. Đây là lý do decoding vẫn có chi phí chấp nhận được. Nhưng giới hạn vẫn nằm ở memory. Mỗi request đang chạy 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 từng 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 thực tế. Đó là mức giá do Anthropic đặt ra, dựa trên sự bất đối xứng này. Điều bạn có thể tự kiểm tra là xu hướng, và việc đó mất khoảng 1 phút.

Tự đo khoảng cách 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 moreutils

Bây giờ stream một prompt ngắn yêu cầu câu trả lời dài, đồng thời thêm thời gian nhận được vào đầu mỗi 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 vào đầu mỗi dòng số giây đã trôi qua kể từ khi lệnh bắt đầu. Có 2 thông tin đáng đọc từ output đó. Dòng content_block_delta đầu tiên là thời gian đến token đầu tiên của bạn, và toàn bộ quá trình prefill diễn ra trong khoảng thời gian đó. Mỗi dòng sau đó là một bước decoding nhỏ, còn 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 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 đáng kể. 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, còn đồng hồ chạy trong toàn bộ khoảng thời gian đó.

Mọi response không stream đều kết thúc bằng các số liệu dùng để tính phí.

{
  "usage": {
    "input_tokens": 41283,
    "output_tokens": 6,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 0
  }
}

Ghi log 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 phí output. Để tí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í. Đây không phải phần duy nhất của API không tính phí, và bạn không bao giờ bị tính phí cho những phần nào của Claude API là thông tin đáng kiểm tra trước khi lập ngân sách cho dự án đầu tiên.

Chi phí Claude cho mỗi triệu token tính đến tháng 8 năm 2026

[
  {
    "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à tỷ lệ output chia cho input, và tỷ lệ này là 5 trên mọi dòng. Haiku 4.5 tính $1 cho input và $5 cho output. Opus 5 tính $5 cho input và $25 cho output. Fable 5 là model đắt nhất, tính $10 cho input và $50 cho output. Bạn nên xem Fable 5 tính ở mức giá đó mang lại gì trước khi loại bỏ dòng đầu tiên. Khi chuyển lên mức model cao hơn, cả hai mức giá đều nhân với cùng một hệ số. Vì vậy, tổng chi phí thay đổi nhưng tỷ lệ input và output vẫn giữ nguyên.

Sonnet 5 xuất hiện 2 lần vì mức giá 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 $2 cho input và $10 cho output. Từ ngày 1 tháng 9 năm 2026, mức giá tiêu chuẩn $3 cho input và $15 cho output sẽ được áp dụng. Cả hai mức đều cao hơn 50%. Mọi ví dụ tính toán bên dưới đều dùng mức giá tháng 8.

Mức giá có thể thay đổi, và bạn không nên kiểm tra giá tại 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 mức giá thay đổi.

Bảng giá không thể hiện một điểm cần lưu ý. Tài liệu của Anthropic cho biết các model Claude 4.7 trở lên dùng tokenizer mới. Tokenizer này 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 chi phí trên mỗi triệu token, bạn sẽ đánh giá model mới cao hơn thực tế, vì cùng một tài liệu sẽ có nhiều token hơn trên model đó. Hãy so sánh chi phí cho mỗi tác vụ hoàn chỉnh, đồng thời tính các prompt thực tế của bạn trên model bạn định sử dụng. Vấn đề tương tự cũng xảy ra giữa các nhà cung cấp, vì tokenizer của họ khác nhau nhiều hơn mức này. Do đó, tính chi phí một công việc thực tế trên cả Claude và ChatGPT sẽ cung cấp nhiều thông tin hơn việc đặt 2 bảng giá cạnh nhau. một triệu token Claude tương đương bao nhiêu văn bản thực tế giải thích rõ khối lượng này trong thực tế.

Khi nào output bắt đầu chiếm phần lớn chi phí?

Khi 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. Nếu thấp hơn tỷ lệ đó, output là khoản chi lớn hơn.

[
  {
    "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 khoản chi 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 đoán sai tỷ lệ của chính mình, vì vậy hãy lấy tỷ lệ này từ log trước khi tối ưu bất kỳ 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, cùng một câu trả lời 800 token. Tỷ lệ là 75 trên 1. Đây là mức bình thường đối với mọi tác vụ đọc trước khi ghi.

[
  {
    "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 call trên mọi model, vì tỷ lệ này cố định trong toàn bộ bảng giá. Call này có giá $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. Chạy 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ỷ lệ này, điểm cần tối ưu trở nên hiển nhiên. 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 call. Loại bỏ 20,000 token context cũ khỏi prompt tiết kiệm khoảng một phần ba chi phí. Tối ưu độ 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.

Tác vụ generation: prompt ngắn, bản nháp dài

Bây giờ đổi tỷ lệ. Một brief 2,000 token và một bản nháp 12,000 token, theo tỷ lệ 1 trên 6.

[
  {
    "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% chi phí này. Opus 5 có giá $0.31 cho mỗi bản nháp, so với $0.062 khi dùng Haiku 4.5. Chênh lệch gấp 5 lần này gần như hoàn toàn đến từ output. Đây chính là phần mà model rẻ hơn giúp tiết kiệm nhiều nhất.

Cột cuối là cùng tác vụ này qua Batch API, với mức giảm 50% cho 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 để generate report qua đêm và classification 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 có lợi trong trường hợp này, nhưng không bao giờ có lợi ở bước agent. Nếu phần dài của tác vụ mang tính cơ học, chẳng hạn reformat text hoặc mở rộng một outline đã được bạn phê duyệt, model rẻ hơn có thể tạo số token đó với chi phí bằng một phần 5. chọn giữa Opus, Sonnet và Haiku giải thích ranh giới chất lượng thực tế nằm ở đâu.

Caching giảm chi phí input, chỉ input

Caching cho prompt lưu một prefix của prompt trên server và tính phí đọc lại theo một phần của mức giá input. Tính đến tháng 8 năm 2026, các hệ số là 1.25x mức giá input cơ bản để ghi cache trong 5 phút, 2x để ghi cache trong 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 luôn bị tính theo toàn bộ mức giá output, trong mọi lần gọi, bất kể bao nhiêu phần prompt được trả về dưới dạng cache hit.

Xét cùng một bước agent trên Opus 5, với 55,000 trong tổng số 60,000 token input được phục vụ từ warm cache.

[
  {
    "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í mỗi 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 đó. Giờ nó chiếm hơn một phần tư tổng chi phí, nên ưu tiên tối ưu tiếp theo cũng thay đổi.

Lần gọi đầu tiên phải trả phí ghi cache. Ghi cache trong 5 phút có chi phí bằng 1.25x input cơ bản, nên hoàn vốn sau một lần cache hit. Ghi cache trong 1 giờ có chi phí bằng 2x, nên cần hai lần cache hit. các hệ số ghi và đọc, cùng đ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 kiểm soát

1. Đặt max_tokens ở độ dài output p95 của bạn, không đặt theo mức tối đa của model.
2. Chuyển các bước dài dòng sang model rẻ hơn.
3. Batch mọi tác vụ không có ai đang chờ kết quả.
4. Xóa các instruction làm reply dài hơn.

max_tokens là giới hạn cứng. Đặt giá trị này cao tự nó không tốn thêm chi phí, vì bạn chỉ bị tính phí cho số token đã tạo ra, không bao giờ bị tính cho giới hạn. Tác dụng của cap rộng là bỏ giới hạn đối với một reply bị kéo dài ngoài dự kiến. Lấy phân phối output_tokens từ log, đặt cap cao hơn percentile 95 một chút, 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ị truncation mà bạn phát hiện được vẫn rẻ hơn một đoạn lan man 4,000 token mà bạn phải trả tiền rồi vứt bỏ. Extended thinking cũng nằm trong output_tokens, nên hãy đặt budget cho phần này dựa trên cùng dữ liệu.

Routing hiệu quả khi phần tốn kém của một bước nằm ở khối lượng chứ không phải khả năng phán đoán. Giữ model mạnh cho việc ra quyết định, rồi chuyển phần gõ nội dung sang model rẻ hơn. Trước tiên hãy đo phiên bản đã routing trên evaluation set của chính bạn, vì một model rẻ cần hai lần thử sẽ tốn hơn một lần thử với model đắt.

Batching là đòn bẩy duy nhất giúp giảm giá output. Được giảm 50% cho cả hai phía, trả kết quả trong vòng 24 giờ, và mọi tác vụ chạy theo lịch đều đủ điều kiện.

Đòn bẩy cuối cùng là thứ nhiều người bỏ qua. Các cụm như "be thorough" và "explain your reasoning" làm tăng độ dài output trong mọi call bạn sẽ thực hiện. Hãy thay chúng bằng định dạng bạn muốn: "Answer in at most three sentences", hoặc "Return only the JSON object, with no preamble". Một system prompt thêm 300 token vào mỗi reply sẽ tốn gấp 5 lần so với cùng 300 token đó ở prompt. duy trì chi phí của agent đang chạy trong tầm kiểm soát trình bày phần monitoring, còn API hay subscription cố định rẻ hơn với mô hình sử dụng của bạn là vấn đề nên chố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. Với một developer, việc này chủ yếu phụ thuộc vào việc Claude Pro có giá $20 mỗi tháng và các giới hạn sử dụng đi kèm có đáp ứng được công việc mà bạn vốn phải đo và tính phí hay không. Nếu bạn đã chạm các giới hạn đó giữa session, trước hết hãy xác định bạn đang chờ giới hạn cửa sổ nào vì cách khắc phục sau đó có thể là dùng model nhỏ hơn, context nhẹ hơn, mua thêm usage credits hoặc chuyển công việc sang API tính phí theo mức sử dụng. Nếu API tính phí theo mức sử dụng rẻ hơn cho công việc đó, hạ xuống plan nhỏ hơn hoặc hủy plan vẫn giữ nguyên tháng bạn đã thanh toán, nên chuyển đổi không khiến bạn mất thêm chi phí. Nếu plan bạn đang so sánh với Pro là plan của ChatGPT thay vì API tính phí theo mức sử dụng, hai bậc subscription đặt cạnh nhau theo giá cho thấy lựa chọn nào rẻ hơn cho công việc coding. Nếu câu hỏi này dành cho một team thay vì một developer, hãy lưu ý rằng Claude Enterprise kết hợp phí theo seat với token được tính theo cùng mức giá API này, nên mọi đòn bẩy trên trang này vẫn áp dụng cho phần hóa đơn được tính theo mức sử dụng.

FAQ

Vì sao output token có chi phí cao hơn input token?

Việc tạo output token cần nhiều thời gian chạy 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 có thể bao phủ hàng nghìn token và phần cứng bị giới hạn bởi khả năng thực hiện phép nhân. Reply được tạo từng token một. Mỗi token cần một forward pass riêng và phải đọc lại toàn bộ model weights, nên 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 tháng 08 năm 2026, cache read có chi phí bằng 0.1x mức giá input cơ bản. Cache write có chi phí bằng 1.25x trong thời gian 5 phút hoặc 2x trong thời gian 1 giờ. Output luôn được tính theo mức giá đầy đủ ở mỗi lần gọi, bất kể cache hoạt động thế nào. Vì vậy, caching thay đổi cả cơ cấu lẫn tổng chi phí của hóa đơn: khi phần input giảm mạnh, output trở thành phầ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 bị tính phí theo số token model thực sự tạo ra, nên max_tokens là giới hạn tối đa chứ không phải số lượng được giữ trước. 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 một reply bị kéo dài ngoài dự kiến. Đặt giá trị này cao hơn một chút so với percentile thứ 95 của output_tokens mà bạn quan sát được, rồi xử lý stop_reason: "max_tokens" trong code thay vì phát hành một answer bị cắt ngầm.

Làm thế nào để tìm tỷ lệ input token trên output token của chính 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 các giá trị trong một tuần. Nếu tỷ lệ lớn hơn 5 input trên 1 output, chi phí của bạn nằm ở prompt. Khi đó, 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í 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 token nhất sang model rẻ hơn hoặc Batch API.