Analisis pascainsiden atas tiga isu penurunan kualitas Claude baru-baru ini

• Sejak Agustus hingga awal September, terjadi fenomena penurunan kualitas respons Claude yang disebabkan oleh tiga bug infrastruktur
• Penyebab utama masing-masing masalah adalah kesalahan routing context window, korupsi output, dan error approximate top-k XLA:TPU yang tidak terkompilasi
• Setiap bug saling tumpang tindih di berbagai hardware dan jalur deployment, sehingga diagnosis menjadi jauh lebih sulit
• Faktor yang menunda deteksi dan perbaikan mencakup celah dalam proses verifikasi serta pembatasan akses akibat kebijakan privasi
• Anthropic mengambil langkah pencegahan insiden serupa dengan memperkuat evaluasi dan pemantauan serta mengembangkan alat debugging yang lebih cepat

---

Ikhtisar dan latar belakang

• Sejak Agustus hingga awal September, dilaporkan adanya penurunan kualitas respons Claude yang terjadi secara intermiten
• Pada awalnya, hal ini dianggap sebagai variasi normal dalam umpan balik pengguna, tetapi investigasi dimulai setelah laporan terus meningkat
• Anthropic menegaskan dengan jelas bahwa penyebab masalah ini bukan permintaan atau beban server, melainkan semata-mata bug infrastruktur
• Claude melayani jutaan pengguna melalui berbagai platform (API, Amazon Bedrock, Google Vertex AI, dll.), dan memiliki standar verifikasi yang ketat untuk menjamin hasil yang setara di berbagai hardware seperti AWS Trainium, NVIDIA GPU, dan Google TPU
• Analisis pascainsiden ini menjelaskan penyebab bug, alasan keterlambatan diagnosis dan perbaikan, serta langkah-langkah pencegahan agar tidak terulang

Cara Claude melayani pada skala besar

• Layanan Claude mempertahankan deployment global melalui berbagai hardware (Trainium, GPU, TPU)
• Standar kesetaraan implementasi untuk menjamin kualitas yang sama di setiap platform sangat ketat
• Saat ada perubahan infrastruktur, diperlukan proses verifikasi yang presisi di semua platform dan konfigurasi

Linimasa utama terjadinya isu

• 5 Agustus: bug pertama, memengaruhi sekitar 0,8% permintaan Sonnet 4
• 25 dan 26 Agustus: bug kedua dan ketiga masing-masing dideploy
• 29 Agustus: perubahan load balancing menyebabkan lonjakan trafik bermasalah, sehingga lebih banyak pengguna terdampak
• Gejala dari tiap bug saling tumpang tindih, sehingga tingkat kesulitan diagnosis menjadi sangat tinggi

Tiga bug yang saling tumpang tindih dan proses penyelesaiannya

1. Kesalahan routing context window

• Pada 5 Agustus, sebagian permintaan Sonnet 4 salah diarahkan ke server untuk context window 1M token
• Setelah perubahan load balancing, dampaknya mencapai hingga 16% permintaan Sonnet 4, dan juga sedikit memengaruhi Amazon Bedrock serta Google Vertex AI
• Karena metode routing bersifat "sticky", setelah terhubung ke server yang salah, koneksi berikutnya terus diarahkan ke server yang sama
• Perbaikan: logika routing ditingkatkan, patch diterapkan ke platform internal pada 4 September, dideploy ke Google Cloud hingga 16 September, dan sedang diterapkan bertahap ke Bedrock

2. Korupsi output (bug)

• Pada 25 Agustus, konfigurasi yang salah diterapkan ke server TPU Claude API sehingga memicu error saat generasi token
• Muncul gejala seperti karakter yang tidak semestinya bercampur dalam jawaban berbahasa Inggris, misalnya bahasa Thai atau Tionghoa, serta kesalahan sintaks yang jelas tersisip ke dalam kode
• Hanya memengaruhi Opus 4.1, Opus 4, dan Sonnet 4; platform pihak ketiga tidak terdampak
• Perbaikan: perubahan di-rollback pada 2 September, dan pengujian untuk mendeteksi keluaran karakter abnormal ditambahkan ke proses deployment

