Uber menghabiskan seluruh anggaran AI 2026 untuk Claude Code hanya dalam 4 bulan

• Uber menghabiskan seluruh anggaran AI 2026 hanya dalam 4 bulan akibat perluasan penggunaan Claude Code dan Cursor, dan eksperimen produktivitas itu langsung berujung pada peninjauan ulang anggaran
• CTO Uber mengungkapkan bahwa biaya API bulanan per insinyur berada di kisaran $500–$2.000, dan 95% insinyur menggunakan alat AI setiap bulan
• 70% kode yang di-commit di Uber berasal dari AI, menandakan alat coding AI telah masuk ke alur kerja inti rekayasa
• Claude Code didistribusikan ke tim engineering pada Desember 2025, lalu setelah kemampuan tugas multilangkahnya terbukti, penggunaannya meningkat dua kali lipat hingga Februari 2026, dan pada April seluruh anggaran tahunan sudah habis
• Sementara pertumbuhan penggunaan Cursor melambat, Claude Code menjadi alat yang dominan, dan Uber kini harus menghitung ulang biaya alat coding AI di dalam pengeluaran R&D tahunan sebesar $3,4 miliar

---

Perluasan adopsi dan peninjauan ulang anggaran

• Uber melihat nilai besar dari Claude Code dan Cursor hingga para insinyur sulit berhenti menggunakannya, meski biayanya melonjak cepat
• Pada Desember 2025, akses ke Claude Code didistribusikan ke tim engineering, dan setelah kemampuan tugas multilangkahnya terverifikasi, penggunaannya meningkat dua kali lipat hingga Februari 2026
• Pada April 2026, biaya tersebut telah menghabiskan seluruh anggaran AI tahunan, membuat kepemimpinan harus mengambil keputusan yang tidak terduga
• CTO Uber mengatakan perusahaan harus kembali “back to the drawing board” dalam menyusun anggaran AI

Perubahan penggunaan per alat

• Cursor adalah alat besar lain yang ikut bersaing dalam adopsi, tetapi pertumbuhan penggunaannya mandek
• Claude Code menjadi alat yang dominan dalam workflow engineering
• Adopsi yang awalnya dimulai sebagai eksperimen produktivitas dengan cepat meluas, sehingga penggunaan alat AI di pekerjaan engineering internal perusahaan benar-benar menjadi arus utama

Arti tekanan biaya

• Pengeluaran anggaran Uber yang tak terduga menunjukkan seberapa bernilainya alat AI dipandang untuk produktivitas engineering
• Peran alat AI kini telah membesar sampai pembatasan akses justru terasa kontraproduktif
• Seiring semakin banyak pengembang mengadopsi Claude Code, ada kemungkinan perusahaan lain mengalami dampak serupa
• Perusahaan software akan menghadapi tekanan untuk mengelola biaya sambil mempertahankan kecepatan pengembangan
• Jika alat produktivitas pengembang dipakai sedemikian bernilai hingga para insinyur menghabiskan seluruh anggaran hanya dalam 4 bulan, maka kesimpulannya bukan alatnya yang bermasalah, melainkan anggarannya dibuat terlalu dini untuk dapat memprediksi kurva adopsi

[picopress]

Seru-seruan menghabiskan uang

[GN⁺]

Opini Hacker News

