Sonnet 5.5 atau Opus 5.5: Agent Mana yang Tepat untuk Tugas Ini?

Anthropic merilis Claude Sonnet 5.5 pada 28 September, enam hari setelah Opus 5.5. Dengan tarif $2 per satu juta token input dan $10 per satu juta token output, biayanya separuh dari tarif Opus 5.5 yang sebesar $4 dan $20. Di halaman peluncuran, performanya hanya terpaut beberapa poin dari Opus 5.5 di sebagian besar pengujian, bahkan melampauinya pada Terminal-Bench 4.0, tolok ukur yang dijalankan sendiri oleh Anthropic. Bagi tim yang menjalankan beberapa agen coding, langkah yang sangat menggiurkan adalah mengalihkan setiap Agent ke Sonnet dan mengantongi selisih biayanya.

Namun, grafik per tingkat upaya (effort) di halaman yang sama menunjukkan hal sebaliknya. Skor utama Terminal-Bench tersebut diraih pada tingkat effort tertinggi Sonnet, dengan biaya $12,54 per percobaan. Pada pengaturan yang biasanya Anda jalankan seharian, urutannya berbalik: Opus 5.5 pada tingkat medium meraih skor 57,6% seharga $2,94, Sonnet 5.5 pada tingkat high meraih skor 43,0% seharga $1,94, dan Sonnet baru melampaui Opus-pada-medium saat disetel ke xhigh, dengan skor 61,5% seharga $5,30.

Ringkasan Singkat (TL;DR)

Gunakan Sonnet 5.5 pada tingkat medium sebagai default untuk pekerjaan dengan cakupan yang jelas. Alihkan pekerjaan yang panjang, ambigu, atau lintas modul ke Opus 5.5 alih-alih menaikkan Sonnet ke xhigh: pada ketiga grafik performa coding per-effort yang dirilis Anthropic, Opus pada tingkat high mengungguli Sonnet pada tingkat xhigh dengan biaya yang hampir sama atau bahkan lebih murah. Rumuskan ini sebagai aturan tertulis pada Agent, bukan sekadar preferensi di kepala seseorang: satu Agent untuk setiap tingkatan model dan effort, kondisi eskalasi yang jelas, serta definisi selesai (definition of done). Sharkly tidak memilih model maupun tingkat effort; Sharkly mencatat riwayat Agent mana yang mengerjakan apa pada setiap Task.

Fakta di balik angka-angka peluncuran

Tabel peluncuran, lengkap dengan tingkat effort di balik setiap sel dan pihak yang menjalankannya:

Ada dua catatan penting pada baris Terminal-Bench. Dokumen kartu sistem menyebutkan bahwa permintaan bermasalah (flagged requests) memengaruhi 10% pengujian Opus 5.5 berbanding 1,5% pada Sonnet, dan pengujian independen oleh Artificial Analysis mencatat Sonnet 5.5 di angka 63,6%, bukan 70,6%. Sementara itu, SWE-Bench Pro menunjukkan selisih 8,6 poin untuk keunggulan Opus. Penentuan posisi dari Anthropic pun sejalan: Sonnet 5.5 ditujukan untuk tugas sehari-hari dan perbaikan bug dengan cakupan terdefinisi, sedangkan Opus 5.5 “tetap jelas lebih unggul pada pekerjaan yang kompleks dan terbuka.”

Angka-angka utama tersebut juga menyembunyikan hal yang sebenarnya dibutuhkan untuk aturan perutean: ketiga tolok ukur coding pada tingkat effort yang realistis Anda gunakan, disajikan dalam skor dan biaya per task.

Sonnet 5.5 adalah opsi paling murah pada tingkat medium dan high, di mana skornya juga paling rendah. Di atas tingkat high, situasinya berbalik: Sonnet pada xhigh memakan biaya lebih tinggi daripada Opus pada medium di ketiga baris tersebut, dan kalah performa dibandingkan Opus pada high di ketiganya dengan biaya yang sebanding atau bahkan lebih hemat. Model yang murah berhenti menjadi murah begitu Anda memaksanya bekerja seperti model mahal. Biaya CursorBench Sonnet merupakan perkiraan dari Anthropic, dan tidak ada satu pun dari tugas ini yang berasal dari repositori kode Anda sendiri, jadi anggaplah titik temu (crossover) ini sebagai hipotesis yang perlu dibuktikan.

Menetapkan aturan perutean secara tertulis

Artikel-artikel sebelumnya telah membahas tentang mencocokkan model dengan peran Agent, menentukan agen mana yang menerima task berdasarkan karakteristik tugasnya, serta menetapkan tingkatan model sebagai aturan pasti. Kehadiran Sonnet 5.5 menambah satu variabel baru. Pada Terminal-Bench, model yang sama pada tingkat medium dan max memiliki selisih biaya percobaan sekitar 15 kali lipat, yakni $0,83 berbanding $12,54. Oleh karena itu, arahan “alihkan ini ke Sonnet” bukanlah aturan yang lengkap sampai Anda menentukan tingkat effort-nya.