3. Error approximate top-k XLA:TPU yang tidak terkompilasi

• Pada 25 Agustus, ketika metode pemilihan token sedang ditingkatkan, terungkap bug laten pada compiler XLA:TPU
• Memengaruhi Claude Haiku 3.5, sebagian Sonnet 4, dan Opus 3
• Platform pihak ketiga tidak terdampak
• Perbaikan: Haiku 3.5 di-rollback pada 4 September, Opus 3 pada 12 September, dan Sonnet 4 juga di-rollback sebagai tindakan pencegahan meski tidak direproduksi secara langsung
• Secara paralel, Anthropic bekerja sama dengan tim XLA:TPU untuk memperbaiki bug compiler dan beralih ke metode top-k yang akurat

Analisis detail bug compiler XLA

• Dalam proses generasi token, Claude melakukan perhitungan probabilitas untuk setiap kandidat dan proses sampling
• TPU beroperasi dalam lingkungan terdistribusi, sehingga perhitungan probabilitas token harus disinkronkan, yang menambah kompleksitas
• Pada Desember 2024, ditemukan masalah di mana token dengan probabilitas tertinggi terlewat karena error akibat penggunaan mixed precision bf16-32-bit, dan perbaikan sementara untuk hal ini telah dideploy
• Pada 26 Agustus, saat kode sampling dirombak untuk menyelesaikan akar masalah, terungkap bug yang lebih dalam, yaitu bahwa operasi approximate top-k dalam kasus tertentu menghasilkan keluaran yang sepenuhnya salah
• Bug ini sebelumnya tertutupi oleh perbaikan sementara tersebut
• Selain itu, gejala bug pada operasi approximate top-k berubah secara tidak teratur tergantung lingkungan produksi dan ukuran batch
• Sebagai pengganti approximate top-k, belakangan ini Anthropic beralih ke exact top-k, yang kini memiliki beban performa jauh lebih rendah, serta meningkatkan operasi utama dengan standarisasi fp32

Penyebab keterlambatan deteksi

• Digunakan prosedur seperti evaluasi otomatis berkala dan deployment ke kelompok awal lebih dulu
• Insiden kali ini menunjukkan adanya celah dalam proses evaluasi. Misalnya, item evaluasi yang kurang mampu mendeteksi situasi bermasalah, serta kebijakan privasi internal (engineer tidak dapat mengakses permintaan pengguna secara spesifik) yang menyulitkan analisis cepat
• Gejala muncul secara beragam tergantung platform dan versi, sehingga sulit mengidentifikasi satu penyebab tunggal
• Bahkan ketika laporan online meningkat tajam, keterkaitannya dengan perubahan load balancing standar tidak langsung disadari

Peningkatan dan langkah penanganan ke depan

• Mengembangkan item evaluasi dengan sensitivitas tinggi dan memperkuat evaluasi otomatis agar dapat lebih jelas membedakan kondisi rusak dan implementasi normal
• Memperluas sistem evaluasi dan pemantauan ke seluruh lingkungan produksi nyata, misalnya dengan evaluasi yang berfokus pada kondisi operasional seperti error routing context window
• Membangun alat debugging yang lebih cepat dan lebih canggih, serta mengembangkan infrastruktur dan alat kustom agar umpan balik komunitas dapat dianalisis cepat sambil tetap menjaga privasi
• Selain evaluasi internal, Anthropic juga menekankan pentingnya keandalan pengumpulan umpan balik pengguna secara berkelanjutan: untuk error atau bug yang sulit diprediksi, laporan pengguna nyata berperan sebagai sinyal penting
• Anthropic secara aktif mendorong penggunaan perintah "/bug" atau fitur 'thumbs down', serta pengiriman lewat email tentang cara mengevaluasi kualitas model

Penjelasan referensi