• Saat melihat pengeluaran perusahaan kira-kira sebulan sekali, membingungkan melihat semakin banyak orang menghabiskan biaya token $1k per bulan, sampai rasanya tidak masuk akal bagaimana itu bisa terjadi
  Bahkan jika memakai LLM setiap hari, model termahal, dan mode berpikir mendalam, biasanya batas atasnya sekitar $200~$400. Bukan berarti menentang penggunaannya seperti kaum luddit, tetapi sulit memahami bagaimana membakar uang sebanyak itu secara bertanggung jawab tiap bulan. Ingin melihat orang yang menghabiskan $5k~$10k per bulan menunjukkan bagaimana itu berubah menjadi nilai $50k~$100k. Dari sudut pandang perusahaan, daripada membenarkan pengeluaran token $100k per tahun, rasanya lebih baik merekrut engineer junior yang produktif dengan biaya $100~$200/bulan

  • Secara umum tampaknya ada tiga kasus ketika uang bisa dibakar sebanyak itu secara “bertanggung jawab”. Pemula biasanya terus membawa satu percakapan raksasa karena penggunaan ulang percakapan panjang, tanpa membuat kompresi konteks atau checkpoint ringkasan, seolah agen itu sudah “terlatih”
    Pengguna tingkat menengah, setelah tahu pola seperti “jalankan 5 sub-agent untuk menganalisis solusi dari sudut berbeda lalu rangkum”, mudah jadi ketagihan. Itu sendiri bukan kebiasaan buruk, tetapi kalau tidak hati-hati bisa jauh melewati kredit. Pengguna mahir bisa menjalankan 10 pohon tugas secara paralel terus-menerus, berpindah di antara respons agen, dan melakukan multitasking ekstrem sehingga biaya bisa naik secara eksponensial
  • Pertama, ada alasan klise: “kalau perusahaan mengizinkan, orang akan boros.” Ini termasuk tidak sering mengosongkan atau mengompresi konteks. Jendela konteks 1M milik Opus sekarang sudah ada, dan sampai 200K kualitasnya masih cukup bagus, jadi tiap kueri membakar banyak token sebelum konteks dibersihkan
    Basis kode yang besar atau masalah yang kompleks juga berpengaruh besar. Jika baru masuk tim dan banyak bagian belum dipahami, saat mendapat tugas kita bisa meminta Claude mencari kode terkait, memahami alur yang ada, lalu baru mencoba perubahan. Keahlian pribadi memang berkembang lebih sedikit, tetapi jika dengan Claude pekerjaan 5 hari bisa selesai dalam 1 hari dan semua orang melakukannya, sulit untuk tidak tertinggal. Jadi saya memilih jalan tengah: selesai dalam 2~3 hari, sambil tetap melihat sedikit kodenya, bukan 1 hari. Apalagi perubahan kode sekarang sangat cepat karena AI, sampai saya membuat alat yang meminta LLM menjelaskan pull request secara mendalam. Bukan untuk reviewer, tetapi agar bisa mengikuti pekerjaan tim. Saya bahkan belum terlalu memikirkan cara memakai LLM lebih jauh, dan rasanya kalau sudah lebih familier dengan basis kode saya mungkin akan memakainya jauh lebih banyak. Bottleneck-nya tetap pada pengujian dan review yang tepat. Untuk kode internal yang kurang penting atau proyek pribadi, sepertinya saya menyerahkan hampir semuanya ke AI, dan jika memakai skill “superpowers”, bahkan fungsi dasar pun membakar banyak token. Biasanya mulai dari 20~40K token lalu saat selesai mencapai 80~90K token, jadi beberapa permintaan terakhir sebelum selesai pada dasarnya mengirim hampir 80K token. Boros, tetapi kalau orang lain yang bayar, jadinya begitu
  • Saya pernah melihat Claude Code memilih solusi yang sangat tidak efisien secara token untuk suatu masalah. Sebuah masalah machine learning/prediksi yang kompleks dibagi ke beberapa agen, dan tiap agen memakai, menjalankan, serta membaca notebook Jupyter
    Awalnya baik-baik saja, tetapi satu agen menulis ratusan ribu baris ke output sel dan membuat file ipynb 500MB, lalu Claude mencoba membacanya berkali-kali sampai seluruh batas konteks habis. Solusinya adalah menetapkan struktur kerja yang lebih baik dengan skrip analisis CLI dan folder penyimpanan hasil riset, tetapi saya sebagai operator tetap harus membuat rencana dan desainnya. Sulit melihat orang yang menghabiskan token $10k per bulan selain sebagai orang yang dengan malas membiarkan Claude Code, palu mahal itu, menyelesaikan masalah. Misalnya membiarkan Claude membaca semua email setiap hari, padahal solusi yang lebih cerdas adalah lebih dulu menghilangkan noise dari HTML isi email
  • Ini sangat bergantung pada repositori yang sedang dikerjakan. Kalau sangat besar, terutama jika harus merujuk framework kustom dan dokumentasi API dengan banyak alat, maka perlu jendela konteks besar sehingga token habis jauh lebih cepat
    Sebaliknya, kalau kecil atau memakai framework umum yang sudah dipelajari model, banyak hal bisa dilakukan dengan jendela konteks lebih kecil dan penggunaan token juga jauh lebih rendah
  • Selain biaya, saya juga tidak paham dari sisi kuota. Saya memakai paket ChatGPT 200 euro, jadi mungkin kuotanya paling tinggi, tetapi meski hampir seharian penuh hanya melakukan agent programming dengan model termahal, penalaran tertinggi, dan mode cepat, saya tetap tidak mendekati batas
    Sejak mulai memakai coding agent, satu-satunya saat saya mendekati batas adalah ketika mengerjakan pengembangan lintas platform di 3 komputer sekaligus dengan kondisi yang sama, dan itu pun hanya hampir menyentuh batas mingguan. Biasanya saya turun ke sekitar 20% dari batas, tetapi hampir tidak pernah lebih rendah dari itu. Saya juga banyak melempar prompt dan kueri untuk bersenang-senang, tapi tetap tidak tahu bagaimana cara menghabiskan lebih banyak