Kondisi eskalasi adalah penentu efektivitas aturan ini. Ketika Agent Sonnet mengalami kesulitan, reaksi spontan kita biasanya menaikkan tingkat effort-nya. Namun grafik di atas menyarankan untuk mengganti modelnya: berdasarkan data ini, Task yang membutuhkan Sonnet pada level xhigh sebenarnya lebih tepat dikerjakan oleh Opus pada level high. Tentukan kondisi Anda sendiri; poin-poin berikut dapat dijadikan acuan:

• Pemeriksaan yang sama gagal dua kali. Pengguna manusia memindahkan Task ke Agent Opus disertai lampiran log; tidak boleh ada percobaan ulang diam-diam pada tier yang lebih besar.
• Perubahan kode membutuhkan lebih banyak berkas daripada batas yang diizinkan untuk worker (misalnya delapan berkas), atau menyentuh path yang tidak disebutkan di dalam Task.
• Agent menanyakan keputusan perancangan atau arsitektur, bukan sekadar klarifikasi redaksional Task.
• Suatu kelompok Task hanya bisa berhasil dengan Sonnet di atas tingkat high. Alihkan kelompok tersebut ke Agent Opus pada Sprint berikutnya.

Ketentuan ini juga berlaku sebaliknya: Task pada Opus yang terus-menerus selesai dalam satu percobaan dengan diff kecil sebaiknya diturunkan satu tingkat ke bawah.

Dampak masing-masing model terhadap antrean review

Aturan yang hanya menentukan model dan effort barulah setengah aturan. Setengah lainnya adalah menetapkan seperti apa kriteria “selesai” (done), karena setiap tingkatan menghasilkan luaran yang berbeda bagi reviewer, dan tahap review sudah menjadi hambatan utama bahkan sebelum kedua model ini diluncurkan. Biaya eksekusi yang lebih murah menambah tumpukan diff yang harus diperiksa, bukan menambah jam kerja reviewer.

Panduan prompting Anthropic untuk Sonnet 5.5 secara gamblang memaparkan apa yang akan dihadapi oleh reviewer:

• Pada tingkat low dan medium, model meminta konfirmasi terlalu dini pada tugas agentic yang panjang: di papan kerja, Task akhirnya terbengkalai menunggu balasan manusia pada pukul 2 dini hari. Seorang komentator di Hacker News menyebut masalah inilah yang menyebabkan perolehan skor rendah 7,4% pada tolok ukur khusus mereka (padahal Sonnet 5 memperoleh 17,8%).
• Pada tingkat low, model bisa melewatkan tahap verifikasi dan melaporkan kode telah selesai tanpa menjalankan pengujian. Status “selesai” dari Agent triase tidak berarti apa pun tanpa hasil pemeriksaan tersebut.
• Pada setiap tingkat effort, model menambahkan pengujian, dokumentasi, dan berkas-berkas kecil yang tidak diminta. Sebagian mungkin bermanfaat, namun semuanya memperpanjang diff yang harus ditinjau.
• Pada tingkat xhigh dan max, model menambahkan putaran review atau subagent reviewer. Halaman peluncuran menyebutkan bahwa hal inilah yang menyebabkan skor Sonnet 5.5 di FrontierCode pada level max lebih rendah daripada level xhigh: model lebih sering menjalankan kemampuan code-review di Claude Code yang bercabang ke banyak subagent, dan dalam dua kasus yang diperiksa Cognition, hal ini memicu timeout atau perubahan di luar cakupan tugas. Masalah-masalah seperti itulah yang paling membebani reviewer, karena seseorang harus menelitinya baris demi baris.

Opus 5.5 memberikan beban yang berbeda pada antrean review. Anthropic menyatakan bahwa model ini mampu bertahan mengerjakan tugas selama 18 jam atau lebih dengan luaran hingga 128k token. Dengan demikian, beban utamanya terletak pada besarnya skala pekerjaan, bukan pada kebisingan (noise), dan paket serah terima yang dibutuhkan reviewer juga berlaku untuk model ini.

Oleh karena itu, definisi selesai harus dicantumkan langsung dalam instruksi worker Agent, yang selalu disertakan Sharkly pada setiap eksekusi:

Agent: sonnet-worker  (Claude Code, claude-sonnet-5-5, effort medium)

Done means:
- The checks named in the Task ran. Paste each command and its exit
  code. "Tests pass" without output is not done.
- Changes stay inside the paths the Task names. List every file you
  created that the Task did not ask for, and why.
- New tests are welcome. New docs files only if the Task asks.

Keep working on long Tasks. Ask only when two readings of the Task
would produce different code; otherwise proceed and record the
assumption in your report.

Stop and return to the Task, without retrying, when a check has failed
twice, the change needs more than 8 files, or the question is about
design rather than the Task's wording.

Menjalankan kedua tingkatan di Sharkly