• XLA:TPU adalah compiler yang mengubah kode bahasa optimisasi tingkat tinggi XLA menjadi instruksi TPU
• Karena ukuran model besar, model dibagi ke beberapa chip, bukan dijalankan pada satu chip saja, dan operasi seperti sorting perlu diimplementasikan dalam bentuk vektorisasi
• Operasi approximate top-k digunakan untuk meningkatkan performa, tetapi dapat mengandung masalah serius seperti mengabaikan token dengan probabilitas tertinggi
• Saat ini metode exact top-k telah diadopsi, dan mungkin ada perubahan halus pada pola token yang disertakan di dekat ambang top-p. Dalam beberapa kasus, pengguna mungkin perlu menyesuaikan nilai top-p

[GN⁺]

Pendapat Hacker News

• Hal menarik yang baru-baru ini terlihat adalah ditemukannya ketiadaan unit test. Bahkan test untuk bug compiler XLA juga hanya sebatas mencetak output, sehingga masih jauh dari unit test sungguhan yang dijalankan dalam test harness nyata sambil melacak coverage. Solusi yang diusulkan terdengar seperti lebih banyak bergantung pada Eval. Saat ini unit testing untuk keseluruhan LLM memang tidak realistis, tetapi sebagian besar bug yang terungkap sejauh ini berada di bagian kecil sistem yang deterministik. Misalnya load balancing, perhitungan probabilitas top-k, dan sebagainya semuanya adalah bagian yang direkayasa seperti software lain pada umumnya, jadi pada prinsipnya bisa diuji dengan unit test. Jika perlu, satu PRNG yang dapat diinjeksikan saja sudah cukup. Bug optimisasi non-deterministik memang jelas merepotkan, tetapi saya juga pernah menemukan bug compiler dan database di masa lalu hanya dengan test suite aplikasi biasa. Jika banyak test dijalankan berulang di CI, kejadian langka pun bisa muncul. Dalam proyek pribadi yang sedang saya kerjakan, semua unit test dijalankan paralel dalam proses yang sama, dan dengan cara ini saya cukup efektif menemukan issue thread safety yang jarang muncul maupun deadlock database. Beberapa hari lalu di thread terkait peluncuran Java, saya sempat menyebut bahwa alasan Java dianggap lebih "enterprise" daripada Python adalah karena kodenya ditulis dengan fokus pada unit test. Karena kebutuhan seperti dependency injection, abstraksi pun jadi banyak dibuat. Sebaliknya, dalam budaya bahasa scripting, test sering kali sama sekali tidak ada atau hanya dilakukan secara dangkal saja (misalnya hanya assertion pada type). Saat belajar PyTorch saya juga mendapat kesan serupa; tutorial-nya memang mencakup hal yang makin kompleks secara bertahap, tetapi hampir tidak membahas test atau struktur kode. Ini mungkin cocok untuk riset ML yang tujuannya menaikkan skor evaluasi, tetapi tidak cocok untuk deployment produksi berskala besar. Saya jadi bertanya-tanya apakah lab AI tidak memerlukan lebih banyak orang berlatar belakang SRE atau software engineer HA. Secara pribadi saya ragu bahwa menjalankan Eval secara agresif di production adalah cara terbaik untuk mencegah bug
  • Saya pernah harus memberikan prompt yang sangat rinci beserta contoh agar AI menulis unit test Python dalam bentuk yang saya inginkan. Saya juga sering melihat AI hanya menulis assertion untuk type. Yang saya inginkan adalah assertion terhadap nilainya sendiri. AI cenderung memock(mocking) semuanya, dan meskipun mocking berguna, dalam unit test makin banyak kode nyata yang dipanggil, makin besar pula cakupan terhadap risiko interaksi kode dan interface. Namun unit test Python hasil AI terlalu terobsesi pada mocking, sehingga sering kali hanya memverifikasi kode yang sifatnya tautologis dan selesai di situ. Karena itu saya aktif memasukkan peringatan agar berhati-hati dengan mocking dan contoh test yang teliti ke dalam prompt. Sebagai catatan, Python juga punya banyak tool yang sangat baik untuk menulis kode yang terstruktur, seperti dependency injection
