Routing Multi-Model untuk Coding Agent: Kapan Hemat?

Dampak routing multi-model terhadap coding agent

Routing multi-model mengirim setiap permintaan ke model termurah yang mampu menanganinya. Pada trafik chat, pendekatan ini bekerja dengan baik. Pada coding agent, pendekatan ini biasanya menghabiskan biaya lebih besar daripada penghematannya. Penyebabnya, sebagian besar biaya agent berasal dari awalan prompt yang di-cache per model. Saat model diganti, cache tersebut terbuang.

Aturan yang dikemukakan dalam artikel ini: lakukan routing lintas provider untuk ketersediaan, lakukan routing lintas tier untuk menghemat biaya hanya pada batas antar-task, dan tetapkan satu model per session untuk semua penggunaan agentic. Semua penjelasan berikut mendasari aturan tersebut.

Empat istilah berikut didefinisikan satu kali. Router memilih model untuk setiap permintaan. Gateway adalah proxy yang dilalui permintaan, yang dapat melakukan routing atau tidak. Prompt cache adalah penyimpanan provider untuk prefix prompt yang telah diproses. Dengan demikian, permintaan berikutnya yang mengulang prefix tersebut dikenai biaya sebesar sebagian kecil dari harga input. KV cache (key value cache) menggunakan gagasan yang sama di dalam server yang Anda jalankan sendiri.

Mengapa trafik chat dapat dirutekan dengan baik, tetapi trafik agen tidak

Satu permintaan chat terdiri dari satu giliran. Permintaan tiba, diklasifikasikan, dikirim ke model, lalu hasilnya dikembalikan. Tidak ada informasi yang diteruskan ke permintaan berikutnya. Router dapat mengirim pertanyaan ini ke model kecil dan pertanyaan berikutnya ke model besar. Tidak satu pun dari kedua permintaan tersebut mengetahui bahwa permintaan lainnya pernah terjadi. Inilah beban kerja yang diukur oleh hampir semua benchmark routing, dan router yang baik memang mampu menanganinya.

Satu giliran agen bukan satu permintaan. Satu instruksi seperti "perbaiki pengujian yang gagal" dapat menjadi dua puluh hingga enam puluh panggilan API. Setiap panggilan mengirim ulang seluruh percakapan: system prompt, setiap definisi tool, setiap file yang telah dibaca agen, dan setiap output perintah yang telah dilihatnya. Context terus bertambah. Pada panggilan ketiga puluh, prefix yang diulang dapat mencapai puluhan ribu token, sedangkan konten baru yang benar-benar ditambahkan pada setiap panggilan hanya beberapa ratus token.

Pola ini mengubah makna kata "mahal". Dalam chat, biaya kurang lebih merupakan harga model dikalikan jumlah permintaan. Dalam loop agen, biaya berasal dari prefix yang ditagihkan ulang pada setiap panggilan. Seluruh isi tulisan ini merupakan konsekuensi dari satu fakta tersebut.

Cache prompt bersifat spesifik untuk setiap model, dan agen berada di dalamnya

Anthropic menetapkan harga pembacaan cache sebesar 0.1 kali harga input dasar, serta penulisan cache lima menit sebesar 1.25 kali harga tersebut. Ini adalah harga daftar yang dipublikasikan per Agustus 2026.

[
  {
    "label": "Opus 5",
    "uncached_input_usd": "5.00",
    "cache_read_usd": "0.50"
  },
  {
    "label": "Sonnet 5",
    "uncached_input_usd": "2.00",
    "cache_read_usd": "0.20"
  },
  {
    "label": "Haiku 4.5",
    "uncached_input_usd": "1.00",
    "cache_read_usd": "0.10"
  }
]

Bandingkan rangkaian kedua dengan rangkaian pertama secara mendatar, bukan ke bawah. Pembacaan cache pada Opus 5 berharga 0.50 dolar per satu juta token. Input tanpa cache pada Haiku 4.5, model termurah dalam daftar, berharga 1.00 dolar. Jadi, membaca ulang prefix yang masih tersimpan pada model termahal membutuhkan biaya per token input yang lebih rendah daripada membaca prefix yang sama tanpa cache pada model termurah.

