Tingkat Cache Hit Codex

Poin penting

• Angka normal: 94.8%, median dari 71 pengguna dalam percakapan berjalan; separuh di tengah 91.2%–96.9%
• Semua request: 91.8%, termasuk routing, kedaluwarsa, dan chat baru
• Penyebab cache miss terbesar: konten baru di giliran yang berjalan, 57% dari cache miss
• Di antara antarmuka: selisih 4.6 poin, Aplikasi desktop, Antarmuka terminal, codex exec (non-interaktif)

Berapa tingkat cache hit yang normal untuk tiap klien

Minggu 2026-11-03 – 2026-11-09 (UTC)

• Tingkat hit percakapan berjalan (median pengguna): 94.8%
• Separuh pengguna di tengah: 91.2%–96.9%
• Pengguna yang memenuhi syarat: 71 (minimal 20 giliran lanjutan dalam seminggu)
• Tingkat hit dari semua request: 91.8%

Tingkat hit Codex per antarmuka

CLI, ekstensi IDE, dan aplikasi desktop dari satu klien mengirim request yang hampir identik, sehingga tingkat hit-nya seharusnya berdekatan.

• Aplikasi desktop: 95.3% (55)
• Antarmuka terminal: 95.8% (11)
• codex exec (non-interaktif): 91.2% (9)

Tingkat hit Codex per versi

Rilis yang mengubah prefiks request menunjukkan tingkat hit yang jelas lebih rendah daripada versi lain, pada minggu rilis itu keluar.

• 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)

Median mingguan

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

Kenapa tingkat cache hit Codex saya rendah? Cache miss per penyebab

8.2% input minggu ini tidak dibaca dari cache. Berikut rinciannya per penyebab, beserta apa yang bisa Anda lakukan untuk masing-masing.

Konten baru dan perubahan prefiks dalam percakapan yang berjalan: 57% dari cache miss, sekitar 4.7% dari seluruh input

Cache OpenAI mengharuskan seluruh prefiks sama. Mengubah reasoning effort, tool, atau format output di tengah sesi, atau Codex yang memadatkan riwayat (compaction), akan mengubah prefiks. Inilah sumber cache miss terbesar di Codex.

Dirutekan ke akun atau endpoint upstream lain: 19% dari cache miss, sekitar 1.6% dari seluruh input

Prompt cache tersimpan di akun upstream yang melayani request. Ketika relay atau gateway multi-akun mengirim giliran berikutnya ke akun lain, seluruh konteks ditulis ulang. Koneksi langsung ke vendor tidak pernah mengalami penyebab ini.

Percakapan baru, atau menganggur lebih dari satu jam: 16% dari cache miss, sekitar 1.3% dari seluruh input

Request pertama dari percakapan baru, atau request setelah menganggur satu jam, harus menulis cache lagi.

Ganti model: 3% dari cache miss, sekitar 0.3% dari seluruh input

Setiap model punya cache sendiri, sehingga request pertama setelah ganti model membaca ulang seluruh riwayat.

Jeda lebih dari 5 menit, cache kedaluwarsa: 3% dari cache miss, sekitar 0.2% dari seluruh input

Pada GPT-5.6 dan yang lebih baru, cache bertahan 30 menit secara default, dihitung dari penulisan atau pemakaian ulang terakhir; model yang lebih lama biasanya membuangnya setelah 5–10 menit menganggur.

Request paralel (request sebelumnya masih berjalan): 2% dari cache miss, sekitar 0.2% dari seluruh input

Request yang dikirim sebelum request sebelumnya selesai (subagent, pemanggilan tool paralel) tidak bisa membaca cache yang masih ditulis oleh request sebelumnya.

TTL cache Codex: berapa lama bertahan dan berapa biayanya

