Fitur Computer Use pada AI 45 kali lebih mahal daripada API terstruktur

 (reflex.dev)
1 poin oleh GN⁺ 2 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Pada tugas panel admin yang sama, agen vision memanipulasi UI lewat screenshot dan klik, sementara agen API memanggil handler aplikasi yang sama melalui respons terstruktur, sehingga hanya antarmuka yang menjadi variabel perbedaan biaya
  • Dengan prompt dasar, agen API menyelesaikan tugas dalam 8 panggilan, tetapi agen vision melewatkan 3 ulasan tertunda yang berada di bawah area yang terlihat dan hanya menyetujui 1 dari 4 ulasan
  • Setelah ditambahkan UI walkthrough 14 langkah, agen vision juga berhasil menyelesaikan tugas, tetapi membutuhkan sekitar 14 menit dan sekitar 500 ribu token input, dan panduan sedetail ini sendiri menjadi biaya engineering tambahan
  • Dalam hasil keseluruhan, berdasarkan Sonnet, jalur vision rata-rata memakai 53 langkah, 1003 detik, dan 550.976 token input, sedangkan jalur API selesai dalam 8 panggilan, 19,7 detik, dan 12.151 token input, dengan variasi biaya dan waktu yang juga jauh lebih kecil
  • Kesenjangan biaya berasal dari struktur antarmuka, bukan kinerja model; dan bila endpoint HTTP dapat dibuat otomatis dari event handler seperti di Reflex 0.9, perhitungan biaya akan lebih menguntungkan untuk jalur API terstruktur pada alat internal yang dibangun sendiri

Tujuan benchmark dan konfigurasi eksperimen

  • Biaya pendekatan penggunaan browser/computer diukur dengan membuat agen vision dan pendekatan API terstruktur mengoperasikan panel admin yang sama
  • Saat agen AI harus mengoperasikan web app yang tidak menyediakan API, agen vision mudah menjadi pilihan default
  • Dalam situasi di mana tiap tim memiliki lebih dari 20 alat internal, menulis permukaan MCP atau REST untuk tiap aplikasi menjadi proyek engineering tersendiri, sehingga banyak tim memilih agen vision
  • Aplikasi uji adalah panel admin untuk mengelola pelanggan, pesanan, dan ulasan, dengan model react-admin Posters Galore demo
  • Kedua agen memakai aplikasi yang sama yang sedang berjalan, Claude Sonnet yang sama, dataset tetap yang sama, dan tugas yang sama, dengan hanya antarmuka sebagai variabel
  • Tugasnya adalah mencari pelanggan bernama “Smith” yang memiliki pesanan terbanyak, menemukan pesanan tertunda terbaru milik pelanggan tersebut, lalu menyetujui semua ulasan yang tertunda dan menandai pesanan sebagai telah dikirim
  • Tugas ini menyentuh tiga resource, serta mencakup filtering, pagination, pencarian antar entitas, serta operasi baca dan tulis, sehingga mirip dengan bentuk pekerjaan umum pada alat internal

Dua jalur eksekusi

  • Jalur A: Vision agent

    • Claude Sonnet menggunakan browser-use 0.12 dalam mode vision untuk mengoperasikan UI lewat screenshot dan klik

  • Jalur B: API agent

    • Claude Sonnet langsung memanggil endpoint HTTP aplikasi melalui penggunaan tool
    • Tiap tool dipetakan ke satu atau lebih event handler pada state aplikasi, dan memakai fungsi yang sama seperti yang dipanggil saat tombol diklik
    • Alih-alih halaman yang sudah dirender, agen menerima respons terstruktur

Mengapa agen vision gagal dengan prompt dasar

  • Kedua agen dijalankan dengan tugas enam kalimat yang sama
  • Agen API menyelesaikan tugas dalam 8 panggilan
    • Menampilkan daftar ulasan pelanggan yang difilter ke status tertunda
    • Menyetujui tiap ulasan
    • Menandai pesanan sebagai telah dikirim
  • Kedua agen memanggil logika aplikasi yang sama, tetapi agen API langsung membaca respons terstruktur alih-alih melihat halaman yang sudah dirender
  • Agen vision dengan prompt yang sama hanya menemukan dan menyetujui 1 dari 4 ulasan tertunda lalu melanjutkan ke langkah berikutnya
  • Tiga ulasan yang tersisa berada di bawah area yang terlihat pada halaman ulasan, dan agen tidak mendapat sinyal bahwa ia perlu menggulir
  • Kegagalan ini bukan masalah penalaran model, melainkan karena halaman yang dirender tidak memberi sinyal bahwa seluruh konten belum terlihat
  • Agen API memanggil handler yang sama seperti yang dipanggil UI, tetapi responsnya memuat seluruh hasil yang dikembalikan handler, bukan hanya baris yang sedang dirender
  • Agen API tidak perlu menafsirkan kontrol pagination dari piksel, melainkan langsung membaca informasi seperti “halaman 1 dari 4, menampilkan 50 item per halaman”

