Tỷ lệ trúng cache của Codex

Điểm chính

• Mức bình thường: 94.8%, trung vị của 71 người dùng trong hội thoại tiếp diễn; một nửa ở giữa 91.2%–96.9%
• Mọi yêu cầu: 91.8%, 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: nội dung mới trong các lượt đang diễn ra, 57% số lượt trượt
• Giữa các dạng: chênh 4.6 điểm, Ứng dụng máy tính, Giao diện terminal, codex exec (không tương tác)

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): 94.8%
• Một nửa người dùng ở giữa: 91.2%–96.9%
• Người dùng đạt điều kiện: 71 (í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: 91.8%

Tỷ lệ trúng của Codex 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: 95.3% (55)
• Giao diện terminal: 95.8% (11)
• codex exec (không tương tác): 91.2% (9)

Tỷ lệ trúng của Codex 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.

• 0.167.0-alpha.3.2: 95.0% (27)
• 0.167.0: 93.3% (6)
• 0.166.0-alpha.6: 95.6% (29)
• 0.166.0-alpha.5.1: 96.4% (28)
• 0.166.0: 96.6% (5)

Trung vị hằng tuần

• 2026-09-29: 96.0% (38 người dùng)
• 2026-10-06: 95.3% (54 người dùng)
• 2026-10-13: 95.4% (62 người dùng)
• 2026-10-20: 95.8% (49 người dùng)
• 2026-10-27: 95.1% (72 người dùng)
• 2026-11-03: 94.8% (71 người dùng)

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

8.2% đầ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.

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

Cache của OpenAI yêu cầu toàn bộ tiền tố phải khớp. Đổi reasoning effort, công cụ hay định dạng đầu ra giữa phiên, hoặc việc Codex nén lịch sử (compaction), đều làm thay đổi tiền tố. Đây là nguồn trượt cache lớn nhất của Codex.

Được định tuyến sang tài khoản hoặc endpoint upstream khác: 19% số lượt trượt, khoảng 1.6% 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.

Hội thoại mới, hoặc nghỉ hơn một giờ: 16% số lượt trượt, khoảng 1.3% 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.

Đổi mô hình: 3% số lượt trượt, khoảng 0.3% 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ử.

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

Trên GPT-5.6 trở về sau, cache mặc định tồn tại 30 phút, tính từ lần ghi hoặc dùng lại gần nhất; các mô hình cũ hơn thường bỏ cache sau 5–10 phút nghỉ.

Yêu cầu song song (yêu cầu trước vẫn đang chạy): 2% số lượt trượt, khoảng 0.2% 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.

TTL cache của Codex: tồn tại bao lâu và tốn bao nhiêu

• OpenAI tự động cache tiền tố prompt, không cần breakpoint phía client; GPT-5.6 trở về sau cache prompt từ 1,024 token.
• GPT-5.6 trở về sau mặc định giữ cache 30 phút, tính từ lần ghi hoặc dùng lại gần nhất. Các mô hình cũ hơn giữ mục trong bộ nhớ khoảng 5–10 phút nghỉ, tối đa một giờ; một số hỗ trợ lưu giữ 24 giờ.
• Đầu vào từ cache thường được tính 0.1× giá đầu vào, 0.05× trên GPT-6.1 Sol; GPT-5.6 trở về sau tính 1.25× cho việc ghi cache.
• Codex gửi ID phiên dưới dạng prompt_cache_key (theo mã nguồn), nên các yêu cầu trong cùng một phiên được định tuyến về cùng một cache.

Prompt caching của OpenAI · Chẩn đoán trượt cache của OpenAI · Mã nguồn Codex (prompt_cache_key) · Codex issue #35416: đổi reasoning effort gây trượt cache

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

• Khi thoát, Codex CLI in ra mức dùng token của phiên; phần "+ N cached" là đầu vào được đọc từ cache (hành vi hiện tại, chưa có trong tài liệu).
• Từ API: usage.input_tokens_details.cached_tokens ÷ usage.input_tokens; GPT-5.6 trở về sau còn báo cả lượt ghi cache.
• Chỉ số OpenTelemetry turn.token_usage có loại cached_input.
• 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.

Chẩn đoán trượt cache của OpenAI

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