Saya Menghabiskan $500 Menguji Claude Sonnet 4.6 vs Opus 4.6 — Inilah Hasil Temuan Saya

Mengapa Saya Menjalankan Eksperimen Ini

Semua orang mempublikasikan tabel benchmark yang membandingkan Claude Sonnet 4.6 dan Opus 4.6. Anda dapat menemukan belasan tabel tersebut dengan pencarian cepat. Namun, benchmark mengukur performa model pada tugas-tugas standar — mereka tidak memberi tahu Anda apa yang terjadi ketika Anda sedang mendalami codebase yang berantakan pada jam 2 pagi untuk mencoba merilis sebuah fitur.

Saya ingin menjawab pertanyaan yang lebih sederhana: di antara tugas-tugas aktual yang saya lakukan setiap hari sebagai developer, kapan Opus 4.6 layak mendapatkan premi harga 5x lipatnya?

Jadi saya menyiapkan eksperimen terkontrol. Selama tiga minggu, saya menjalankan setiap tugas coding melalui kedua model tersebut — prompt yang sama, codebase yang sama, kriteria evaluasi yang sama. Saya melacak biaya, kualitas output, waktu penyelesaian, dan jumlah koreksi lanjutan yang diperlukan.

Tagihannya mencapai sekitar $500. Inilah semua yang saya pelajari.

Penyiapan: Bagaimana Saya Menyusun Pengujian Ini

Saya menggunakan Claude API secara langsung dengan system prompts yang identik untuk kedua model. Tanpa wrapper, tanpa asisten, tanpa konfigurasi khusus — hanya pemanggilan API mentah agar perbandingannya bersih.

Model yang diuji:

• Claude Sonnet 4.6 (claude-sonnet-4-6) — $3 input / $15 output per million tokens
• Claude Opus 4.6 (claude-opus-4-6) — $15 input / $75 output per million tokens

Metodologi:

• Prompt yang sama untuk setiap tugas, dikirim ke kedua model dalam jam yang sama
• Setiap tugas dinilai berdasarkan: kebenaran, kualitas kode, kelengkapan, dan jumlah follow-up prompts yang diperlukan
• Semua tugas diambil dari proyek nyata — bukan benchmark sintetis
• Saya menilai setiap model pada skala 1-10 untuk setiap dimensi

Data harga berasal langsung dari halaman harga resmi Anthropic. Pengukuran kecepatan berasal dari benchmark Artificial Analysis.

Skenario 1: Debugging race condition pada Kode Async

Tugas: Sebuah aplikasi Node.js mengalami kegagalan intermiten di mana penulisan database selesai tidak berurutan. Bug tersebut hanya muncul di bawah beban tinggi. Saya memberikan kedua model file sumber yang relevan (sekitar 8K tokens konteks) dan log error.

Hasil Sonnet 4.6: Mengidentifikasi await yang hilang pada rantai Promise dalam dua kali pertukaran pesan. Menyarankan untuk membungkus penulisan dalam sebuah transaction. Perbaikan yang bersih dan benar.

Hasil Opus 4.6: Mengidentifikasi akar masalah yang sama pada pertukaran pesan pertama tetapi melangkah lebih jauh — ia menandai race condition potensial kedua yang tidak saya sadari di modul yang berdekatan. Ia juga menjelaskan mengapa bug tersebut bersifat intermiten (timing event loop di bawah koneksi konkuren) dan menyarankan perbaikan struktural menggunakan write queue.

Pemenang: Opus 4.6

Perbedaannya bukan pada menemukan bug tersebut. Keduanya menemukannya. Opus menemukan bug kedua dan memberikan konteks arsitektural yang mencegah masalah di masa depan. Ini sejalan dengan apa yang dilaporkan Anthropic tentang Opus 4.6 yang memiliki keterampilan debugging yang lebih baik dan kemampuan untuk menangkap kesalahannya sendiri.

Biaya: Sonnet $0.12 | Opus $0.58

Skenario 2: Membangun CRUD Endpoints untuk sebuah REST API

Tugas: Menghasilkan set lengkap CRUD endpoints untuk sumber daya "projects" dalam aplikasi Express.js dengan TypeScript, Prisma ORM, validasi input melalui Zod, dan penanganan error yang tepat.

