Input vs output token: Vì sao Claude lệch giá 5 lần

Vì sao output token có giá cao hơn input token

Output token có giá cao gấp 5 lần input token trên mọi model Claude trong danh mục hiện tại. Nguyên nhân nằm ở cách tính toán. Đọc prompt là một lượt chạy qua model. Viết câu trả lời là một lượt chạy cho mỗi token, và mỗi lượt phải chờ lượt ngay trước đó hoàn tất.

Tỷ lệ này giống nhau ở mọi dòng trong bảng giá, nên model bạn chọn không làm thay đổi tỷ trọng output trong hóa đơn. Chính dạng workload 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ẽ gần như không tốn chi phí cho output. Một tác vụ soạn thảo đọc 2,000 token và viết 12,000 token sẽ gần như không tốn chi phí cho input. Hai trường hợp này được tính chi tiết bên dưới theo bảng giá do Anthropic công bố, được kiểm tra vào ngày 16 October 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, bao phủ hàng nghìn token mỗi lần. Một lần đọc 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 theo cách đó 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, và mỗi pass phải đọc toàn bộ model weights từ high-bandwidth memory để tạo 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 traffic của weights xử lý toàn bộ prompt trong prefill chỉ tạo được 1 token trong decoding.

Các hệ thống serving khắc phục hạn chế này 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. Đó là lý do decoding vẫn có chi phí chấp nhận được. Giới hạn một lần nữa 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 cho đến thời điểm hiện tại). Cache này tăng lên theo mỗi token được tạo ra. Khi cache lấp đầy accelerator, batch không thể tăng thêm.

Những điều trên không cho bạn một con số chính xác, và không nên xem 5x là một 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à xu hướng, và việc này mất khoảng 1 phút.

Tự đo thời gian xử lý input và output

Cài đặt 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ờ hãy stream một prompt ngắn yêu cầu câu trả lời dài, đồng thời ghi thời điểm nhận được của 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 vào đầu mỗi dòng số giây đã trôi qua kể từ khi command bắt đầu. Có 2 điểm đáng chú ý trong output này. Dòng content_block_delta đầu tiên là thời gian để nhận token đầu tiên, và 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ỏ, 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 đo. Đư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 và đồng hồ chạy trong toàn bộ thời gian đó.

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

Claude tính phí bao nhiêu cho mỗi triệu token tính đến tháng 10/2026

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5",
    "input_usd": 2,
    "output_usd": 10,
    "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à giá trị này là 5 ở mọi hàng. Haiku 4.5 tính phí $1 cho input và $5 cho output. Opus 5 tính phí $5 và $25. Fable 5, model đắt nhất, tính phí $10 và $50, và bạn nhận được gì với mức giá của Fable 5 đáng để đọc trước khi bạn bỏ qua hàng đầu tiên đó. Khi chuyển lên model đắt hơn, cả hai mức giá cùng nhân với một hệ số, nên tổng chi phí thay đổi nhưng tỷ lệ input trên output giữ nguyên.

Sonnet 5 tính phí $2 cho input và $10 cho output. Anthropic ra mắt model này với mức giá đó dưới dạng giá mở đầu đến hết ngày 31 August 2026, sau đó dự kiến tăng lên $3 và $15 từ ngày 1 September. Tuy nhiên, vào ngày 10 August 2026, Anthropic đã đặt $2 và $10 làm mức giá chuẩn. Việc tăng giá không bao giờ có hiệu lực, nên mức giá trong mọi ví dụ bên dưới là mức bạn phải trả hiện nay.

