GPT-6.1 Terra Caching: Lima Sen per Pembacaan, dan Kapan Penulisan Membuahkan Hasil

Tarif input cache GPT-6.1 Terra adalah $0,05 per juta token — 95% di bawah tarif input standar $1,00, dan merupakan diskon tunggal terbesar di seluruh kartu tarif. Jebakannya ada di sisi lain pembukuan: menulis ke cache biayanya $1,25 per juta untuk retensi 30 menit atau $2,50 per juta untuk 12 jam. Beban kerja yang membaca prefiks yang sama dua kali akan diuntungkan. Beban kerja yang membangun ulang prefiksnya pada setiap panggilan membayar biaya tulis dan tidak pernah mendapatkan diskon, dan kartu tarif tidak akan memberi tahu Anda mana yang sedang Anda jalankan.

Tulisan ini melakukan perhitungan: titik impas persis, tiga beban kerja yang dihitung pada skala berbeda, interaksi dengan ambang konteks panjang 272K, dan kebiasaan rekayasa prompt yang diam-diam merusak cache.

Keempat angka tersebut

• Input standar — $1.00 per juta token.

• Input cache — $0.05 per juta, diskon 95%.

• Penulisan cache, retensi 30 menit — $1,25 per juta.

• Penulisan cache, retensi 12 jam — $2,50 per juta.

Di atas 272.000 token input, semuanya menjadi dua kali lipat: input $2,00, cache $0,10, penulisan cache $2,50. Jadi tebing konteks panjang tidak hanya menaikkan tarif input — tetapi juga menaikkan harga untuk caching dan penulisan sekaligus.

Sebagai perbandingan, input cache GPT-6.1 Sol adalah $0.10 dan GPT-5.6 Terra adalah $0.20. Tarif baca lima sen Terra adalah yang termurah di keluarganya, dan diskon 95% itulah yang membuat panggilan konteks panjang yang berulang secara ekonomi benar-benar mungkin dilakukan.

Titik impas yang tepat

Asumsikan sebuah prefiks berisi P token yang digunakan kembali di seluruh N panggilan, dan untuk sementara abaikan output.

• Tanpa caching: N × P × $1.00.

• Dengan caching: satu penulisan sebesar $1.25 × P, lalu N pembacaan sebesar $0.05 × P.

Menyamakan keduanya: 0,95N = 1,25, sehingga N ≈ 1,32. Dalam praktiknya, itu berarti panggilan kedua sudah menguntungkan: penulisan berbiaya 1,25 per juta dan setiap pembacaan menghemat 0,95, sehingga dua pembacaan menutup lebih dari biaya penulisan. Dengan retensi 12 jam, biaya penulisan adalah $2,50 dan titik impasnya adalah 2,63 pembacaan — panggilan ketiga yang membayarnya.

Ambang itu lebih rendah daripada yang diasumsikan sebagian besar tim. Mitos umumnya adalah bahwa caching hanya menguntungkan untuk penggunaan ulang yang sangat tinggi; pada kartu ini, caching sudah menguntungkan mulai dari permintaan kedua, asalkan prefiksnya benar-benar cocok.

Tiga beban kerja

Prompt sistem 50.000 token untuk 10.000 permintaan singkat. Tanpa cache: 10.000 × 50.000 × $1,00 per juta = $500 hanya untuk prefiks. Dengan cache: satu penulisan 50.000 × $1,25 per juta = $0,0625, ditambah 10.000 pembacaan sebesar 50.000 × $0,05 per juta = $25. Total $25,06 — penghematan 95% pada prefiks, dan penulisan cache hanyalah kesalahan pembulatan.

Repositori 900.000 token untuk 20 pertanyaan. Tanpa cache, setiap permintaan kena tarif konteks panjang: 900.000 × $2,00 per juta = $1,80 per panggilan, $36 untuk dua puluh panggilan. Dengan cache: sekali tulis 900.000 × $2,50 per juta = $2,25, lalu dua puluh baca pada 900.000 × $0,10 per juta = $0,09 per baca, total $1,80. Total $4,05 — penghematan 89%, dan selisih delapan belas dolar itu adalah seluruh margin pada sebagian produk.

Dokumen 20.000 token yang mencakup tiga pertanyaan, masing-masing dengan persona dan instruksi berbeda. Inilah kasus ketika caching gagal: jika prefiks berubah antar panggilan — system prompt berbeda, urutan instruksi berbeda, ID pengguna yang diinterpolasi di bagian atas — model melihat tiga prefiks berbeda dan menulis tiga cache. Biaya uncached dan "cached" sama, kecuali Anda membayar untuk penulisan. Perbaikannya bersifat struktural: letakkan semua yang variabel di akhir prompt, dan pertahankan dokumen serta instruksi stabil di depan.

