Cara Audit Biaya Token Agent per Tugas (Bukan Cuma Tagihan Bulanan)

Biaya token agent bisa diaudit per tugas kalau lo menyimpan empat angka untuk tiap panggilan model: input token, output token, cache read, dan cache write, ditambah harga satuan model saat panggilan itu terjadi. Tanpa itu, yang lo punya cuma tagihan bulanan gabungan, dan tagihan gabungan tidak bisa menunjukkan tugas mana yang boros. Taruhannya besar: dari 436 model berharga di dump OpenRouter pada 8 November 2026, harga input bergerak dari 0,006 sampai 30 dolar per juta token, output dari 0,03 sampai 180 dolar per juta token.

TL;DR

• Audit per tugas butuh 4 angka per panggilan: input, output, cache read, cache write, plus snapshot harga.
• Rasio output terhadap input tidak seragam: Claude Sonnet 4.5 sekitar 5x, DeepSeek V4.1 Flash sekitar 11x, jadi satu angka “biaya per token” selalu salah.
• Harga satuan bisa berubah karena panjang konteks: Qwen3.7 Flash naik 3,3x begitu prompt lewat 32 ribu token.
• Tanpa cache, biaya loop agent tumbuh kuadratik terhadap jumlah langkah, bukan linier.
• Yang dipakai untuk menghitung biaya harus angka dari provider, bukan estimasi tokenizer lokal.

Kenapa biaya token agent susah dihitung per tugas?

Karena satu tugas biasanya berisi puluhan panggilan model, dan setiap panggilan membawa ulang seluruh riwayat percakapan sebagai input. Panggilan pertama mengirim 2 ribu token, panggilan kedua 4 ribu, panggilan kedua puluh 40 ribu. Jumlahkan semuanya: tugas 20 langkah dengan riwayat rata-rata 1,5 ribu token per langkah mendekati 315 ribu token input, bukan 30 ribu. Pertumbuhan kuadratik itu yang bikin tagihan membengkak tanpa kelihatan di grafik harian.

Masalah kedua: satuan harganya tidak seragam. Tiga model harian untuk kerja agent, angka dari dump https://openrouter.ai/api/v1/models pada 8 November 2026:

Model                    Input/M   Output/M   Rasio out:in   Cache read/M
deepseek/deepseek-v4.1-flash   $0,051   $0,567   11,1x          $0,018
z-ai/glm-5.3-flash             $0,0335  $0,083   2,5x           $0,030
anthropic/claude-sonnet-4.5    $3,00    $15,00   5,0x           $0,30

Lihat baris kedua dan ketiga. Output GLM 5.3 Flash 180x lebih murah dari Sonnet 4.5, tapi input-nya cuma 90x lebih murah. Kalau audit lo mencampur semua model ke satu rata-rata “biaya per 1.000 token”, hasilnya tidak mewakili apa pun. Simpan biaya per panggilan, baru agregasikan.

Dari mana angka biaya yang boleh dipercaya?

Dari respons provider itu sendiri, karena provider yang menagih juga yang menghitung. Di OpenCrabs, angka usage dari gateway yang menagih dalam dolar (contohnya usage.cost OpenRouter atau LiteLLM) ditulis langsung ke ledger sebagai nilai final, sementara tabel harga lokal cuma dipakai saat provider tidak melaporkan biaya. Tabel harga itu tebakan lo soal invoice, angka provider itu invoice-nya.

Kalau membangun sendiri, ikuti pola yang sama. Standar OpenTelemetry untuk generative AI sudah punya nama metrik yang jelas. Di dokumen semantic conventions token metrics, counter gen_ai.client.inference.usage.input_tokens dan output_tokens dipakai untuk konsumsi dan aproksimasi biaya, sedangkan histogram gen_ai.client.inference.operation.input_tokens dinyatakan tidak boleh dipakai untuk total maupun kalkulasi biaya, fungsinya cuma melihat p95 dan outlier. Banyak dashboard buatan sendiri terbalik: histogram dipakai menjumlahkan biaya, lalu heran kenapa tidak cocok dengan invoice.

Untuk hitungan token di sisi klien, tiktoken masih jadi acuan de facto untuk model keluarga OpenAI (19.618 bintang per 7 November 2026), tapi jangan pakai tokenizer itu untuk semua model. Setiap keluarga model punya potongan token sendiri, dan selisih beberapa persen pada prompt 30 ribu token cukup untuk menggeser keputusan optimasi.

Untuk jalur klasifikasi dan routing, tier harga Qwen di Alibaba Cloud Model Studio sering jadi pembanding lebih murah. Yang penting bukan mereknya, tapi lo tahu harga satuan dan ambang konteks yang memicu kenaikan tarif.