Hasil Sonnet 4.6: Menghasilkan kelima endpoints (create, read one, read all dengan pagination, update, delete) dalam satu respons. Validasi input benar, penanganan error solid, tipe TypeScript akurat. Siap untuk disalin dan diuji.

Hasil Opus 4.6: Menghasilkan kelima endpoints yang sama dengan struktur yang hampir identik. Menambahkan komentar yang sedikit lebih detail. Juga menyertakan saran middleware untuk authentication yang tidak saya minta.

Pemenang: Sonnet 4.6

Output-nya secara fungsional identik. Sonnet lebih cepat, lebih murah, dan tidak memadatkan respons dengan saran arsitektur yang tidak diminta. Untuk tugas yang terdefinisi dengan baik dan terlingkup seperti pembuatan CRUD, kedalaman penalaran ekstra dari Opus tidak menambahkan apa pun selain biaya.

Biaya: Sonnet $0.08 | Opus $0.41

Skenario 3: Melakukan Refactoring Komponen Monolitik menjadi Bagian yang Lebih Kecil

Tugas: Sebuah komponen React sepanjang 600 baris yang menangani profil pengguna — termasuk state form, pemanggilan API, pemeriksaan izin, dan logika rendering — perlu dipecah menjadi bagian-bagian yang lebih kecil dan dapat diuji. Saya menyediakan komponen lengkap beserta file pengujiannya.

Hasil Sonnet 4.6: Memecah komponen menjadi empat bagian: komponen kontainer, komponen form, permissions hook, dan API hook. Dekomposisi yang masuk akal. Namun, ia melewatkan pembaruan dua import paths di file pengujian, dan permissions hook memiliki masalah manajemen state halus di mana ia tidak melakukan memoizing pada sebuah callback.

Hasil Opus 4.6: Memecah menjadi lima bagian dengan pemisahan yang lebih bersih. Ia membuat file tipe khusus, memperbarui semua imports dengan benar termasuk file pengujian, dan permissions hook di-memoize dengan benar. Ia juga mencatat bahwa komponen asli memiliki potensi memory leak dalam pembersihan effect dan memperbaikinya.

Pemenang: Opus 4.6

Di sinilah celah tersebut menjadi nyata. Refactoring multi-file dengan pelacakan dependensi adalah skenario tepat di mana skor 76% Opus 4.6 pada MRCR v2 (penalaran multi-file dan code review) diterjemahkan menjadi nilai praktis. Solusi Sonnet membutuhkan dua putaran koreksi. Opus mengirimkan hasil yang benar pada percobaan pertama.

Biaya: Sonnet $0.22 (termasuk koreksi) | Opus $0.95

Skenario 4: Menulis Unit Test untuk Kode yang Sudah Ada

Tugas: Menulis unit test yang komprehensif untuk modul pemrosesan pembayaran dengan berbagai edge cases — kartu kedaluwarsa, dana tidak mencukupi, network timeouts, pengembalian dana sebagian, dan konversi mata uang.

Hasil Sonnet 4.6: Menghasilkan 14 test cases yang mencakup semua skenario yang saya jelaskan. Pengujian terstruktur dengan baik dengan blok describe/it yang jelas. Penyiapan mock benar. Dua edge cases yang tidak saya sebutkan secara eksplisit (jumlah kosong, jumlah negatif) disertakan.

Hasil Opus 4.6: Menghasilkan 16 test cases. Struktur serupa. Menambahkan satu pengujian bergaya integrasi yang memverifikasi alur pembayaran lengkap dari awal hingga akhir. Sedikit lebih bertele-tele dalam deskripsi pengujian.

Pemenang: Seri (Sonnet 4.6 dalam hal nilai)

Keduanya menghasilkan suite pengujian yang sangat baik. Opus menambahkan dua pengujian ekstra, tetapi keduanya tidak lebih baik secara signifikan. Untuk pembuatan pengujian, Sonnet memberikan kualitas yang setara dengan biaya 5x lebih rendah. Kecuali Anda menguji logika bisnis yang sangat kompleks, Sonnet adalah pilihan yang tepat.

Biaya: Sonnet $0.09 | Opus $0.47

Skenario 5: Menulis Dokumentasi Teknis

