Prompt Caching LLM 2026: Hemat 90% Biaya…

Diperbarui: 4 Agustus 2026

Prompt caching adalah mekanisme di mana penyedia LLM menyimpan hasil komputasi prefix prompt yang berulang (system prompt, definisi tool, few-shot examples) dan menagihnya dengan diskon hingga 90% ketika prefix tersebut muncul lagi. Di 2026, ketiga penyedia utama (Anthropic Claude, OpenAI GPT-5.x, dan Google Gemini 2.5+) mendukung prompt caching dengan diskon read yang sama, tetapi dengan model biaya, TTL, dan mekanisme konfigurasi yang sangat berbeda. Artikel ini membedah trade-off nyata berdasarkan pola workload produksi yang saya lihat di beberapa klien SaaS Eropa selama 18 bulan terakhir.

Ketiga penyedia besar (Anthropic, OpenAI, Gemini) memberikan diskon 90% pada cached input token di 2026, tetapi struktur biaya write dan minimum size berbeda drastis.
Anthropic mewajibkan marker cache_control eksplisit dengan write surcharge 1.25x (5 menit) atau 2x (1 jam); OpenAI cache otomatis tanpa konfigurasi; Gemini butuh minimum 32K token dan biaya penyimpanan per jam.
Per 6 Maret 2026, Anthropic mengubah default TTL dari 3600 detik menjadi 300 detik. Pin ttl: 3600 eksplisit kalau workload Anda mengandalkan cache 1 jam.
ROI break-even Anthropic tercapai setelah minimal 5 cache hit per siklus write; di bawah angka itu, OpenAI biasanya lebih murah untuk workload dengan pola akses tak menentu.
Arsitektur cache multi-tier (exact-match Redis + semantic cache + provider prompt cache) memberikan penghematan gabungan 40–86% dalam sistem produksi.
Cache hit rate harus diinstrumentasi via field cached_tokens. Tanpa observabilitas Anda tidak akan tahu ketika hit rate collapse karena perubahan prompt satu karakter.

Apa itu prompt caching dan bagaimana cara kerjanya?

Ketika sebuah LLM memproses prompt Anda, model menghitung key-value tensors (KV cache) untuk setiap token pada tahap prefill. Untuk prompt panjang dengan 20K token instruksi sistem plus dokumen referensi, prefill inilah yang mendominasi latensi dan biaya. Prompt caching menyimpan KV tensor tersebut di sisi server. Ketika request berikutnya mulai dengan byte prefix yang sama persis, model melewati komputasi ulang dan memuat state yang di-cache; output-nya identik byte-per-byte, hanya langkah prefill yang di-shortcut.

Efeknya dua lapis. Pertama, biaya: cached input token ditagih pada 10% harga input normal (diskon 90%) di ketiga penyedia utama sejak Q2 2026. Kedua, latensi: karena prefill sering menjadi bagian terlambat dari request, cache hit biasanya memotong Time-to-First-Token (TTFT) sebesar 30–80%. Pada agen ReAct yang saya deploy untuk klien fintech Berlin, prompt caching menurunkan p95 latency dari 4.2s ke 1.1s untuk turn setelah turn pertama. Honestly, hasil itu yang akhirnya membuat tim mereka mau serius menginvestasikan waktu untuk mendesain ulang struktur prompt.

Yang penting dipahami: caching hanya berlaku untuk prefix. Kalau Anda menempatkan timestamp atau session ID di baris pertama prompt, seluruh cache akan miss, bahkan kalau 99% prompt sisanya identik. Ini alasan aturan pertama caching yang saya pegang teguh di semua project: static content sebelum dynamic content. Tool definitions, system prompt, few-shot examples, dokumen referensi statis, semua ini masuk di atas. Query pengguna, history percakapan, dan variabel dinamis lainnya di bawah.

Perbandingan Anthropic vs OpenAI vs Gemini 2026

Tabel di bawah merangkum kondisi produksi per Agustus 2026. Angka-angka ini saya verifikasi dengan billing dashboard aktual dari tiga workload klien berbeda (satu Claude Sonnet 4.5, satu GPT-5.1, satu Gemini 2.5 Pro).

