Bởi Matt Connor
Prompt caching Claude: tính điểm hòa vốn
Cache write Claude tốn 1,25x, cache read chỉ 0,1x hoặc thấp hơn. Tính điểm hòa vốn cho prefix và kiểm chứng bằng API để biết request thứ mấy bắt đầu lời.
Chi phí của prompt caching trước khi mang lại lợi ích
Prompt caching cho phép Claude tái sử dụng 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 hai hệ số nhân trên giá input cơ bản của model. Tính đến tháng 10 năm 2026, ghi cache có chi phí bằng 1.25x giá input cơ bản trong thời gian lưu 5 phút, hoặc 2x trong thời gian lưu 1 giờ, trên mọi model. Đọc từ cache có chi phí bằng 0.1x trên hầu hết model, nhưng hệ số đọc hiện không còn giống nhau ở mọi nơi. Hệ số này là 0.025x trên Claude Fable 5.1 và Claude Mythos 5.1; hai model này được ra mắt với mức giá đó vào ngày 1 tháng 9 năm 2026. Hệ số này là 0.05x trên Claude Opus 5.5 và Claude Sonnet 5.5. Sonnet 5.5 đã được giảm từ 0.1x xuống mức này vào ngày 7 tháng 10 năm 2026. Các ví dụ tính toán bên dưới sử dụng mức đọc tiêu chuẩn 0.1x. Mức đọc thấp hơn sẽ làm điểm hòa vốn có lợi cho bạn hơn một chút. Phần tiếp theo cho biết mức chênh lệch cụ thể.
Đây là sự đánh đổi giữa một khoản phụ phí hiện tại và một khoản giảm giá về sau. Bạn trả thêm một lần để lưu một prefix. Mỗi request tiếp theo bắt đầu bằng đúng các byte đó sẽ chỉ phải trả một phần mười giá input thông thường cho phần này, hoặc thấp hơn trên các model nêu trên. Nếu một prefix không bao giờ được tái sử dụng trong thời gian lưu, bạn sẽ trả thêm 25 phần trăm mà không nhận được lợi ích gì.
Điểm hòa vốn, chỉ bằng một dòng đại số
Gọi B là chi phí input cơ sở của prefix nếu bạn gửi prefix đó mà không dùng cache. Không có 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, còn N trừ 1 request tiếp theo đọc prefix với giá 0.1B. Cho hai 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 không dùng cache.
Lặp lại phép tính với mức ghi 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.
Khi giá đọc thấp hơn, đường hòa vốn có thay đổi nhưng không nhiều. Với giá đọc 0.05x, cache 5 phút cho 0.95N = 1.2, nên N = 1.26. Với giá 0.025x, kết quả là 0.975N = 1.225, cũng bằng N = 1.26. Cache 1 giờ giảm xuống lần lượt còn N = 2.05 và N = 2.03. Kết luận thực tế giống nhau trên mọi mô hình: cache 5 phút bắt đầu có lợi từ request thứ hai, còn cache 1 giờ bắt đầu có lợi từ request thứ ba.
Biểu đồ bên dưới tính chi phí này cho prefix 20,000 token trên Claude Opus 5. Tính đến October 2026, giá input cơ sở là $5 trên một triệu token và chưa thay đổi kể từ August. Opus 5 hiện là model legacy nhưng vẫn còn được cung cấp. Model kế nhiệm, Claude Opus 5.5, có giá $4 trên một triệu token với mức đọc 0.05x. Vì vậy, cùng prefix đó có giá ghi là $0.10 và giá đọc là $0.004. Với model có giá $3 trên một triệu token và mức đọc tiêu chuẩn 0.1x, hãy nhân mọi con số với 0.6. Hình dạng đường cong không thay đổi.
Dữ liệu đằng sau biểu đồ này
[
{
"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ó chi phí $0.10 khi không dùng cache và $0.125 khi dùng cache. Vì vậy, dùng cache cho prompt chỉ chạy một lần sẽ làm tăng chi phí. Đến request thứ hai, cache 5 phút có chi phí $0.135, so với $0.20. Ở thời điểm đó, cache 1 giờ vẫn đắt hơn, ở mức $0.21 so với $0.20. Cache này chỉ thấp hơn chi phí không dùng cache từ request thứ ba: $0.22 so với $0.30. Với 20 request, chênh lệch là $2.00 so với $0.315.
Một cache hit cũng refresh entry. Vì vậy, bảng giá được công bố đặt tên cột đó là cache hits and refreshes. Do đó, một 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. Lifetime 1 giờ chỉ mang lại lợi ích từ mức ghi 2x khi lưu lượng của bạn thực sự có những khoảng gián đoạn.
Chi phí khi tỷ lệ cache hit thấp
Lưu lượng thực tế sẽ có request cache miss. Request cache miss nhưng vẫn mang breakpoint sẽ bị tính như một lần write, vì vậy cách tính đúng là biểu diễn chi phí theo hit rate. Biểu đồ dưới đây thực hiện việc đó với 1,000 request, mỗi request mang cùng một prefix 20,000 token.
Dữ liệu đằng sau biểu đồ này
[
{
"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%, bạn trả $125.00 thay vì $100.00, còn 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, ta thấy cache 5 phút bắt đầu tiết kiệm chi phí ở hit rate khoảng 22%, đó là lý do hit rate 25% đã cho mức $96.25. Tính tương tự với write 2x cho kết quả khoảng 53% đối với cache 1 giờ, nên hit rate 50% vẫn có chi phí $105.00, cao hơn đường chi phí không cache. Ở mức 90%, hai loại cache lần lượt có chi phí $21.50 và $29.00. Ở mức 99%, cache ngắn hạn đạt $11.15, gần với mức sàn bằng một phần mười giá không cache.
Với model có read 0.05x, các ngưỡng giảm xuống còn khoảng 21% đối với cache 5 phút và 51% đối với cache 1 giờ. Với read 0.025x, các ngưỡng giảm xuống còn khoảng 20% và 51%. Mức sàn giảm theo giá read, xuống còn một phần hai mươi hoặc một phần bốn mươi chi phí không cache.
Hit rate là số liệu 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ể mang tối đa 4 breakpoint cho cache, vì vậy cần xác định 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 trên 1,000 request, với hit rate 90 phần trăm trên cache 5 phút.
Dữ liệu đằng sau biểu đồ này
[
{
"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ỉ gồm 2,000 token 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ền đáng kể, nhưng chưa phải lý do khiến caching trở nên đáng chú ý. Thêm các định nghĩa tool vào prompt, bạn sẽ 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 cùng mới là yếu tố làm thay đổi kiến trúc: 120,000 token context từ 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 vào yếu tố nào khác. Điều này thay đổi cách đánh giá nội dung nào đá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 mức giá niêm yết, hoặc thấp hơn với các model có chi phí đọc rẻ hơn, đố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.
Dữ liệu đằng sau biểu đồ này
[
{
"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 nghiêm trọng tỷ lệ cache hit
Cache so khớp một prefix theo từng byte, 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 ở bất kỳ cấp nào sẽ làm invalid cấp đó và mọi cấp phía sau. Chỉnh sửa một mô tả tool sẽ làm invalid system prompt và toàn bộ message history, dù bạn không thay đổi chúng.
Điều này tạo ra 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ể so khớp. Hãy chuyển dòng này vào user message, ở cuối. Session identifier hoặc per-request nonce cũng gây ra vấn đề tương tự và có cùng cách xử lý. Các tài liệu được retrieve và thay đổi theo từng request cũng phải nằm sau block được 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 write diễn ra tại breakpoint. Vì vậy, nếu block đó khác nhau trong mỗi lần gọi, không có nội dung ổn định nào được lưu. 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 nhau giữa các request.
Thủ phạm thứ ba là một thay đổi parameter mà bạn không xem là nội dung prompt. Model khác sẽ dùng cache khác. Thay đổi tool_choice sẽ làm invalid message history, dù tools và system prompt vẫn được cache. Thêm hoặc xóa một tool sẽ làm invalid mọi thứ.
Tiền tố tối thiểu và thao tác không làm gì một cách im lặng
Tiền tố ngắn hơn mức tối thiểu của model sẽ không được cache, và bạn không nhận được thông báo nào. Không có lỗi, không có cảnh báo. Request vẫn thành công và cả hai counter đều có giá trị 0. Tính đến tháng 10 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, cũng như Opus 5.5, Sonnet 5.5, Fable 5.1 và Haiku 5.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 có giá trị 0 trong một request mà bạn cho rằng đã được cache, hãy kiểm tra độ dài tiền tố trước tiên. Đây cũng là lý do model rẻ nhất không tự động là model rẻ nhất cho workload sử dụng caching. Haiku 4.5 cần tiền tố 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 một cách im lặng trên model còn lại.
Claude Code cache gì cho bạn và không thể cache ở đâu
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í mỗi turn trong một session dài thấp hơn nhiều so với mức mà context size gợi ý. Chi phí này xuất hiện trong các counter được mô tả tại cách Claude Code báo cáo token usage.
Claude Code không thể giúp khi có thay đổi gần đầu context. Conversation history chỉ được append, nên các turn mới thông thường chỉ mở rộng prefix đã được cache. Việc chỉnh sửa một file được đọc sớm trong session cũng không phá cache, vì Claude Code thêm một note cho biết file đã thay đổi thay vì ghi lại phần đã đọc trước đó. Việc chuyển model sẽ phá cache, vì mỗi model có cache riêng. Kết nối một MCP server có các tool được load vào prefix cũng phá cache. Compact conversation cũng vậy. Mỗi thao tác này khiến turn tiếp theo phải ghi lại prefix. Một khoảng idle dài cũng có tác dụng tương tự, vì entry hết hạn và turn tiếp theo phải trả toàn bộ chi phí ghi. Đây không phải bug. Đó là quy tắc prefix hoạt động đúng như thiết kế.
Nếu bạn tự viết client, hãy áp dụng layout này ngay từ request đầu tiên thay vì bổ sung về sau: xây dựng call theo cách một ứng dụng Claude API đầu tiên trên VPS thực hiện, với các block ổn định ở trước và các phần dễ thay đổi ở sau.
Các trường hợp lỗi và những gì bạn sẽ thấy
Mọi request đều là write. cache_creation_input_tokens khác 0 trong mọi request, còn cache_read_input_tokens vẫn bằng 0. Có thành phần tại hoặc trước breakpoint thay đổi giữa các request. 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 field cache_control chưa bao giờ được gửi đến API. Trước tiên, đếm số token trong prefix, sau đó log request body thực tế đã gửi.
Read hoạt động, rồi dừng. Có một chuỗi hit, sau đó là một write, rồi lại có hit. Khoảng thời gian giữa các request dài hơn lifetime. Hãy chấp nhận write, hoặc chuyển sang TTL 1 giờ sau khi xác nhận hit rate vượt 53 phần trăm, hoặc khoảng 51 phần trăm trên model có read ở mức 0.05x hoặc 0.025x.
Hit rate giảm sau một lần deploy. Mô tả tool đã được chỉnh sửa hoặc model đã thay đổi. Cả hai trường hợp đều làm toàn bộ prefix mất hiệu lực. Sau mỗi lần deploy có thay đổi prompt, hãy dự kiến một lượt write 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 phút, nếu dưới khoảng 22 phần trăm thì gửi prefix mà không cache sẽ rẻ hơn. Với cache 1 giờ, điều tương tự đúng khi hit rate dưới khoảng 53 phần trăm. Trên các model có read rẻ hơn, các ngưỡng này lần lượt khoảng 20 đến 21 phần trăm và 51 phần trăm.
FAQ
Phải tái sử dụng một prompt bao nhiêu lần thì cache 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 trên hầu hết model. 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 với 0.1 nhân N trừ 1. Hai mức chi phí này giao nhau tại N = 1.28, nên từ request thứ hai đã có lợi. Với các model có chi phí đọc 0.05x hoặc 0.025x, điểm giao là N = 1.26, cho cùng một kết luận. Cache 1 giờ có chi phí ghi là 2x và giao nhau tại N = 2.11, hoặc khoảng 2.05 với các mức đọc rẻ hơn, nên cần 2 lần đọc.
Vì 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, là 512 token trên Claude Opus 5 và 4,096 trên Claude Haiku 4.5 tính đến October 2026, caching sẽ bị bỏ qua một cách im lặng và cả 2 counter đề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 nhưng 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 counter trước đây hoạt động rồi dừng lại, khoảng thời gian giữa 2 request đã dài hơn lifetime 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 trong cả 2 trường hợp. Đây là tính năng về billing và latency, không phải thay đổi về 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 evaluation.
Có nên trả tiền 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 vẫn đạt khoảng 53%, hoặc khoảng 51% trên model có chi phí đọc rẻ hơn. Khi cache miss, chi phí ghi 2x đắt gấp 4 lần chi phí ghi 1.25x. Một lần ghi cache 1 giờ bị miss sẽ làm lãng phí toàn bộ giá input cơ sở của prefix, trong khi một lần ghi cache 5 phút bị miss chỉ lãng phí một phần tư giá đó. Entry 5 phút được refresh sau mỗi lần hit, nên traffic ổn định sẽ giữ entry này hoạt động với chi phí đọc mà không bao giờ phải trả cho lifetime dài hơn.