Agen support itu menjawab setiap tiket dengan benar. Di prompt-nya ada buku panduan kebijakan enam ribu kata, lima definisi tool, dan transkrip percakapan yang terus tumbuh. Prompt caching menyala, dan itulah bagian yang diperiksa tim waktu tagihan mulai naik.
Dua puluh empat giliran di tiga tiket mengirim 164.854 token dan menagih $0,4841. Loop yang sama dengan caching dimatikan menagih $0,4017. Fiturnya bukan cuma gagal menolong; dia menagih premi 21% untuk itu.
Ini lab 6 dari inva-lab, dan cukup python3: tanpa Docker, tanpa database, tanpa key, tanpa jaringan. Provider-nya simulasi dari aturan satu vendor yang diterbitkan November 2026, jadi angkanya bisa diulang dan gratis.
Poin Penting
- Caching menyala dan hit rate-nya 0,0%. 164.854 token terkirim dalam dua puluh empat giliran, $0,4841, yaitu 21% lebih mahal daripada loop yang sama dengan caching dimatikan di $0,4017.
- Tiga baris merusak prefix-nya, dan ketiganya terlihat wajar saat review. Timestamp registry di dalam definisi tool, jam di dalam system prompt, dan breakpoint yang diparkir di blok yang berubah tiap giliran.
- Misinya
make check: tujuh pemeriksaan, tidak ada yang hijau di kondisi awal, dan versi yang diperbaiki mencapai 90,9% dengan tagihan 34% dari jalan tanpa cache. - Lab-nya jalan offline. Python 3, tanpa API key, tanpa jaringan: provider-nya simulasi deterministik dari aturan caching satu vendor.
Yang kamu lihat saat menjalankannya
| perintah | yang muncul |
|---|---|
make demo |
hit= 0.0% $0.4841 untuk ketiga tiket |
make what-changes |
tools DIFFERENT, blok [0] CHANGED, breakpoint pindah dari blok [1] ke [3] |
make check |
0 dari 7 pemeriksaan hijau |
loop yang sama dengan cache_enabled=False |
$0.4017 |
Tidak ada yang terlihat rusak. Semua tiket terjawab, loop keluar dengan kode 0, dan provider tidak melaporkan error. Tagihannya satu-satunya gejala, dan make bench mengubahnya jadi tabel per giliran di mana write sama dengan sent di setiap baris: seluruh prompt ditulis ulang, tiap giliran, dan tidak ada yang pernah dibaca.
Kenapa prompt yang kelihatan statis tidak statis
Ada tiga hal yang berubah antara dua permintaan berurutan, dan tiap satunya masuk akal saat review kode.
Definisi tool membawa field notes berisi waktu snapshot registry. Itu ada untuk debugging, berubah tiap giliran, dan provider mem-hash tools sebelum menghash apa pun, jadi buku panduan di bawahnya menjadi teks baru setiap kali.
System prompt dibuka dengan tanggal dan jam. Memberi tahu agen hari apa sekarang kelihatan jelas berguna, dan model memang memakainya; cache-nya tidak.
Breakpoint-nya duduk di pesan terakhir. Itu blok yang berubah tiap giliran. Dokumentasi provider menamainya sebagai kesalahan yang menulis entri baru dan tidak pernah membaca satu pun: pencariannya menelusuri mundur mencari entri yang ditulis permintaan sebelumnya, dan tidak ada yang pernah ditulis di ujung buku panduan.
Ada satu lagi yang lebih sunyi di loop-nya: setiap giliran ketiga transkrip diganti ringkasan satu baris supaya konteksnya kecil. Konteksnya memang jadi kecil. Prefix-nya juga dipastikan tidak pernah bertahan, karena transkrip yang ditulis ulang bukan prefix.
Misimu
Buat make check hijau. Tujuh pemeriksaan, satu tema: cache mengikuti byte.
- Sedikitnya 75% token yang kamu kirim kembali sebagai cache read, dan biayanya paling banyak 45% dari loop yang sama dengan caching dimatikan.
- Model tetap menerima yang dia butuhkan. Tanggal harus sampai ke model, array tool harus identik byte demi byte di setiap permintaan, dan tiap permintaan harus merupakan permintaan sebelumnya ditambah blok baru, bukan penulisan ulang.
- Loop bertahan melewati jeda sepuluh menit setelah giliran keempat, dan
python3 agent/loop.pymencetak satu baris berisi angka yang benar-benar dia ukur.
Versi yang diperbaiki di repo mencapai 90,9% dan $0,1437, yaitu 34% dari permintaan yang sama dengan caching dimatikan. Transkripnya 6% lebih panjang daripada versi yang rusak, karena tidak ada lagi yang diringkas. Tagihannya turun sementara jumlah tokennya naik, dan itulah seluruh pelajarannya.
Kenapa provider-nya simulasi
Lab yang memanggil API sungguhan adalah lab yang butuh uang, butuh key, dan memberi angka berbeda di mesinmu. Yang ini punya jam palsu, jadi timeout cache lima menit dan jeda pelanggan sepuluh menit berjalan di bawah satu detik, dan ledger-nya deterministik. Tukarnya dinyatakan terang: agent/provider.py menerapkan aturan satu vendor, satu token adalah satu kata, dan angkanya bukan yang akan ditagih ke akunmu.
Kalau kamu mau aturan yang dipakai vendor lain, dan apa yang terjadi saat prefix tumbuh dari 512 token ke 1.024 sementara cache-nya diam, itu ada di artikel pendampingnya.
Kalau kamu buntu
HINTS.md punya tiga tingkat, dan tingkat pertama cuma meminta kamu melihat dua permintaan berurutan berdampingan. Artikel jawabannya memuat progresi terukur, termasuk dua perbaikan yang tidak mengubah apa pun dan satu baris yang mengubah segalanya.