Satu perbandingan ini membatalkan sebagian besar rencana routing. Router yang memindahkan pekerjaan "ke bawah" dalam suatu tier sedang membandingkan harga daftar. Namun, agen yang berada di tengah sesi tidak membayar harga daftar untuk model yang sedang digunakannya. Agen tersebut membayar harga pembacaan cache, yang sudah lebih rendah daripada tarif input tanpa cache pada model murah.

Cache menggunakan hash dari prefix prompt sebagai kunci, dan cache bersifat spesifik untuk setiap model. Permintaan ke model lain dihitung hash-nya terhadap penyimpanan yang belum pernah melihatnya, sehingga tidak menemukan apa pun dan membayar harga penuh. Cache juga memiliki hierarki: tools terlebih dahulu, lalu system, kemudian messages. Perubahan pada tingkat mana pun membatalkan tingkat tersebut dan semua tingkat setelahnya. Artinya, mengedit satu definisi tool membuang cache system prompt yang berada di belakangnya. Agen yang mendaftarkan tools saat runtime dapat mengalami hal ini tanpa router perlu melakukan apa pun.

Biaya nyata dari satu kali perpindahan di tengah sesi

Gunakan sesi dengan prefiks stabil sepanjang 40,000 token. Ini adalah ukuran yang umum setelah agen membaca beberapa file. Berikut biaya prefiks untuk satu giliran, yang dihitung dari harga daftar di atas.

[
  {
    "label": "Opus 5, cache warm",
    "prefix_cost_usd": "0.020"
  },
  {
    "label": "Sonnet 5, turn after switch",
    "prefix_cost_usd": "0.100"
  },
  {
    "label": "Opus 5, cache re-warmed",
    "prefix_cost_usd": "0.250"
  }
]

Tetap menggunakan Opus 5 dengan cache yang masih hangat memerlukan biaya 0.020 dolar untuk prefiks giliran tersebut. Giliran pertama setelah perutean dialihkan ke Sonnet 5 memerlukan biaya 0.100 dolar, karena Sonnet belum memiliki entri untuk prefiks ini dan harus menulisnya. Kembali ke Opus 5 memerlukan biaya 0.250 dolar, karena entri asli telah kedaluwarsa selama sesi menggunakan model lain.

Jadi, perjalanan pulang-pergi tersebut membayar dua penulisan cache untuk menghindari dua pembacaan cache. Sebagai gantinya, perpindahan ini menghasilkan satu giliran output dengan harga output Sonnet, bukan harga output Opus. Blok detail berikut menghitung seluruh perjalanan: penghematannya hanya sepersekian sen, sedangkan penalti cache mencapai puluhan sen. Penalti tersebut lebih besar dengan selisih lebih dari satu orde besaran. Penalti juga bertambah seiring panjang prefiks, sedangkan penghematan tidak.

Opus 5, warm read     40,000 x $0.50 / 1e6  = $0.020
Sonnet 5, cache write 40,000 x $2.50 / 1e6  = $0.100   (1.25 x $2 base)
Opus 5, cache write   40,000 x $6.25 / 1e6  = $0.250   (1.25 x $5 base)

800 x ($25 - $10) / 1e6 = $0.012

Format pemanggilan alat tidak sama di setiap penyedia

Agen bekerja dalam loop pemanggilan alat, sehingga format pemanggilan alat menjadi penting, berbeda dari chat. Messages API milik Anthropic mengembalikan blok konten tool_use dan mengharapkan blok tool_result sebagai respons. API yang kompatibel dengan OpenAI mengembalikan array tool_calls, yang di dalamnya function.arguments merupakan string berkode JSON, bukan objek bertingkat. Gateway menerjemahkan kedua format tersebut, dan untuk pemanggilan biasa hasil terjemahannya berjalan baik.

Masalah muncul pada kasus-kasus tertentu. Pemanggilan alat secara paralel, yaitu ketika model menghasilkan beberapa pemanggilan dalam satu respons, direpresentasikan secara berbeda dan tidak didukung dengan cara yang sama di semua tempat. Penerapan skema ketat merupakan fitur khusus setiap penyedia. Karena itu, model yang menjamin argumen sesuai skema pada satu endpoint hanya cenderung menghasilkan argumen yang valid pada endpoint lain. Agen melihat perbedaan ini sebagai hasil alat yang berisi error penguraian, lalu mencoba memperbaikinya dengan menggunakan giliran tambahan. Giliran perbaikan tersebut ditagihkan dengan harga prefix penuh. Akibatnya, ketidakcocokan format terlihat pada tagihan dan transkrip.

