🔬 BACOT — Sesi 15:00 Technical Exploration

📚 Topik: Prompt Caching, Token Budget & Optimasi Biaya LLM

Level: menengah · Kategori: AI Engineering · Verifikasi: docs resmi per 2026-11-08

🎯 Tujuan Belajar

Setelah sesi ini, kamu bisa:

1. Hitung break-even caching sebelum menulis satu baris kode integrasi
2. Tahu kenapa cache miss terjadi di prompt yang "kelihatan sama"
3. Rancang layout prompt (tools → system → messages) supaya cache hit stabil sepanjang umur aplikasi
4. Pilih TTL dan provider berdasarkan pola trafik, bukan berdasarkan harga headline
5. Pasang observability supaya cache hit rate jadi metrik yang dipantau, bukan asumsi

🏗️ Arsitektur & Alur Teknis

Apa yang sebenarnya di-cache

Bukan teks. Yang disimpan adalah KV tensors — intermediate state hasil komputasi attention untuk prefix tertentu. Konsekuensinya:

Urutan hierarki cache (Anthropic)

tools[]  →  system[]  →  messages[]  →  (breakpoint terakhir)
   ↑ dibangun berurutan, tiap level menumpuk di atas level sebelumnya

Artinya: tool definition yang berubah meng-invalidate seluruh cache system + messages. Ini sumber cache miss nomor satu di produksi — orang menambahkan tool baru per-request berdasarkan permission user.

Mekanisme breakpoint & lookback (Anthropic, sumber: docs resmi)

• Maksimum 4 cache breakpoint per request
• Cache write hanya terjadi di breakpoint, bukan di posisi lain yang "kebetulan stabil"
• Saat read, sistem mencari hash prefix yang cocok; kalau tidak ada, walk backward maksimal 20 blok
• Kalau breakpoint ditaruh di blok yang berubah tiap request (timestamp, user input) → tulis entry baru terus, tidak pernah hit

Turn 1: blok 1..10, breakpoint di 10  → write entry @10
Turn 2: blok 1..15, breakpoint di 15  → miss @15, lookback → hit @10, write @15
Turn 3: blok 1..35, breakpoint di 35  → cek 35..16, entry @15 di luar jendela → MISS

Fix: tambah breakpoint kedua di blok 15. Ini bukan bug, ini desain jendela lookback.

Perbedaan model mental antar provider

⚠️ Angka di tabel ini berubah. Anthropic baru saja menurunkan multiplier read dari 0.1× → 0.05× untuk Opus 5.5 / Sonnet 5.5, dan ke 0.025× untuk Fable 5.1 / Mythos 5.1. Kalau kamu baca artikel 2025, angkanya salah.

📊 Angka & Benchmark

Harga Anthropic (docs resmi, diakses 2026-11-08, USD/MTok)

Minimum cacheable token (Anthropic): - 512 tok → Fable 5.1, Mythos 5.1, Opus 5.5, Opus 5, Sonnet 5.5, Haiku 5.5 - 1.024 tok → Opus 4.8, Sonnet 5, Sonnet 4.6/4.5, Opus 4.1, Sonnet 4 - 2.048 tok → Mythos Preview, Opus 4.7 - 4.096 tok → Opus 4.6, Opus 4.5, Haiku 4.5

Perhatikan: Haiku 4.5 butuh 4.096 token minimum — model termurah justru paling sulit di-cache. Ironi yang sering bikin perhitungan orang meleset.

Harga OpenAI (GPT-5.6+)

• Write 30m: 1.25× input · Write 12h: 2.5× input
• Read: 0.1× (0.05× untuk GPT-6.1 Sol / Terra)
• Minimum: 1.024 visible input token — token dari hidden system content tidak dihitung
• Model lama (GPT-5.5 ke bawah): tidak ada write charge sama sekali, tapi minimum bervariasi menurut tools/images/schema/reasoning effort

Harga Gemini (AI Studio pricing, diakses 2026-11-08)

Storage fee adalah pembeda utama. Gemini satu-satunya dari empat provider ini yang menagih cache per jam disimpan, terlepas dari berapa kali dibaca.

Harga DeepSeek (docs resmi, per 1M token)

Cache hit 50× lebih murah dari miss. Peak hours: 01:00–04:00 dan 06:00–10:00 UTC, Sen–Jum.