Berapa harga token yang benar kalau konteksnya panjang?

Harga satuan bisa berubah di dalam satu model begitu prompt melewati ambang tertentu, dan ini yang paling sering luput dari audit. Qwen3.7 Flash dipatok 0,03 dolar per juta token input, tapi dump yang sama mencatat override: lewat 32 ribu token naik ke 0,10 dolar, lewat 256 ribu naik lagi ke 0,20 dolar. Output ikut naik dari 0,13 ke 0,40 lalu 0,80. Claude Sonnet 4.5 punya tier kedua juga: di atas 200 ribu token prompt, input jadi 6 dolar dan output 22,50 dolar per juta token.

Artinya tugas dengan model murah bisa empat kali lebih mahal dari tugas serupa hanya karena konteksnya menyeberang ambang. Audit yang menyimpan harga satuan per model tanpa panjang prompt saat itu tidak akan menemukan penyebabnya. Simpan juga prompt_tokens dan tier yang berlaku.

Kenapa tidak pakai model termurah saja? Karena murah di token belum tentu murah per tugas selesai. Model yang gagal di percobaan pertama memaksa retry, dan retry membawa seluruh riwayat lagi. Biaya per tugas selesai jauh lebih jujur daripada biaya per seribu token.

Bagaimana membagi biaya per tugas, bukan per bulan?

Caranya: beri setiap tugas satu identitas, tempelkan ke tiap panggilan model, lalu disiplin mencatat empat kolom. Urutannya begini.

Langkah 1, bikin ledger per panggilan. Satu baris per request model, bukan per sesi. Kolom wajibnya: task_id, model, prompt_tokens, completion_tokens, cache_read_tokens, cache_write_tokens, cost, created_at. Tanpa task_id, audit cuma bisa menjawab “mahal”, bukan “mahal di mana”.

Langkah 2, simpan snapshot harga, jangan query harga saat laporan. Kalau laporan bulan lalu dihitung ulang dengan harga hari ini, angkanya berubah sendiri dan periode tidak bisa dibandingkan. Simpan harga satuan yang berlaku di baris ledger saat panggilan terjadi. Untuk gateway yang melaporkan biaya sendiri, simpan angka gateway dan tandai sumbernya, jangan dihitung ulang pakai tabel lokal. Contoh gateway yang menyajikan tagihan per request adalah NgodeAI.

Langkah 3, hitung biaya dengan aritmetika yang benar. Rumusnya bukan total_token x harga, tapi empat suku terpisah:

biaya = prompt_tokens/1e6       * harga_input
      + completion_tokens/1e6   * harga_output
      + cache_read_tokens/1e6   * harga_cache_read
      + cache_write_tokens/1e6  * harga_cache_write
      + biaya_tool_eksternal

Suku terakhir sering dilupakan. Pencarian web, OCR, dan tool berbayar lain menempel di tugas yang sama, dan kadang tagihan tool lebih besar dari tagihan token.

Langkah 4, perlakukan cache sebagai komponen tersendiri. Cache read bukan diskon otomatis, dia baris biaya dengan harga sendiri. Di OpenCrabs, usage_pricing.toml memakai default cache write 1,25x harga input dan cache read 0,1x, dan keduanya bisa diubah per model. Default itu gampang dicek silang: Claude Sonnet 4.5 di dump OpenRouter tercatat 3 dolar input, 3,75 cache write, 0,30 cache read per juta token, persis 1,25x dan 0,1x.

Efek cache ke biaya tugas lebih besar daripada yang biasanya diperkirakan. Simulasi loop 20 langkah dengan riwayat rata-rata 1,5 ribu token: total input sekitar 315 ribu token, output 8 ribu token, tarif Claude Sonnet 4.5.

Tanpa cache:      315k x $3,00/M  = $0,945   + 8k x $15/M = $0,120  -> $1,065
80% cache read:   252k x $0,30/M  = $0,076
                  63k  x $3,00/M  = $0,189   + 8k x $15/M = $0,120  -> $0,385

Selisihnya 0,68 dolar per tugas, turun sekitar 64 persen, dan itu baru satu tugas. Kalau agent lo jalan 200 tugas sebulan, selisihnya 136 dolar hanya dari satu keputusan desain: apakah prefix stabil dikirim dengan penanda cache atau tidak. Di instance yang gue pakai, satu sesi chat panjang mencatat 11 juta token input segar dan 62 juta token cache read, jadi cache read mendominasi volume.

Langkah 5, cocokkan ledger dengan invoice bulanan. Selisih di bawah 2 persen wajar, pembulatan. Selisih 10 persen ke atas berarti ada jalur tidak tercatat: retry tanpa ledger, request dari layanan lain, atau tool berbayar yang luput. Pemeriksaan termurah yang paling sering menemukan kebocoran.