Anthropic cũng đã phát hành các model mới hơn kể từ khi trang này được đăng lần đầu. Hiện tại, claude.com/pricing liệt kê 4 model trên là các model legacy vẫn còn khả dụng. Các model mới vẫn giữ tỷ lệ 5x. Opus 5.5 tính phí $4 và $20, Sonnet 5.5 tính phí $2 và $10, Fable 5.1 tính phí $10 và $50, còn Haiku 5.5 tính phí $0.10 và $0.50 cho prompt tối đa 100,000 token; trên mức đó, giá tăng lên $0.50 và $2.50. Chi phí cho agent step 60,000 token được tính ở phần dưới vẫn nằm trong mức đầu tiên. Tuy nhiên, nếu history của agent tiếp tục tăng, cuối cùng nó sẽ vượt ngưỡng này. Cách hai mức giá của Haiku 5.5 áp dụng cho các tác vụ thực tế cho thấy thay đổi đó ảnh hưởng đến hóa đơn như thế nào.

Mức giá input và output cơ bản của Opus 5.5 thấp hơn Opus 5 20%. Vì vậy, mọi con số của Opus 5 không dùng cache ở phần dưới sẽ thấp hơn 20% khi dùng Opus 5.5. Giá khi dùng cache còn giảm thêm, vì Opus 5.5 tính $0.20 cho mỗi triệu token đọc từ cache hit, so với $0.50 trên Opus 5, tức giảm 60%. Agent step dùng cache có giá $0.0725 trên Opus 5 ở phần dưới sẽ có giá khoảng $0.047 trên Opus 5.5, thấp hơn khoảng 35%.

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 là thứ vẫn còn đúng sau khi giá thay đổi.

Có một điểm cần lưu ý mà bảng giá không thể hiện. Tài liệu của Anthropic cho biết các model Claude 4.7 trở lên sử 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 trước đó. 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, vì cùng một tài liệu sẽ chứa nhiều token hơn trên model đó. Hãy so sánh chi phí cho mỗi task hoàn thành và tính các prompt thực tế của bạn theo đúng model bạn dự đị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ên tính chi phí cho một công việc thực tế trên cả Claude và ChatGPT sẽ cho bạn nhiều thông tin hơn việc đặt hai bảng giá cạnh nhau. một triệu Claude token tương đương bao nhiêu văn bản thực tế 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í?

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 phí lớn hơn. Dưới tỷ lệ đó, output là khoản 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à việc rút ngắn prompt là việc duy nhất đáng làm. Ở tỷ lệ 5 trên 1, hai phía 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 đ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 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, 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 hệ thống đọc trước khi ghi.

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.06,
    "output_cost": 0.004,
    "total_cost": 0.064
  },
  {
    "label": "Sonnet 5",
    "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 trên toàn bộ bảng giá. Mỗi lần gọi có giá $0.32 trên Opus 5, $0.128 trên Sonnet 5 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ỷ lệ này, điểm cần tối ưu rất 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 lỗi thời khỏi prompt tiết kiệm khoảng một phần ba chi phí. 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 gì tạo nên prompt đó ngay từ đầu.

Một workload generation: prompt ngắn, bản nháp dài

Bây giờ đổi tỷ lệ. Một bản tóm tắt 2,000 token, một bản nháp 12,000 token, 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",
    "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
  }
]

Đầu ra 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ần 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 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 với việc 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 đang ngồi chờ kết quả.

Model routing mang lại hiệu quả ở đây theo cách không bao giờ xảy ra ở 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 ra 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 chất lượng thực tế nằm ở mức nào.

Caching chỉ giảm chi phí input, không giảm chi phí output

Prompt caching lưu một prefix của prompt trên server và tính phí đọc lại prefix đó theo một phần của mức giá input. Tính đến ngày 16 October 2026, các hệ số là 1.25x mức giá input cơ bản khi ghi cache 5 phút, 2x khi ghi cache 1 giờ và 0.1x khi đọc một cache hit trên các model được định giá trong trang này. Các model mới nhất có mức đọc cache hit thấp hơn: 0.05x trên Opus 5.5 và Sonnet 5.5, và 0.025x trên Fable 5.1.

Output không nằm trong cơ chế đó. Không có output được cache. Mọi token model ghi ra đều bị tính theo đầy đủ mức giá output trong mọi lần, bất kể bao nhiêu phần của prompt được trả về dưới dạng cache hit.