💻 Kode Nyata

1. Model biaya & break-even — runnable, zero dependency

"""breakeven.py — stdlib saja, Python 3.11+"""
def reads_to_breakeven(write_mult, read_mult):
    """Berapa cache-read dibutuhkan agar premium write tertutup."""
    return (write_mult - 1.0) / (1.0 - read_mult)

def cost_mtok(prefix_tok, n_req, write_mult, read_mult, price_mtok, hit_ratio=1.0):
    reuse = max(n_req - 1, 0)
    hits = reuse * hit_ratio
    misses = reuse - hits
    return prefix_tok * (write_mult + hits * read_mult + misses) * price_mtok / 1e6

def gemini_cost(prefix_tok, cached_mtok, storage_mtok_hour, hours):
    return prefix_tok * (cached_mtok + storage_mtok_hour * hours) / 1e6

assert abs(reads_to_breakeven(1.25, 0.1) - 0.2778) < 1e-3
assert reads_to_breakeven(2.0, 0.1) > 1.0   # 1h TTL butuh >1 read

P, N, price = 20_000, 100, 2.0              # Sonnet 5.5
uncached = P * N * price / 1e6
cached = cost_mtok(P, N, 1.25, 0.05, price)
print(f"uncached ${uncached:.4f} | cached ${cached:.4f} | -{1-cached/uncached:.0%}")

wasted = cost_mtok(P, N, 1.25, 0.05, price, hit_ratio=0.0)
assert abs(wasted - P * (1.25 + (N - 1)) * price / 1e6) < 1e-12

Output nyata dari eksekusi:

Sonnet 5.5  100 req cached = $0.2480 (uncached $4.0000, -94%)
tanpa hit   $4.0100 vs uncached $4.0000 = +0.2% lebih mahal
Gemini      cache 1 jam = $0.2350; plain 1 req = $0.1000 -> butuh >1 read
  n= 2 read/jam: cached $0.2350 vs plain $0.2000 -> plain unggul
  n= 5 read/jam: cached $0.2350 vs plain $0.5000 -> cache unggul

Cara baca hasil ini: - 0.278 read untuk 5m TTL → praktis balik modal di request kedua kalau prefix sama - write tanpa hit cuma rugi 0.2% karena write charge 1.25× hanya berlaku sekali dari 100 request — premium write itu kecil, dan hampir selalu tertutup - Gemini butuh >1 read dalam 1 jam karena storage fee. Di 2 read masih kalah; baru unggul di 5+.

2. Anthropic — explicit breakpoint yang benar

import anthropic  # pip install anthropic (Messages API, non-beta, per docs 2026)

client = anthropic.Anthropic()

SYSTEM = "Kamu analis kontrak. Jawab ringkas, kutip pasal." * 200  # ~2k token, stabil
DOC    = open("kontrak.txt").read()   # ~40k token, stabil per dokumen

def ask(question: str, doc_id: str):
    return client.messages.create(
        model="claude-sonnet-5-5",
        max_tokens=1024,
        system=[
            # breakpoint 1: system prompt, dipakai semua dokumen
            {"type": "text", "text": SYSTEM,
             "cache_control": {"type": "ephemeral"}},
            # breakpoint 2: dokumen, dipakai semua pertanyaan atas dokumen ini
            {"type": "text", "text": DOC, "cache_control": {"type": "ephemeral"}},
        ],
        messages=[{"role": "user", "content": question}],
    )

r = ask("Apa klausul terminasi?")
u = r.usage
print(u.cache_creation_input_tokens, u.cache_read_input_tokens, u.input_tokens)

Kenapa 2 breakpoint, bukan 1: pertanyaan berubah tiap request, dokumen tidak. Kalau breakpoint cuma di akhir (setelah pertanyaan), hash selalu berubah → tidak pernah hit. Ini kesalahan paling umum.

Kalau system prompt sudah ≥ minimum tapi dokumen berubah-ubah per user (tiap user beda dokumen), breakpoint 1 tetap berguna sendirian — cross-user cache hit pada system prompt.

3. Anthropic — automatic caching untuk chat multi-turn

resp = client.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=2048,
    cache_control={"type": "ephemeral"},   # TTL top-level, breakpoint auto geser
    system="Kamu asisten yang mengingat percakapan.",
    messages=history,
)