• Saya terkejut artikel itu menyebut bahwa Anthropic bisa berdampak langsung pada infrastruktur AWS Bedrock. Ini bertentangan dengan janji awal AWS. Saya rasa Google Vertex AI juga demikian, meskipun saya belum memverifikasinya dari sisi compliance. <br> > Saya setuju dengan pernyataan bahwa karena kebijakan privasi dan keamanan internal, akses engineer ke interaksi pengguna Claude dibatasi. <br> > Saya juga setuju bahwa mengirim feedback secara langsung oleh pengguna tetap yang paling membantu, dan bahwa di Claude Code ada perintah /bug yang bisa digunakan. Jika laporan dikirim lewat perintah itu, engineer kemungkinan bisa melihat konteksnya, tetapi sebagai pengguna saya berharap prosedur ini diberi tahu dengan sangat jelas (saya bukan pengguna Claude Code). <br> > Panduan untuk menggunakan tombol "thumbs down" di aplikasi Claude agak mengkhawatirkan. Kebanyakan pengguna mungkin tidak menganggap bahwa menekan tombol ini punya bobot yang setara dengan melepaskan privasi mereka
  • (Karyawan Anthropic, berbicara atas nama pribadi) <br> > Pernyataan bahwa Anthropic mengelola langsung infrastruktur AWS Bedrock tidak benar. Saat ini AWS yang mengoperasikannya secara langsung. <br> > Soal pemberitahuan privasi pada tombol "thumbs down", di modal tersebut tertulis, "Dengan mengirimkan feedback ini, seluruh percakapan saat ini akan dikirim ke Anthropic dan digunakan untuk peningkatan model." Saya penasaran apakah ada cara untuk membuat kalimat pemberitahuan ini lebih mudah dipahami
  • Saat mengklik "thumbs down", ada pesan yang menjelaskan, "Dengan mengirimkan feedback ini, seluruh percakapan akan dikirim ke Anthropic," jadi menurut saya pemberitahuannya cukup jelas
• Jika lab sekelas Anthropic sampai membagikan detail infrastruktur, sepertinya situasinya memang cukup sulit. Bug presisi di sisi FMA (multiply-accumulate) sungguh disayangkan, dan masalah numerik memang sering sangat membingungkan serta masih di luar jangkauan AI untuk menyelesaikannya. Dalam situasi tekanan ekstrem ketika pesaing merebut pangsa pasar secara real-time, campur tangan manusia pada akhirnya tetap penting, dan mencari akar penyebabnya bisa memakan waktu berminggu-minggu
• Ada penjelasan bahwa "perubahan load balancing pada 29 Agustus secara tidak sengaja membuat lebih banyak request konteks pendek dikirim ke server konteks 1M, dan selama satu jam pada 31 Agustus, 16% request Sonnet 4 terdampak". Ini terdengar seolah server konteks 1M justru berkinerja lebih buruk pada input konteks pendek. Mungkin karena server-server ini memakai pendekatan terpisah seperti kompresi KV cache, eviction, sparse attention, dan sebagainya?
  • Ini disebabkan oleh penskalaan RoPE(rotary positional embedding). Kebanyakan framework open source terkenal mengimplementasikan static YaRN, yang faktor scaling-nya tetap tak peduli panjang input, sehingga bisa memengaruhi performa saat memproses teks pendek. Sebaiknya konfigurasi rope_scaling hanya ditambahkan saat memang membutuhkan konteks panjang, dan faktornya juga disesuaikan dengan panjang input rata-rata aplikasi. Misalnya jika berada di sekitar 520 ribu token, lebih baik set factor ke 2.0 <br> Sumber (halaman penjelasan Qwen3-Next-80B)
  • Inti dari laporan postmortem mereka adalah bahwa untuk dua dari tiga masalah, penyebab pastinya belum ditemukan. Sejauh yang saya pahami, request saya sekarang bisa dikirim ke salah satu dari tiga jalur kode yang sepenuhnya berbeda, masing-masing dengan stack dan tuning terpisah. Optimisasi ini juga bisa tiba-tiba berubah tanpa ada hubungannya dengan upgrade versi model, jadi sesuatu yang kemarin berjalan baik bisa rusak hari ini. Sampai-sampai saya malah makin frustrasi dan tidak mengerti kenapa postmortem seperti ini dipuji