Fitur	Anthropic Claude	OpenAI GPT-5.x	Google Gemini 2.5+
Diskon cached read	90% (0.1x)	90% (0.1x)	90% (0.1x)
Biaya cache write	1.25x (5 mnt) / 2x (1 jam)	Gratis (otomatis)	Biaya storage per jam
Minimum cacheable size	1,024 token (2,048 untuk Haiku)	~1,024 token	32,768 token
Default TTL	5 menit (sejak 6 Maret 2026)	5–10 menit otomatis	Eksplisit, per jam
Long TTL	1 jam (opt-in, write surcharge)	Tidak ada	Sesuai konfigurasi
Konfigurasi diperlukan	Ya (cache_control markers)	Tidak	Ya (SDK createCachedContent)
Maksimum breakpoints	4 per request	Otomatis (implicit)	1 per cache
Cocok untuk	Agen dengan tool definitions besar	Workload heterogen tak terprediksi	Batch processing dokumen sangat besar

Kesimpulan operasional: kalau workload Anda memiliki system prompt panjang yang stabil dan pola panggilan yang predictable (minimal 5 hit per 5 menit), Anthropic memberikan kontrol paling granular dan sering menjadi opsi termurah. Kalau traffic Anda spiky dan sulit diprediksi, caching otomatis OpenAI menghilangkan overhead tuning tanpa memaksa Anda memikirkan cache lifecycle. Gemini masuk akal hanya ketika Anda punya konteks statis sangat besar (dokumen 100K+ token) yang di-reuse ribuan kali per jam. Di bawah threshold itu, biaya storage per jam-nya lebih besar dari penghematan.

Implementasi Anthropic: cache_control, TTL, dan Breakpoints

Anthropic memberikan kontrol paling eksplisit. Anda menandai content block sebagai cache breakpoint dan Anthropic menyimpan encoded state untuk semua yang di atasnya. Berikut pola minimum yang saya pakai di production untuk agen dengan tool definitions besar:

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": SYSTEM_PROMPT_LONG,  # 8K token instruksi statis
            "cache_control": {"type": "ephemeral", "ttl": "1h"}
        }
    ],
    tools=[
        {
            "name": "search_orders",
            "description": TOOL_DESC_ORDERS,
            "input_schema": SCHEMA_ORDERS,
            "cache_control": {"type": "ephemeral", "ttl": "1h"}
        },
        # ... 15 tool definitions lainnya
    ],
    messages=[
        {"role": "user", "content": user_query}  # dinamis, tidak di-cache
    ]
)

# Cek metrik cache
print(f"Cache write tokens: {response.usage.cache_creation_input_tokens}")
print(f"Cache read tokens:  {response.usage.cache_read_input_tokens}")
print(f"Input uncached:     {response.usage.input_tokens}")

Perhatikan tiga hal. Pertama, ttl: "1h" harus di-set eksplisit. Sejak 6 Maret 2026, Anthropic mengubah default dari 3600 ke 300 detik, dan banyak codebase produksi mengalami cache hit rate collapse dalam semalam karena mengandalkan default lama. (I hit this exact bug shipping ke staging tiga hari setelah rollout perubahan itu.) Kedua, kalau Anda mencampur TTL 1 jam dan 5 menit dalam satu request, breakpoint 1 jam harus muncul lebih dulu. Pelanggaran urutan ini menyebabkan API mengembalikan 400. Ketiga, minimum cacheable adalah 1,024 token (2,048 untuk Haiku); block lebih pendek diabaikan meski di-mark.

Untuk agen multi-turn, gunakan mode automatic caching: letakkan satu cache_control di level teratas request dan Anthropic akan otomatis memindahkan breakpoint ke block cacheable terakhir seiring history percakapan bertumbuh. Ini menghindari kebutuhan mengelola breakpoint manual per turn, pola yang mahal untuk maintain di codebase besar. Detail lengkap ada di dokumentasi Anthropic prompt caching.

Implementasi OpenAI: caching otomatis tanpa konfigurasi

Filosofi OpenAI kebalikan dari Anthropic: tidak ada tombol untuk ditekan. Sejak GPT-4o dan berlaku default untuk seluruh keluarga GPT-5.x, setiap request dengan prefix minimal 1,024 token yang cocok dengan request sebelumnya (dalam window 5–10 menit) secara otomatis di-serve dari cache. Anda tidak dikenakan biaya write terpisah; panggilan pertama ditagih pada tarif input standar, panggilan berikutnya yang match di-tag sebagai cached.

