Cara Talorys Menjalankan Agen AI Stateful di Serverless

Ini pendapat kontrarian saya, dan saya akan mempertahankannya: agen AI pribadi justru lebih cocok dijalankan di infrastruktur serverless daripada di Raspberry Pi yang ada di bawah meja Anda. Proyek Talorys — asisten pribadi open-source yang di-deploy ke akun Cloudflare Anda sendiri hanya dengan npx create-talorys@latest — adalah bukti terbaik sejauh ini bahwa masalah agen AI stateful di serverless stateless bukan hanya bisa diatasi, tapi memang cocok. Dan diskusi di Hacker News yang memperdebatkan apakah ini bisa disebut “self-hosted” sebenarnya salah fokus sama sekali.

Saya sudah bertahun-tahun mengurus infrastruktur dan membereskan kekacauannya. Yang membunuh perangkat lunak pribadi self-hosted bukan proses deploy-nya — melainkan bulan ketiga, saat disk penuh log, sertifikat TLS kedaluwarsa, dan Anda lupa unit systemd mana yang mengatur penjadwalan. Talorys menghindari seluruh kelas kegagalan itu dengan tidak punya server sama sekali. Semua yang dibutuhkan — chat, memori, tugas, pengingat terjadwal — berjalan di free tier Cloudflare: Pages untuk frontend, Worker privat untuk API, Durable Object berbasis SQLite untuk semua state, dan Workers AI untuk model. Total biaya bulanan untuk satu pengguna: nol.

Masalah Sebenarnya: Agen Itu Stateful, Serverless Tidak

Agen AI pada dasarnya adalah tumpukan state berumur panjang yang berpura-pura jadi aplikasi request-response. Ia butuh riwayat percakapan, memori yang tahan lama, daftar tugas, job terjadwal yang jalan jam 7 pagi meskipun tidak ada yang sedang login, dan tempat untuk menyimpan output tool selama rantai multi-langkah berjalan. Setiap bagian itu bertentangan dengan model serverless klasik, di mana fungsi Anda ibarat ikan mas: bangun, menangani satu request, lalu lupa segalanya.

Jawaban standar industri adalah menyusun ulang state di tepi sistem: Redis untuk data sesi, Postgres untuk catatan permanen, antrean plus scheduler untuk cron, dan vector database untuk recall semantik. Itu memang berhasil, tapi Anda malah membangun ulang server farm dari layanan terkelola, lengkap dengan tagihan dan permukaan operasional yang ikut membesar. Saya pernah melihat tim menghabiskan lebih banyak waktu engineering untuk merangkai lima layanan stateful bagi sebuah agen daripada menulis logika agennya sendiri. Seperti yang sudah pernah saya bahas, agen LLM pada dasarnya adalah sistem terdistribusi — dan sistem terdistribusi adalah tempat niat baik untuk mati.

Talorys mengambil taruhan sebaliknya: taruh semua state di satu tempat. Satu Durable Object bernama personal-agent menyimpan seluruh dunia — percakapan, memori, tugas, catatan, proyek, otomasi, sesi, pengaturan, dan pelacakan penggunaan — di dalam database SQLite tertanam. Tidak ada KV, D1, R2, maupun Vectorize. README-nya jelas bahwa semua itu tidak di-provision. Itu bukan kebetulan; itulah arsitekturnya.

Durable Objects Adalah Jurus Pamungkasnya

Durable Objects mungkin primitif paling diam-diam radikal di cloud computing saat ini, dan saya tidak sedang berlebihan. Durable Object adalah potongan kode dengan satu instance, dilengkapi penyimpanan transaksional yang konsisten secara kuat dan terletak secara fisik berdekatan dengannya. Ketika request datang ke objek personal-agent, Cloudflare membangunkan objek itu — dalam hitungan milidetik, dari kondisi dingin — menjalankan kode Anda terhadap SQLite lokalnya, lalu membekukannya lagi saat idle. Anda mendapat kemudahan proses server yang berjalan lama dengan model billing ala Lambda.

Untuk agen pribadi single-user, batasan model ini yang terkenal justru jadi keunggulan:

• Single-writer adalah fitur. Satu pengguna berarti satu penulis. Semua kerumitan konkurensi state multi-tenant hilang; Anda mendapat akses serial dan transaksional ke semuanya secara gratis.
• Kedekatan fisik memangkas latensi. Query memori agen, pencarian tugas, dan riwayat percakapan adalah pembacaan SQLite dari disk lokal, bukan round trip jaringan ke database di availability zone lain.
• Alarm menggantikan cron. Alarm Durable Object memungkinkan objek menjadwalkan kebangkitannya sendiri. Pengingat, rutinitas berulang, dan ringkasan harian berjalan tanpa mesin apa pun harus tetap online — objek tidur, alarm membangunkannya, ia mengerjakan tugasnya, lalu tidur lagi.
• Hibernasi itu gratis. Waktu idle tidak berbiaya. Asisten pribadi yang menganggur 23 jam sehari adalah beban kerja yang justru menjadi alasan harga serverless diciptakan.