Tugas: Menghasilkan dokumentasi API untuk sebuah SDK internal — termasuk tanda tangan metode, deskripsi parameter, tipe kembalian, contoh penggunaan, dan panduan penanganan error untuk 12 metode publik.

Hasil Sonnet 4.6: Dokumentasi yang bersih dan terorganisir dengan baik. Setiap metode memiliki deskripsi, tabel parameter, tipe kembalian, contoh, dan bagian error. Pemformatan konsisten di seluruh bagian.

Hasil Opus 4.6: Dokumentasi yang hampir identik. Opus menambahkan bagian "Pola Umum" di akhir yang menunjukkan bagaimana metode-metode tersebut disusun bersama — yang mana bagus tetapi tidak diminta.

Pemenang: Sonnet 4.6

Dokumentasi adalah tugas di mana ringkasnya Sonnet sebenarnya merupakan keuntungan. Seperti yang dicatat oleh para pengembang yang membandingkan kedua model tersebut, Opus terkadang menambahkan penjelasan yang tidak perlu pada tugas-tugas sederhana, membuang tokens dan waktu. Untuk dokumentasi, Anda menginginkan kejelasan dan kelengkapan, bukan gaya bahasa yang bertele-tele dan filosofis.

Biaya: Sonnet $0.14 | Opus $0.72

Skenario 6: Code Review pada sebuah Pull Request

Tugas: Meninjau sebuah pull request sepanjang 400 baris yang menambahkan lapisan caching ke sebuah API. Saya ingin kedua model mengidentifikasi bug, menyarankan perbaikan, dan menandai masalah keamanan.

Hasil Sonnet 4.6: Menemukan tiga masalah — cache invalidation yang hilang pada saat pembaruan, potensi memory leak dari pertumbuhan cache yang tidak terbatas, dan saran untuk menambahkan TTL. Umpan balik yang baik dan dapat ditindaklanjuti.

Hasil Opus 4.6: Menemukan tiga masalah yang sama ditambah dua masalah lagi — kerentanan timing attack pada pembuatan cache key dan masalah halus di mana permintaan konkuren dapat mengembalikan data usang selama pengisian cache. Menyarankan pola tertentu (read-through cache dengan distributed locks) untuk memperbaiki masalah konkurensi tersebut.

Pemenang: Opus 4.6

Code review pada kode yang relevan dengan keamanan adalah area lain di mana Opus unggul. Kerentanan timing attack tersebut nyata dan tidak jelas. Ini sesuai dengan laporan dari para pengembang yang menganggap Opus sangat kuat ketika kegagalan mencakup permukaan arsitektural yang luas.

Biaya: Sonnet $0.11 | Opus $0.53

Skenario 7: Prototyping Cepat sebuah Fitur Baru

Tugas: Membangun sistem notifikasi real-time menggunakan WebSockets — handler sisi server, hook sisi klien, dan komponen notifikasi dengan animasi. Waktu adalah prioritas, bukan kesempurnaan.

Hasil Sonnet 4.6: Memberikan implementasi yang berfungsi dalam satu respons. Handler WebSocket, custom React hook, dan komponen notifikasi semuanya bekerja bersama. Animasinya berbasis CSS dan mulus. Masalah kecil: tidak ada logika koneksi ulang.

Hasil Opus 4.6: Output dengan kualitas serupa tetapi menyertakan logika koneksi ulang dan strategi exponential backoff. Juga menambahkan mekanisme heartbeat. Membutuhkan waktu sekitar 30% lebih lama untuk menghasilkan output karena kecepatan token yang lebih rendah.

Pemenang: Sonnet 4.6

Untuk prototyping, kecepatan lebih penting daripada kelengkapan. Pembuatan output Sonnet yang lebih cepat (sekitar 47 tokens per detik dibandingkan 40 untuk Opus) berarti siklus iterasi yang lebih ketat. Logika koneksi ulang yang ditambahkan Opus memang bagus, tetapi saya bisa saja menambahkannya pada iterasi kedua. Prototyping menghargai output yang cepat dan cukup baik.

Biaya: Sonnet $0.10 | Opus $0.48

Skenario 8: Pengambilan Keputusan Arsitektural

Tugas: Kami perlu memilih antara struktur monorepo dan polyrepo untuk proyek microservices. Saya memberikan ukuran tim, persyaratan deployment, batasan CI/CD, dan batas-batas layanan. Saya meminta kedua model untuk menganalisis kelebihan dan kekurangan serta merekomendasikan sebuah pendekatan.