Sharkly tidak memilih model, dan tidak mengatur tingkat effort. Dokumentasi Agents menyatakan secara lugas: “Agent mengikuti model default milik Runtime. Agent tidak menjanjikan atau menampilkan nama model tertentu. Ubah model pada konfigurasi tool Runtime atau Computer, bukan pada Agent.” Pengaturan kedalaman berpikir (thinking-depth) juga tidak ada pada Agent. Sebuah tier merupakan konfigurasi Claude Code pada Computer; Agent adalah cara tim mendelegasikan tugas ke dalamnya.

Jadi aturannya: satu Agent untuk setiap tier. sonnet-worker berjalan pada Computer yang Claude Code-nya disetel ke claude-sonnet-5-5, sedangkan opus-lead berjalan pada Computer yang disetel ke claude-opus-5-5. Sebuah Computer dapat berupa kontainer, sehingga tier kedua tidak membutuhkan laptop fisik kedua. Tiga poin dari dokumentasi konfigurasi model Claude Code menentukan apakah suatu tier benar-benar berjalan sesuai namanya:

• Kunci ID lengkapnya. Alias sonnet hanya merujuk ke Sonnet 5.5 pada Anthropic API (Bedrock dan Google Cloud masih mengarahkannya ke Sonnet 4.5), dan Sonnet 5.5 membutuhkan Claude Code v2.1.284 atau versi lebih baru.
• Model default pada Claude Code adalah Opus 5.5 pada paket Pro, Max, Team, Enterprise, dan API. Artinya, Computer yang belum dikonfigurasi sudah otomatis menjadi tier Opus.
• Tingkat effort default Sonnet 5.5 di Claude Code adalah medium, yakni tier worker yang dibahas sebelumnya. Pengubahannya dilakukan pada Computer, bukan pada Agent.

Sharkly tidak dapat membaca secara andal model apa yang sedang digunakan oleh Runtime, jadi cantumkan nama tier pada nama Agent, serta ubah nama dan konfigurasi secara bersamaan. Panduan penyiapan Sonnet 5.5 menguraikan langkah-langkahnya.

Untuk pekerjaan yang membutuhkan kedua tier dalam satu Task, gunakan Crew. Crew adalah grup People dan Agent yang dapat digunakan kembali serta dikoordinasikan oleh satu Agent pemimpin (leader). Dengan opus-lead sebagai leader dan worker Sonnet sebagai anggota, leader akan membaca Task, menanganinya langsung atau menyebut anggota untuk bagian tertentu, kemudian para anggota menambahkan hasil kerja mereka ke Task yang sama. Pola orkestrator Opus inilah yang diusulkan oleh komentator Hacker News, dengan proses delegasi tugas yang dapat dipantau langsung oleh manusia. Untuk pekerjaan berskala kecil dan terdefinisi dengan jelas, lewati Crew dan tugaskan langsung ke sonnet-worker.

Alias opusplan milik Claude Code menghadirkan variasi dari pola ini dalam satu sesi: Opus berjalan pada mode perencanaan (plan mode), dan Sonnet bertugas melakukan eksekusi. Komponen Sonnet di sini merujuk ke Sonnet 5.5 hanya pada Anthropic API; pada Bedrock, Google Cloud, atau Foundry, alias tersebut mengarah ke versi Sonnet yang lebih lama. Gunakan opsi ini jika satu orang menjalankan sekaligus meninjau sesi tersebut; gunakan dua Agent terpisah apabila ada pihak lain yang perlu melihat dengan jelas agen mana yang merencanakan dan agen mana yang mengeksekusi.

Satu hal yang tidak pernah berpindah antar-tier: proses penalaran (reasoning). Blok pemikiran (thinking blocks) Sonnet 5.5 terikat secara eksklusif pada model dan percakapan tersebut. Tidak ada model lain yang dapat membacanya, dan Sonnet 5.5 tidak dapat membaca blok pemikiran Opus 5.5. Penggunaan kembali direktori Crew hanya berbagi berkas, bukan riwayat sesi Agent sebelumnya. Arahan yang diputuskan leader hanya akan sampai ke worker jika dituliskan secara eksplisit pada Task, yang menjadi pokok pembahasan tersendiri di artikel lain.

Semua ini tidak mengubah siapa yang memiliki wewenang untuk menyetujui hasil akhir pekerjaan. Agent bertugas meriset, mengeksekusi, menguji, dan melapor. Manusia yang menentukan arah, memberi otorisasi, dan menerima hasilnya. Biaya di atas akan ditagihkan pada akun penyedia layanan Anda, karena penggunaan model berjalan melalui langganan atau API key yang dikonfigurasi pada tool tersebut. Penugasan, log eksekusi, pertanyaan, hasil kerja, serta review manusia akan tetap tersimpan di dalam Task model mana pun yang memimpin di kuartal berikutnya, dan logika ini tetap relevan lintas vendor, seperti yang ditunjukkan dalam komparasi Sonnet 5.5 dan GPT-6 Sol. Jika Anda ingin terus memanfaatkan berbagai agen coding daripada terikat pada satu ekosistem saja, permasalahan itulah yang menjadi fokus utama perancangan Sharkly.