Tỷ lệ trúng cache của OpenCode với mô hình Claude

Điểm chính

• Mức bình thường: 97.6%, trung vị của 20 người dùng trong hội thoại tiếp diễn; một nửa ở giữa 97.1%–98.9%
• Mọi yêu cầu: 95.1%, tính cả định tuyến, hết hạn và hội thoại mới
• Nguyên nhân trượt lớn nhất: hội thoại mới, 34% số lượt trượt
• Giữa các dạng: chênh 0.6 điểm, Ứng dụng máy tính, CLI (terminal)

Tỷ lệ trúng cache bao nhiêu là bình thường với từng client

Tuần 2026-11-03 – 2026-11-09 (UTC)

• Tỷ lệ trúng khi hội thoại tiếp diễn (trung vị người dùng): 97.6%
• Một nửa người dùng ở giữa: 97.1%–98.9%
• Người dùng đạt điều kiện: 20 (ít nhất 20 lượt tiếp diễn trong tuần)
• Tỷ lệ trúng trên mọi yêu cầu: 95.1%

Tỷ lệ trúng của OpenCode theo dạng sử dụng

CLI, tiện ích IDE và ứng dụng desktop của cùng một client gửi các yêu cầu gần như giống nhau, nên tỷ lệ trúng của chúng phải gần nhau.

• Ứng dụng máy tính: 98.0% (7)
• CLI (terminal): 97.4% (6)

Tỷ lệ trúng của OpenCode theo phiên bản

Một bản phát hành thay đổi tiền tố yêu cầu sẽ có tỷ lệ trúng thấp hơn hẳn các phiên bản khác ngay trong tuần phát hành.

• 2.2.5: 97.5% (10)

Trung vị hằng tuần

• 2026-09-29: 96.5% (7 người dùng)
• 2026-10-06: 97.6% (8 người dùng)
• 2026-10-13: 98.8% (11 người dùng)
• 2026-10-20: 97.4% (10 người dùng)
• 2026-10-27: 96.4% (13 người dùng)
• 2026-11-03: 97.6% (20 người dùng)

Vì sao tỷ lệ trúng cache của OpenCode thấp? Lượt trượt theo nguyên nhân

4.9% đầu vào tuần này không được đọc từ cache. Dưới đây là phân tích theo nguyên nhân, kèm việc bạn có thể làm với từng nguyên nhân.

Hội thoại mới, hoặc nghỉ hơn một giờ: 34% số lượt trượt, khoảng 1.7% tổng đầu vào

Yêu cầu đầu tiên của một hội thoại mới, hoặc yêu cầu sau một giờ nghỉ, phải ghi lại cache.

Nội dung mới và thay đổi tiền tố trong hội thoại đang diễn ra: 31% số lượt trượt, khoảng 1.5% tổng đầu vào

Nội dung mới trong một lượt chỉ có thể được ghi, không thể đọc, điều này không tránh được; system prompt hoặc danh sách công cụ thay đổi, hay lịch sử bị viết lại, cũng làm tiền tố mất hiệu lực.

Nghỉ hơn 5 phút, cache đã hết hạn: 31% số lượt trượt, khoảng 1.5% tổng đầu vào

Hơn 5 phút trôi qua giữa các yêu cầu, nên mục cache trước đó có thể đã hết hạn.

Được định tuyến sang tài khoản hoặc endpoint upstream khác: 3% số lượt trượt, khoảng 0.2% tổng đầu vào

Prompt cache nằm ở tài khoản upstream đã xử lý yêu cầu. Khi một relay hoặc gateway nhiều tài khoản gửi lượt tiếp theo sang tài khoản khác, toàn bộ ngữ cảnh phải được ghi lại. Kết nối trực tiếp tới nhà cung cấp không bao giờ gặp nguyên nhân này.

Yêu cầu song song (yêu cầu trước vẫn đang chạy): 0% số lượt trượt, khoảng 0.0% tổng đầu vào

Một yêu cầu được gửi trước khi yêu cầu trước đó kết thúc (subagent, gọi công cụ song song) không thể đọc cache mà yêu cầu trước vẫn đang ghi.

Đổi mô hình: 0% số lượt trượt, khoảng 0.0% tổng đầu vào