Hasil setelah menambahkan panduan UI 14 langkah

  • Demi perbandingan yang adil, prompt vision ditulis ulang menjadi UI walkthrough yang eksplisit
  • Elemen UI yang harus diinteraksikan agen di tiap langkah, seperti item sidebar, tab, dan field formulir, disebutkan namanya
  • Proses navigasi yang sebelumnya tidak bisa ditemukan agen sendiri ditulis menjadi 14 instruksi bernomor
  • Setelah panduan ini diberikan, agen vision berhasil menyelesaikan tugas
  • Namun, eksekusinya memakan waktu 14 menit dan menghabiskan sekitar 500 ribu token input
  • Tiap instruksi bernomor tidak tampak dalam jumlah token, tetapi tetap merupakan biaya engineering nyata
  • Untuk menerapkan agen vision pada alat internal, Anda harus menulis prompt dengan tingkat detail seperti ini, atau menerima kemungkinan agen diam-diam melewatkan pekerjaan

Cara eksekusi dan variabilitas

  • Jalur API dijalankan 5 kali, sedangkan jalur vision dijalankan 3 kali
  • Jalur vision memerlukan 14–22 menit per run dan menghabiskan 400 ribu–750 ribu token, sehingga dibatasi menjadi 3 run
  • Jalur vision menunjukkan varian yang besar antarrun
    • Dalam 3 run, waktu wall-clock berkisar dari 749 detik hingga 1257 detik
    • Token input berkisar dari 407 ribu hingga 751 ribu
    • Run tercepat membutuhkan 43 siklus, dan yang terlama 68 siklus
  • Pengulangan screenshot-penalaran-klik cukup nondeterministik, sehingga satu run saja sulit dipakai untuk memperkirakan biaya yang representatif
  • Jalur API tidak menunjukkan variabilitas seperti ini
    • Sonnet memakai 8 panggilan tool yang sama pada semua 5 run
    • Jumlah token input di seluruh 5 run hanya berubah dalam rentang ±27
    • Karena respons terstruktur tidak memberi alasan bagi agen untuk menyimpang, ia memanggil handler yang sama dalam urutan yang sama

Hasil keseluruhan

Metrik Vision agent (Sonnet) API (Sonnet) API (Haiku)
Langkah / panggilan 53 ± 13 8 ± 0 8 ± 0
Waktu wall-clock 1003 detik ± 254 detik, sekitar 17 menit 19,7 detik ± 2,8 detik 7,7 detik ± 0,5 detik
Token input 550.976 ± 178.849 12.151 ± 27 9.478 ± 809
Token output 37.962 ± 10.850 934 ± 41 819 ± 52
  • Angka ditulis sebagai rata-rata ± simpangan baku sampel (n−1); untuk jalur API n=5, untuk jalur vision n=3
  • Detail lengkap tiap run tersedia di repositori
  • Haiku tidak berhasil menyelesaikan jalur vision
  • Kegagalan ini terbatas pada skema output terstruktur milik browser-use 0.12; Haiku tidak dapat menghasilkan skema tersebut secara stabil baik dalam mode vision maupun mode teks saja
  • Pada jalur API, Haiku menyelesaikan tugas dalam kurang dari 8 detik dan kurang dari 10 ribu token input, sehingga menjadi konfigurasi termurah yang diuji