Breakpoint otomatis pindah ke blok cacheable terakhir tiap request. Cocok kalau setiap turn menambah <20 blok — lewat dari itu, jendela lookback tidak menemukan write sebelumnya dan kamu perlu breakpoint tambahan.

Aturan kombinasi (docs): - Blok terakhir sudah punya cache_control TTL sama → automatic jadi no-op - TTL beda → HTTP 400 - 4 breakpoint eksplisit sudah terpakai → HTTP 400 (tidak ada slot untuk automatic)

4. OpenAI — TTL campuran dalam satu request

from openai import OpenAI
client = OpenAI()

BASE = "..."  # instruksi panjang, stabil sepanjang hari, >1024 token

resp = client.responses.create(
    model="gpt-5.6",
    prompt_cache_options={"ttl": "30m"},          # default request
    input=[
        {"role": "developer",
         "content": [{"type": "input_text", "text": BASE}],
         "prompt_cache_breakpoint": {"ttl": "12h"}},   # override: prefix panjang
        {"role": "user", "content": "Ringkas bagian 3."},
    ],
)
usage = resp.usage
print(usage.input_tokens_details.cached_tokens)

Cara hitung biaya input yang benar (dari docs OpenAI, diadaptasi):

def input_cost(usage, price_per_mtok, cached_mult=0.1, write_mult=1.25):
    inp  = usage.input_tokens
    cach = usage.input_tokens_details.cached_tokens
    wr   = usage.input_tokens_details.cache_write_tokens
    ordinary = inp - cach - wr
    weighted = ordinary + cach * cached_mult + wr * write_mult
    return weighted * price_per_mtok / 1_000_000

⚠️ Write charge bukan fee tambahan di atas harga normal — token masuk salah satu dari tiga bucket: uncached, cached, atau cache-write. Menjumlahkan keduanya = double count.

5. Instrumentasi — cache hit rate sebagai metrik

from dataclasses import dataclass

@dataclass
class CacheStat:
    read: int = 0
    write: int = 0
    fresh: int = 0

    def record(self, usage):
        self.read  += getattr(usage, "cache_read_input_tokens", 0) or 0
        self.write += getattr(usage, "cache_creation_input_tokens", 0) or 0
        self.fresh += getattr(usage, "input_tokens", 0) or 0

    @property
    def hit_rate(self) -> float:
        total = self.read + self.write + self.fresh
        return self.read / total if total else 0.0

    def alert(self, floor=0.6) -> str | None:
        if self.hit_rate < floor and (self.read + self.write + self.fresh) > 50_000:
            return f"cache hit rate {self.hit_rate:.1%} di bawah floor {floor:.0%}"
        return None

Pasang ini per-endpoint, bukan global. Global hit rate 85% bisa menyembunyikan satu endpoint yang 0% dan membakar 40% budget.

6. Script verifikasi cepat (jalankan sebelum deploy)

# pastikan prefix benar-benar > minimum & konsisten
python3 -c "
import anthropic,json,hashlib
c=anthropic.Anthropic()
h=lambda s:hashlib.sha256(s.encode()).hexdigest()[:12]
r=c.messages.create(model='claude-sonnet-5-5',max_tokens=16,
  system=[{'type':'text','text':open('system.txt').read(),
           'cache_control':{'type':'ephemeral'}}],
  messages=[{'role':'user','content':'ping'}])
print('write',r.usage.cache_creation_input_tokens,'read',r.usage.cache_read_input_tokens)
"
# jalankan 2x. run pertama: read=0, write>0. run kedua: read>0, write=0 atau kecil.

Kalau run kedua write masih besar → prefix berubah. Cek: timestamp di system prompt, tool list yang di-generate, JSON key ordering, atau user ID yang di-interpolasi.

⚖️ Trade-off & Alternatif

Catatan penting soal stacking: diskon batch dan cache read bertumpuk. Anthropic mendokumentasikan pola optimal untuk batch: kirim 1 request dengan shared prefix + 1h cache dulu, tunggu selesai, baru kirim sisanya. Ini jauh lebih efektif daripada 5m TTL karena batch job biasanya selesai dalam 5 menit–1 jam.