from openai import OpenAI

client = OpenAI()

response = client.chat.completions.create(
    model="gpt-5.1",
    messages=[
        {"role": "system", "content": SYSTEM_PROMPT_LONG},  # otomatis di-cache
        {"role": "user", "content": user_query}
    ]
)

# Field cached_tokens muncul di usage
usage = response.usage
cached = usage.prompt_tokens_details.cached_tokens
total_input = usage.prompt_tokens
print(f"Cache hit rate this call: {cached}/{total_input} = {cached/total_input:.1%}")

Konsekuensi desain ini: Anda tidak bisa memaksa cache membentuk breakpoint tertentu. Aturan main OpenAI adalah match prefix terpanjang yang tersedia. Kalau prompt Anda menyisipkan variabel dinamis di posisi ke-500 sementara sisanya statis, cache hit hanya untuk 500 token pertama, sedangkan sisa 20K token dihitung dari nol. Ini menjadikan disiplin static-before-dynamic lebih penting di OpenAI daripada di Anthropic, karena Anda tidak punya safety net eksplisit.

Satu kejutan yang saya alami: OpenAI cache tidak selalu memberikan hit meski prefix identik byte-per-byte. Cache di-partition per data-center region, dan traffic Anda bisa dirouting ke instance berbeda. Untuk workload latensi-kritis (voice agents, real-time chat), sertakan header OpenAI-Beta: prompt-cache-affinity=1 untuk sticky routing, dan ini biasanya menaikkan hit rate dari sekitar 65% ke minimal 90% pada trafik konstan.

Implementasi Gemini: explicit context caching

Gemini mengambil pendekatan ketiga: cache eksplisit sebagai resource pertama-kelas. Anda memanggil createCachedContent untuk mengunggah konten yang di-cache, dapat cache_id, lalu mereferensikannya di setiap request. Model biayanya bukan write-surcharge tapi storage-per-hour.

from google import genai
from google.genai import types

client = genai.Client()

# Buat cache eksplisit (minimum 32K token)
cache = client.caches.create(
    model="gemini-2.5-pro",
    config=types.CreateCachedContentConfig(
        display_name="legal-doc-corpus-v3",
        system_instruction=SYSTEM_PROMPT,
        contents=[LARGE_DOC_CORPUS],  # 120K token dokumen hukum
        ttl="3600s"
    )
)

# Gunakan cache di request berikutnya
response = client.models.generate_content(
    model="gemini-2.5-pro",
    contents=user_query,
    config=types.GenerateContentConfig(cached_content=cache.name)
)

# Biaya storage terus berjalan sampai TTL habis atau cache di-delete
print(f"Cache size: {cache.usage_metadata.total_token_count} tokens")
print(f"Cache expires: {cache.expire_time}")

Model ini optimal ketika Anda punya konteks statis besar (100K+ token) yang di-reuse ratusan kali dalam window pendek, misalnya chat-with-your-documents untuk corpus regulasi hukum yang sama diakses oleh 50 pengguna simultan. Di bawah pola itu, ekonominya tidak masuk akal: minimum 32K token menghilangkan penggunaan untuk sistem RAG umum yang chunking-nya berkisar 5–10K token per query. Ada juga Gemini 3.1 Pro Preview yang menggandakan harga input dari $2 ke $4 dan output dari $12 ke $18 begitu prompt melewati 200K token. Tarif cache ikut naik dua kali lipat pada threshold yang sama.

Matematika biaya: kapan setiap penyedia menang?

Contoh konkret dari klien saya: agen customer support dengan system prompt 12K token, dijalankan 40,000 kali per hari, dengan trafik yang cukup konstan sehingga cache 5-menit selalu warm. Perhitungan bulanan (Sonnet 4.5 vs GPT-5.1 vs Gemini 2.5 Pro):

