Talorys कैसे Serverless पर Stateful AI Agents चलाता है

यह मेरा उल्टा नज़रिया है, और मैं इसका बचाव करूँगा: एक निजी AI एजेंट, आपकी मेज़ के नीचे रखे Raspberry Pi की तुलना में serverless infrastructure पर कहीं बेहतर फिट बैठता है। Talorys प्रोजेक्ट, एक open-source personal assistant जो सिर्फ़ एक npx create-talorys@latest से आपके अपने Cloudflare account में deploy हो जाता है, इस बात का अब तक का सबसे अच्छा सबूत है कि stateful-AI-agent-on-stateless-serverless समस्या सिर्फ़ हल होने लायक नहीं, बल्कि स्वाभाविक रूप से फिट बैठती है। और Hacker News वाले इस बहस में लगे हैं कि इसे "self-hosted" कहा जा सकता है या नहीं, असल में वे पूरी तरह गलत बहस कर रहे हैं।

मैं सालों से infrastructure चला रहा हूँ और उसकी सफ़ाई भी करता आया हूँ। self-hosted personal software को जो चीज़ मारती है, वह deploy नहीं है, बल्कि तीसरा महीना है, जब disk logs से भर जाती है, TLS cert expire हो जाता है, और आपको याद नहीं रहता कि scheduling किस systemd unit से होती है। Talorys पूरी failure class को बस इसलिए टाल देता है कि उसका कोई server ही नहीं है। उसे जो भी चाहिए, chat, memory, tasks, scheduled reminders, सब Cloudflare के free tier पर चलता है: frontend के लिए Pages, API के लिए एक private Worker, सारे state के लिए SQLite-backed Durable Object, और model के लिए Workers AI। एक यूज़र के लिए कुल मासिक खर्च: शून्य।

असली समस्या: Agents stateful हैं, Serverless नहीं

AI एजेंट असल में लंबे समय तक चलने वाले state का एक गट्ठर है, जो खुद को request-response application बताता है। उसे conversation history, स्थायी memories, task list, ऐसे scheduled jobs चाहिए जो सुबह 7 बजे चलें चाहे कोई logged in हो या न हो, और multi-step chain चलते समय tool outputs रखने की जगह भी। इनमें से हर चीज़ classic serverless model के खिलाफ़ है, जहाँ आपका function एक goldfish जैसा होता है: जागता है, एक request संभालता है, और सब भूल जाता है।

इंडस्ट्री का आम जवाब है कि state को किनारों पर दोबारा जोड़ा जाए: session data के लिए Redis, स्थायी records के लिए Postgres, cron के लिए queue और scheduler, semantic recall के लिए vector database। यह काम करता है, लेकिन इससे आपने managed services से एक server farm दोबारा खड़ा कर लिया है, जिसका बिल और operational जटिलता भी उतनी ही है। मैंने टीमों को देखा है कि वे एजेंट के लिए पाँच stateful services जोड़ने में उतना engineering समय लगाती हैं जितना खुद एजेंट की logic लिखने में नहीं लगता। जैसा मैं पहले भी कह चुका हूँ, LLM agents असल में distributed systems ही हैं, और distributed systems वह जगह है जहाँ अच्छे इरादे दम तोड़ देते हैं।

Talorys इसका उल्टा दांव लगाता है: सारा state एक ही जगह रखो। एक Durable Object, जिसका नाम personal-agent है, पूरी दुनिया रखता है: conversations, memories, tasks, notes, projects, automations, sessions, settings और usage tracking, सब अपने embedded SQLite database में। कोई KV नहीं, कोई D1 नहीं, कोई R2 नहीं, कोई Vectorize नहीं। README साफ़ कहता है कि इनमें से कुछ भी provision नहीं होता। यह कोई संयोग नहीं है; यही architecture है।

Durable Objects ही असली कुंजी हैं

Durable Objects इस समय cloud computing की सबसे चुपचाप क्रांतिकारी primitive हैं, और मैं इसे अतिशयोक्ति नहीं मानता। Durable Object एक single-instance code है, जिसके साथ strongly consistent, transactional storage भौतिक रूप से जुड़ा होता है। जब object personal-agent के नाम से request आती है, Cloudflare उस object को ठंडी अवस्था से मिलीसेकंड में जगा देता है, आपका code उसके local SQLite पर चलता है, और idle होने पर उसे फिर से freeze कर देता है। आपको लंबे समय तक चलने वाले server process की सुविधा मिलती है, और billing Lambda जैसी।

