Bởi Prompt caching Claude: tính điểm hòa vốn
Claude ghi cache tốn 1,25x, đọc tốn 0,1x giá input. Tính điểm hòa vốn của prefix, rồi kiểm chứng trực tiếp bằng API để biết khi nào bắt đầu tiết kiệm.
Chi phí của prompt caching trước khi bắt đầu tiết kiệm
Prompt caching cho phép Claude dùng lại phần đầu của prompt thay vì đọc lại phần đó trong mỗi lần gọi. Toàn bộ quyết định phụ thuộc vào 2 hệ số nhân trên giá input cơ bản của model. Tính đến tháng 8 năm 2026, ghi vào cache có chi phí bằng 1.25x giá input cơ bản với thời hạn 5 phút, hoặc 2x với thời hạn 1 giờ. Đọc từ cache có chi phí bằng 0.1x. Các hệ số này áp dụng cho toàn bộ danh sách model, nên điểm hòa vốn bên dưới không thay đổi khi giá mỗi token thay đổi.
Đây là việc trả thêm chi phí trước để được giảm giá về sau. Bạn trả thêm một lần để lưu một prefix. Mỗi request sau đó bắt đầu bằng đúng cùng các byte sẽ chỉ trả một phần mười giá input thông thường cho phần đó. Nếu một prefix không bao giờ được dùng lại trong thời hạn của nó, bạn đã trả thêm 25 phần trăm mà không nhận được lợi ích nào.
Điểm hòa vốn, trong một dòng đại số
Gọi B là chi phí input cơ sở của prefix nếu gửi prefix mà không dùng cache. Không dùng cache, N request tốn N lần B. Với cache 5 phút, request đầu tiên ghi prefix với giá 1.25B và N trừ 1 request còn lại đọc prefix với giá 0.1B. Đặt hai tổng chi phí bằng nhau, ta được 0.9N = 1.15, nên N = 1.28. Request thứ hai đã rẻ hơn so với hoàn toàn không dùng cache.
Lặp lại phép tính với thao tác ghi có giá 2x của cache 1 giờ, ta được 0.9N = 1.9, nên N = 2.11. Cache dài hạn cần hai lần đọc mới hòa vốn. Vì vậy, đây không phải lựa chọn mặc định.
Biểu đồ bên dưới tính chi phí này cho prefix 20,000 token trên Claude Opus 5, với giá input cơ sở là $5 cho mỗi triệu token tính đến tháng 8 năm 2026. Nhân mọi giá trị với 0.6 nếu dùng model có giá $3 cho mỗi triệu token. Hình dạng đường cong không thay đổi.
The data behind this chart
[
{
"requests": 1,
"uncached_usd": "0.10",
"cached_5m_usd": "0.125",
"cached_1h_usd": "0.20"
},
{
"requests": 2,
"uncached_usd": "0.20",
"cached_5m_usd": "0.135",
"cached_1h_usd": "0.21"
},
{
"requests": 3,
"uncached_usd": "0.30",
"cached_5m_usd": "0.145",
"cached_1h_usd": "0.22"
},
{
"requests": 5,
"uncached_usd": "0.50",
"cached_5m_usd": "0.165",
"cached_1h_usd": "0.24"
},
{
"requests": 10,
"uncached_usd": "1.00",
"cached_5m_usd": "0.215",
"cached_1h_usd": "0.29"
},
{
"requests": 20,
"uncached_usd": "2.00",
"cached_5m_usd": "0.315",
"cached_1h_usd": "0.39"
}
]Một request đơn lẻ có giá $0.10 nếu không dùng cache và $0.125 nếu dùng cache, nên dùng cache cho prompt chỉ chạy một lần là hoàn toàn không có lợi. Đến request thứ hai, cache 5 phút có giá $0.135 so với $0.20. Cache 1 giờ vẫn đắt hơn ở thời điểm đó, với giá $0.21 so với cùng mức $0.20, và chỉ thấp hơn chi phí không dùng cache từ request thứ ba: $0.22 so với $0.30. Ở 20 request, khoảng chênh lệch là $2.00 so với $0.315.
Một cache hit cũng làm mới entry. Vì vậy, bảng giá được công bố gọi cột đó là cache hits and refreshes. Do đó, endpoint có lưu lượng cao có thể giữ entry 5 phút sống vô thời hạn với giá đọc, còn thời hạn 1 giờ chỉ phát huy lợi ích ghi 2x khi lưu lượng của bạn có những khoảng ngắt thực sự.
Chi phí khi hit rate thấp
Lưu lượng thực tế sẽ có các request cache miss. Một request cache miss nhưng vẫn có breakpoint sẽ bị tính như một write, vì vậy cách mô hình hóa chính xác là biểu diễn chi phí theo hit rate. Biểu đồ dưới đây áp dụng cho 1,000 request, mỗi request có cùng một prefix 20,000 token.
The data behind this chart
[
{
"hit_rate_percent": 0,
"cost_5m_usd": "125.00",
"cost_1h_usd": "200.00",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 25,
"cost_5m_usd": "96.25",
"cost_1h_usd": "152.50",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 50,
"cost_5m_usd": "67.50",
"cost_1h_usd": "105.00",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 75,
"cost_5m_usd": "38.75",
"cost_1h_usd": "57.50",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 90,
"cost_5m_usd": "21.50",
"cost_1h_usd": "29.00",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 95,
"cost_5m_usd": "15.75",
"cost_1h_usd": "19.50",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 99,
"cost_5m_usd": "11.15",
"cost_1h_usd": "11.90",
"uncached_usd": "100.00"
}
]Ở hit rate 0 phần trăm, bạn trả $125.00 thay vì $100.00, còn cache 1 hour làm hóa đơn tăng gấp đôi lên $200.00. Giải phương trình 1.25 trừ 1.15h = 1, cache 5 minute bắt đầu giúp tiết kiệm khi hit rate đạt khoảng 22 phần trăm. Vì vậy, ngay ở mức 25 phần trăm, chi phí đã là $96.25. Tính tương tự với write 2x cho kết quả khoảng 53 phần trăm đối với cache 1 hour. Do đó, hit rate 50 phần trăm vẫn có chi phí $105.00, cao hơn mức không dùng cache. Ở mức 90 phần trăm, hai mức chi phí lần lượt là $21.50 và $29.00. Ở mức 99 phần trăm, cache ngắn đạt $11.15, gần mức sàn bằng một phần mười giá không dùng cache.
Hit rate là chỉ số cần instrument, vì sau khi cố định kích thước prefix, đây là input duy nhất bạn có thể kiểm soát.
Những prefix nào đáng đặt breakpoint
Một request có thể chứa tối đa 4 breakpoint cho cache, nên câu hỏi là block nào đáng đặt breakpoint. Các ứng viên là những block giống hệt nhau theo từng byte giữa các lần gọi và đủ lớn để tạo khác biệt. Biểu đồ dưới đây tính chi phí của 4 dạng phổ biến trong 1,000 request, với hit rate 90 phần trăm trên cache 5 phút.
The data behind this chart
[
{
"label": "System prompt",
"prefix_size_tokens": "2,000",
"uncached_usd": "10.00",
"cached_usd": "2.15",
"saved_usd": "7.85"
},
{
"label": "System plus tools",
"prefix_size_tokens": "8,000",
"uncached_usd": "40.00",
"cached_usd": "8.60",
"saved_usd": "31.40"
},
{
"label": "Policy document",
"prefix_size_tokens": "25,000",
"uncached_usd": "125.00",
"cached_usd": "26.88",
"saved_usd": "98.12"
},
{
"label": "Codebase context",
"prefix_size_tokens": "120,000",
"uncached_usd": "600.00",
"cached_usd": "129.00",
"saved_usd": "471.00"
}
]Một system prompt chỉ chứa token với độ dài 2,000 giúp tiết kiệm $7.85 trên mỗi 1,000 request so với mức $10.00 khi không dùng cache. Ở quy mô lớn, đây là khoản tiết kiệm đáng kể, nhưng chưa phải lý do khiến caching trở nên đáng chú ý. Thêm các tool definition vào, bạn có 8,000 token và tiết kiệm được $31.40. Một tài liệu policy dài 25,000 token mà mọi request đều đặt câu hỏi về nó giúp tiết kiệm $98.12. Dòng cuối mới là dòng làm thay đổi kiến trúc: 120,000 token context chứa codebase hoặc transcript có chi phí $600.00 khi không dùng cache và $129.00 khi dùng cache, tức tiết kiệm $471.00.
Mức tiết kiệm tăng theo kích thước prefix và hit rate, không phụ thuộc yếu tố nào khác. Điều này thay đổi những gì đáng đưa vào prompt ngay từ đầu: chi phí thực tế của một triệu token Claude giảm xuống còn một phần mười giá niêm yết đối với mọi nội dung bạn gửi nhiều hơn một lần.
Hóa đơn hàng tháng sẽ như thế nào
Biểu đồ bên dưới lấy prefix 8,000 token ở phần trên, cùng với system prompt và các định nghĩa tool, tại tỷ lệ cache hit 90 phần trăm, rồi mở rộng theo số lượng request hàng tháng.
The data behind this chart
[
{
"label": "10k requests",
"uncached_usd": "400.00",
"cached_usd": "86.00",
"saved_usd": "314.00"
},
{
"label": "100k requests",
"uncached_usd": "4,000.00",
"cached_usd": "860.00",
"saved_usd": "3,140.00"
},
{
"label": "1M requests",
"uncached_usd": "40,000.00",
"cached_usd": "8,600.00",
"saved_usd": "31,400.00"
}
]Với 10,000 request mỗi tháng, khoản tiết kiệm là $314.00, tức chênh lệch giữa $400.00 và $86.00. Với 100,000 request, khoản tiết kiệm là $3,140.00. Với một triệu request, chi phí input khi không dùng cache là $40,000.00, và caching loại bỏ $31,400.00 trong số đó. Đây chỉ là token input. Output được tính giá riêng và caching không ảnh hưởng đến phần này. Hãy nhớ điều đó trước khi hứa với ai rằng hóa đơn sẽ giảm 90 phần trăm. Caching là một phần trong các thói quen rộng hơn để kiểm soát hóa đơn AI agent trên VPS.
Cách xác minh cache đang hoạt động
Không nên chỉ tin vào thiết kế. Hãy đọc phần thống kê sử dụng trong response. Mỗi response từ Messages API (application programming interface) đều báo số token được ghi vào cache, số token được đọc từ cache và số token mới phải xử lý.
from anthropic import Anthropic
client = Anthropic()
resp = client.messages.create(
model="claude-opus-5",
max_tokens=512,
system=[
{
"type": "text",
"text": POLICY_DOCUMENT,
"cache_control": {"type": "ephemeral"},
}
],
messages=[{"role": "user", "content": question}],
)
u = resp.usage
print("write:", u.cache_creation_input_tokens)
print("read: ", u.cache_read_input_tokens)
print("fresh:", u.input_tokens)Hãy chạy lệnh 2 lần với cùng một tài liệu nhưng đặt câu hỏi khác nhau. Lần gọi đầu tiên báo cache_creation_input_tokens khác 0 và cache_read_input_tokens bằng 0. Lần gọi thứ hai có kết quả ngược lại vì prefix đã được tìm thấy. input_tokens chỉ đếm số token sau breakpoint cuối cùng. Vì vậy, trong lần gọi thứ hai hoạt động bình thường, số này nhỏ, thường chỉ gồm user message mới. Cả 2 lần gọi đều được tính phí vì Claude API không có free tier, dù với prefix 20,000 token, tổng chi phí của 2 lần gọi chỉ khoảng mười bốn cent.
Bạn cũng có thể thực hiện kiểm tra tương tự từ shell với request body đã lưu vào request.json:
curl -s 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 @request.json | jq '.usage'Lần gọi thứ hai hoạt động bình thường sẽ in ra nội dung gần giống như sau:
{
"input_tokens": 42,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 20143,
"output_tokens": 187
}Một dòng sẽ cho bạn biết kết quả thực sự. Nếu cache_read_input_tokens vẫn bằng 0 qua nhiều lần gọi, bạn đang trả phí ghi 1.25x trong mỗi lần nhưng không nhận lại được lợi ích nào.
Với thời gian tồn tại 1 hour, breakpoint có time to live (TTL):
{
"type": "text",
"text": "your stable prefix",
"cache_control": {"type": "ephemeral", "ttl": "1h"}
}API cũng hỗ trợ caching tự động: chỉ cần một trường cache_control ở top level của request. Sau đó, API tự quản lý các breakpoint khi conversation phát triển. Cách này sử dụng một trong 4 breakpoint slot của bạn. Hãy bắt đầu với cách này. Chuyển sang breakpoint tường minh khi cần quyết định chính xác vị trí đặt boundary.
Quy tắc sắp xếp làm giảm tỷ lệ cache hit
Cache khớp từng byte của prefix, bắt đầu từ đầu request. Request được ghép theo thứ tự cố định: tools, rồi system, rồi messages. Một thay đổi ở cấp nào sẽ invalidate cấp đó và mọi cấp phía sau. Chỉnh sửa một mô tả tool sẽ invalidate system prompt và toàn bộ lịch sử message, dù bạn không thay đổi chúng.
Điều này dẫn đến một quy tắc không có ngoại lệ. Mọi thứ thay đổi giữa các lần gọi phải nằm sau mọi thứ không thay đổi.
Thủ phạm thường gặp là timestamp. Một dòng chứa Current time: 2026-08-03T14:07:11Z ở đầu system prompt sẽ khiến tỷ lệ hit bằng 0 phần trăm, vì prefix hash khác nhau trong mỗi lần gọi và không có entry trước đó nào có thể khớp. Hãy chuyển dòng này vào user message, ở cuối message. Session identifier hoặc per-request nonce cũng gây lỗi tương tự và có cùng cách khắc phục. Các tài liệu được retrieve khác nhau theo từng request cũng phải nằm sau block đã cache. Nếu không, chúng sẽ đẩy mọi token ổn định ra sau một boundary luôn thay đổi.
Thủ phạm thứ hai là đặt breakpoint trên block thay đổi. Cache được ghi tại breakpoint. Vì vậy, nếu block đó khác nhau mỗi lần, không có nội dung ổn định nào được lưu. Cơ chế lookback chỉ tìm thấy các entry mà những request trước đó đã ghi tại breakpoint luôn thay đổi của chúng. Đặt cache_control trên block cuối cùng có nội dung giống hệt giữa các request.
Thứ ba là thay đổi một parameter mà bạn không xem là nội dung của prompt. Model khác sẽ dùng cache khác. Thay đổi tool choice sẽ invalidate từ cấp system trở đi. Thêm hoặc xóa một tool sẽ invalidate mọi thứ.
Prefix tối thiểu và thao tác không làm gì trong im lặng
Prefix ngắn hơn mức tối thiểu của model sẽ không được cache và không có thông báo nào cho bạn biết. Không có lỗi, không có cảnh báo. Request vẫn thành công và cả hai counter đều là 0. Tính đến tháng 8 năm 2026, các mức tối thiểu được công bố là:
- 512 token trên Claude Opus 5 và Claude Fable 5
- 1,024 token trên Claude Sonnet 5 và Claude Opus 4.8
- 4,096 token trên Claude Haiku 4.5
Nếu cả hai counter đều là 0 trong một request mà bạn cho rằng đã được cache, hãy kiểm tra độ dài prefix trước tiên. Đây cũng là lý do model rẻ nhất không mặc định là model rẻ nhất cho workload dùng caching. Haiku 4.5 cần prefix dài gấp 8 lần Opus 5 thì caching mới được kích hoạt, nên system prompt dài 2,000 token sẽ được cache trên một model nhưng bị bỏ qua trong im lặng trên model còn lại.
Claude Code cache nội dung nào cho bạn và nội dung nào không thể cache
Claude Code cache prefix của chính nó. System prompt và các định nghĩa tool nằm ở đầu mỗi request và không thay đổi, nên chúng chỉ được ghi một lần rồi đọc lại trong phần còn lại của session. Vì vậy, chi phí cho mỗi lượt của một session dài thấp hơn nhiều so với mức mà kích thước context gợi ý. Điều này được thể hiện trong các bộ đếm được mô tả tại cách Claude Code báo cáo mức sử dụng token.
Claude Code không thể giúp khi bạn chỉnh sửa nội dung gần đầu context. Lịch sử hội thoại chỉ được nối thêm, nên mỗi lượt mới thông thường mở rộng một prefix đã được cache. Nếu bạn chỉnh sửa một file đã được đọc sớm trong session, nội dung ở giữa prefix đó sẽ thay đổi, và mọi token sau vị trí thay đổi phải được ghi lại. Một khoảng thời gian idle dài cũng gây ra kết quả tương tự vì entry hết hạn, nên lượt tiếp theo phải trả toàn bộ chi phí ghi. Đây không phải là bug. Cả hai trường hợp đều là quy tắc prefix hoạt động đúng như thiết kế.
Nếu tự viết client, hãy áp dụng layout này ngay từ request đầu tiên thay vì bổ sung sau: xây dựng call giống như trong ứng dụng Claude API đầu tiên trên VPS, với các block ổn định ở trước và các phần hay thay đổi ở sau.
Các dạng lỗi và dấu hiệu bạn sẽ thấy
Mỗi lần gọi đều là một lần ghi. cache_creation_input_tokens khác 0 trong mọi request, còn cache_read_input_tokens luôn bằng 0. Có thành phần tại hoặc trước breakpoint thay đổi giữa các lần gọi. Hãy in 200 ký tự đầu tiên của prefix đã ghép trong 2 request liên tiếp, rồi so sánh trực tiếp.
Cả hai counter đều bằng 0. Prefix ngắn hơn mức tối thiểu của model, hoặc trường cache_control chưa bao giờ được gửi đến API. Trước tiên, hãy đếm token trong prefix, sau đó ghi log request body thực tế đã gửi.
Đọc hoạt động rồi dừng. Có một chuỗi lần hit, sau đó là một lần ghi, rồi lại có các lần hit. Khoảng thời gian giữa các request dài hơn TTL. Hãy chấp nhận lần ghi đó, hoặc chuyển sang TTL 1 hour sau khi xác nhận hit rate vượt 53 percent.
Hit rate giảm sau khi deploy. Mô tả của tool đã được chỉnh sửa hoặc model đã thay đổi. Cả hai trường hợp đều làm mất hiệu lực của toàn bộ prefix. Sau mỗi lần deploy có thay đổi prompt, hãy dự kiến một lượt ghi tốn kém.
Hóa đơn tăng sau khi bật caching. Hit rate của bạn thấp hơn điểm hòa vốn. Với cache 5 minute, nếu hit rate dưới khoảng 22 percent thì gửi prefix không dùng cache sẽ rẻ hơn. Với cache 1 hour, điều tương tự xảy ra khi hit rate dưới khoảng 53 percent.
FAQ
Phải tái sử dụng một prompt bao nhiêu lần thì caching mới có lợi?
Chỉ 1 lần với cache 5 phút. Chi phí ghi là 1.25x input cơ sở và chi phí đọc là 0.1x. Vì vậy, N request không dùng cache có chi phí N, còn N request dùng cache có chi phí 1.25 cộng 0.1 nhân với N trừ 1. Hai mức này giao nhau tại N = 1.28, nên từ request thứ hai đã có lợi. Cache 1 giờ có chi phí ghi 2x và giao nhau tại N = 2.11, nên cần 2 lần đọc.
Tại sao cache_read_input_tokens luôn bằng 0?
Trước tiên, hãy kiểm tra độ dài prefix: nếu thấp hơn mức tối thiểu của model, 512 tokens trên Claude Opus 5 và 4,096 trên Claude Haiku 4.5 tính đến August 2026, caching sẽ bị bỏ qua một cách im lặng và cả hai bộ đếm đều có giá trị 0. Nếu prefix đủ dài, hãy tìm nội dung thay đổi giữa các lần gọi nằm tại hoặc trước breakpoint, chẳng hạn timestamp hoặc session identifier trong system prompt. Nếu các bộ đếm trước đây hoạt động rồi dừng, khoảng cách giữa các request đã dài hơn thời gian tồn tại của cache.
Prompt caching có làm thay đổi câu trả lời của Claude không?
Không. Cache lưu dạng đã xử lý của các token bạn đã gửi, còn model vẫn thấy cùng một prompt. Đây là tính năng về billing và latency, không thay đổi behaviour. Vì vậy, bạn có thể bật tính năng này cho một prompt đang hoạt động mà không cần chạy lại các bài đánh giá.
Có nên trả phí cho cache 1 giờ không?
Chỉ khi traffic của bạn có các khoảng gián đoạn dài hơn 5 phút và hit rate dự kiến vẫn đạt khoảng 53 phần trăm trở lên. Chi phí ghi 2x có mức bất lợi cao gấp đôi so với chi phí ghi 1.25x khi không có cache hit. Entry 5 phút được refresh sau mỗi lần hit, nên traffic ổn định sẽ giữ entry hoạt động với chi phí đọc mà không phải trả thêm cho thời gian tồn tại dài hơn.