Endpoint yang di-host sendiri memerlukan konfigurasi eksplisit. Server yang kompatibel dengan OpenAI milik vLLM memerlukan --enable-auto-tool-choice bersama --tool-call-parser yang sesuai dengan keluarga model (hermes, mistral, llama3_json, dan lainnya), serta chat template yang menangani pesan dengan peran tool. Dokumentasi vLLM menjelaskan batasan jalur ini secara langsung: dengan tool_choice="auto" dan tanpa batasan skema yang ketat, vLLM mengekstrak pemanggilan alat dari teks mentah. Karena itu, argumen terkadang dapat memiliki format yang salah atau melanggar skema parameter fungsi. Memilih parser yang salah untuk model Anda merupakan kesalahan konfigurasi yang tampil sebagai agen yang tidak dapat memanggil alat. Hal ini perlu diketahui sebelum Anda mengarahkan trafik ke endpoint tersebut. Perbedaan antara Ollama dan vLLM untuk menjalankan model sendiri relevan di sini karena keduanya menyediakan pemanggilan alat dengan ketentuan yang berbeda.

Fallback di tengah tugas mengubah perilaku tanpa error

Routing fallback adalah fitur yang paling mungkin diaktifkan secara tidak sengaja. Gateway dikonfigurasi untuk mencoba model lain ketika model pertama mengembalikan rate limit atau error 5xx, lalu menempatkan model yang gagal dalam masa cooldown selama beberapa detik. Pada trafik chat, perilaku ini tepat. Dalam tugas agen yang panjang, paruh kedua tugas dapat berjalan pada model yang tidak Anda pilih.

Tidak ada komponen yang melaporkan perubahan ini. Tugas tidak gagal, agen tidak memberikan peringatan, dan exit status bernilai sukses. Hasilnya adalah tugas yang rencananya ditulis oleh satu model, tetapi pengeditannya dilakukan oleh model lain, dengan gaya bahasa dan kebiasaan yang berubah di tengah proses. Satu-satunya sinyal yang dapat diandalkan adalah field model pada log request gateway atau metadata respons. Karena itu, jika Anda menggunakan fallback, catat field tersebut untuk setiap request dan periksa nilainya ketika hasil tidak sesuai dugaan. Men-debug perilaku tanpa mengetahui model yang menghasilkan output akan menghabiskan lebih banyak waktu daripada waktu yang dihemat oleh fallback.

Jebakan yang sama juga berlaku pada kompresi konteks. Banyak agen merangkum riwayat yang panjang dengan memanggil model berukuran kecil. Jika pemanggilan tersebut menggunakan model atau system prompt yang berbeda, pemanggilan itu menulis cache entry sendiri dan tidak memperbarui cache milik sesi utama. Akibatnya, turn lengkap berikutnya harus memproses ulang prefix dari kondisi cold. Kompresi memang menghemat token, tetapi cache menjadi tidak terpakai.

Overhead routing itu nyata, tetapi latensi bukan sumber masalahnya

Router memang menambahkan pekerjaan pada setiap permintaan, dan penting untuk memahami besarnya secara akurat. DigitalOcean melaporkan bahwa model Arch-Router mereka menentukan tujuan routing dalam sekitar 51 milidetik, dengan akurasi routing 93.17% berdasarkan evaluasi mereka sendiri. Angka tersebut berasal dari pengukuran dan benchmark mereka, bukan dari kami dan bukan hasil yang berlaku secara universal. Jika angka itu diterima apa adanya, kesimpulannya cukup meyakinkan: 51 milidetik pada empat puluh pemanggilan agen menambahkan sekitar dua detik pada tugas yang berjalan selama beberapa menit.

Dua detik bukan faktor yang membuat routing mahal dalam konteks ini. Overhead yang benar-benar berdampak adalah router yang melakukan klasifikasi dengan pemanggilan model penuh, karena itu berarti ada inferensi kedua pada setiap permintaan, yang ditagihkan dan diantrekan seperti pemanggilan lainnya. Di bawah kedua hal tersebut terdapat perhitungan cache di atas, yang sama sekali bukan overhead. Perhitungan itu adalah biaya dari hal yang seharusnya dioptimalkan oleh routing.