• Dengan segala hormat kepada tim Anthropic, kualitas halaman status Claude seharusnya sudah cukup untuk memicu code red secara internal. Ada 50 insiden pada Juli, 40 pada Agustus, dan 21 pada September. Dulu saya pernah mengalami situasi di mana setengah dari angka itu saja sudah cukup untuk membelokkan arah organisasi secara keras agar semua fokus ke uptime dan kualitas. Meski begitu, Claude tetap produk yang hebat sehingga saya masih terus membayar. Saya mencoba API-nya lalu langsung berlangganan Max membership. Produktivitas saya melonjak karenanya. Tetapi penurunan kualitas yang terus berulang dalam beberapa minggu terakhir membuat saya mulai ragu apakah langganan ini patut diteruskan. Saya menghargai keterbukaan mereka dalam membagikan kondisi masalahnya, tetapi dari sudut pandang pelanggan tetap sangat mengecewakan. Saya rasa issue seperti load balancing juga belum benar-benar terdeteksi sepenuhnya, apalagi terselesaikan. Secara spesifik, sekitar pukul 12 siang (Timur)/9 pagi (Barat), kualitas Claude Code terasa turun cukup banyak. Saya harap tim terus mencari dan memperbaiki masalah ini. Saat menjalankan model lokal di rumah pun saya sering menghadapi bug rumit, jadi saya paham masalah seperti ini memang tidak mudah. <br> tautan halaman status
  • Saya tidak bisa memastikan apakah Claude lebih baik atau lebih buruk dibanding perusahaan lain, tetapi satu hal yang pasti adalah banyak halaman status perusahaan yang penuh kebohongan. Gangguan sebenarnya sering terjadi, tetapi tidak ditampilkan di halaman status. Malah sekarang saya lebih terkejut kalau mereka jujur soal masalahnya. Secara pribadi saya belum mengalami issue serius di Claude, tetapi mungkin saya hanya beruntung. Dari sudut pandang saya, justru Claude tampaknya lebih rajin melaporkan gangguan. Tentu saja ini bisa saja kebetulan
  • Yang lebih mengkhawatirkan adalah banyak insiden kecil yang sama sekali tidak muncul di status page. Semua penyedia AI mirip begitu. Jika mereka memublikasikan grafik statistik seperti latensi token real-time, request yang gagal, atau throughput token per detik, hasilnya akan cukup mengejutkan. Dari data OpenRouter terlihat bahwa uptime API sebenarnya sama sekali tidak bagus. Claude Code juga sering menjadi sangat lambat sehingga harus dihentikan manual lalu dicoba ulang. Terutama sangat lambat pada pukul 4-6 sore (waktu UK), saat trafik dari Eropa, AS Timur, dan AS Barat bertumpuk. Hari ini pun Gemini AI studio mengembalikan error 503 karena model overload, tetapi tidak ada apa pun di status page. Saya jadi berpikir apakah Claude dan lain-lain bisa memperkenalkan paket harga lebih murah di jam off-peak agar permintaan lebih merata. Namun paket seperti itu juga mungkin terlihat buruk secara persepsi. Tambahan lagi, adopsi GPU GB200 tampaknya jauh lebih lambat dari perkiraan, dan sepertinya ada banyak cacat hardware/software. Masalah liquid cooling juga tampaknya tidak ringan (kalau gagal, dampaknya fatal)
  • Ucapan "tetap bayar karena Claude terlalu bagus" itu sendiri adalah implikasi yang penting. Pada titik ini, kualitas AI lebih penting bagi pelanggan (termasuk saya) dibanding keandalan layanan. Tentu vendor pada akhirnya juga akan fokus pada reliability, tetapi kenapa sekarang harus memprioritaskan reliability di atas kualitas?
  • Penurunan kualitas yang tajam belakangan ini cukup membuat cemas. Untungnya saya belum memakai AI untuk layanan produksi, tetapi saat pengembangan, kondisi ketika model tiba-tiba "menjadi bodoh" sangat sulit untuk diakali. Pada titik ini saya bahkan curiga berbagai vendor di openrouter diam-diam mengurangi resource komputasi dengan trik seperti memotong konteks, menurunkan tingkat kuantisasi, atau mengurangi jumlah expert
  • Karena alasan seperti inilah mereka memakai strategi meminimalkan jumlah insiden yang ditandai di halaman status. Penilaian pelanggan memang memburuk untuk sementara, tetapi seiring waktu dampak negatif itu hilang. Namun jika halaman status dijalankan secara konsisten, "bukti" masalah akan tertinggal dengan jelas. Dalam jangka panjang, menipu malah lebih menguntungkan. Faktanya, S3 beberapa kali mengalami gangguan seperti error tetapi tidak dipublikasikan, dan tidak ada yang mempermasalahkannya. Orang banyak bicara, tetapi dalam praktiknya perilaku pasar justru memberi imbalan kepada pihak yang menutup-nutupi. Semua growth hacker startup sudah paham hal ini
