GLM-5.3 menghapus flag “thinking: disabled”, sehingga integrasi apa pun yang mengirimkan {"thinking":{"type":"disabled"}} kini mengembalikan error alih-alih respons. Perubahan ini merusak puluhan rangkaian pengujian dalam semalam dan memaksa pengembang untuk menulis ulang satu baris kode agar aplikasi mereka tetap berjalan.

Mengapa perubahan ini penting

Pada GLM-5.2, API mengizinkan pemanggil untuk mematikan mode thinking untuk prompt yang sederhana. Opsi tersebut merupakan pola umum dalam skrip otomatisasi, alur kerja pemrosesan batch, dan bot dengan latensi rendah. GLM-5.3 menghapus flag tersebut sepenuhnya dan memperkenalkan tiga tingkat upaya—low, high, dan max—dengan max sebagai default. Model baru ini selalu menghasilkan jejak penalaran (reasoning trace); mode tersebut tidak lagi dapat dimatikan sepenuhnya.

Apa yang rusak dan bagaimana dampaknya menyebar

Ketika body permintaan berisi "type":"disabled", server menolak payload tersebut dan mengembalikan respons kegagalan umum. Tidak ada kesalahan autentikasi atau sintaksis yang muncul, sehingga masalah ini bisa sulit dideteksi hingga pengujian regresi penuh gagal. Karena flag tersebut berada dalam satu fungsi pembantu (helper function) yang dapat digunakan kembali di banyak basis kode, dampaknya merambat melalui rangkaian pengujian besar maupun endpoint produksi.

Perubahan kode yang tepat

Ganti payload lama:

extra_body = {"thinking": {"type": "disabled"}}

dengan versi yang kompatibel dengan GLM-5.3:

extra_body = {"thinking": {"type": "enabled", "effort": "low"}}

Key "type":"enabled" mengaktifkan kembali mesin penalaran, sementara "effort":"low" meniru kecepatan mode nonaktif sebelumnya sedekat mungkin yang diizinkan oleh model baru.

Implikasi performa

Menjalankan prompt peninjauan kode yang sama dengan pengaturan effort rendah (low-effort) menghasilkan hasil yang “mendekati kecepatan lama” tetapi tidak identik. Model tetap mengeluarkan jejak penalaran, yang menambah beberapa token ekstra dan sedikit peningkatan latensi. Dalam beban kerja dengan throughput tinggi atau yang kritis terhadap latensi, Anda harus melakukan benchmark pada data Anda sendiri untuk memastikan bahwa overhead tersebut dapat diterima.

Mengapa bermigrasi meskipun ada konsekuensi

GLM-5.3 mempertahankan arsitektur 744 miliar parameter dari pendahulunya tetapi berfokus kembali pada tugas pengodean dan tugas-tugas agentic. Benchmark independen (Terminal-Bench 3.0) menunjukkan lonjakan skor yang nyata, dan pengujian internal melaporkan deteksi kesalahan logika yang lebih baik di berbagai file. Bagi tim yang mengandalkan model ini untuk analisis kode yang kompleks, peningkatan performa dapat lebih besar daripada sedikit peningkatan konsumsi token.

Kompromi yang tidak bisa Anda abaikan

Jika sebuah aplikasi benar-benar membutuhkan respons tanpa penalaran (zero-thinking)—misalnya, layanan penyelesaian token murni—kini ia tidak memiliki opsi bawaan di GLM-5.3. Pengembang harus menerima output penalaran tambahan atau beralih ke model lain yang masih menawarkan mode nonaktif.

Apa yang perlu diperhatikan selanjutnya

  • Pemantauan latensi: Setelah perubahan payload, pantau waktu respons dan jumlah token untuk mendeteksi regresi lebih dini.
  • Penyesuaian effort: Beberapa beban kerja mungkin mendapat manfaat dari effort “high” tanpa penalti penuh, jadi bereksperimenlah di luar pengaturan low.
  • Depresiasi di masa mendatang: Penghapusan satu flag menunjukkan bahwa API dapat mengalami lebih banyak konsolidasi; perhatikan catatan rilis mendatang.

Intinya: Memperbarui payload thinking menjadi {"type":"enabled","effort":"low"} memulihkan kompatibilitas dengan GLM-5.3. Verifikasi latensi dan penggunaan token dalam alur kerja Anda, dan putuskan apakah peningkatan kemampuan pengodean sebanding dengan jejak penalaran yang tidak dapat dihindari.

Diskusi dan dukungan komunitas tersedia di saluran Telegram GyaanSetu AI.