Alternatif selain caching (sering lebih besar dampaknya):

Jebakan: compaction dan caching saling bertentangan. Compaction memotong konteks → prefix berubah → cache miss. Docs OpenAI eksplisit menyebut ini. Hitung total biaya sebelum/sesudah compaction, jangan cuma lihat hit rate yang turun.

🏭 Use Case Produksi & Failure Mode

Kasus 1: Agent coding dengan 40 tool definition

Gejala: hit rate 12%, biaya input 6× estimasi. Penyebab: tool list di-generate per request berdasarkan permission user, urutan tool berubah karena iterasi dict dari DB. Fix: sort tool list deterministik, pisahkan tool yang jarang dipakai ke toolset terpisah (bukan di array utama), cache tool+system sebagai satu breakpoint. Pelajaran: perubahan urutan = perubahan prefix = miss. Docs OpenAI menyebut tools ordering sebagai faktor invalidasi eksplisit.

Kasus 2: RAG dengan timestamp di system prompt

Gejala: hit rate 0% padahal prompt "sama". Penyebab: f"Tanggal hari ini: {datetime.now()}" di awal system prompt. Fix: pindahkan timestamp ke setelah breakpoint, atau bundel jadi granularitas harian.

Kasus 3: Parallel request saat warm-up

Gejala: 20 request paralel, semuanya kena write charge, nol read. Penyebab: cache entry baru tersedia setelah response pertama mulai. Docs Anthropic eksplisit: "For concurrent requests, note that a cache entry only becomes available after the first response starts." Fix: serialize request pertama (warm), baru fan-out. Atau terima biaya write 20× sebagai trade-off latency.

Kasus 4: Model swap di tengah deployment

Gejala: hit rate drop ke 0 setelah upgrade model. Penyebab: ganti model = cache terpisah. Tidak ada cache sharing lintas model. Fix: rollout bertahap; jangan swap model di jam sibuk.

Kasus 5: Prompt di bawah minimum

Gejala: cache_creation_input_tokens = 0 dan cache_read_input_tokens = 0 selamanya, tanpa error. Penyebab: prompt < 1.024/2.048/4.096 token. Tidak ada error yang dikembalikan — caching dilewati diam-diam. Fix: log kedua field itu; kalau keduanya 0, prompt tidak pernah di-cache. Catatan docs OpenAI: memperpanjang prefix pendek sampai minimum bisa lebih murah daripada tidak cache sama sekali — ada titik break-even. Tapi jangan tambah token sampah; tambah contoh/rubrik yang benar-benar memperbaiki output.

Kasus 6: Cross-tenant cache leak (mitos vs fakta)

Cache tidak dibagi lintas organisasi. Anthropic: isolasi per workspace dalam organisasi (Claude API) atau per organisasi (Bedrock/Vertex). OpenAI: tidak dibagi lintas organisasi maupun lintas regional boundary, dan tidak bisa di-clear manual. Prompt caching eligible untuk ZDR dan HIPAA di kedua provider.

🛠️ Latihan Praktis Kecil (±25 menit)

Target: buktikan sendiri bahwa urutan prompt menentukan hit rate.

1. Simpan breakeven.py di atas, jalankan. Catat angka hemat untuk kasusmu sendiri (ganti P, N, price dengan workload realistis).

2. Kalau punya API key — jalankan pola verifikasi 2-run:

# run A
r1 = call(system_with_timestamp)   # write>0, read=0
r2 = call(system_with_timestamp)   # write>0 LAGI, read=0  <- bug
# run B
r1 = call(system_without_timestamp)  # write>0, read=0
r2 = call(system_without_timestamp)  # write=0, read>0     <- benar

3. Tanpa API key: tulis fungsi hit_rate() dan bikin unit test pakai dict palsu berisi tiga angka — pastikan hit_rate benar saat total = 0 (jangan ZeroDivisionError).

4. Hitung: untuk workload-mu, berapa request/jam minimum agar 1h TTL di Anthropic mengalahkan 5m TTL? Pakai reads_to_breakeven(2.0, 0.1) = 11.1 read — artinya TTL 1 jam butuh ≥12 read dalam window 1 jam untuk menang atas 5 menit.

✅ Cek Pemahaman