• Dijelaskan bahwa pada 25 Agustus, konfigurasi yang salah diterapkan pada server TPU Claude API, menyebabkan error saat token dihasilkan. Saya paham bug kode, tetapi LLM tidak ditulis langsung oleh manusia melainkan lahir dari pelatihan otomatis skala besar, jadi saya penasaran bagaimana bug seperti ini bisa muncul. Misalnya ketika di tengah query berbahasa Inggris tiba-tiba muncul 'สวัสดี' (bahasa Thai), dari sudut pandang manusia saya penasaran secara struktural bug seperti itu bisa disuntikkan bagaimana
  • LLM pada akhirnya tetap dijalankan oleh kode yang ditulis manusia. Pada tahap terakhir, model menghasilkan distribusi probabilitas untuk seluruh token(vocab sekitar 200 ribu). Setelah itu manusia memutuskan bagaimana token berikutnya benar-benar dipilih. Misalnya selalu mengambil token dengan probabilitas tertinggi, atau memilih secara acak dari top-k untuk meningkatkan kreativitas. Untuk memproses sampling top-k ini secara efisien, kernel dikompilasi dengan XLA, dan tampaknya ada bug di kernel tersebut sehingga sesekali token di luar top-k ikut terpilih
  • LLM mengeluarkan distribusi probabilitas untuk token berikutnya, dan hasil aktualnya berubah sesuai metode sampling contoh. Misalnya kalau logikanya adalah "acak dari 4 probabilitas tertinggi" lalu operatornya(tanda pertidaksamaan) salah, terjadilah fenomena seperti di artikel
  • Di antara pengguna dan parameter model ada banyak lapisan kode yang ditulis manusia
  • Sederhananya, ada dua tahap: training dan inference. Training berlangsung lama secara otomatis, tetapi inference adalah stack software terpisah yang dijalankan segera setelah prompt pengguna masuk. Stack ini terus menerima update untuk peningkatan performa, dan dalam proses itulah issue terkait inference seperti ini muncul
  • Kernel AI adalah komputasi floating point, sehingga dalam rentang bilangan real biasa, nilai yang seharusnya tidak negatif bisa secara aneh menjadi negatif. Demi performa, pemeriksaan overflow kadang dimatikan, dan ketika nilai negatif muncul, kadang itu diperlakukan sebagai bilangan yang sangat besar (mirip seperti meminta indeks array ke--1 lalu yang keluar malah elemen terakhir)