Mỗi mô hình có cache riêng, nên yêu cầu đầu tiên sau khi đổi mô hình phải đọc lại toàn bộ lịch sử.

Chênh vài điểm tỷ lệ trúng, hóa đơn chênh nhiều lần

Theo giá chính thức của Claude Opus 5.5, với phần trượt được ghi vào cache 5 phút, chi phí thực tế cho mỗi triệu token đầu vào:

• Trung vị tuần này, 97.6%: $0.32 (×1.0)
• 90%: $0.68 (×2.1)
• 80%: $1.16 (×3.7)
• 50%: $2.60 (×8.2)

Tự tính với số liệu của bạn trong công cụ tính chi phí Claude API

Cách kiểm tra tỷ lệ trúng cache của OpenCode

• Định dạng Anthropic: cache_read_input_tokens ÷ (input_tokens + cache_read_input_tokens + cache_creation_input_tokens).
• Định dạng OpenAI: cached_tokens (trong prompt_tokens_details hoặc input_tokens_details) ÷ prompt_tokens / input_tokens.
• Trên Wokey, mỗi yêu cầu trong nhật ký yêu cầu của bảng điều khiển đều hiển thị lượt đọc cache và ghi cache.

Vì sao tỷ lệ trúng giảm khi đi qua relay

• Đổi tài khoản: cache thuộc về tài khoản upstream, nên một lượt được gửi sang tài khoản khác phải ghi lại toàn bộ. Đây là nguyên nhân phổ biến nhất ở relay; kết nối trực tiếp không bao giờ gặp.
• Chuyển đổi định dạng: chuyển qua lại giữa định dạng Anthropic và OpenAI có thể làm thay đổi tiền tố hoặc làm mất breakpoint cache_control.
• Claude Code trước v2.1.181, khi dùng base URL tùy chỉnh, chèn một token khác nhau cho mỗi yêu cầu vào khối ghi nhận nguồn ở đầu system prompt, khiến các gateway cache theo nội dung yêu cầu luôn trượt; hãy cập nhật, hoặc đặt CLAUDE_CODE_ATTRIBUTION_HEADER=0.
• Tự kiểm tra: gửi hai yêu cầu có cùng tiền tố dài hơn độ dài cache tối thiểu; lượt đọc cache của yêu cầu thứ hai phải gần bằng độ dài tiền tố.

Wokey định tuyến các yêu cầu sau của một hội thoại về cùng tài khoản upstream bất cứ khi nào có thể. Từ 2026-10-04 đến 2026-10-10, người dùng Wokey thông thường đạt tỷ lệ trúng 92.8% trên Claude Opus 5.5 tính trên mọi yêu cầu, so với 87.8% của OpenRouter nói chung.

So sánh với tỷ lệ trúng cache của OpenRouter · Trực tiếp: API công khai về tỷ lệ trúng cache của Wokey (7 ngày qua)

Cách chúng tôi đo

• Các yêu cầu thực tế của người dùng qua gateway Wokey; mỗi thứ Hai lúc 05:00 UTC chúng tôi tính cho tuần trước đó (thứ Hai đến Chủ nhật).
• Client được nhận diện qua User-Agent của yêu cầu. Các yêu cầu từ SDK, thư viện HTTP và relay phía sau, vốn không rõ client thật, không được tính, tài khoản doanh nghiệp cũng vậy.
• Một lượt tiếp diễn có cùng mô hình và tài khoản upstream với yêu cầu trước đó trong hội thoại và bắt đầu trong vòng 5 phút sau khi yêu cầu đó kết thúc. Tỷ lệ của mỗi người dùng là đọc cache ÷ đầu vào trên các lượt đó (đầu vào gồm cả đọc và ghi cache); chúng tôi công bố trung vị của những người dùng có ít nhất 20 lượt như vậy trong tuần.
• Một ô chỉ được công bố khi có ít nhất 5 người dùng đạt điều kiện; thay đổi hơn 3 điểm so với tuần trước sẽ được kiểm tra thủ công trước.
• Các sai lệch đã biết: chỉ gồm người dùng Wokey; thói quen sử dụng rất khác nhau; tỷ lệ trên mọi yêu cầu bao gồm cả tổn thất định tuyến của chính gateway (nguyên nhân "được định tuyến sang tài khoản upstream khác").

Câu hỏi thường gặp