Cost management — token, caching, model routing

Server biasa punya biaya yang relatif stabil. Biaya API LLM bertambah setiap token yang dikirim dan diterima — riwayat chatbot yang terus dikirim ulang (Fase 6) berarti biaya per percakapan bisa naik terus tanpa disadari.

Biaya bertambah per token, bukan per bulan

Server tradisional punya biaya yang relatif tetap (harga instance per jam). Biaya LLM API bertambah linear dengan pemakaian — setiap token input dan output punya harga sendiri, biasanya output lebih mahal dari input. Chatbot yang riwayatnya (Fase 6) terus dikirim ulang tiap turn berarti kamu membayar ulang token yang sama, berkali-kali, sepanjang percakapan.

Percakapan dengan 10 turn, riwayat terus bertambah tanpa dipangkas:
Turn 1:  100 token riwayat dikirim
Turn 2:  250 token riwayat dikirim  (turn 1 dikirim ULANG + pesan baru)
Turn 3:  450 token riwayat dikirim  (turn 1-2 dikirim ULANG + pesan baru)
...
Turn 10: 2000+ token riwayat dikirim setiap kali

Total token yang DIBAYAR sepanjang 10 turn jauh lebih besar dari total token PERCAKAPAN itu sendiri.

Prompt caching: membayar lebih murah untuk bagian yang berulang

Kalau sebagian besar prompt sama persis dari satu panggilan ke panggilan berikutnya — system prompt yang panjang, atau riwayat percakapan yang stabil — provider bisa meng-cache bagian itu, dan panggilan berikutnya membayar jauh lebih murah untuk token yang sudah pernah diproses.

response = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=1024,
    system=[{
        "type": "text",
        "text": instruksi_panjang_dan_konteks_perusahaan,  # ribuan token, sama di setiap panggilan
        "cache_control": {"type": "ephemeral"},  # tandai bagian ini untuk di-cache
    }],
    messages=riwayat_percakapan,
)

Model routing: jangan pakai model termahal untuk semuanya

Ingat dari Fase 6: query rewriting memakai model kecil (Haiku) karena tugasnya sederhana, sementara jawaban final ke pengguna memakai model yang lebih mampu. Ini pola umum yang layak diterapkan sengaja di seluruh sistem:

Jangan kirim token yang tidak perlu

• Potong konteks RAG ke jumlah chunk yang benar-benar dipakai (Fase 5) — mengirim 20 chunk "untuk jaga-jaga" membayar token yang sebagian besar tidak relevan.
• Set max_tokens realistis — nilai yang terlalu besar tidak menambah biaya kalau modelnya berhenti lebih awal, tapi nilai yang jauh melebihi kebutuhan sering menandakan output yang bertele-tele juga tidak dibatasi di prompt.
• Ringkas riwayat panjang (Fase 3, 6) — selain mengatasi context window, ini juga langsung memangkas biaya per turn.

Pasang budget alert sejak hari pertama

Sama seperti pelajaran dari akun cloud (budget alert AWS): pasang batas anggaran & alert di dashboard provider LLM sebelum trafik nyata masuk, dan pertimbangkan batas biaya per pengguna/percakapan di level aplikasi (mis. hentikan agent kalau sudah menghabiskan lebih dari X token dalam satu sesi — pengaman yang sama dari Fase 3).