Bởi Matt Connor
Tính điểm hòa vốn khi sử dụng Claude prompt caching
Chi phí ghi cache là 1.25x và đọc là 0.1x giá input. Bạn cần hiểu rõ công thức tính toán để biết khi nào việc lưu trữ prefix qua API thực sự giúp tối ưu hóa ngân sách hệ thống.
Chi phí của prompt caching trước khi đạt điểm hòa vốn
Prompt caching cho phép Claude tái sử dụng phần đầu của prompt thay vì đọc lại toàn bộ trong mỗi lần gọi API. Quyết định sử dụng tính năng này phụ thuộc vào hai hệ số nhân so với giá input cơ bản của model. Tính đến tháng 8 năm 2026, chi phí ghi vào cache là 1.25x giá input cơ bản cho thời hạn 5 phút, hoặc 2x cho thời hạn 1 giờ. Chi phí đọc từ cache là 0.1x. Các hệ số nhân này áp dụng cho toàn bộ danh sách model, vì vậy điểm hòa vốn dưới đây không thay đổi khi giá trên mỗi token thay đổi.
Đây là sự đánh đổi giữa việc trả thêm phí ngay bây giờ để nhận chiết khấu về sau. Bạn trả thêm phí một lần để lưu trữ một prefix. Mọi request sau đó bắt đầu bằng chính xác các byte đó sẽ chỉ phải trả một phần mười giá input thông thường cho phần nội dung đó. Một prefix không bao giờ được tái sử dụng trong thời hạn của nó sẽ khiến bạn tốn thêm 25 phần trăm chi phí mà không mang lại lợi ích gì.
Điểm hòa vốn, tính bằng một dòng đại số
Gọi B là chi phí đầu vào cơ bản của prefix nếu bạn gửi mà không dùng cache. Nếu không có cache, N request sẽ 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 với giá 0.1B. Đặt hai vế bằng nhau, ta có 0.9N = 1.15, suy ra N = 1.28. Request thứ hai đã rẻ hơn so với việc không dùng cache.
Lặp lại phép tính với mức phí ghi gấp 2 lần của cache 1 giờ, ta có 0.9N = 1.9, suy ra N = 2.11. Cache thời gian dài cần hai lần đọc mới đạt điểm hòa vốn, đó là lý do nó không phải là lựa chọn mặc định.
Biểu đồ dưới đây tính giá cho một prefix 20,000 token trên Claude Opus 5, với mức giá đầu vào cơ bản là $5 mỗi triệu token tính đến tháng 8 năm 2026. Hãy nhân mọi con số với 0.6 cho model có giá $3 mỗi triệu token. Hình dạng của đườ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ẻ tốn $0.10 nếu không cache và $0.125 nếu có cache, vì vậy cache một prompt dùng một lần là hoàn toàn lỗ. Đến request thứ hai, cache 5 phút đạt mức $0.135 so với $0.20. Cache 1 giờ vẫn đắt hơn tại thời điểm đó, với $0.21 so với cùng mức $0.20, và nó chỉ vượt qua đường không cache ở request thứ ba: $0.22 so với $0.30. Đến 20 request, khoảng cách là $2.00 so với $0.315.
Một cache hit cũng làm mới entry, đó là lý do bảng giá công bố đặt tên cột đó là cache hits và refreshes. Do đó, một endpoint bận rộn sẽ giữ cho entry 5 phút tồn tại vô thời hạn với giá đọc, và thời gian sống 1 giờ chỉ phát huy tác dụng với mức phí ghi gấp 2 lần khi lưu lượng truy cập của bạn có những khoảng nghỉ thực sự.
Chi phí của tỷ lệ hit thấp
Lưu lượng thực tế sẽ có các miss. Một request bị miss cache nhưng vẫn chứa breakpoint sẽ bị tính phí như một thao tác ghi, vì vậy cách chính xác nhất để mô hình hóa vấn đề này là tính chi phí dựa trên hàm số của tỷ lệ hit. Biểu đồ dưới đây thể hiện điều đó cho 1.000 request, mỗi request mang 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"
}
]Tại tỷ lệ hit 0 phần trăm, bạn phải trả $125.00 thay vì $100.00, và cache 1 giờ 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 bằng 1, cache 5 phút bắt đầu tiết kiệm chi phí tại tỷ lệ hit khoảng 22 phần trăm, đó là lý do tại sao mức 25 phần trăm đã hiển thị $96.25. Cách tính tương tự cho thao tác ghi 2x cho ra kết quả khoảng 53 phần trăm đối với cache 1 giờ, vì vậy tỷ lệ hit 50 phần trăm vẫn tốn $105.00, cao hơn mức không dùng cache. Tại 90 phần trăm, cả hai đạt mức $21.50 và $29.00. Tại 99 phần trăm, cache ngắn hạn đạt mức $11.15, gần với mức sàn là một phần mười giá không dùng cache.
Tỷ lệ hit là chỉ số cần đo lường, vì đây là đầu vào duy nhất bạn có thể kiểm soát sau khi kích thước prefix đã được cố định.
Những prefix nào đáng để đặt breakpoint
Một request có thể mang tối đa bốn cache breakpoint, vì vậy câu hỏi đặt ra là những block nào xứng đáng được đặt breakpoint. Các ứng viên là những block có nội dung byte-identical (giống hệt nhau về byte) qua các lần gọi và đủ lớn để tạo ra sự khác biệt. Biểu đồ dưới đây tính giá cho bốn hình thái phổ biến trên 1.000 request với tỷ lệ 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 dạng 2,000 token cơ bản 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. Đây là số tiền thực tế khi có volume lớn, nhưng đó không phải là điều làm cho việc caching trở nên thú vị. Thêm các định nghĩa tool vào và bạn sẽ có 8,000 token và tiết kiệm được $31.40. Một tài liệu chính sách 25,000 token mà mọi request đều truy vấn sẽ giúp tiết kiệm $98.12. Hàng cuối cùng là hàng làm thay đổi kiến trúc: 120,000 token của codebase hoặc ngữ cảnh transcript có giá $600.00 nếu không cache và $129.00 nếu có cache, giúp tiết kiệm $471.00.
Số tiền tiết kiệm được tỷ lệ thuận với kích thước prefix và tỷ lệ hit rate, không phụ thuộc vào yếu tố nào khác. Điều này thay đổi quan điểm về việc những gì đáng đưa vào prompt: 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 so với giá niêm yết cho bất kỳ nội dung nào bạn gửi nhiều hơn một lần.
Chi phí hiển thị trên hóa đơn hàng tháng
Biểu đồ dưới đây lấy 8,000 token prefix từ phần trên, cộng với system prompt và các định nghĩa tool, với tỷ lệ hit rate là 90 phần trăm, sau đó quy đổi theo lưu 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, số tiền tiết kiệm được là $314.00, đây là chênh lệch giữa $400.00 và $86.00. Với 100.000 request, con số này là $3,140.00. Với một triệu request, hóa đơn cho input không dùng cache là $40,000.00 và việc sử dụng cache giúp giảm đi $31,400.00. Đây chỉ là chi phí cho input token. Output được tính giá riêng và caching không có tác dụng với output, bạn cần lưu ý điều này trước khi cam kết cắt giảm 90 phần trăm hóa đơn cho bất kỳ ai. Caching là một phần trong các thói quen tối ưu hóa chi phí khi kiểm soát hóa đơn của AI agent trên VPS.
Cách kiểm tra cache có đang hoạt động hay không
Đừng tin vào thiết kế. Hãy đọc khối usage trong phản hồi. Mọi phản hồi từ Messages API (application programming interface) đều báo cáo số lượng token đã ghi vào cache, số lượng token đã đọc từ cache và số lượng 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 hai lần với cùng một tài liệu nhưng với câu hỏi khác nhau. Lần gọi đầu tiên báo cáo cache_creation_input_tokens khác 0 và cache_read_input_tokens bằng 0. Lần gọi thứ hai sẽ đảo ngược kết quả đó vì prefix đã được tìm thấy. input_tokens chỉ đếm các token sau breakpoint cuối cùng, vì vậy trong lần gọi thứ hai nếu hệ thống hoạt động tốt, con số này sẽ nhỏ, thường chỉ là tin nhắn mới của người dùng.
Kiểm tra tương tự từ shell, đối với body của request mà bạn đã 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'Một lần gọi thứ hai hoạt động tốt sẽ in ra kết quả như sau:
{
"input_tokens": 42,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 20143,
"output_tokens": 187
}Một dòng duy nhất sẽ cho bạn biết sự thật. Nếu cache_read_input_tokens luôn giữ ở mức 0 qua các lần gọi, bạn đang phải trả phí ghi 1.25x mỗi lần và không nhận lại được bất kỳ lợi ích nào.
Đối với thời gian tồn tại 1 giờ, breakpoint sẽ mang theo một thời gian sống (TTL):
{
"type": "text",
"text": "your stable prefix",
"cache_control": {"type": "ephemeral", "ttl": "1h"}
}Ngoài ra còn có tính năng tự động cache: một trường cache_control duy nhất ở cấp cao nhất của request, sau đó API sẽ tự quản lý các breakpoint khi cuộc hội thoại dài ra. Nó sẽ tiêu tốn một trong bốn slot breakpoint của bạn. Hãy bắt đầu từ đó. Chuyển sang breakpoint thủ công khi bạn cần quyết định chính xác vị trí đặt ranh giới.
Quy tắc thứ tự làm giảm tỷ lệ hit rate
Cache khớp từng byte một tiền tố từ đầu request, và request được lắp ghép theo một thứ tự cố định: tools, sau đó là system, rồi đến messages. Một thay đổi ở bất kỳ cấp độ nào cũng sẽ vô hiệu hóa cấp độ đó và mọi thứ phía sau nó. Chỉ cần sửa một mô tả tool, thì system prompt và toàn bộ lịch sử tin nhắn đều bị vô hiệu hóa theo, mặc dù bạn không hề đụng đến chúng.
Điều này dẫn đến một quy tắc không có ngoại lệ. Bất cứ thứ gì thay đổi giữa các lần gọi đều phải nằm sau tất cả những thứ không thay đổi.
Thủ phạm thường gặp là timestamp. Một dòng ghi Current time: 2026-08-03T14:07:11Z ở đầu system prompt đảm bảo tỷ lệ hit rate bằng 0 phần trăm, vì hash của tiền tố khác nhau trong mỗi lần gọi và không có entry nào trước đó có thể khớp với nó. Hãy chuyển nó vào user message, ở phần cuối. Một session identifier hoặc một nonce theo từng request cũng gây ra lỗi tương tự và có cách khắc phục như vậy. Các tài liệu được truy xuất khác nhau theo từng request cũng cần nằm sau khối đã cache, nếu không chúng sẽ đẩy mọi token ổn định ra sau một ranh giới luôn thay đổi.
Thủ phạm thứ hai là đặt breakpoint tại khối có thay đổi. Việc ghi cache diễn ra tại breakpoint, vì vậy nếu khối đó luôn khác nhau mỗi lần, sẽ không có dữ liệu ổn định nào được lưu trữ, và quá trình tìm kiếm ngược (lookback) chỉ tìm thấy các entry mà những request trước đó đã ghi tại các breakpoint thay đổi của chính chúng. Hãy đặt cache_control tại khối cuối cùng mà nội dung của nó giống hệt nhau giữa các request.
Thủ phạm thứ ba là thay đổi tham số mà bạn không nghĩ đó là nội dung của prompt. Một model khác sẽ có một cache khác. Thay đổi lựa chọn tool sẽ vô hiệu hóa từ cấp độ system trở đi. Thêm hoặc bớt một tool sẽ vô hiệu hóa mọi thứ.
Prefix tối thiểu và cơ chế no-op âm thầm
Một prefix ngắn hơn mức tối thiểu của model sẽ không được cache, và hệ thống không thông báo gì cả. Không có lỗi, không có cảnh báo. Request vẫn thành công và cả hai bộ đếm đều hiển thị 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 bộ đếm đều hiển thị 0 trong một request mà bạn tin rằng đã được cache, hãy kiểm tra độ dài prefix trước tiên. Đây cũng là lý do vì sao model rẻ nhất không mặc định là lựa chọn rẻ nhất cho workload có sử dụng caching. Haiku 4.5 cần một prefix dài gấp tám lần so với Opus 5 để bắt đầu cache, vì vậy một system prompt 2.000 token sẽ được cache trên model này nhưng lại bị bỏ qua âm thầm trên model kia.
Claude Code lưu cache ở đâu và ở đâu thì không thể
Claude Code tự lưu cache phần prefix của nó. System prompt và các định nghĩa tool nằm ở đầu mỗi request và không thay đổi, vì vậy chúng được ghi một lần và đọc lại cho phần còn lại của phiên làm việc. Đó là lý do tại sao chi phí cho mỗi lượt (turn) trong một phiên dài thấp hơn nhiều so với kích thước context, và điều này được hiển thị trong các bộ đếm được mô tả tại cách Claude Code báo cáo mức sử dụng token.
Nơi nó không thể giúp bạn là khi thực hiện chỉnh sửa gần phần đầu của context. Lịch sử hội thoại chỉ có thể thêm vào (append-only), vì vậy các lượt mới thông thường sẽ mở rộng một prefix đã được lưu cache. Việc chỉnh sửa một file đã được đọc từ đầu phiên sẽ làm thay đổi nội dung ở giữa prefix đó, và mọi token sau thay đổi đó đều phải được ghi lại. Một khoảng thời gian chờ lâu cũng gây ra tình trạng tương tự, vì mục cache hết hạn và lượt tiếp theo sẽ phải trả phí ghi đầy đủ. Cả hai trường hợp này đều không phải là lỗi. Đó chỉ là quy tắc prefix hoạt động đúng như mô tả.
Nếu bạn đang tự viết client của riêng mình, hãy áp dụng bố cục từ request đầu tiên thay vì điều chỉnh lại sau: hãy xây dựng lời gọi API theo cách mà một ứng dụng Claude API đầu tiên trên VPS thực hiện, với các khối ổn định ở trước và các khối thay đổi ở sau.
Các kiểu lỗi và những gì bạn sẽ thấy
Mọi yêu cầu đều là ghi. cache_creation_input_tokens khác 0 trên mọi yêu cầu trong khi cache_read_input_tokens vẫn là 0. Có thứ gì đó tại hoặc trước điểm breakpoint bị thay đổi giữa các lần gọi. Hãy in 200 ký tự đầu tiên của prefix đã lắp ghép trên hai yêu cầu liên tiếp và so sánh chúng bằng mắt thường.
Cả hai bộ đếm đều là 0. Prefix nằm dưới mức tối thiểu của model, hoặc trường cache_control không bao giờ đến được API. Hãy đếm số token của prefix trước, sau đó log lại body của yêu cầu mà bạn thực sự đã gửi.
Đọc hoạt động, sau đó dừng. Một chuỗi các hit, sau đó là một lần ghi, rồi lại các hit. Khoảng cách giữa các yêu cầu dài hơn thời gian tồn tại (lifetime). Hãy chấp nhận việc ghi, hoặc chuyển sang TTL 1 giờ sau khi bạn đã kiểm tra tỷ lệ hit vượt quá 53 phần trăm.
Tỷ lệ hit giảm sau khi deploy. Mô tả công cụ đã bị chỉnh sửa hoặc model đã bị thay đổi. Cả hai đều làm mất hiệu lực của toàn bộ prefix. Hãy dự kiến một đợt ghi tốn kém sau mỗi lần deploy có tác động đến prompt.
Hóa đơn tăng sau khi bạn bật cache. Tỷ lệ hit của bạn nằm dưới mức hòa vốn. Dưới khoảng 22 phần trăm đối với cache 5 phút, việc gửi prefix không qua cache sẽ rẻ hơn, và dưới khoảng 53 phần trăm thì điều tương tự cũng đúng với cache 1 giờ.
FAQ
Cần tái sử dụng prompt bao nhiêu lần để việc cache trở nên hiệu quả?
Chỉ cần một lần đối với cache 5 phút. Một lần ghi tốn 1.25x chi phí input cơ bản và một lần đọc tốn 0.1x, vì vậy N yêu cầu không cache tốn N chi phí, trong khi N yêu cầu có cache tốn 1.25 cộng với 0.1 nhân với N trừ 1. Hai giá trị này giao nhau tại N = 1.28, nên yêu cầu thứ hai đã bắt đầu có lợi. Cache 1 giờ ghi ở mức 2x và giao nhau tại N = 2.11, nên cần hai lần đọc.
Tại sao cache_read_input_tokens luôn bằng không?
Trước tiên hãy kiểm tra độ dài prefix: dưới mức tối thiểu của model, 512 token trên Claude Opus 5 và 4,096 trên Claude Haiku 4.5 tính đến tháng 8 năm 2026, việc caching sẽ bị bỏ qua âm thầm và cả hai bộ đếm đều hiển thị 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 điểm ngắt, ví dụ như timestamp hoặc định danh phiên làm việc trong system prompt. Nếu các bộ đếm đã hoạt động rồi dừng lại, khoảng cách giữa các yêu cầu đã 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 trữ dạng đã xử lý của các token bạn đã gửi, và model nhìn thấy cùng một prompt dù có cache hay không. Đây là tính năng về chi phí và độ trễ, không phải là thay đổi về hành vi. Điều này cũng có nghĩa là bạn có thể bật nó trên một prompt đang hoạt động mà không cần chạy lại các đánh giá của mình.
Tôi có nên trả phí cho cache 1 giờ không?
Chỉ khi lưu lượng truy cập của bạn có khoảng nghỉ dài hơn 5 phút và tỷ lệ hit vẫn đạt khoảng 53 phần trăm. Mức ghi 2x gây thiệt hại gấp đôi so với mức ghi 1.25x khi bạn bị miss cache. Một mục 5 phút sẽ tự làm mới sau mỗi lần hit, vì vậy lưu lượng truy cập ổn định sẽ duy trì nó ở mức giá đọc mà không bao giờ phải trả phí cho thời gian tồn tại dài hơn.