• Saya sadar saya sedang menjawab AI sekarang, tetapi pernyataan “mencari tahu apakah perusahaan bisa menanggung tingkat produktivitas ini dalam skala besar” terdengar aneh. Kalau memang produktif, pendapatan semestinya naik dan pertanyaan apakah mampu menanggungnya seharusnya bukan masalah

  • Benar. Produktivitas, secara definisi, menghasilkan sesuatu, idealnya sesuatu yang bernilai. Yang perlu dilihat adalah apakah biaya tambahan untuk chatbot itu sepadan dengan nilainya. Yang jadi pertanyaan adalah apakah Uber benar-benar menjadi jauh lebih efisien dan efektif berkat pembengkakan anggaran besar ini, atau hanya memberi orang cara baru yang berkilau dan mahal untuk melakukan hal yang sama
  • Pendapatan memang naik. Dari hasil terbaru Meta, bahkan dalam situasi ekonomi seperti ini pendapatan +33%. Jadi kemampuan menanggungnya bukan persoalan, dan ada alasan perusahaan seperti Meta tidak peduli jika engineer menghabiskan $1k per hari untuk token. Dibanding uang yang dihasilkan per karyawan, itu bukan jumlah yang besar
  • Tidak semua perubahan yang dibuat developer langsung menaikkan pendapatan, dan perubahan yang memang menaikkan pendapatan pun biasanya punya jedanya
  • Jika ingin memberi argumen lawan dalam bentuk terbaiknya, contoh tandingannya bisa saja bahwa para pesaing memakai alat yang sama dan mendapat peningkatan produktivitas yang sama
  • Kalau dipakai dengan benar, ini benar-benar sangat produktif. Sampai membuat khawatir seberapa cerdas model-model AI serupa ini akan menjadi tahun depan

• Pernyataan “95% engineer Uber kini memakai alat AI tiap bulan, dan 70% kode yang dikomit berasal dari AI” adalah hal yang bisa diperkirakan. Penggunaan alat AI akan seperti itu kalau dimasukkan ke penilaian kinerja

  • Mengejutkan melihat orang meremehkan betapa mudahnya hal seperti ini dimanipulasi ketika non-developer memaksakan KPI kepada developer. AI, menghitung pull request, atau menghitung jumlah baris, sama saja
  • Begitu KPI bukan lagi “apa yang diluncurkan” melainkan “seberapa banyak memakai AI”, maka ledakan anggaran akan datang dengan sendirinya. Orang akan berusaha memenuhi angka itu
  • Kalau para manajer dan vice president semua berkata “kalau tidak pakai AI, kamu tidak bisa bekerja di sini”, tentu saja orang akan memakainya
  • Saya kurang paham kritik ini. Bukankah sejak awal orang dibayar untuk melakukan apa yang perusahaan inginkan dan dianggap produktif oleh perusahaan? Dan saya juga ragu apakah pandangannya adalah bahwa semua kode hasil AI itu tidak berguna