Kesenjangan biaya yang bersifat struktural

  • Perbedaan biaya muncul langsung dari arsitektur
  • Agen yang harus melihat untuk bisa bertindak akan selalu membayar biaya melihat, bahkan jika modelnya membaik
  • Model vision yang lebih baik dapat menurunkan tingkat kesalahan per screenshot, tetapi tidak mengurangi jumlah screenshot yang dibutuhkan untuk mencapai data yang relevan
  • Tiap render adalah screenshot, dan screenshot menjadi ribuan token input
  • Kedua agen melewati logika aplikasi yang sama
    • Keduanya melakukan filtering, pagination, dan update dengan cara yang sama seperti UI
    • Perbedaannya terletak pada apa yang dibaca di tiap langkah
  • Agen vision membaca piksel, dan harus merender serta menafsirkan semua status antara
  • Agen API membaca respons terstruktur dari handler yang sama, dan respons itu sudah memuat data yang ingin ditampilkan UI
  • Model yang lebih baik dapat menurunkan biaya per langkah, tetapi tidak mengurangi jumlah langkah, karena itu ditentukan oleh antarmuka

Saat biaya engineering API menurun, penilaiannya berubah

  • Benchmark ini dapat dijalankan dengan biaya murah berkat Reflex 0.9
  • Reflex 0.9 menyertakan plugin yang otomatis membuat endpoint HTTP dari event handler aplikasi Reflex
  • Argumen strukturalnya tidak bergantung pada Reflex, tetapi Reflex memungkinkan jalur API dijalankan tanpa codebase terpisah
  • Intinya adalah apa yang menjadi mungkin saat biaya engineering untuk permukaan API mendekati nol
  • Agen vision tetap cocok untuk aplikasi yang tidak Anda kendalikan secara langsung
    • Produk SaaS pihak ketiga
    • Sistem legacy
    • Aplikasi yang tidak bisa dimodifikasi
  • Pada alat internal yang Anda bangun sendiri, perhitungan biayanya berbalik menguntungkan API

Cakupan eksperimen dan catatan kehati-hatian

  • Hasil vision terbatas pada mode vision browser-use 0.12, dan agen vision lain bisa berperilaku berbeda
  • Runner jalur B membentuk endpoint yang dibuat otomatis menjadi permukaan tool REST kecil sekitar 30 baris
  • Agen melihatnya sebagai tool seperti list_customers, update_order
  • Dataset bersifat tetap dan kecil
    • 900 pelanggan
    • 600 pesanan
    • 324 ulasan
  • Perilaku pada data berskala produksi belum diukur
  • Agen vision dijalankan melalui ChatAnthropic milik LangChain
  • Agen API dijalankan dengan langsung memakai Anthropic SDK
  • Jumlah token yang dilaporkan adalah token input yang tidak di-cache

Materi reproduksi

  • Repositori mencakup pembuatan seed data, demo react-admin yang telah dipatch, skrip kedua agen, dan hasil mentah

Bacaan terkait

