Hari ini saya coba jawab pertanyaan yang sering muncul di kalangan yang baru mulai pakai AI coding agent: “Kalau pakai model non-thinking, apakah tetap bisa dipakai untuk coding yang kompleks?” Singkatnya: bisa, tapi dengan syarat — dan ada jenis pekerjaan yang memang lebih aman diserahkan ke model thinking. Catatan ini saya tulis khusus dari sudut pandang coding (Hermes Agent dan OpenCode), tidak membahas hal lain di luar itu.
Apa Bedanya Model Thinking vs Non-Thinking?
Dalam konteks coding, “thinking” (atau extended thinking / reasoning) artinya model diberi ruang untuk berpikir panjang sebelum menjawab — ia menuliskan rantai penalaran internal dulu, baru menghasilkan kode atau keputusan. Ini memakai token tambahan (biasanya tidak terlihat di output akhir), sehingga lebih lambat dan lebih mahal.
Secara arsitektural, perbedaannya terletak pada proses generasi token. Model thinking menjalankan apa yang bisa dipandang sebagai “loop penalaran” — setiap token output dikalkulasi ulang dengan mempertimbangkan konteks yang sudah ditulis di block thinking. Bayangkan seperti programmer yang menulis draf di sticky note sebelum menulis kode final: prosesnya lebih lama, tapi hasilnya lebih matang karena ada ruang untuk revisi internal.
Model non-thinking menjawab langsung: input diproses, output langsung keluar. Lebih cepat, lebih murah, tapi untuk masalah yang butuh penalaran bertingkat, hasilnya bisa meleset lebih cepat.
Penting: yang wajib dimiliki untuk coding adalah kemampuan tool calling yang baik (membaca file, menjalankan perintah, melihat error, mengedit). Mode thinking itu nilai tambah, bukan prasyarat.
Kapan Non-Thinking Masih Andal
Untuk jenis pekerjaan berikut, model non-thinking yang bagus biasanya sudah cukup:
- Boilerplate dan scaffolding — kerangka proyek, file konfigurasi, stub fungsi.
- CRUD sederhana — endpoint API, form, operasi database standar.
- Task satu file dengan spesifikasi eksplisit — “ubah fungsi ini supaya menerima parameter X”.
- Refactor kecil dan mekanis — rename, pindah fungsi, ubah format.
- Perbaikan bug yang error-nya jelas dan lokal.
Ciri umumnya: tugasnya jelas, ruang lingkupnya sempit, dan ada cara verifikasi cepat (test, compile, atau output yang bisa dicek).
Di Mana Non-Thinking Sering Gagal
Yang berikut ini justru menjadi titik lemah model non-thinking:
- Debugging bertingkat — error menimpa error, root cause tersembunyi di balik gejala.
- Refactor lintas file — banyak dependensi silang yang harus diikuti konsistensinya.
- Keputusan arsitektur — memilih desain dengan trade-off yang saling bertabrakan.
- Memahami codebase besar yang belum familiar — butuh penalaran panjang untuk membangun model mental.
- Task ambigu — spesifikasi tidak lengkap, perlu inferensi dan pertimbangan.
Pada kasus seperti ini, model non-thinking berisiko gagal diam-diam: hasilnya terlihat jalan, tapi logikanya salah di tempat yang tidak langsung kelihatan.
Bukti dari Benchmark
Di benchmark agentic coding seperti SWE-bench Verified (500 isu GitHub nyata dari repo populer seperti Django, Flask, scikit-learn yang harus diselesaikan oleh model), posisi papan atas hampir selalu diisi model reasoning/thinking. Menurut leaderboard yang dipantau benchlm.ai per Agustus 2026, model teratas (Claude Opus 5) mencapai sekitar 96% resolusi.
Pola umumnya: versi thinking dari sebuah model hampir selalu mengungguli versi non-thinking-nya pada task multi-step, dan gap-nya mengecil drastis pada task sederhana. Jadi benchmark ini menegaskan — bukan soal “bisa atau tidak”, tapi soal di titik mana non-thinking mulai jebol.
Perbandingan Biaya dan Kecepatan
Secara garis besar, model thinking mengonsumsi 3–5 kali lebih banyak token dibanding non-thinking untuk tugas yang sama. Artinya, biaya per request juga melonjak sekitar 3–5 kali lipat. Untuk sesi coding panjang (misalnya refactor besar atau debugging berulang), selisih ini bisa terasa signifikan di bill API bulanan.
Soal kecepatan, model non-thinking biasanya sudah menjawab dalam hitungan detik untuk task sederhana. Model thinking butuh waktu lebih karena fase “berpikir” — bisa 10–30 detik lebih lama tergantung kompleksitas reasoning yang diminta. Untuk task seperti generate boilerplate atau edit mekanis, menunggu model thinking terasa seperti menggunakan excavator untuk menggali lubang kucing.
| Aspek | Non-Thinking | Thinking |
|---|---|---|
| Biaya | Murah | Mahal (token reasoning) |
| Kecepatan | Cepat | Lambat |
| Konsumsi token | Hemat | Boros |
| Task sederhana & jelas | Sangat cocok | Bisa, tapi boros |
| Debugging & refactor besar | Risiko gagal diam-diam | Andal |
Pendekatan Hybrid: Rencana vs Eksekusi
Cara paling efektif menurut pengalaman saya bukan memilih salah satu, tapi memakai keduanya secara strategis — model thinking untuk perencanaan, non-thinking untuk eksekusi. Ini seperti peran lead developer dan junior developer dalam satu tim: lead merancang arsitektur dan memecah task, junior mengeksekusi detailnya.
Workflow-nya kira-kira begini:
- Buka sesi dengan model thinking. Jelaskan tujuan besar, biarkan model merancang pendekatan, memecah task, dan mengidentifikasi potensi masalah.
- Simpan hasil perencanaan (bisa dalam file markdown atau catatan di sesi).
- Switch ke model non-thinking untuk eksekusi per task kecil berdasarkan rencana tadi.
- Setiap kali ada error atau hasil tidak sesuai ekspektasi, kembali ke model thinking untuk analisis.
Pola ini menghemat biaya tanpa mengorbankan kualitas di tahap kritis.
Contoh Kasus Praktis
Beberapa situasi di mana saya sering beralih model:
Code review — model thinking lebih unggul di sini karena harus memahami konteks lintas file, mengenali pola yang berpotensi bermasalah, dan memberikan rekomendasi bermakna. Non-thinking bisa menangani review untuk satu fungsi atau satu file, tapi meleset untuk review arsitektural.
Test generation — untuk unit test dari fungsi sederhana, non-thinking sudah cukup. Untuk integration test atau test yang menangkap edge case kompleks, model thinking lebih andal karena bisa menalar skenario yang tidak obvious.
Dokumentasi — menulis README, JSDoc, atau komentar untuk fungsi individual: non-thinking cepat dan memadai. Menulis arsitektur decision record atau technical design doc: thinking model lebih tepat karena perlu menghubungkan banyak konteks.
Pola Praktis: Campur, Jangan Pilih Satu
Cara paling efektif bukan memilih salah satu, tapi memakai keduanya sesuai tugas — di Hermes dan OpenCode, ganti model per sesi/per task itu normal.
Hermes Agent
Ganti model kapan saja via hermes model, atau langsung set default:
hermes model hermes config set model.default nama-model-non-thinking
Di dalam sesi, perintah /model untuk ganti model, dan /reasoning untuk mengatur level reasoning — kalau modelnya memang mendukung mode thinking. Model non-thinking tetap jalan normal tanpa setting tambahan.
OpenCode
Pilih model via /models. Kalau model default-nya thinking (misalnya Claude lewat provider Anthropic) dan ingin mematikannya, set lewat opencode.json:
{
"$schema": "https://opencode.ai/config.json",
"provider": {
"anthropic": {
"models": {
"claude-sonnet-4-5": {
"options": {
"thinking": { "type": "disabled" }
}
}
}
}
}
}Untuk provider OpenAI-compatible (misalnya GPT), mode reasoning diatur lewat reasoningEffort — nilai rendah berarti “hampir non-thinking”.
Catatan Pribadi: Beralih Model
Pengalaman saya pribadi: awalnya saya tergoda pakai thinking model untuk semua hal. Rasanya aman — seperti pakai GPS untuk ke warung dekat rumah. Tapi setelah beberapa minggu, tagihan API mulai terasa. Akhirnya saya kembangkan kebiasaan: mulai sesi dengan thinking untuk merencanakan, lalu switch ke non-thinking untuk eksekusi.
Yang paling mengejutkan: untuk banyak task sehari-hari (rename, move file, generate CRUD, fix typo), non-thinking sebenarnya lebih cepat dan hasilnya sama. Saya malah jadi lebih produktif karena tidak perlu menunggu model “berpikir” untuk hal mekanis. Kuncinya adalah kemampuan membedakan mana task yang butuh penalaran dan mana yang cukup eksekusi — dan itu sendiri adalah skill yang terasah seiring waktu.
Kesimpulan
Model non-thinking bisa dipakai untuk coding kompleks, asal tugas dipecah kecil dan ada loop verifikasi: tulis sedikit → jalankan → lihat error → perbaiki. Untuk boilerplate, CRUD, dan task single-file, non-thinking bahkan pilihan paling efisien.
Tapi untuk debugging bertingkat, refactor lintas file, dan keputusan desain, model thinking masih pilihan yang jauh lebih aman — terutama kalau pekerjaan berjalan tanpa pengawasan. Prinsipnya: pakai model sesuai tingkat kesulitan tugas, bukan satu model untuk segalanya.
Sumber
- OpenCode Docs — Models (konfigurasi model & opsi thinking), diakses 15 Agustus 2026
- SWE-bench Verified — deskripsi benchmark, diakses 15 Agustus 2026
- benchlm.ai — SWE-bench Verified Leaderboard (Agustus 2026), diakses 15 Agustus 2026
- Hermes Agent Docs, diakses 15 Agustus 2026
Komentar Terbaru