• Saya tidak mengerti bagian “mencari tahu apakah perusahaan bisa menanggung tingkat produktivitas ini dalam skala besar.” Anggaran sudah dipakai dan ada data 4 bulan, jadi yang penting adalah hasil apa yang bisa ditunjukkan
  Saya bukan pembenci AI atau luddit, dan saya memakai paket Max $200. Tetapi apakah maksudnya Uber membuka alat ini, mendorong semua orang memakainya, lalu ketika ternyata berjalan baik mereka malah bingung melihat apa yang terjadi? Menilai bahwa produktivitas AI tidak cukup sebanding dengan biayanya adalah hal terpisah. Saya bahkan jadi bertanya apakah mereka kehabisan hal untuk dibuat selanjutnya

  • Paket Max pribadi dan Teams itu benar-benar harga yang mengejutkan jika dibandingkan dengan biaya API Enterprise berbasis pemakaian. Mungkin mereka benar-benar butuh fitur Enterprise. Kalau tidak, mestinya cukup menyuruh pengguna membebankan langganan Max $200 sebagai pengeluaran. Pada akhirnya perusahaan tetap bertindak seperti perusahaan
  • Mungkin memang belum ada yang terlihat saat ini. Perubahan besar yang terlihat oleh pengguna eksternal memang butuh waktu lebih lama untuk diluncurkan secara luas. Secara internal, kemungkinan banyak fitur yang bergerak lebih cepat
    Di Salesforce saya pernah melihat perubahan di mana pekerjaan yang biasanya butuh beberapa minggu tampak selesai dalam hitungan hari. Itu memang tidak langsung berubah menjadi uang, tetapi meningkatkan potensi untuk menghasilkan uang
  • Layak juga bertanya apa lagi yang akan Uber buat berikutnya. Mereka sudah punya platform ride-hailing yang berfungsi. Mereka juga sudah meluas ke pengantaran makanan, bahan makanan, dan “apa pun yang muat di dalam mobil”. Saya tidak tahu apa lagi yang tersisa di ranah ada orang yang mengemudikan mobil
  • Saya tidak paham kenapa, jika alat pengendali pengeluaran itu bagus, mereka tidak memasang batas. Mereka juga bisa meminta engineer membenarkan pengeluaran itu
    Harusnya mereka ditanya kenapa perlu memakai token sebanyak itu dan apa yang didapat sebagai imbalannya. Kalau ini AWS, semua orang pasti akan menunjuk dan berkata, “memangnya kamu tidak melihat pengeluaran bulanan?”
  • Rasanya diskusi AI kini sudah sampai tahap di mana agar kritik apa pun tidak dianggap sesat, orang harus lebih dulu berkata, “saya juga bagian dari sekte ini, bukan orang tak beriman”