• Saya rasa memikirkan cara membuat proses inferensi LLM menjadi deterministik mungkin bisa membantu pelacakan masalah. Baru-baru ini juga ada paper yang menyatakan bahwa "anggapan umum bahwa penyebab utamanya hanyalah urutan penggabungan floating point ternyata sama sekali bukan inti masalahnya" <br> pengantar paper terkait
  • Trafik jaringan atau beban mesin pada dasarnya non-deterministik. Dalam waktu dekat, determinisme penuh (misalnya untuk audit) hanya realistis untuk pekerjaan batch yang tidak sensitif biaya. Faktanya, Google Search maupun pemuatan jumlah rekomendasi media sosial juga sama sekali tidak deterministik. Dalam sistem terdistribusi, saran kuncinya adalah graceful degradation (menjaga sebagian layanan tetap berjalan), tetapi dalam sistem yang sepenuhnya deterministik respons seperti itu tidak mungkin dilakukan
  • Desain deterministik berdampak negatif pada performa. Pada akhirnya yang tersisa adalah pendekatan seperti "tes IQ" dengan membuat model lain untuk memantau dan memberi peringatan terhadap kualitas model yang ada
• Saya setuju dengan pernyataan bahwa "di Google Cloud Vertex AI, routing yang salah antara 27 Agustus-16 September kurang dari 0,0004%". Dalam pekerjaan saya memang menggunakan CC dengan akun itu, dan saya tidak pernah merasakan penurunan kualitas. Secara keseluruhan bug-bug ini memang serius, tetapi rasanya jauh lebih jarang daripada yang disebutkan di ulasan online. Periode terjadinya issue juga sebenarnya kebanyakan terkonsentrasi dalam 1-2 minggu. Proporsi request yang terdampak dibanding seluruh request juga relatif kecil
  • Tetapi di artikel perusahaan itu sendiri juga tertulis bahwa "30% pengguna Claude Code setidaknya sekali dirouting ke server yang salah dan mengalami penurunan kualitas respons". Karena routing-nya bersifat sticky, setelah sekali dialokasikan ke server yang salah, request berikutnya terus dikirim ke server yang sama. Jika 30% pengguna Claude Code mengalami penurunan kualitas, itu bug yang sangat besar
  • Belakangan ini, bahkan ketika terjadi gangguan global, perusahaan sering hanya memakai ungkapan halus seperti "sejumlah kecil pengguna mengalami peningkatan error", lalu baru memperbarui status page setelah disetujui CTO, jadi saya tidak mudah percaya pada perusahaan. Jika ada perusahaan yang benar-benar berkomunikasi secara jujur, itu akan menjadi keunggulan di pasar
• Pendapatnya adalah bahwa jika layanan LLM dibuat berjalan secara deterministik, pelacakan masalah akan lebih mudah. Juga disebutkan paper terbaru yang menunjukkan bahwa penyebab yang selama ini hanya dikaitkan pada urutan asosiasi operasi floating point sebenarnya melibatkan faktor-faktor lain yang lebih beragam dalam runtuhnya determinisme. tautan paper
• Saya mengalami fenomena serius belakangan ini dalam desain webapp, di mana claude membuat teks acak apa saja muncul di DOM. Sepertinya ini terjadi secara spesifik saat dipakai bersama svelte, dan saya tidak yakin apakah masalah ini berhubungan dengan fenomena dalam artikel, tetapi sebelumnya saya belum pernah mengalami penurunan kualitas separah ini
• Saya berharap postingannya menyertakan contoh kasus gagal yang sebenarnya. Saya cukup sering mengalami Claude Code berhenti total setelah tool call, jadi saya penasaran apakah itu disebabkan salah satu bug yang disebut kali ini
  • Saya juga mengalami masalah yang sama semakin sering dalam beberapa hari terakhir. Mungkin ini terpisah dari bug di artikel (meskipun tetap bug), tetapi saya berharap dugaan saya salah. Frekuensi saya harus mengirim ulang permintaan seperti "kenapa berhenti? lanjutkan" meningkat secara mencolok