Tanpa caching: 12,000 token x $3/juta x 40,000 request x 30 hari = $43,200/bulan (input saja, exclude output).
Anthropic dengan cache_control 1 jam: 1 write per jam x $6/juta (2x surcharge) x 12,000 x 24 x 30 + (40,000 - 24) x 12,000 x $0.30/juta x 30 = ~$52 write + ~$4,320 read = $4,372/bulan.
OpenAI otomatis 5 menit: asumsi 92% hit rate (measured) = 3,200 uncached calls/hari x 12,000 x $3/juta x 30 + 36,800 cached x 12,000 x $0.30/juta x 30 = $3,456 + $3,974 = $7,430/bulan.
Gemini dengan explicit cache: cache 12K token gagal minimum 32K, jadi tidak layak untuk pola ini.

Penghematan dari harga list: 90% (Anthropic), 83% (OpenAI). Anthropic menang di sini karena Anda bisa memaksa TTL 1 jam dan menghindari re-write setiap 5 menit. Kalau Anda menonaktifkan long TTL dan tetap di default 5-menit, Anthropic dan OpenAI kembali setara. Ini contoh mengapa context engineering yang disiplin (di mana struktur prompt didesain sengaja untuk caching) memberikan ROI yang jauh melebihi micro-optimization pada model selection.

Prompt caching vs semantic caching: kapan pakai yang mana?

Prompt caching hanya menyelamatkan prefill, bagian input dari request. Ia tidak menghemat token output, dan ia melihat kecocokan byte-per-byte pada prefix. Semantic caching berbeda kategori: ia mem-bypass model sepenuhnya untuk query yang serupa secara semantik, mengembalikan response yang di-cache dari query serupa sebelumnya. Penghematannya berlaku pada input dan output.

Alur semantic cache: query masuk, di-embed, dicari similarity di vector store; kalau similarity di atas threshold (biasanya 0.85–0.95), return cached response; kalau tidak, panggil LLM dan simpan pasangan (embedding, response) untuk lookup berikutnya. Tool populer di 2026: GPTCache untuk stack Python, dan RedisSemanticCache untuk aplikasi yang sudah menjalankan Redis Stack.

from langchain_redis import RedisSemanticCache
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain.globals import set_llm_cache

set_llm_cache(RedisSemanticCache(
    embeddings=OpenAIEmbeddings(model="text-embedding-3-small"),
    redis_url="redis://localhost:6379",
    distance_threshold=0.15,  # cosine distance; makin rendah = makin strict
    ttl=3600
))

llm = ChatOpenAI(model="gpt-5.1")

# Query 1: cache miss, panggil LLM, simpan
r1 = llm.invoke("How do I reset my password?")

# Query 2: similarity 0.92, cache hit, LLM tidak dipanggil
r2 = llm.invoke("Where can I change my password?")

Tuning threshold adalah trade-off precision-recall yang klasik. Threshold terlalu longgar (distance 0.3+) menghasilkan false positive: pertanyaan berbeda arti dijawab dengan response salah. Threshold terlalu ketat (distance 0.05) melewatkan paraphrase valid. Saya biasanya mulai di 0.15 untuk aplikasi customer support dengan FAQ berulang, lalu turunkan ke 0.10 kalau observasi menunjukkan false positive muncul. Untuk domain teknis (kode, medis, hukum), threshold-per-kategori memberikan hasil lebih baik daripada satu threshold global. Variasi threshold berdasarkan kategori query mengakui bahwa jenis query berbeda butuh policy cache berbeda.

Arsitektur cache multi-tier untuk produksi

Sistem produksi matang mengoperasikan tiga layer cache yang saling melengkapi. Deploy ketiganya adalah standar di stack yang benar-benar mencapai target penghematan 40–86%.

Exact-match cache (Redis): query di-hash (SHA-256 dari normalized prompt string) dan dicek ke key-value store. Hit rate rendah (~10–20%) tapi latensi ~2ms dan biaya nol. Menangkap query duplicate persis.
Semantic cache (vector store): kalau exact miss, cek similarity embedding di vector store. Hit rate 30–50% pada workload dengan intent berulang. Latensi ~5–8ms plus biaya embedding (~$0.02/juta token). Menangkap paraphrase.
Provider prompt cache: kalau kedua layer di atas miss, request dikirim ke LLM dengan cache_control aktif. Menangkap prefix statis yang tersisa (system prompt, tool definitions).