• Menarik melihat tulisan seperti ini tiba-tiba membuat banyak orang merasa mengukur produktivitas developer itu sederhana. Benar bahwa produktivitas pada akhirnya harus berujung pada pendapatan atau penghematan biaya, dan pendapatan bisa diukur, tetapi kenyataannya tidak sesederhana itu
  Kita menghabiskan uang hari ini untuk membuat fitur yang menghasilkan pendapatan di masa depan, jadi meski biaya hari ini melonjak, belum tentu ada pendapatan yang bisa diukur sekarang. Kalau AI membuat suatu fitur selesai hari ini, itu tidak langsung berarti AI produktif atau tidak produktif; kita juga harus memperkirakan apa yang akan dilakukan tanpa AI dan bagaimana dampaknya pada pendapatan. Bisnis sering kali adalah perlombaan Ratu Merah, sehingga kalau tidak membaik kita justru kalah dari pesaing dan kehilangan pendapatan. Penggunaan AI kemungkinan mencampurkan pekerjaan penting dengan “hal-hal yang sekarang mudah jadi kita lempar saja sekalian”, dan untuk mengukur peningkatan produktivitas yang nyata, kita harus tahu bagaimana mempertahankan yang pertama dan menghindari yang kedua. Ini bukan soal pro atau kontra AI, melainkan soal jangan bermalas-malasan dengan berkata “kalau produktif pasti bisa diukur”

  • Saya justru melihat konsensus utamanya adalah bahwa mengukur produktivitas developer itu sangat sulit. Setiap kali kita mencoba mengukurnya, metrik itu sendiri segera berubah menjadi target, dan meskipun awalnya pengukuran itu kuat, akhirnya menjadi tidak bermakna
    Saya tidak tahu dari mana datangnya gagasan bahwa mengukur produktivitas orang yang bukan pekerja pabrik itu mudah
  • Rasanya fitur baru atau software yang lebih baik tidak akan terlalu banyak menaikkan pendapatan/laba Uber
  • Pilihannya bukan cuma produktivitas nol atau sebagian, tetapi juga bisa produktivitas negatif. Dari pengalaman saya memakai Claude Code, saya curiga menuangkan token sebanyak itu ke dalam organisasi bukan hanya tidak produktif, tetapi bisa aktif merugikan
  • Perubahan produktivitas kecil memang sulit diukur, tetapi lompatan besar seharusnya akan terlihat jelas. Jika AI memengaruhi produktivitas, tampaknya paling banter hanya dalam skala kecil
  • Kalau benar produktivitas 10x, itu seharusnya bisa diukur setidaknya secara tidak langsung, bahkan nyaris mustahil untuk tidak terlihat. Klaim-klaim awal jelas salah, dan pertanyaan riset yang sebenarnya adalah apakah lebih besar dari 1.0x
    Saya setuju itu sangat sulit diukur. Tetapi dengan biaya sebesar ini, perusahaan seharusnya wajib bisa menjawabnya, dan kelipatannya pun harus cukup untuk membenarkan biaya tersebut

• Menurut [1], organisasi engineering Uber berjumlah sekitar 5.500 orang. Jika ambil titik tengah rentang pengeluaran di $1.250, maka pengeluaran AI engineering kira-kira $6.8M, dengan rentang $2.75M~$12M. Tulisan itu menyebut pengeluaran R&D sebesar $3.4B
  Pengeluaran AI bukan porsi besar dari pengeluaran R&D. Dalam basis 4 bulan, sekitar 0,3%; jika disetahunkan sekitar 1%. Kalau tidak direncanakan, ini bukan uang receh dalam anggaran, tetapi dalam konteksnya juga tidak terlalu besar. Pertanyaan sebenarnya adalah apa yang didapat dari uang itu. Tulisan tersebut mengklaim 70% commit kode dihasilkan AI, jadi mungkin sudah lolos review dan testing. Yang penting adalah apakah jumlah fitur bertambah cepat, apakah masalah kualitas berkurang, atau ada manfaat lain. Sayangnya tulisan itu tidak membahas hasil selain kenaikan pengeluaran. Mungkin 4 bulan terlalu cepat untuk menilai manfaatnya. Di sisi lain, dalam dunia agile mungkin penilaiannya berbeda. [1] https://www.unifygtm.com/insights-headcount/uber

  • Sumber aslinya https://www.theinformation.com/newsletters/applied-ai/uber-c... menyebut bahwa “sekitar 11% dari pembaruan kode live aktual pada sistem backend ditulis oleh agen AI yang terutama dibuat dengan Claude Code, naik dari porsi kecil di bawah 1% tiga bulan sebelumnya”
    Juga disebut bahwa “perusahaan tidak mengungkap angka pasti anggaran software atau pengeluaran alat coding AI-nya”
  • Semua hal dalam tulisan ini tampak benar-benar palsu. Angkanya tidak cocok, tidak sesuai dengan informasi yang dilaporkan, dan terasa seperti fiksi belaka