एक-यूज़र वाले personal agent के लिए इस model की बदनाम सीमाएँ ही खूबियाँ बन जाती हैं:

• Single-writer एक खूबी है। एक यूज़र का मतलब है एक writer। multi-tenant state की सारी concurrency की परेशानी ख़त्म हो जाती है; आपको हर चीज़ तक serialized, transactional access मुफ़्त में मिलता है।
• Colocation latency को ख़त्म करता है। एजेंट की memory queries, task lookups और conversation history local disk पर SQLite reads हैं, न कि किसी दूसरे availability zone के database तक network round trips।
• Alarms cron की जगह लेते हैं। Durable Object alarms object को अपने आप जगने का समय तय करने देते हैं। Reminders, recurring routines और daily digests बिना किसी machine के online रहे चलते हैं: object सोता है, alarm उसे जगाता है, वह अपना काम करता है, और फिर सो जाता है।
• Hibernation मुफ़्त है। Idle समय का कोई खर्च नहीं। जो personal assistant दिन के 23 घंटे idle रहता है, वह ठीक वही workload है जिसके लिए serverless pricing बनी थी।

इस प्रोजेक्ट से मैं चाहता हूँ कि ज़्यादा लोग यही बात समझें। अगर आपका application स्वाभाविक रूप से single-tenant है, जैसे एक personal tool, प्रति-ग्राहक workspace, या प्रति-device coordinator, तो "एक Durable Object प्रति tenant" pattern आपको वह चीज़ देता है जिसके लिए पहले VPS चाहिए था: एक छोटा computer जो वैचारिक रूप से हमेशा चालू रहता है, idle होने पर कुछ खर्च नहीं करता, और किसी sysadmin की ज़रूरत नहीं पड़ती। सिर्फ़ scheduling की कहानी ही प्रवेश शुल्क के बराबर है। जो भी personal cron box चला चुका है, वह failure mode जानता है: box reboot होता है, cron daemon वापस नहीं आता, और दो हफ़्ते बाद पता चलता है कि आपके reminders चुपचाप बंद हो चुके थे। Alarms infrastructure के अपने scheduling हैं, और इससे एक चीज़ कम देखभाल चाहिए।

Networking model ज़्यादातर production setups से बेहतर है