Hasil Sonnet 4.6: Memberikan analisis pro/kontra yang solid. Merekomendasikan monorepo dengan Turborepo berdasarkan ukuran tim. Masuk akal tetapi agak umum.

Hasil Opus 4.6: Mengajukan tiga pertanyaan klarifikasi sebelum memberikan rekomendasi — tentang frekuensi deployment, dependensi data lintas layanan, dan apakah tim memiliki pengalaman monorepo. Setelah saya menjawab, ia memberikan analisis bernuansa yang merekomendasikan pendekatan hybrid: monorepo untuk pustaka bersama dan layanan yang terkait erat, repositori terpisah untuk layanan yang dideploy secara independen dengan siklus rilis yang berbeda. Ia juga menguraikan jalur migrasi dari struktur saat ini.

Pemenang: Opus 4.6

Opus menangani ambiguitas dengan lebih baik. Sebagaimana dikonfirmasi oleh berbagai laporan pengembang, Opus mengajukan pertanyaan klarifikasi yang lebih baik dan membuat asumsi yang lebih dapat dipertahankan. Untuk senior engineers yang bekerja pada keputusan arsitektur yang kompleks, perilaku tersebut menghemat waktu berjam-jam dalam tanya jawab.

Biaya: Sonnet $0.07 | Opus $0.62

Hasil Akhir

Inilah performa masing-masing model di delapan skenario, dinilai pada skala 1-10 untuk kualitas output:

Opus 4.6 menang: 4 skenario (debugging, refactoring, code review, arsitektur) Sonnet 4.6 menang: 2 skenario (dokumentasi, prototyping) Seri: 2 skenario (CRUD endpoints, penulisan pengujian)

Namun inilah bagian yang disembunyikan oleh kartu skor tersebut: Sonnet 4.6 adalah pilihan yang tepat dalam 6 dari 8 skenario ketika Anda memperhitungkan biaya. Dua skenario di mana ia mendapat nilai jauh lebih rendah (refactoring dan arsitektur) adalah tugas yang dilakukan sebagian besar developer beberapa kali seminggu, bukan puluhan kali sehari.

Realitas Biaya

Selama tiga minggu pengujian, inilah rincian tagihannya:

Opus memakan biaya rata-rata 5.25x lebih besar per tugas. Untuk set tugas yang identik, Sonnet memberikan 90% kualitas dengan biaya 19%.

Jika saya menggunakan pendekatan hybrid — Sonnet untuk tugas rutin, Opus hanya untuk 20% tugas yang melibatkan refactoring, debugging, dan arsitektur — total tagihan saya akan menjadi sekitar $160, bukan $500. Itu adalah pengurangan sebesar 68% dengan hampir tidak ada penurunan kualitas.

Ini konsisten dengan apa yang dilaporkan oleh deployment produksi: pola hybrid router di mana 80-90% permintaan masuk ke Sonnet dan hanya tugas-tugas kritis yang dialihkan ke Opus menghemat 60-80% biaya API.

Tiga Pola yang Saya Perhatikan yang Tidak Ditangkap oleh Benchmark

1. Opus lebih baik dalam mengatakan "tunggu, saya butuh informasi lebih lanjut"

Pada prompt yang ambigu, Sonnet cenderung memilih default yang masuk akal dan menjalankannya. Opus berhenti sejenak dan bertanya. Ini sangat berharga untuk pekerjaan arsitektural tetapi sedikit mengganggu untuk tugas-tugas rutin di mana Anda hanya ingin ia membuat pilihan dan segera menyelesaikannya.

2. Sonnet lebih baik dalam mengikuti instruksi secara harfiah

Ketika saya memberikan spesifikasi terperinci, Sonnet membangun tepat seperti yang saya minta. Opus terkadang "meningkatkan" hal-hal yang tidak saya minta untuk ditingkatkan — menambahkan lapisan abstraksi, menyarankan pola, menyertakan edge cases di luar cakupan. Untuk tugas di mana Anda menginginkan kepatuhan di atas kreativitas, Sonnet menang.

3. Celah kualitas melebar seiring dengan panjangnya konteks

