Framework Milih Model per Task: Berhenti Bayar Model Pinter Buat Kerjaan Bodoh

Pertanyaan yang paling sering masuk DM gue: "bang, buat agent bagusnya pake model apa?"

Salah pertanyaan. Itu kayak nanya "buat perusahaan bagusnya rekrut orang kayak apa?" Ya tergantung posisinya. Lo gak akan gaji senior engineer buat data entry, dan lo gak akan nyuruh anak magang mutusin arah perusahaan.

Model AI sama persis. Di sistem gue, 60+ agent jalan tiap hari di Mac mini, gak ada satu model tunggal. Ada router: satu layer kecil yang mutusin task ini dikirim ke model mana. Hasilnya: biaya turun drastis, dan kualitas justru NAIK, karena tiap task dipegang model yang emang cocok.

Tiga pertanyaan sebelum milih model

Sebelum mikir nama model, jawab tiga hal soal task-nya:

1. Seberapa jelas spec-nya? Task yang bisa lo tulis SOP-nya langkah demi langkah (rangkum artikel ini, ekstrak angka dari teks, format ulang data) = task mekanis. Task yang butuh judgment (keputusan arsitektur, diagnosa kenapa sistem error, review kualitas tulisan) = task mikir.

2. Seberapa mahal kalau salah? Salah rangkum satu berita di digest harian: gak ada yang mati, besok kebenerin. Salah diagnosa bug yang lagi live, atau salah nulis logic yang megang duit: mahal. Makin mahal konsekuensi salah, makin layak bayar model terbaik.

3. Seberapa sering jalan? Task yang jalan 50 kali sehari, selisih biaya per-call kecil pun jadi signifikan sebulan. Task yang jalan sekali seminggu, biaya per-call hampir gak relevan. Kualitas yang relevan.

Tiga tier yang gue pakai

Dari tiga pertanyaan itu, task jatuh ke salah satu dari tiga tier:

Tier 1. Volume/mekanis: model murah. Rangkum berita, klasifikasi konten, ekstraksi data, draft pertama konten volume tinggi, kerjaan coding yang scope-nya udah jelas banget. Ini 70-80% dari total call di sistem gue, dan semuanya jalan di model kelas menengah yang harganya sepersekian model flagship. Daily digest gue, pipeline konten harian, screener: semua tier ini.

Tier 2. Judgment: model terbaik yang lo mampu. Keputusan desain, diagnosa error yang gak jelas sumbernya, review akhir sebelum sesuatu di-publish, sintesis dari banyak sumber yang saling kontradiksi. Di sistem gue, slot ini dipegang Claude. Jumlah call-nya kecil, tapi ini call yang menentukan. Pelit di sini = penny wise pound foolish: satu diagnosa salah dari model murah bisa makan waktu lo berjam-jam, dan waktu lo itu biaya paling mahal di seluruh sistem.

Tier 3. Embedding & utility: lokal/gratis. Embedding buat semantic search, similarity check, klasifikasi super ringan. Gue jalanin model embedding lokal (bge-m3 via ollama) di Mac mini: biaya nol, jalan offline, dan buat use case ini kualitasnya udah cukup. Knowledge base 800+ halaman gue di-index pakai ini.

Plus satu aturan: selalu punya fallback. Router gue punya model cadangan kalau provider utama lagi down atau rate limited. Provider AI itu bukan infrastruktur yang gak pernah mati. Mereka mati justru pas lo lagi butuh.

Kesalahan umum yang gue liat (dan pernah gue lakuin)

Flagship buat semua. Awal-awal gue juga gini. Enak, kualitas konsisten. Terus tagihan bulanan dateng dan lo sadar 80% duitnya kepake buat task yang model setengah harga bisa kerjain sama bagusnya.

Murah buat semua. Kebalikannya lebih halus bahayanya: sistemnya "jalan", tapi kualitas output pelan-pelan turun, dan lo yang jadi quality control manual tiap hari. Lo hemat di API tapi bayar pakai waktu lo sendiri. Itu bukan otomatisasi.

Ganti-ganti model tanpa dicatat. Model baru rilis, lo langsung pindahin semua. Dua minggu kemudian ada yang aneh dan lo gak bisa jawab "ini gara-gara model baru atau emang bug?" Perlakuin ganti model kayak ganti karyawan: satu posisi dulu, dievaluasi, baru rollout.

Lupa itung biaya tersembunyi. Model "murah" yang outputnya harus lo revisi 30% itu lebih mahal dari model "mahal" yang outputnya langsung kepake. Hitung biaya per hasil jadi, bukan per call.

Cara mulai tanpa ribet

Gak perlu langsung bangun router canggih. Mulai dari sini:

1. List semua task AI lo sekarang, termasuk yang masih manual copy-paste ke ChatGPT.
2. Kasih label tiap task: mekanis / judgment / utility. Pakai tes SOP: bisa ditulis langkah-langkahnya dengan jelas? Mekanis.
3. Satu file config yang nge-map kategori task → model. Jangan hardcode nama model di tiap script. Pas mau ganti model, lo cuma edit satu tempat.
4. Catat pemakaian. Gak usah fancy, log biaya per agent per hari udah cukup buat liat mana yang boros.

Di sistem gue ini bentuknya satu file router yang semua agent lewatin. Ganti model buat satu kategori task = edit satu baris. Pas salah satu provider gue bermasalah bulan lalu, yang gue ubah cuma config fallback, 60+ agent lainnya gak disentuh.

Intinya

Model itu karyawan, bukan agama. Gak usah fanboy ke satu provider. Yang lo bangun adalah SISTEM yang bisa gonta-ganti karyawan tanpa bongkar kantor, karena model terbaik hari ini pasti kesalip 6 bulan lagi, dan lo mau posisi di mana upgrade itu tinggal edit config, bukan rewrite semua.

---

Arsitektur routing kayak gini, termasuk kapan pakai model lokal dan gimana setup fallback, kita bangun bareng di JARVIS Class by INFJ Labs, pakai pattern yang sama dengan yang jalan di sistem gue sekarang.