Apa yang merusak cache/p> p>Prompt caching OpenAI bekerja pada prefiks permintaan yang tidak berubah. Apa pun yang berubah di bagian awal prompt membuat semua yang setelahnya menjadi tidak valid. Penyebab utamanya:/p> p>• Stempel waktu atau ID permintaan di prompt sistem. Ini adalah penyebab paling umum dari tingkat cache hit 0%./p> p>• Personalisasi per pengguna yang disisipkan di bagian atas, bukan di bagian bawah./p> p>• Definisi tool yang diurutkan ulang atau daftar tool yang berubah antar panggilan./p> p>• Langkah retrieval yang menggabungkan dokumen dalam urutan yang berbeda setiap kali./p> p>• Perubahan whitespace dari mesin templating — memformat ulang blok JSON saja sudah cukup./p> p>• Beralih antara Chat Completions dan Responses di tengah pipeline, yang mengubah prefiks terserialisasi./p> p>Diagnostiknya sederhana: catat 2.000 token pertama dari setiap permintaan dan hash token tersebut. Jika hash berubah antar panggilan yang seharusnya identik, cache sudah mati dan tidak ada penyetelan sebanyak apa pun yang dapat menghidupkannya kembali./p> h2>Cache dan jurang 272K

Keduanya saling berinteraksi dengan cara yang mudah terlewat. Prefiks ter-cache 250.000 token dikenai biaya $0,05 per juta untuk dibaca dan $1,25 untuk ditulis. Naikkan menjadi 300.000 token dan setiap angka berlipat dua: $0,10 untuk baca, $2,50 untuk tulis, dan bagian yang tidak ter-cache ditagih sebesar $2,00. Pipeline yang melewati ambang batas membayar lonjakan biaya di sisi ter-cache maupun tidak ter-cache.

Ini menciptakan insentif desain yang tidak terlihat jelas: jika beban kerja berada tepat di atas 272K, menyusutkan prefiks menjadi 270K dapat memangkas tagihan hingga setengahnya tanpa mengubah tugas. Memangkas bagian boilerplate, menghapus blok retrieval yang tidak diperlukan, atau memindahkan contoh keluar dari prompt sistem lebih bernilai di batas tersebut daripada di tempat lain mana pun pada kartu.

Caching versus alternatifnya

• Caching — paling baik saat prefiks panjang yang sama digunakan berulang kali dalam jendela retensi, dan prefiks tersebut benar-benar stabil.

• Chunking — paling cocok ketika dokumen besar tetapi setiap pertanyaan hanya menyentuh sebagian kecil; pengambilan lebih murah daripada mengirim 900K token bahkan pada tarif yang di-cache.

• Batch/Flex — diskon 50% dari tarif standar, tetapi latensi batch diukur dalam hitungan jam; dapat dikombinasikan dengan caching, bukan dengan produk real-time.

• Model yang lebih murah — GPT-6 Luna dengan $0.10/$0.50 dapat mengalahkan tarif cache Terra untuk tugas sederhana, karena input non-cache Luna hanya dua kali input cache Terra.

Perbandingan terakhir adalah yang sering tim lupakan. Caching adalah diskon pada Terra, bukan jaminan bahwa Terra adalah cara termurah untuk menjawab sebuah pertanyaan. Untuk klasifikasi atas prompt 50.000 token, Luna yang di-cache dengan $0,01 per juta pembacaan tetap menjadi pilihan yang lebih murah jika tugasnya cukup sederhana.

Apa yang dapat Anda jalankan hari ini

GPT-6.1 Terra tidak ada dalam katalog OrcaRouter pada saat penulisan ini, sehingga perilaku cache-nya harus diukur langsung terhadap OpenAI. Model-model yang sudah tersedia — GPT-6.1 Sol seharga $2/$10 dengan tarif cache $0.10, GPT-5.6 Terra seharga $2/$12 dengan $0.20, GPT-6 Luna seharga $0.10/$0.50 — semuanya dapat diuji dengan satu kunci pada markup 0% di atas harga daftar penyedia.

Pengukuran yang perlu dibangun bukanlah "apakah caching berfungsi" — memang berfungsi — melainkan "berapa fraksi trafik saya yang memiliki prefiks stabil". Fraksi itulah satu-satunya angka yang menentukan apakah pembacaan lima sen Terra berdampak pada tagihan Anda, dan itu adalah properti dari prompt Anda, bukan dari model.