• OpenAI meng-cache prefiks prompt secara otomatis, tanpa breakpoint dari klien; GPT-5.6 dan yang lebih baru meng-cache prompt mulai dari 1,024 token.
• GPT-5.6 dan yang lebih baru menyimpannya 30 menit secara default, dihitung dari penulisan atau pemakaian ulang terakhir. Model yang lebih lama menyimpan entri di memori sekitar 5–10 menit menganggur, paling lama satu jam; sebagian mendukung retensi 24 jam.
• Input yang di-cache biasanya ditagih 0.1× harga input, 0.05× pada GPT-6.1 Sol; GPT-5.6 dan yang lebih baru mengenakan 1.25× untuk tulis cache.
• Codex mengirim ID sesi sebagai prompt_cache_key (menurut kode sumbernya), sehingga request dalam satu sesi dirutekan ke cache yang sama.

Prompt caching OpenAI · Diagnosis cache miss OpenAI · Kode sumber Codex (prompt_cache_key) · Codex issue #35416: cache miss saat mengubah reasoning effort

Cara mengecek tingkat cache hit Codex Anda

• Saat keluar, Codex CLI mencetak penggunaan token sesi itu; bagian "+ N cached" adalah input yang dibaca dari cache (perilaku saat ini, tidak ada di dokumentasi).
• Dari API: usage.input_tokens_details.cached_tokens ÷ usage.input_tokens; GPT-5.6 dan yang lebih baru juga melaporkan tulis cache.
• Metrik OpenTelemetry turn.token_usage memiliki tipe cached_input.
• Di Wokey, setiap request di log request konsol menampilkan baca cache dan tulis cache-nya.

Diagnosis cache miss OpenAI

Kenapa tingkat hit turun di balik relay

• Pergantian akun: cache dimiliki akun upstream, sehingga giliran yang dikirim ke akun lain menulis ulang semuanya. Penyebab paling umum pada relay; koneksi langsung tidak pernah mengalaminya.
• Konversi format: menerjemahkan antara format Anthropic dan OpenAI dapat mengubah prefiks atau menghilangkan breakpoint cache_control.
• Claude Code sebelum v2.1.181, pada base URL kustom, menaruh token yang berbeda di setiap request dalam blok atribusi di awal system prompt, sehingga gateway yang meng-cache berdasarkan body request selalu meleset; perbarui, atau setel CLAUDE_CODE_ATTRIBUTION_HEADER=0.
• Uji sendiri: kirim dua request dengan prefiks yang sama dan lebih panjang dari panjang minimum cache; baca cache pada request kedua seharusnya mendekati panjang prefiks.

Wokey sebisa mungkin merutekan request lanjutan dari sebuah percakapan ke akun upstream yang sama. Dari 2026-10-04 hingga 2026-10-10, pengguna biasa Wokey mencapai 92.8% pada Claude Opus 5.5 dari semua request, dibanding 87.8% untuk OpenRouter secara keseluruhan.

Bandingkan dengan tingkat cache hit OpenRouter · Live: API publik tingkat cache hit Wokey (7 hari terakhir)

Cara kami mengukur

• Request nyata pengguna melalui gateway Wokey; setiap Senin pukul 05:00 UTC kami menghitung minggu sebelumnya (Senin sampai Minggu).
• Klien dikenali dari User-Agent request. Request dari SDK, library HTTP, dan relay hilir, yang klien aslinya tidak diketahui, tidak disertakan; begitu pula akun enterprise.
• Giliran lanjutan memiliki model dan akun upstream yang sama dengan request sebelumnya dalam percakapannya dan dimulai dalam 5 menit setelah request itu selesai. Tingkat tiap pengguna adalah baca cache ÷ input pada giliran-giliran tersebut (input mencakup baca dan tulis cache); kami melaporkan median dari pengguna yang punya minimal 20 giliran seperti itu dalam seminggu.
• Sebuah sel dipublikasikan jika punya minimal 5 pengguna yang memenuhi syarat; perubahan lebih dari 3 poin dari minggu lalu diperiksa manual terlebih dahulu.
• Bias yang diketahui: hanya pengguna Wokey; kebiasaan pemakaian sangat beragam; tingkat hit dari semua request mencakup kehilangan akibat routing gateway itu sendiri (penyebab “dirutekan ke akun upstream lain”).

Pertanyaan umum