• Sebagai orang yang sedang bootstrap, saya sering iri pada engineer di perusahaan besar, tetapi juga khawatir insentifnya rusak
  Kalau saya engineer Uber, tidak ada alasan untuk tidak menulis gpt 5.5 pro @ very high thinking + fast mode di prompt bahkan untuk perubahan kecil. Tidak ada insentif untuk tidak memakai model paling kuat, dan karena itu juga paling mahal. Saya pernah mencoba satu prompt seperti itu untuk tes konversi gambar→HTML, dan satu prompt saja menghabiskan $40. Kalau bayar sendiri, hampir pasti orang tidak akan pernah memilih setelan ini, tetapi di perusahaan besar kalau orang lain yang menanggung, tentu akan sering dipakai. Hasilnya memang jelas lebih baik. Engineer dinilai dari apa yang berhasil mereka kirim, bukan dari biaya prosesnya. Ada cara yang lebih murah, tetapi engineer tidak punya insentif untuk memilihnya

  • Software engineer itu mahal. Gaji median $133k, dan itu belum termasuk asuransi kesehatan, pajak payroll, dan lain-lain. Kalau kredit LLM $40 bisa menghemat 1 jam waktu pengembangan, maka hitungannya $26.50 lebih murah dibanding tidak memakainya
    Apakah itu benar-benar terjadi, saya masih belum yakin, tetapi secara teori seperti itulah. Upaya menurunkan biaya LLM juga pedang bermata dua. Penghematan biaya LLM harus lebih besar daripada biaya yang dikeluarkan untuk membayar developer tersebut. Kalau menghabiskan sehari penuh untuk mengurangi $1 per panggilan, butuh hampir 2 tahun hanya untuk balik modal dari biaya gaji. Belum lagi LLM berubah terlalu cepat sehingga sulit yakin solusi itu tidak akan usang dalam 2 tahun. Dua tahun lagi, bahkan penyedia frontier pun mungkin belum tahu apakah kita masih akan memanggil tool, apakah mode reasoning masih ada, dan seterusnya
  • Perusahaan mungkin ingin terlebih dulu melihat seberapa cepat pekerjaan bisa diskalakan, lalu setelah itu baru menekannya demi efisiensi
  • Gambar→HTML itu pekerjaan yang cukup kompleks. Pada dasarnya itu pekerjaan frontend developer, dan $40 bahkan tidak sampai 1 jam waktu mereka

• Makin sering eksekutif berpikir software engineering bisa digantikan oleh agen, saya jadi bertanya apakah mereka membuat keputusan berdasarkan pandangan yang tidak realistis tentang rata-rata software engineer
  Di satu sisi memang ada unsur garbage in, garbage out. CTO yang cerdas bisa sangat antusias dengan apa yang bisa dilakukan agen, lalu keliru mengira semua engineer juga bisa melakukan hal yang sama. Kenyataannya, engineer rata-rata di organisasi mungkin bahkan tidak punya kreativitas untuk membayangkan di mana pekerjaan bisa dikurangi. Maka jika penggunaan agen diwajibkan, produktivitas bisa tidak naik sama sekali dan biaya AI malah bertambah. Di sisi lain, memakai AI justru memperjelas dua jurang: siapa yang akan memberi tahu agen apa yang harus dilakukan, dan bagaimana menanggung siklus QA/review. Di banyak organisasi, product person tidak cukup teknis untuk membuat spesifikasi atau rencana rinci yang bisa dipakai LLM, sementara developer yang berperan seperti roda gigi mesin tidak berada pada posisi membuat spesifikasi dan hanya ingin mengimplementasikan. Jika developer pengguna agen justru diharapkan membuat implementasinya, yang bisa terjadi adalah makin banyak orang yang menganggur sambil menunggu pekerjaan datang. Saya mendukung adopsi LLM yang opsional untuk meningkatkan kecepatan dan kualitas developer yang sudah ada, tetapi arus “mari restrukturisasi organisasi” terasa cukup berbahaya, terutama bagi perusahaan kecil dan menengah

  • Lebih dari itu, AI adalah pengganda kekuatan, dan ia tidak peduli apakah kekuatan itu bernilai positif atau negatif. Jika orang dengan prinsip software engineering yang buruk memakai AI, dalam sekejap ia bisa menciptakan kekacauan total
  • Terkait poin nomor 2, perusahaan kami sangat mendorong developer agar punya product mindset dan tidak terlalu menjadi roda gigi belaka
    Saya mungkin bias karena product mindset saya sendiri lebih kuat dibanding developer lain, tetapi saya melihat orang seperti ini berada pada posisi yang lebih produktif saat memakai agen. Mereka cukup paham teknis untuk mengimplementasikan lewat agen, dan juga cukup paham produk untuk tahu apa yang harus diimplementasikan. Saya kira perusahaan lain juga akan bergerak ke arah itu
  • Pada akhirnya itu sama saja dengan berbicara tentang pengurangan besar-besaran jumlah karyawan