Pada server yang Anda kelola sendiri, aturan yang sama berlaku dengan ruang optimasi yang lebih terbatas. Padanan lokal untuk prompt cache adalah caching prefix pada KV cache, yang berada di memori GPU. Menjalankan dua model pada satu GPU membagi memori tersebut di antara keduanya, sehingga masing-masing model memiliki KV cache yang lebih kecil dan lebih cepat mengeluarkan prefix dari cache. Karena itu, routing di antara dua model lokal dapat menurunkan cache hit rate keduanya sekaligus. Jika Anda sedang menentukan kebutuhan hardware untuk ini, memori dan CPU yang sebenarnya dibutuhkan coding agent pada VPS adalah titik awal yang lebih berguna daripada router.

Aturan keputusan

• Arahkan lintas provider untuk ketersediaan. Jika alternatifnya adalah request yang gagal, biaya apa pun merupakan biaya yang tepat. Tetapkan fallback ke model dengan format tool call yang sama agar loop agent tetap berjalan, lalu catat model yang melayani setiap call.
• Arahkan lintas tier hanya pada batas tugas. Memilih Haiku untuk mengganti nama dan Opus untuk refactor merupakan keputusan yang baik jika dibuat sekali, sebelum sesi dimulai. Keputusan yang sama menjadi buruk jika dibuat pada turn tiga puluh dalam sesi tersebut.
• Tetapkan satu model per sesi untuk semua hal yang bersifat agentic. Nilai sebuah sesi terletak pada cache hangatnya. Perlakukan pergantian model seperti menghapus cache tersebut, karena itulah yang terjadi.
• Arahkan subagent secara bebas. Subagent yang dimulai dengan context baru dan kecil tidak memiliki cache hangat yang dapat hilang, sehingga dapat berjalan pada model apa pun yang sesuai dengan tugasnya. Inilah satu-satunya tempat di dalam agent yang routing-nya hampir tanpa biaya.

Untuk membangun konfigurasi ini, gateway yang menangani pekerjaan tersebut: alias model dan daftar fallback eksplisit. Berikut konfigurasi proxy LiteLLM minimal.

model_list:
  - model_name: agent-primary
    litellm_params:
      model: anthropic/claude-opus-5
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: agent-standby
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY

router_settings:
  fallbacks: [{"agent-primary": ["agent-standby"]}]
  num_retries: 2
  cooldown_time: 30

Arahkan agent ke agent-primary agar agent tetap menggunakan satu model sampai model tersebut tidak dapat dijangkau. Kedua entri menggunakan provider yang sama, sehingga format tool call tidak berubah saat fallback aktif. Anda tetap menerima perubahan tier pada saat itu. Perubahan tersebut layak dilakukan hanya karena alternatifnya adalah request yang gagal. Ini adalah routing untuk ketersediaan tanpa routing untuk biaya, yaitu kombinasi yang paling sering dibutuhkan coding agent. Implementasi lengkapnya, termasuk key dan budget, dibahas dalam menjalankan gateway LiteLLM yang di-host sendiri pada VPS milik Anda, dan tulisan ini sengaja tidak mengulanginya.

Ketika satu model yang dipilih dengan tepat mengungguli router mana pun

Routing digunakan untuk mengatasi variasi tingkat kesulitan permintaan. Variasi tersebut pada coding agent tidak sebesar yang terlihat, karena bagian mahal dalam setiap pemanggilan selalu berupa prefix yang sama, apa pun permintaannya. Setelah prefix mendominasi, perbedaan antara tier murah dan tier mahal Anda menyusut hingga mendekati perbedaan harga output, sedangkan output hanya mencakup sebagian kecil token agent.

Jadi, pilihan default yang tepat adalah satu model yang dipilih sekali, dengan caching diaktifkan dan TTL (time to live) yang cukup panjang untuk mencakup jeda saat Anda berhenti membaca diff. Anthropic menawarkan penulisan cache selama satu jam dengan biaya 2 kali input dasar. Biaya tersebut tertutupi setelah dua kali pembacaan. Langkah ini sering lebih efektif daripada router apa pun. Pilih tier secara sengaja menggunakan perbandingan langsung Opus, Sonnet, dan Haiku, lalu jika tagihan masih menjadi masalah, kurangi biayanya dengan budget dan context yang lebih kecil seperti dalam mengendalikan biaya AI agent pada VPS, bukan dengan mengganti model di tengah sesi.