1 komentar

 
GN⁺ 2 jam lalu
Komentar Hacker News

  • Di sinilah tersembunyi cara membuat agen menjelajahi situs web menjadi mahal: pindahkan elemen layar saat mouse bergerak, buat UI hanya berfungsi jika dipaksa mengikuti gerakan mouse yang natural, acak nama label tombol di JavaScript setiap kali dikunjungi, lalu paksa scroll sampai ke bagian paling bawah layar untuk memeriksa adanya tugas tambahan tersembunyi
    Tunggu, ini terdengar seperti aplikasi SaaS enterprise pada umumnya

    • Aneh melihat orang-orang yang dulu tidak percaya tiba-tiba rajin menerapkan praktik rekayasa perangkat lunak yang baik gara-gara AI, terutama menulis spesifikasi
      Mereka tidak punya kemauan melakukan ini demi manusia, tetapi karena AI membutuhkannya, semua langsung bergegas. Menarik sekaligus agak menyedihkan. Pada akhirnya, tampaknya ini hanya dilakukan untuk AI karena terasa menguntungkan bagi diri mereka sendiri, bukan untuk seseorang abstrak di masa depan
    • Intinya adalah membuatnya menjadi sesuatu yang ingin dilakukan manusia. Seperti di [0], elemen interaktif bisa dibuat bergerak dan berinteraksi dengan lingkungan sesuai konteks
      [0] https://www.cs.unm.edu/~dlchao/papers/p152-chao.pdf
    • Jadi ternyata ASP WebForms adalah teknologi yang selama ini kita butuhkan
    • Dulu ada proyek dengan sebuah aplikasi desktop yang sengaja menyembunyikan seluruh isi kontrol grid dari Windows accessibility API, mencegah checkbox atau radio button yang dipilih lewat accessibility API agar tidak benar-benar diterapkan, dan semua fitur ekspor data dilindungi CAPTCHA
      Itu bahkan sebelum era AI generatif, tetapi untuk menjalankan aplikasi dan mengekspor data kami harus menggabungkan OCR, input pengguna tersimulasi, dan penangkapan hasil cetak. Saya tidak tahu apa yang akan mereka lakukan jika para pengembangnya tahu tentang Windows DRM API yang bisa memblokir screen capture, atau bahwa teks dari file PostScript bisa dipulihkan dengan mudah dengan format seminimal mungkin
      Ironisnya, proses sebelum diganti adalah memberi tenaga kerja murah di luar negeri akses remote read-only ke seluruh data sistem, yang jelas merupakan risiko keamanan jauh lebih besar daripada staf yang disetujui mengotomatiskan pekerjaan dengan alat lokal dari vendor tepercaya tanpa akses jaringan

  • Saya sedang membuat sesuatu yang memecahkan masalah persis ini[1]
    Belum saya tonjolkan di landing page, tetapi pada dasarnya ini memberi agen sekumpulan alat kecil untuk menjelajahi permukaan aplikasi dan, khususnya, functional API macOS yang umum terkait aksesibilitas
    Setelah agen menjelajahi aplikasi, ia bisa menulis workflow yang dapat diulang, lalu menjalankannya dari CLI seperti invoke chrome pinTab
    Alasan memakai accessibility adalah karena pada akhirnya ini seperti DOM yang baik untuk aplikasi. Tidak semua aplikasi mengimplementasikannya dengan sempurna, tetapi cukup banyak yang melakukannya sehingga sangat berguna
    [1] https://getinvoke.com - landing page saat ini ditujukan untuk kreator, jadi use case ini belum dibahas

    • Kalau agen mendorong hadirnya aksesibilitas (a11y) yang baik, saya bisa menerimanya. Saya mungkin akan mengeluh, tapi tetap saya terima
    • Jika tertarik dengan bidang ini di macOS, saya sangat merekomendasikan membuka Accessibility Inspector.app bawaan sistem dan langsung mengutak-atik aplikasi serta browser
      Dari situ Anda bisa melihat bagaimana sel hijau dapat mengarahkan LLM agar hanya perlu membaca bagian tertentu dari layar atau melakukan OCR, berapa banyak teks yang sebenarnya sudah disediakan langsung oleh mesin aksesibilitas, dan bagaimana ini bisa berkembang bukan hanya ke MCP tetapi juga ke generator kode yang membangun dan menjalankan skrip yang merayapi lapisan aksesibilitas workflow
      Menurut saya ini area yang sangat subur. Lab besar harus memakai pendekatan yang bekerja di banyak platform dan workflow arbitrer, dan visi layar penuh adalah penyebut umum terendah. Pendekatan spesifik per platform adalah ruang terbuka yang benar-benar menarik
    • Daripada semua orang mengulang tugas penggunaan komputer yang sama dan membuang token, ini solusi bagus untuk membuat model berbagi workflow
      Hanya saja, harus ada jaminan kuat agar workflow yang mengekstrak informasi pengguna seperti kata sandi tidak ikut dibagikan
    • Menarik. Saya juga memulai sesuatu yang mirip, meski jauh kurang matang dan cukup berbeda, tetapi sama-sama memakai elemen UI aksesibilitas
      Masalah besarnya adalah terlalu banyak aplikasi yang sangat buruk dalam mengekspos elemen-elemen ini. Pendekatan saya adalah memakai UIAccess atau one-pass dari vision model untuk membuat template UI: https://github.com/willwade/app-automate?tab=readme-ov-file#...
      Sanggahan reddit terhadap ini adalah bahwa pengalaman nyata justru mendekati kebalikannya. UIA tampak seragam di dokumen, tetapi WPF, WinForms, dan Win32 masing-masing mengekspos pola kontrol yang berbeda sehingga pada akhirnya perlu handler per toolkit. Qt hanya mengekspos sesuatu jika QAccessible dikompilasi dan plugin aksesibilitas dimuat saat runtime, dan itu hampir tidak pernah terjadi pada binary distribusi. Electron di Windows juga setidaktransparan di macOS, karena pada akhirnya Chromium yang sama tetap menggambar ke canvas. Pembeda sebenarnya bukan OS lawan OS, melainkan toolkit native lawan semua yang lain

  • Pernyataan bahwa menulis permukaan MCP atau REST untuk setiap aplikasi adalah proyek engineering tersendiri tidak selalu benar, jika backend cukup terpisah dari frontend dan operasi sisi server dirancang dengan hati-hati serta secara umum

  • Saya penasaran apakah UI bisa dibuat agar “dipetakan” oleh agen vision, lalu diekspos ke agen lain sebagai kumpulan antarmuka yang lebih mirip API
    Pemahaman saya, saat ini agen vision harus tahu sekaligus bahwa “halaman berikutnya” menampilkan lebih banyak hasil, dan bahwa memang perlu mengambil lebih banyak hasil sejak awal
    Jika satu agen hanya menjelajahi UI di lingkungan seperti test environment dan membuat deskripsi yang agak terstruktur tentang berbagai elemen dan tindakan UI, lalu agen lain menerima deskripsi itu, saya penasaran apakah hasilnya akan lebih baik daripada agen yang harus sekaligus menavigasi UI dan menjalankan tugas
    Misalnya, “ambil semua ulasan” bisa didefinisikan sebagai harus masuk ke setiap halaman lalu mengklik “lihat ulasan lengkap” pada setiap ringkasan ulasan, dan “masuk ke setiap halaman” didefinisikan sebagai mulai dari halaman 1, default tab ulasan, lalu menekan tombol “berikutnya” sampai tombol itu hilang
    Dengan begitu agen kedua sudah punya teknik itu, jadi beban berpikir tentang cara navigasi bisa berkurang, dan agen pertama cukup menjelajahi UI sekali saja di lingkungan uji tanpa khawatir salah. Mungkin saya salah paham total terhadap artikelnya, tapi tetap menarik

    • Saya sempat memikirkan hal yang sama lebih dulu. Pengembangan web sekarang sangat bergantung pada code generation, lalu ditumpuk dengan obfuscation dan compression, dan di atasnya JavaScript sisi klien menyusun ulang semuanya lagi
      Pada akhirnya kita harus menembus HTML/CSS/JavaScript yang rumit. Suka atau tidak, aplikasi web berukuran 5~10MiB bukan hal langka
      Daripada mendekati dari “bawah ke atas” seolah membalik pekerjaan browser engine, kelihatannya lebih mudah mendekati dari “atas ke bawah” dengan melihat representasi visual seperti manusia
    • Sepertinya benar. Kita bisa membuat agen mempelajari cara kerja situs web seperti yang kita lakukan, lalu mengekspos model itu sebagai API sederhana
      Untuk navigasi mungkin masih perlu sedikit pekerjaan vision, tetapi itu akan menjadi pekerjaan vision sederhana yang tidak memerlukan pemikiran
    • Saya rasa meminta agen vision untuk melakukan “pemetaan” itu sulit. Kebanyakan vision model saat melakukan image→text fokus pada sebagian area gambar pada satu waktu
      Sedangkan image→image memakai keseluruhan gambar

  • Saya kurang paham premisnya. Kalau ini aplikasi internal, kenapa harus memakai computer use, bukannya membuat agen menulis CLI atau MCP
    Jelas computer use lebih buruk. Itu opsi terakhir. Saat menangani state di DB yang saya miliki sendiri, seharusnya itu tidak dipakai
    Justru mengesankan kalau ternyata hanya 50 kali lebih buruk

  • Saya sepenuhnya setuju. Baru-baru ini saat membuat alat visual AI, saya mencoba kedua pendekatan itu, dan latensi serta biaya penggunaan browser generik bergaya “agen” saat ini mematikan untuk aplikasi konsumen real-time
    Structured API, bahkan hanya rantai pemanggilan LLM dengan skema JSON yang ketat, bukan cuma 40 kali lebih murah, tetapi juga penentu apakah produk yang stabil benar-benar bisa dirilis. Computer use adalah demo yang keren, tetapi yang membayar biaya server adalah structured API

    • “Agentic engineering” ternyata hanya tren untuk menaikkan pendapatan penyedia token
      Jika Anda merasa LLM cocok untuk suatu pekerjaan, buat middleware yang didefinisikan dengan baik dan sangat deterministik di atas Openrouter untuk tujuan itu

  • Structured API membutuhkan pemikiran sungguhan, dan belakangan ini berpikir tampaknya tidak dianggap baik

  • Beberapa bulan lalu saya membuat desktopctl CLI untuk mengendalikan aplikasi GUI, terinspirasi dari kubectl
    Di Mac, alat ini menggabungkan OCR dan Accessibility API untuk merepresentasikan UI sebagai Markdown dan mengekspos aksi mouse serta keyboard
    Ide intinya adalah loop persepsi yang “cepat” sepenuhnya lokal, dioptimalkan GPU untuk tokenisasi UI dan deteksi perubahan, sedangkan loop kontrol yang “lambat” perlu bolak-balik ke LLM, dan output CLI memakai antarmuka Markdown yang efisien secara token
    Kontrol memakai identifier yang relatif stabil, jadi agen bisa membuat skrip aksi umum seperti desktopctl pointer click --id btn_save tanpa perlu loop tokenisasi UI
    https://github.com/yaroshevych/desktopctl/tree/main

    • Dibandingkan API, antarmuka untuk manusia memang lambat dan berantakan, tetapi saya belajar bahwa di balik itu tetap ada cukup banyak sains
      Aplikasi yang baik menampilkan informasi dengan baik dan dioptimalkan untuk klik, mengetik, dan sebagainya
      GUI terbaik sangat memanfaatkan muscle memory, sehingga menjadi kandidat sempurna untuk discript lewat CLI. Misalnya urutan sederhana seperti “buka aplikasi Notes, tekan Cmd+F, ketik kata pencarian, baca daftar hasil” bisa menjadi satu perintah Bash yang dipanggil agen AI

  • Saya selalu skeptis terhadap keseluruhan konsep “computer use”. Rasanya seperti mempekerjakan seseorang untuk masuk ke rumah, lalu membiarkannya tidur di tempat tidur, memakai toilet, memakan isi kulkas, menonton TV, dan bahkan diberi tahu bahwa kode brankas juga ada di sini
    Hanya saja orang yang Anda pekerjakan itu adalah monyet

    • Saya sampai merasa apakah saya yang gila. Sungguh mengejutkan bahwa karena kita tidak mampu membuat cara agar satu software bisa menanyakan dan memerintah software lain, solusinya justru membuat AI mondar-mandir dengan mouse sambil klik sana-sini
    • Kalau mau adil, sebenarnya kita hanya ingin si monyet itu mengerjakan pekerjaan ala monyet yang kita sendiri tidak mau lakukan

  • Situs web yang saat ini berusaha memblokir Claude Code atau agen AI lain sedang menjalani pertempuran yang kalah
    Computer use masih tahap awal, dan yang tampaknya menghambat adopsi massal adalah jumlah token yang dibutuhkan. Kalau agen salah mencoba 10 perintah CLI sebelum menemukan yang benar, kita hampir tidak peduli
    Tetapi untuk agen visual seperti penggunaan browser atau computer use, sekalipun akhirnya sampai ke tempat yang benar, kita tidak punya kesabaran menunggu 20 menit hanya untuk satu klik tombol. Jika token menjadi lebih murah dan lebih cepat, besar kemungkinan akan muncul model yang memakai antarmuka UI senatural CLI

    • Saya tidak yakin token akan jadi lebih murah. Token yang disubsidi dana ventura dipakai untuk membangun basis pengguna, dan pada akhirnya saat beralih dari pertumbuhan ke profitabilitas, saya rasa harga token akan naik
    • Dan ada juga trilema mematikan. Untuk saat ini memang berlaku pada semua agen, tetapi semua penyedia AI memberi peringatan keras soal mengizinkan AI mengakses data pribadi di browser
    • Penyedia LLM yang sesungguhnya tidak bisa dihentikan siapa pun. Mereka memakai permintaan yang disamarkan untuk memindai konten, bahkan kadang memakai proxy rumahan
    • Tidak harus 100% efektif. Cukup menakut-nakuti orang agar mengurungkan niat mencoba karena takut akunnya diblokir
    • Yang menghambat adopsi massal bukan jumlah token, melainkan biaya yang sangat besar, pemborosan listrik yang terus meningkat, dan pemborosan air yang dapat digunakan