• Saya tidak tahu Uber sedang mengembangkan apa. Mereka punya aplikasi dan backend penugasan kendaraan, dan keduanya sudah cukup berfungsi. Saya heran kenapa mereka menghabiskan sebanyak itu
  Kendaraan otonom sudah mereka tinggalkan, jadi pasti bukan itu

  • Ini pertanyaan yang sangat diremehkan. Ini menunjukkan dengan baik apa sebenarnya yang dilakukan perusahaan teknologi modern dengan semua sumber daya besar itu. Elon memangkas sebagian besar tim Twitter, dan setelah serangkaian kesalahan awal yang mengerikan, bukankah akhirnya sistem itu tetap berjalan lumayan baik meski dengan 80% lebih sedikit orang?
  • Andaikan “keduanya cukup berfungsi” itu benar, tetapi kenyataannya tidak. Pengalaman pengguna sekarang begitu buruk karena optimisasi algoritme pencocokan sampai saya rutin memakai Lyft
  • Komentar model “X itu cuma Y, jadi kenapa bisa serumit ini” adalah salah satu tipe komentar paling membosankan di HN. Menulis begitu pada setiap artikel tentang perusahaan besar yang tidak disukai terasa malas dan melelahkan dibaca

• Dengan token API, terutama kalau memakai konteks 1M tanpa hati-hati membersihkan konteks lama, sangat mudah menghabiskan ratusan dolar dalam satu sesi
  Sementara itu, langganan mengizinkan penggunaan serupa hanya dengan biaya beberapa ratus dolar per bulan. Tampaknya Anthropic entah menagih pengguna API sangat mahal, atau sangat mensubsidi langganan, atau keduanya

  • https://www.forbes.com/sites/annatong/2026/03/05/cursor-goes...
    “Tahun lalu Cursor memperkirakan bahwa langganan Claude Code $200 per bulan bisa memakai komputasi senilai hingga $2.000, yang mengisyaratkan subsidi besar dari Anthropic. Sekarang subsidinya tampak lebih agresif lagi: paket $200 dapat mengonsumsi komputasi senilai sekitar $5.000”
  • Anthropic punya model bisnis yang cukup “menarik”. Saat karyawan masih 150 orang atau kurang, mereka memungut harga langganan, tetapi begitu menjadi 151 orang, seluruh karyawan tiba-tiba harus membayar harga API dalam semalam dan total tagihan langsung melonjak beberapa kali lipat
    Mereka seperti membuat orang kecanduan token murah lalu menagih balik saat skala membesar. Uber mungkin mendapat diskon dari harga resmi, tetapi jelas tidak akan mendekati harga langganan untuk 150 orang ke bawah
  • Saya sudah meninjau harganya, tetapi tetap tidak bisa membenarkan lompatan dari Team ke Enterprise. Begitu pindah ke Enterprise, langganan bulanan hilang sepenuhnya dan kita kehilangan kemampuan mengendalikan biaya
    Kita memang bisa menetapkan batas per pengguna, tetapi tanpa batas rolling bulanan, akhirnya kita bisa berada dalam situasi harus berkata pada anggota tim, “sisa bulan ini tidak ada AI untukmu.” Dengan struktur saat ini, menurut saya itu transaksi yang cukup berisiko