Susunan ini penting: exact-match lebih dulu karena termurah dan tercepat. Semantic kedua karena butuh embedding computation. Provider cache terakhir karena tetap butuh round-trip ke penyedia. Untuk mengukur efektivitas gabungan, instrumentasikan hit-rate per layer. Kalau Anda tidak tahu layer mana yang menangkap traffic, Anda tidak bisa tuning threshold atau eviction policy. Pola instrumentasi standar dijelaskan lebih dalam di panduan LLM observability dengan OpenTelemetry, Langfuse, dan Helicone.

Monitoring cache hit rate dan anti-pola umum

Semua penyedia memaparkan metrik cache di response usage. Wire ini ke observability stack Anda supaya regresi hit-rate memicu alert, bukan tagihan mengejutkan di akhir bulan. Field yang harus Anda log:

Anthropic: usage.cache_creation_input_tokens, usage.cache_read_input_tokens, usage.input_tokens.
OpenAI: usage.prompt_tokens_details.cached_tokens, usage.prompt_tokens.
Gemini: usage_metadata.cached_content_token_count, usage_metadata.prompt_token_count.

Alert rule yang saya set default untuk semua klien: hit-rate 15-menit rolling turun minimal 20% dari baseline 24 jam, memicu PagerDuty warning. Penyebab paling sering di lapangan: developer menambahkan datetime.now() atau UUID request-tracking di baris pertama prompt tanpa menyadari dampaknya ke cache. Debugging pola ini di production tanpa observabilitas berarti membakar ribuan dolar sebelum akhirnya menemukannya.

Anti-pola lain yang saya lihat berulang: developer meletakkan cache_control di block yang berubah setiap request (misalnya menandai user message alih-alih system prompt). Cache write dijalankan setiap turn tapi tidak pernah di-read, jadi Anda membayar 1.25x untuk setiap request tanpa penghematan sama sekali. Rule of thumb: kalau content berubah lebih sering dari TTL, jangan cache. Untuk deep-dive tentang bagaimana caching berinteraksi dengan tool use dan function calling di agen kompleks, lihat panduan function calling LLM 2026 yang membahas trade-off ini.

Pertanyaan yang Sering Diajukan

Apakah prompt caching mempengaruhi kualitas output LLM?

Tidak. Cache hit mengembalikan output yang byte-identical dengan cache miss karena hanya tahap prefill (komputasi KV tensors) yang di-shortcut; tahap decoding tetap berjalan penuh. Cache memberikan persis kata-per-kata output yang sama seolah Anda menghitung ulang dari nol.

Berapa lama data cache disimpan di server penyedia?

Anthropic: 5 menit default atau 1 jam opt-in. OpenAI: 5–10 menit otomatis. Gemini: sesuai TTL yang Anda set (per detik hingga jam). Semua penyedia menyatakan cache di-scope per-organisasi dan dihapus setelah TTL habis; tidak ada cross-tenant caching.

Apakah prompt caching aman untuk data sensitif seperti PII atau credentials?

Cache di-isolasi per API key/organisasi jadi tidak ada risiko leak antar tenant. Namun karena cache menyimpan raw prompt content di infrastruktur vendor, Anda tetap harus menghindari mengirim PII yang tidak perlu dan mengaudit compliance kontrak (GDPR Article 28 processor terms) sebelum caching data teregulasi. Untuk workload sangat sensitif, self-hosted vLLM atau TensorRT-LLM dengan KV cache lokal adalah alternatif yang lebih ketat.

Bagaimana cara memaksa cache miss saat testing?

Tambahkan string unik (misalnya UUID atau timestamp mikrodetik) di baris pertama system prompt. Ini menggagalkan prefix match dan memaksa full recomputation. Berguna untuk load testing dan menghitung baseline latency non-cached. Ingat untuk menghapusnya sebelum deploy produksi.

Bisakah semantic cache dan prompt cache digunakan bersamaan?

Ya, dan itu justru direkomendasikan. Semantic cache berjalan di aplikasi Anda sebelum request dikirim ke penyedia. Kalau semantic cache miss, request diteruskan ke LLM dengan prompt cache aktif di sisi penyedia. Kedua mekanisme menyelamatkan biaya di layer berbeda dan tidak konflik.