Ini insight yang saya harap lebih banyak orang tangkap dari proyek ini. Jika aplikasi Anda secara alami single-tenant — alat pribadi, workspace per pelanggan, koordinator per perangkat — pola “satu Durable Object per tenant” memberi Anda sesuatu yang dulu butuh VPS: komputer kecil yang secara konseptual selalu berjalan, tidak memakan biaya saat idle, dan tidak pernah butuh sysadmin. Cerita penjadwalannya saja sudah sepadan. Siapa pun yang pernah menjalankan kotak cron pribadi tahu pola kegagalannya: kotak reboot, daemon cron tidak kembali, dan dua minggu kemudian Anda baru sadar pengingat Anda diam-diam berhenti. Alarm adalah penjadwalan yang dikelola infrastruktur, dan itu berarti satu hal lagi yang tidak perlu Anda jaga.

Model Jaringannya Lebih Baik dari Kebanyakan Setup Produksi

Ini bagian yang membuat saya tegak, mengingat latar belakang saya di keamanan. Worker agen di Talorys di-deploy dengan workers_dev: false dan preview_urls: false. Worker itu sama sekali tidak punya URL publik. Browser hanya berbicara dengan situs *.pages.dev; sebuah Pages Function di /api/* meneruskan request ke Worker lewat service binding — jaringan internal dan privat Cloudflare antar compute dalam akun yang sama. Autentikasi dan otorisasi dilakukan di Worker, bukan di frontend.

Pikirkan apa yang dihilangkan dengan ini. Tidak ada endpoint API publik untuk dipindai. Tidak ada aturan firewall yang bisa salah konfigurasi. Tidak ada reverse proxy yang lupa di-patch. Attack surface backend agen pada dasarnya adalah “Anda harus lewat alur auth frontend”. Saya pernah mereview deployment produksi di perusahaan sungguhan — dengan anggaran dan tim keamanan — yang postur jaringannya lebih longgar dari proyek sampingan ini. Pola insiden paling umum yang saya lihat di lingkungan cloud adalah layanan internal yang “hanya bisa diakses dari dalam” sampai suatu hari ternyata tidak, karena seseorang salah ketik konfigurasi load balancer. Anda tidak bisa salah ketik service binding sampai menjadi publik; URL-nya memang tidak ada.

Installer-nya juga layak disebut. Ia melakukan hash password owner secara lokal dengan PBKDF2-SHA256 dan hanya menyimpan hash-nya sebagai secret Cloudflare, membuat session secret 256-bit, memberi nama resource yang unik, lalu memverifikasi deployment yang sudah live — termasuk memastikan request tanpa autentikasi benar-benar ditolak — tanpa menghabiskan kuota inferensi AI. Pengecekan pasca-deploy yang memastikan auth benar-benar menolak yang tidak terautentikasi adalah hal yang biasanya saya tulis di postmortem insiden. Melihatnya ada di installer satu perintah adalah kejutan yang menyenangkan.

Hidup di Free Tier Tanpa Membohongi Diri Sendiri

Free tier itu nyata, tapi ia adalah anggaran, bukan prasmanan. Cloudflare memberi akun gratis alokasi harian Workers AI yang diukur dalam “Neurons” — 10.000 per hari — ditambah kuota request dan penggunaan Durable Object. Angka-angka itu ditentukan Cloudflare dan bisa berubah. Talorys menangani ini lebih jujur daripada kebanyakan proyek “free tier” yang pernah saya lihat: ketika alokasi AI habis, chat memberi tahu dengan jelas dan kembali berjalan setelah reset harian, sementara tugas, catatan, memori, dan pengingat tetap jalan karena tidak satu pun membutuhkan model.

Pagar pengamannya layak Anda curi untuk proyek Anda sendiri. Talorys menyediakan batas yang bisa dikonfigurasi untuk max output token, max context token (riwayat lama diringkas, bukan dipotong diam-diam), max tool call dan langkah reasoning per request, max request AI per hari, dan max run AI terjadwal per hari. Itu sikap yang matang. Loop agen tanpa batas adalah cara terbaik untuk bangun dengan tagihan membengkak atau outage karena kuota habis, dan “agen memutuskan memanggil tool 40 kali” adalah mode kegagalan yang pernah saya lihat membakar uang sungguhan di produksi. Terkait itu: keputusan proyek untuk membuat pengingat dan ringkasan sederhana tidak pernah memakai AI sudah tepat. Jika sebuah jalur kode itu deterministik, jangan lewatkan ke model probabilistik. Disiplin yang sama ada di balik membatasi output model ke keputusan terstruktur — gunakan model hanya di tempat yang benar-benar membutuhkan penilaian.

Satu catatan dari komunitas: beberapa orang melaporkan kejutan tagihan yang tidak jelas saat menggabungkan Workers AI dengan paket Workers berbayar, dengan perhitungan Neuron yang tidak sesuai batas dokumentasi dan tiket support yang tidak ke mana-mana. Saya tidak bisa memverifikasi detailnya, tapi ini cocok dengan pola yang saya kenal baik — billing AI berbasis meter memang membingungkan di mana-mana, dan “ramah free tier” tidak sama dengan “mustahil ditagih”. Jika Anda men-deploy ini di paket berbayar, pasang spend alert di dashboard Cloudflare sejak hari pertama. Anggap UI penggunaan dari provider sebagai sumber kebenaran, bukan estimasi lokal aplikasinya.

Perdebatan “Self-Hosted” Melewatkan Intinya

Sekarang, konsesi yang dituntut oleh klaim pembuka saya. Komentar teratas di proyek ini adalah perang api soal kata “self-hosted”, dan para pedant punya poin nyata: semua ini bergantung sepenuhnya pada Cloudflare. Data Anda ada di pusat data mereka, inferensi Anda berjalan di GPU mereka, dan jika mereka mengubah free tier besok, asisten Anda ikut berubah. Menyebut itu self-hosting meregangkan kata tersebut sampai patah. Pembacaan yang lebih adil — tidak ada pihak ketiga selain akun Cloudflare yang sudah Anda kendalikan, tidak ada telemetri ke pengembang, tidak ada operator di tengah — lebih tepat digambarkan sebagai “self-owned” atau “self-custodied”. Kata itu penting, dan proyek ini akan kurang dikritik jika memakai kata yang lebih tepat.

Tapi di sinilah para pedant kehilangan saya. Ancaman nyata untuk perangkat lunak pribadi bukan “syarat layanan perusahaan bisa berubah”. Ancamannya adalah kebocoran data, telemetri, dan pengembang yang bangkrut lalu mematikan versi hosted-nya. Untuk ketiganya, Talorys benar-benar kuat: tidak ada kode analitik atau pelacakan, tidak ada yang menghubungi pembuatnya, dan tidak ada versi hosted untuk dimatikan. Sementara itu, kodenya berlisensi MIT, dan seperti yang dicatat seorang komentator, mengarahkan panggilan AI ke server model lokal hanyalah patch kecil — seluruh stack bahkan bisa berjalan secara lokal dengan wrangler dev menggunakan provider AI tiruan. Jika Cloudflare suatu saat tidak bisa diterima, jalan keluarnya pendek. Bandingkan dengan aplikasi “self-hosted” rata-rata yang sebenarnya cuma file Docker Compose yang menarik image dari registry seseorang, sambil menelepon rumah untuk cek lisensi.

Ada juga kritik yang lebih adil yang terselip di thread: tidak ada bukti bahwa asisten ini benar-benar bagus. Antarmuka chat, CRUD memori, embedding, dan cron masing-masing sangat mudah dibuat; harness, prompting, kebijakan retrieval memori, dan skema tool-lah tempat asisten pribadi hidup atau mati, dan tak ada yang ditunjukkan oleh diagram arsitektur yang rapi. Itu berlaku untuk hampir semua proyek di genre ini, dan itu memang hal yang tepat untuk diragukan. Nilai Talorys sebagai infrastruktur — sasis yang dirancang dengan baik — bukan sebagai copilot yang terbukti. Jika Anda sedang menimbang model untuk hal seperti ini, tulisan kami tentang menjalankan LLM di perangkat keras Anda sendiri membahas ujung lain dari spektrum kedaulatan.

Apa yang Harus Anda Curi dari Desain Ini

Meski Anda tidak pernah men-deploy Talorys, arsitekturnya adalah referensi yang layak dipahami. Ide-ide yang bisa dipindahkan:

1. Satu objek per tenant. Jika aplikasi Anda single-user atau bisa dipartisi dengan rapi, gabungkan kode dan state dalam satu Durable Object lalu hapus lapisan cache, message queue, dan connection pooler Anda.
2. Tidak ada URL backend publik. Service binding dengan workers_dev: false adalah kemenangan keamanan termurah di serverless. Layanan yang tidak bisa dijangkau tidak bisa diserang.
3. Alarm mengalahkan kotak cron. Penjadwalan yang hidup bersama infrastruktur akan bertahan dari reboot, redeploy, dan kepikunan Anda sendiri.
4. Degradasi yang sadar kuota. Rancang aplikasi agar dependensi mahal (model) bisa gagal atau kehabisan kuota sementara produk inti tetap bekerja. Degradasi seharusnya menjadi fitur, bukan outage.
5. Migrasi yang hanya menambah. Namespace Durable Object tidak pernah dibuat ulang saat update; migrasi skema berjalan secara transaksional pada request pertama. Begitulah cara memperbarui serverless yang stateful tanpa mempertaruhkan kehilangan data.

Pelajaran yang lebih luas adalah soal ke mana arah perangkat lunak pribadi. Selama dua puluh tahun, pilihannya biner: mempercayakan data pada perusahaan SaaS, atau menjadi sysadmin paruh waktu. Durable Objects — dan primitif tiruan yang pasti akan dirilis cloud lain — membuka jalan ketiga: perangkat lunak yang hanya Anda kendalikan, dioperasikan oleh infrastruktur yang Anda sewa, dengan biaya nol di skala personal. Ini bukan self-hosting. Mungkin malah lebih baik.