यहाँ वह हिस्सा है जिसने मुझे सीधा होकर बैठने पर मजबूर किया, क्योंकि मेरी पृष्ठभूमि security की है। Talorys में agent Worker workers_dev: false और preview_urls: false के साथ deploy होता है। उसका कोई सार्वजनिक URL नहीं है। Browser सिर्फ़ एक *.pages.dev site से बात करता है; /api/* पर एक Pages Function service binding के ज़रिए requests को Worker तक भेजता है, यानी Cloudflare की internal, private वायरिंग जो एक ही account के compute के बीच होती है। Authentication और authorization frontend में नहीं, Worker में होते हैं।

सोचिए इससे क्या ख़त्म हो जाता है। scan करने के लिए कोई public API endpoint नहीं। misconfigure करने के लिए कोई firewall rules नहीं। patch करना भूलने के लिए कोई reverse proxy नहीं। एजेंट backend की attack surface असल में बस यह है: "आपको frontend के auth flow से होकर आना होगा।" मैंने असली कंपनियों के production deployments की समीक्षा की है, बजट और security टीमों के साथ, जिनका network posture इस side project से भी ढीला था। cloud environments में मैंने सबसे आम incident pattern यह देखा है कि कोई internal service "सिर्फ़ internally reachable" होती है, जब तक एक दिन वह नहीं रहती, क्योंकि किसी ने load balancer config में गलती कर दी। आप service binding को गलती से public नहीं बना सकते; URL होता ही नहीं।

Installer का ज़िक्र भी ज़रूरी है। वह owner password को PBKDF2-SHA256 से locally hash करता है और सिर्फ़ hash को Cloudflare secret के रूप में रखता है, 256-bit session secret बनाता है, resources को unique नाम देता है, और फिर live deployment को verify करता है, जिसमें यह जाँच भी शामिल है कि unauthenticated requests सच में reject होती हैं, और यह सब AI inference quota खर्च किए बिना। Deploy के बाद की ऐसी जाँच जो पुष्टि करे कि auth सच में unauthenticated को रोकता है, वह ऐसी चीज़ है जो मैंने incident postmortems में लिखी है। एक-कमांड installer में इसे देखना सुखद झटका है।

Free tier में रहना, खुद से झूठ बोले बिना

Free tier असली है, पर वह एक बजट है, buffet नहीं। Cloudflare free accounts को "Neurons" में मापा जाने वाला रोज़ाना Workers AI allocation देता है, यानी रोज़ 10,000, साथ ही request और Durable Object usage की quotas। ये संख्याएँ Cloudflare तय करता है और बदल सकती हैं। Talorys इसे उन ज़्यादातर "free tier" प्रोजेक्ट्स से ईमानदारी से संभालता है जो मैंने देखे हैं: जब AI allocation खत्म होता है, chat साफ़ बताता है और रोज़ के reset के बाद फिर चालू हो जाता है, जबकि tasks, notes, memories और reminders चलते रहते हैं, क्योंकि उनमें से किसी को model की ज़रूरत नहीं।

अपने प्रोजेक्ट्स के लिए इन guardrails को उधार लेना फ़ायदेमंद है। Talorys में configurable सीमाएँ हैं: max output tokens, max context tokens (पुराना history चुपचाप काटने के बजाय summarize होता है), प्रति request max tool calls और reasoning steps, प्रतिदिन max AI requests, और प्रतिदिन max scheduled AI runs। यह एक परिपक्व रुख है। बिना सीमा वाले agent loops ही वे चीज़ें हैं जिनसे आप बिल या quota outage के साथ जागते हैं, और "एजेंट ने tool को 40 बार call करने का फ़ैसला किया" वह failure mode है जिसे मैंने production में असली पैसा जलाते देखा है। इससे जुड़ी बात: प्रोजेक्ट का सरल reminders और digests को कभी AI इस्तेमाल न करने देना बिल्कुल सही है। अगर code path deterministic है, तो उसे probabilistic model से न गुज़ारें। यही अनुशासन model output को structured decisions तक सीमित करने के पीछे है: model का इस्तेमाल सिर्फ़ वहीं करें जहाँ सच में judgment चाहिए।

समुदाय से एक war-story चेतावनी: कई लोग बताते हैं कि Workers AI को paid Workers plans के साथ मिलाने पर अपारदर्शी billing के झटके लगे, Neuron हिसाब documented limits से मेल नहीं खाता था, और support tickets कहीं नहीं पहुँचीं। मैं विवरण की पुष्टि नहीं कर सकता, लेकिन यह उस पैटर्न से मेल खाता है जो मैं अच्छी तरह जानता हूँ: metered AI billing हर जगह भ्रमित करने वाली है, और "free tier के अनुकूल" होना "कभी बिल न आना" होने जैसा नहीं है। अगर आप इसे paid plan पर deploy करें, तो पहले ही दिन Cloudflare dashboard में spend alert सेट करें। प्रदाता के usage UI को ही सच का स्रोत मानें, ऐप के local अनुमानों को नहीं।

"Self-Hosted" की लड़ाई असली बात को चूक जाती है

अब वह रियायत जो मेरा शुरुआती दावा माँगता है। इस प्रोजेक्ट पर सबसे ऊपर की टिप्पणियाँ "self-hosted" शब्द पर झगड़ा हैं, और शब्दों के पंडितों की बात में दम है: यह सब पूरी तरह Cloudflare पर निर्भर है। आपका डेटा उनके data centers में रहता है, आपका inference उनके GPUs पर चलता है, और अगर वे कल free tier बदल दें, तो आपका assistant भी बदल जाएगा। इसे self-hosting कहना शब्द को तोड़ने जैसा है। सबसे उदार पाठ, यानी Cloudflare account के अलावा किसी तीसरे पक्ष की ज़रूरत नहीं, developers तक कोई telemetry नहीं, बीच में कोई operator नहीं, को "self-owned" या "self-custodied" कहना बेहतर होगा। शब्द मायने रखते हैं, और अगर प्रोजेक्ट बेहतर शब्द चुनता तो उसे इतनी आलोचना कम झेलनी पड़ती।

पर यहीं पर पंडित मेरी पकड़ से निकल जाते हैं। निजी software के लिए असली threat model यह नहीं है कि "किसी कंपनी की service शर्तें बदल सकती हैं।" असली खतरा है data exfiltration, telemetry, और developer का दिवालिया होकर hosted version बंद कर देना। इन तीनों पर Talorys सच में मज़बूत है: कोई analytics या tracking code नहीं, कुछ भी लेखकों के पास "घर फ़ोन" नहीं करता, और बंद करने के लिए कोई hosted version है ही नहीं। साथ ही code MIT-licensed है, और जैसा एक commenter ने नोट किया, AI calls को local model server पर भेजना एक छोटा patch है। पूरा stack wrangler dev के तहत mock AI provider के साथ locally भी चलता है। अगर Cloudflare कभी अस्वीकार्य हो जाए, तो बाहर निकलने का रास्ता छोटा है। इसकी तुलना उस औसत "self-hosted" ऐप से करें जो असल में किसी के registry से image खींचने वाली Docker Compose फ़ाइल है और license checks के लिए घर फ़ोन करती है।

थ्रेड में एक निष्पक्ष आलोचना भी छिपी है: इस बात का कोई सबूत नहीं कि assistant सच में अच्छा है। Chat interface, memory CRUD, embeddings और cron, इनमें से हर एक बनाना सरल है; असली काम harness, prompting, memory retrieval नीति और tool schemas में है, और यह सब एक साफ़ architecture diagram से साबित नहीं होता। इस शैली के लगभग हर प्रोजेक्ट के साथ यही सच है, और इस पर संदेह करना सही है। Talorys को एक अच्छी तरह डिज़ाइन की गई chassis के रूप में आंकें, साबित copilot के रूप में नहीं। अगर आप इस तरह के काम के लिए models तौल रहे हैं, तो हमारा लेख LLMs को अपने hardware पर चलाने पर संप्रभुता के दूसरे छोर को कवर करता है।

इस डिज़ाइन से आपको क्या अपनाना चाहिए

भले ही आप कभी Talorys deploy न करें, यह architecture एक संदर्भ है जिसे समझना उपयोगी है। इसके हस्तांतरणीय विचार:

1. प्रति tenant एक object। अगर आपका app single-user है या साफ़ तौर पर बाँटा जा सकता है, तो code और state को एक Durable Object में रखें और अपनी cache layer, message queue और connection pooler हटा दें।
2. कोई सार्वजनिक backend URL नहीं। workers_dev: false के साथ service bindings serverless में सबसे सस्ती security जीत हैं। जिस service तक पहुँचा नहीं जा सकता, उस पर हमला भी नहीं हो सकता।
3. Cron boxes की जगह alarms। Infrastructure के साथ रहने वाली scheduling reboots, redeploys और आपकी अपनी भुलक्कड़ी से बची रहती है।
4. कोटा-सजग degradation। ऐप ऐसा डिज़ाइन करें कि महँगी निर्भरता (model) फेल हो सकती हो या कोटा ख़त्म हो सकता हो, फिर भी मुख्य product काम करता रहे। Degradation एक feature होना चाहिए, outage नहीं।
5. Append-only migrations। Update पर Durable Object namespace दोबारा नहीं बनता; schema migrations पहले request पर transactionally चलते हैं। स्टेटफुल serverless को बिना डेटा-हानि के जुए के update करने का यही तरीका है।

व्यापक सबक इस बारे में है कि निजी software किस दिशा में जा रहा है। बीस सालों से विकल्प दो में बँटा था: अपना डेटा किसी SaaS कंपनी पर भरोसा करें, या अंशकालिक sysadmin बन जाएँ। Durable Objects, और दूसरे clouds जो अनिवार्य रूप से ऐसी ही primitives लाएँगे, एक तीसरा रास्ता खोलते हैं: ऐसा software जिसे सिर्फ़ आप नियंत्रित करें, जिसे आपके किराए के infrastructure चलाए, और जो निजी स्तर पर कोई खर्च न करे। यह self-hosting नहीं है। हो सकता है यह उससे बेहतर हो।