Untuk tugas di bawah 10K tokens konteks, saya hampir tidak bisa membedakan kedua model tersebut. Setelah konteks melebihi 30K tokens — refactor besar, tinjauan multi-file — Opus menjadi jauh lebih koheren. Ini konsisten dengan skor 76% Opus 4.6 pada MRCR v2 untuk penalaran multi-file dalam konteks panjang.

Posisi Benchmark (sebagai Referensi)

Bagi mereka yang menginginkan angka-angka, berikut adalah benchmark utama per Maret 2026:

Sumber: Ikhtisar model Anthropic, Artificial Analysis, Analisis benchmark Claude 5

Kesenjangan SWE-bench hanya 1.2 poin. Tetapi kesenjangan GPQA Diamond (penalaran ilmiah) sangat besar — 17 poin. Dan kesenjangan MRCR v2 (pekerjaan multi-file konteks panjang) adalah tempat di mana perbedaan praktis yang nyata berada.

Rekomendasi Saya: Kerangka Kerja Keputusan

Setelah pengeluaran $500 dan tiga minggu pengujian, inilah decision tree saya:

Gunakan Sonnet 4.6 ketika:

• Tugas terdefinisi dengan baik dengan persyaratan yang jelas
• Anda sedang menulis kode baru dari awal (endpoints, komponen, skrip)
• Anda membutuhkan kecepatan iterasi yang cepat (prototyping, eksplorasi kode)
• Anda sedang membuat pengujian atau dokumentasi
• Panjang konteks di bawah 20K tokens
• Anda memiliki anggaran terbatas atau menangani volume permintaan yang tinggi

Gunakan Opus 4.6 ketika:

• Tugas melibatkan refactoring di beberapa file dengan dependensi yang kompleks
• Anda membutuhkan model untuk memikirkan kelebihan dan kekurangan sebelum menetapkan desain
• Anda sedang melakukan debugging pada masalah yang tidak jelas di codebase besar
• Anda sedang meninjau kode yang kritis secara keamanan
• Panjang konteks melebihi 30K tokens dan koherensi sangat penting
• Biaya dari jawaban yang salah melebihi biaya pemanggilan model tersebut

Gunakan keduanya (hybrid router) ketika:

• Anda sedang membangun sistem produksi dengan kompleksitas tugas yang beragam
• Anda menginginkan penghematan biaya 60-80% dari Sonnet dengan jaring pengaman Opus untuk masalah yang sulit

Untuk tim yang membangun alat developer — kami menggunakan versi pendekatan hybrid ini di ZBuild — pola router telah menjadi standar industri untuk tahun 2026.

Apa yang Akan Saya Lakukan Secara Berbeda

Jika saya menjalankan eksperimen ini lagi, saya akan menambahkan dimensi ketiga: mengukur berapa banyak follow-up prompts yang dibutuhkan setiap model untuk mencapai output yang siap produksi. Firasat saya mengatakan ini akan lebih menguntungkan Opus pada tugas-tugas kompleks, karena akurasi percobaan pertamanya secara konsisten lebih tinggi untuk pekerjaan multi-file.

Saya juga akan menguji dengan fitur extended thinking yang diaktifkan untuk Opus, yang dilaporkan dapat meningkatkan penalaran debugging dan arsitekturalnya yang sudah kuat.

Intinya: mulailah dengan Sonnet 4.6 untuk segalanya. Anda akan tahu — dengan cepat — kapan sebuah tugas menuntut Opus. Tugas-tugas yang menuntutnya bersifat spesifik, relatif jarang, dan bernilai cukup tinggi untuk membenarkan biaya preminya.

Sumber

• Anthropic — Introducing Claude Opus 4.6
• Anthropic — Claude Models Overview
• Anthropic — Claude Pricing
• Artificial Analysis — Claude Sonnet 4.6 Performance
• Claude 5 — Opus 4.6 Benchmark Analysis
• Bind AI — Sonnet 4.6 vs Opus 4.6 for Coding
• Emergent — Claude Sonnet vs Opus 2026
• DEV Community — Opus 4.6 vs Sonnet 4.6 Coding Comparison
• Macaron — Claude Opus 4.6 for Code Review
• Apiyi — Opus 4.6 vs Sonnet 4.6 Comparison Guide
• Medium — Tested Sonnet 4.6 vs Opus 4.6 for Vibe Coding