1. System prompt kamu 800 token, dokumen 30.000 token berubah tiap user, model Sonnet 5.5. Kalau kamu taruh cache_control hanya di akhir dokumen, apa yang terjadi pada cache_read_input_tokens? Di mana seharusnya breakpoint?

2. Agent kamu mengirim 25 blok pesan per turn. Di turn ke-2 hit, turn ke-3 miss. Kenapa? Perbaikan minimal apa?

3. Gemini 3.1 Pro dengan prefix 100k token, dibaca 3× dalam 1 jam. Lebih murah cache atau tidak? Tunjukkan hitungannya. (Input $2/MTok ≤200k, cached $0.20, storage $4.50/MTok/jam.)

🔑 Poin Kunci

• Cache menyimpan KV tensors, bukan teks. Hash kumulatif per prefix → satu token berubah di awal, semua di belakangnya invalid.
• Break-even diukur dalam "berapa read", bukan "berapa request": 5m TTL ≈ 0.28 read, 1h TTL ≈ 1.1 read. Keduanya hampir selalu tercapai.
• Write premium kecil, miss mahal. 1 write 1.25× untuk 100 request = +0.2% biaya. Tapi hit rate 0% berarti kamu bayar overhead tanpa manfaat.
• Breakpoint harus di blok terakhir yang identik antar request — bukan di blok yang berubah. Ini 80% penyebab cache miss produksi.
• Urutan tools matter. Tool list non-deterministik = cache mati.
• Minimum token bervariasi per model dan tidak ada error kalau di bawahnya. Selalu log cache_creation_input_tokens dan cache_read_input_tokens; keduanya 0 = tidak pernah cache.
• Gemini beda: ada storage fee per jam. Cache baru unggul di ≥3–5 read per jam untuk Pro. Hitung dulu, jangan asumsi.
• Compaction dan caching bertentangan. Compaction hemat token tapi merusak cache dari token pertama yang berubah. Bandingkan total biaya, bukan hit rate.
• Batch + cache stacking ~50% × 90% = jauh lebih murah, tapi butuh pola khusus (warm dengan 1h TTL, baru fan-out).

➡️ Eksplorasi Lanjut

• Prompt cache diagnostics — OpenAI baru merilis tool khusus untuk debugging cache miss (path: /api/docs/guides/prompt-caching/diagnostics). Bandingkan metodenya dengan skrip verifikasi manual di atas.
• Cache-aware agent loop — bagaimana mengatur urutan tool call agar tool_result tidak memecah prefix. Perhatikan: Anthropic menghitung run tool_use berurutan sebagai satu posisi dalam jendela lookback — desain ini sengaja untuk parallel tool calls.
• Batch API + 1h cache — pola "warm 1 request, lalu submit sisanya" untuk backfill eval set. Baca bagian Message Batches di docs Anthropic.
• Token budget sebagai constraint arsitektur — bukan cuma soal harga: hitung budget token per request sebagai fungsi dari fitur, dan buat ceiling yang di-enforce di gateway.
• Model routing + cache interplay — kalau kamu route ke model berbeda, cache terpisah. Routing dinamis bisa menghapus manfaat caching. Ini area yang jarang dibahas dan sering jadi bug mahal.

📄 Sumber (diakses 2026-11-08):

[1] Anthropic. "Prompt caching" — platform.claude.com/docs/en/build-with-claude/prompt-caching [2] OpenAI. "Prompt caching" — developers.openai.com/api/docs/guides/prompt-caching [3] Google. "Context caching" — ai.google.dev/gemini-api/docs/caching [4] Google. "Gemini Developer API pricing" — aistudio.google.com/docs/pricing [5] DeepSeek. "Models & Pricing" — api-docs.deepseek.com/quick_start/pricing [6] DeepSeek. "Context Caching" — api-docs.deepseek.com/guides/kv_cache

⚠️ Limitasi: Semua harga berubah cepat — Anthropic menurunkan multiplier read Opus 5.5/Sonnet 5.5 ke 0.05× dan Gemini mengumumkan kenaikan harga per 2027-01-01. Verifikasi ulang sebelum commit ke anggaran. Minimum token GPT-5.5 ke bawah "bervariasi menurut request settings" dan tidak dipublikasikan sebagai angka tunggal — jangan asumsikan 1.024 untuk model lama tanpa mengukur.