Contoh query audit dari ledger lokal

Kalau agent lo menyimpan data di SQLite seperti OpenCrabs, audit per sesi bisa dijawab tanpa dashboard. Tabel messages punya kolom input_tokens, cache_read_tokens, cache_creation_tokens, dan cost, tabel sessions menyimpan token_count dan total_cost. Query berikut jalan apa adanya di ~/.opencrabs/opencrabs.db:

SELECT s.title, s.model,
       COUNT(m.id)                        AS langkah,
       SUM(COALESCE(m.input_tokens,0))    AS input_tok,
       SUM(COALESCE(m.cache_read_tokens,0)) AS cache_read,
       ROUND(SUM(COALESCE(m.cost,0)),4)   AS biaya
FROM sessions s JOIN messages m ON m.session_id = s.id
WHERE s.updated_at > strftime('%s','now') - 7*86400
GROUP BY s.id ORDER BY biaya DESC LIMIT 10;

Tiga hal langsung kelihatan dari hasil query itu. Sesi termahal hampir selalu sesi dengan langkah terbanyak, bukan model termahal. Rasio cache_read / input_tok menunjukkan apakah prompt caching benar-benar bekerja, rasio jauh di bawah 1 berarti prefix lo sering berubah. Sesi mahal dengan langkah sedikit biasanya berisi konteks besar yang dijejalkan sekaligus.

Kapan harus curiga angkanya salah?

Curigai ledger kalau muncul empat gejala ini. Biaya turun tiba-tiba tanpa perubahan model atau prompt, biasanya panggilan gagal tidak tercatat. Rasio cache read nol padahal provider mendukung cache, berarti penanda cache tidak terkirim. Biaya tool nol padahal tugas memanggil pencarian web atau OCR. Dan total ledger lebih kecil dari invoice provider, tanda ada request di luar jalur instrumentasi.

Ambang yang gue pakai sengaja kasar: selisih ledger versus invoice di atas 5 persen itu bug instrumentasi, dan biaya satu tugas yang naik lebih dari 2x dibanding median tugas sejenis itu regresi yang harus dijelaskan sebelum deploy berikutnya.

Rekomendasi Tools & Layanan

• OpenCrabs untuk contoh implementasi utuh: ledger token dan biaya, tabel harga di usage_pricing.toml, dashboard /usage yang memecah biaya per hari, proyek, provider, model, dan aktivitas. Repo: github.com/adolfousier/opencrabs.
• OpenTelemetry semantic conventions untuk standar metrik lintas vendor.
• OpenRouter models API untuk menarik harga satuan terbaru secara programatik.
• Alibaba Cloud untuk komputasi batch audit: halaman benefits Alibaba Cloud merangkum kredit dan paket untuk eksperimen biaya.

FAQ

Berapa angka minimal yang harus dicatat untuk audit biaya token?
Lima: input token, output token, cache read, cache write, dan biaya per panggilan. Tanpa cache read dan cache write, hitungan meleset jauh pada agent yang memakai prompt caching.

Apakah estimasi tokenizer lokal cukup untuk laporan biaya?
Tidak. Tokenizer lokal untuk estimasi sebelum request, pembukuan tetap pakai angka usage dari respons provider. Selisih beberapa persen per panggilan menumpuk jadi besar dalam sebulan.

Kenapa biaya satu tugas bisa naik tanpa ganti model?
Karena konteksnya menyeberang ambang harga. Qwen3.7 Flash naik dari 0,03 ke 0,10 dolar per juta token input begitu prompt lewat 32 ribu token, dan Claude Sonnet 4.5 berubah tarif di atas 200 ribu token.

Apakah prompt caching selalu menghemat?
Tidak. Cache write dibayar lebih mahal dari input biasa, sekitar 1,25x, jadi cache baru untung kalau prefix yang sama dipakai ulang. Prefix yang berubah tiap request justru menambah biaya.

Seberapa sering audit biaya sebaiknya dijalankan?
Mingguan untuk tren per tugas, bulanan untuk mencocokkan ledger dengan invoice provider.

Kesimpulan

Audit biaya token per tugas bukan soal dashboard mahal, tapi soal mencatat empat angka yang benar lalu menghitungnya dengan harga satuan yang berlaku saat itu. Tiga jebakan termahal: satu rata-rata harga untuk semua model, lupa harga berubah menurut panjang konteks, dan memperlakukan cache read sebagai bonus padahal dia baris biaya sendiri. Kalau ledger lo menyimpan input, output, cache read, cache write, dan biaya per panggilan, pertanyaan “tugas mana yang boros” dijawab satu query.