Gunakan routing jika permintaan bersifat independen dan singkat, atau jika subagent memulai dengan context baru. Tetapkan satu model jika Anda memiliki satu sesi panjang untuk mengerjakan satu tugas. Sebagian besar pekerjaan coding agent termasuk jenis kedua. Karena itu, router yang menghemat biaya pada produk chat Anda justru dapat diam-diam menambah biaya di sini. Jika Anda belum menentukan agent yang akan digunakan, perbandingan Claude Code dengan Cursor, Codex, dan Copilot menjelaskan cara setiap agent menangani pemilihan model. Beberapa di antaranya membuat keputusan ini untuk Anda.

FAQ

Apakah pergantian model di tengah sesi benar-benar menghilangkan cache prompt?

Ya. Cache prompt menggunakan hash awalan prompt sebagai kunci dan disimpan per model. Karena itu, permintaan yang dikirim ke model lain akan dicocokkan dengan penyimpanan yang belum pernah menerima awalan tersebut. Tidak ada entri yang ditemukan, sehingga Anda membayar harga input tanpa cache secara penuh. Jika caching diaktifkan, Anda juga membayar biaya penulisan cache. Beralih kembali tidak memulihkan entri asli karena masa berlaku default lima menit biasanya sudah berakhir. Periksa field cache_read_input_tokens dan cache_creation_input_tokens dalam objek penggunaan respons. Pada sesi panjang, giliran yang membaca nol token cache merupakan gejalanya.

Apakah merutekan permintaan ke model yang lebih murah pernah menghemat biaya untuk agent?

Hanya jika tidak ada cache hangat yang hilang. Pembacaan cache pada Anthropic dikenai biaya 0.1 kali input dasar. Dengan demikian, pembacaan cache hangat pada Opus 5 lebih murah daripada tarif input tanpa cache pada Haiku 4.5. Setelah sesi memiliki awalan yang besar dalam cache, model yang sedang digunakan sudah menjadi pilihan murah untuk input. Perutean menghemat biaya ketika konteks masih baru dan kecil, misalnya pada awal tugas atau pada subagent yang hanya membawa konteks yang diperlukan.

Mengapa agent saya berperilaku berbeda di tengah tugas?

Periksa apakah fallback gateway aktif. Batas laju atau respons 5xx pada model utama membuat gateway mencoba ulang dengan model siaga dan menempatkan model utama dalam cooldown selama beberapa detik. Akibatnya, sisa tugas berjalan pada model lain. Kondisi ini tidak menghasilkan error atau peringatan, dan tugas tetap melaporkan keberhasilan. Field model dalam log permintaan gateway atau metadata respons merupakan satu-satunya catatan yang andal. Karena itu, catat field tersebut untuk setiap permintaan jika Anda menggunakan fallback.

Apakah pemanggilan tool bekerja dengan cara yang sama pada semua provider?

Tidak sepenuhnya. Messages API milik Anthropic menggunakan blok konten tool_use dan tool_result, sedangkan API yang kompatibel dengan OpenAI menggunakan array tool_calls yang function.arguments-nya berupa string berkode JSON. Gateway menerjemahkan kasus umum dengan baik, tetapi pemanggilan tool paralel dan penegakan skema ketat berbeda-beda menurut provider. Pada vLLM yang di-host sendiri, Anda harus menetapkan --enable-auto-tool-choice dan --tool-call-parser yang sesuai dengan keluarga model Anda. Dokumentasi vLLM mencatat bahwa tanpa batasan skema ketat, server mengekstrak pemanggilan tool dari teks mentah. Karena itu, argumen sesekali dapat memiliki format yang tidak valid.

Berapa lama TTL cache sebaiknya ditetapkan untuk sesi coding?

Gunakan masa berlaku default lima menit untuk pekerjaan berkelanjutan. Gunakan opsi satu jam ketika manusia membaca diff di antara giliran. Anthropic menetapkan biaya penulisan lima menit sebesar 1.25 kali input dasar dan penulisan satu jam sebesar 2 kali, sedangkan pembacaan dikenai biaya 0.1 kali. Biaya penulisan lima menit tertutup oleh satu kali pembacaan, sedangkan penulisan satu jam tertutup oleh dua kali pembacaan. Jadi, pada sesi yang kemungkinan akan dilanjutkan setelah jeda, masa berlaku yang lebih panjang biasanya lebih murah daripada membayar awalan yang tidak tersimpan di cache.