Thực hiện 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 cung cấp 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 đó. Bây giờ output chiếm hơn một phần tư tổng chi phí, nên việc nê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 5 phút có chi phí bằng 1.25x input cơ bản, nên hoàn vốn sau một cache hit duy nhất. Ghi cache 1 giờ có chi phí bằng 2x, nên cần hai cache hit. phần 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 đó và xác định thời điểm caching không còn giúp tiết kiệm.

Bốn đòn bẩy bạn có thể kiểm soát

1. Đặt max_tokens ở độ dài output p95, không đặt theo mức tối đa của model.
2. Chuyển các bước nhiều chữ sang model rẻ hơn.
3. Batch mọi việc mà không 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. Việc đặt giới hạn này 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 phần giới hạn chưa dùng. Tác dụng của cap rộng là bỏ giới hạn đối với một reply bị lỗi. Lấy phân phối output_tokens từ log, đặt cap cao hơn một chút so với percentile 95, rồi xử lý stop_reason: "max_tokens" trong code bằng cách tiếp tục response hoặc retry. Phát hiện một lần bị cắt sẽ rẻ hơn việc trả tiền cho một đoạn lan man 4,000 token rồi bỏ đi. Phần suy luận cũng nằm trong output_tokens và được tính vào max_tokens, nên hãy đặt kích thước cap dựa trên cùng dữ liệu đó. Với các model có adaptive thinking, hãy giảm mức effort nếu phần suy luận liên tục chiếm hết reply.

Routing hiệu quả khi phần tốn kém của một bước nằm ở volume chứ không phải judgement. Giữ model mạnh để đưa ra quyết định, rồi giao phần gõ nội dung cho 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ẻ nhưng cần thử 2 lần sẽ tốn hơn một lần thử bằng model đắt.

Batching là đòn bẩy duy nhất giảm giá output. Giảm 50% cho cả hai phía, trả 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. Các cụm như "be thorough" và "explain your reasoning" làm tăng độ dài output trong mọi call bạn thực hiện về sau. Hãy thay chúng bằng hình thức output 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. giữ chi phí của agent chạy liên tục trong tầm kiểm soát trình bày phần monitoring, còn xác định API hay gói subscription cố định rẻ hơn với kiểu sử dụng của bạn là việc nên chốt trước khi bạn mất 1 tuần tinh chỉnh chi phí trên từng token mà một gói 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 với mức $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à nếu không bạn phải đo đếm theo mức sử dụng hay không. Nếu bạn đã chạm các giới hạn đó giữa session, trước tiên hãy xác định bạn đang phải chờ window nào, vì giải pháp 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 đã trả tiền, nên việc chuyển đổi không làm 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, bảng so sánh 2 bậc subscription đặt cạnh nhau 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 đúng các mức 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 tính theo mức sử dụng.

FAQ

Vì sao output token có giá cao hơn input token?

Việc tạo output token cần nhiều thời gian xử lý trên 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 weight đã 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 và phải đọc lại toàn bộ model weight. 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 5.5 đến Fable 5.1.

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 16 October 2026, cache read có giá bằng 0.1x mức input cơ bản trên hầu hết model (0.05x trên Opus 5.5 và Sonnet 5.5, 0.025x trên Fable 5.1), còn cache write có giá 1.25x với thời lượng 5 phút hoặc 2x với thời lượng 1 giờ. Output luôn được tính theo mức giá đầy đủ trong mỗi call, bất kể cache đã làm gì. Vì vậy, caching 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 phần đáng tối ưu nhất.

max_tokens cao có làm 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à giới hạn trần chứ không phải số lượng được đặt trước. Tham số này vẫn quan trọng vì đó là giới hạn cứng duy nhất đối với một 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, rồi 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 thế nào để tìm tỷ lệ input token trên 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 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 thấp hơn mức đó, chi phí của bạn nằm ở reply: hãy giới hạn độ dài và chuyển các bước tạo ra nhiều nội dung nhất sang model rẻ hơn hoặc Batch API.