Neon Functions अब असीमित अवधि वाले स्ट्रीमिंग कनेक्शन का समर्थन करते हैं, जिससे AI agents बिना किसी टाइमआउट सीमा (timeout limits) के सेकंडों, मिनटों या उससे अधिक समय तक एक लाइव चैनल खुला रख सकते हैं, जो आमतौर पर अधिकांश serverless workloads को बंद कर देते हैं। यह बदलाव उन सभी के लिए महत्वपूर्ण है जो चैट-शैली के असिस्टेंट या टूल-उपयोग करने वाले बॉट्स बना रहे हैं, क्योंकि एक टूटा हुआ स्ट्रीम बातचीत को रोक देता है और उपयोगकर्ता अनुभव (user experience) को खराब कर देता है।

क्यों serverless और AI agents के बीच तालमेल की कमी रही है

अधिकांश serverless प्लेटफॉर्म त्वरित, 'fire-and-forget' कार्यों के लिए बनाए गए हैं। संसाधनों को अनुमानित रखने के लिए वे निष्पादन की सख्त सीमाएं (execution caps) लागू करते हैं—अक्सर फ्री टियर पर 10 सेकंड और पेड प्लान पर 60 सेकंड। हालाँकि, एक AI agent सोचने, बाहरी टूल्स को कॉल करने और टोकन जेनरेट होने पर उन्हें प्रसारित करने में समय बिताता है। वह "सोचने" वाला चरण अक्सर कई सेकंड तक खिंच जाता है, और टोकन स्ट्रीम तब तक जारी रह सकती है जब तक मॉडल आउटपुट देता रहता है। जब प्लेटफॉर्म का टाइमर समाप्त हो जाता है, तो यह कनेक्शन बंद कर देता है और क्लाइंट को एक टूटा हुआ स्ट्रीम दिखाई देता है।

Neon का समाधान: डिफ़ॉल्ट रूप से लॉन्ग-लिव्ड स्ट्रीमिंग

Neon Functions इस स्थिति को पूरी तरह बदल देता है। एक function call बिना किसी विशेष कॉन्फ़िगरेशन के WebSockets या Server-Sent Events (SSE) के माध्यम से डेटा डिलीवर करते हुए अनिश्चित काल तक खुला रह सकता है। प्लेटफॉर्म एक लंबे स्ट्रीम को एक सामान्य अनुरोध (request) के रूप में मानता है, इसलिए डेवलपर्स केवल स्ट्रीम जेनरेट करने वाला लॉजिक लिखते हैं और बाकी काम Neon पर छोड़ देते हैं।

हाल ही में किए गए एक परीक्षण में, दो endpoints ने इस व्यवहार का प्रदर्शन किया:

  • Heartbeat endpoint – फंक्शन ने 90 सेकंड तक प्रति सेकंड एक बार "tick" प्रसारित किया। सामान्य serverless tiers 10 या 60 सेकंड के बाद अनुरोध को समाप्त कर देते; Neon ने कनेक्शन को तब तक जीवित रखा जब तक कि फंक्शन अपने आप समाप्त नहीं हो गया।
  • Token-relay endpoint – फंक्शन ने AI मॉडल से क्लाइंट को टोकन तब स्ट्रीम किए जैसे ही प्रत्येक टोकन तैयार हुआ। उपयोगकर्ताओं ने पूरे टेक्स्ट ब्लॉक का इंतज़ार करने के बजाय उत्तर को शब्द दर शब्द आते हुए देखा।

दोनों उदाहरणों में क्लाइंट से केवल एक ही अनुरोध की आवश्यकता थी; किसी भी polling या keep-alive ट्रिक की ज़रूरत नहीं पड़ी।

किसे लाभ होगा, और किसे सावधान रहना चाहिए

कन्वर्सेशनल असिस्टेंट, टूल-उपयोग करने वाले एजेंट, या ऐसी किसी भी सेवा को बनाने वाली टीमें जिन्हें क्रमिक परिणाम (incremental results) भेजने की आवश्यकता होती है, उन्हें तुरंत लाभ मिलता है: टाइमआउट की समस्या खत्म हो जाती है। इसका परिणाम सरल कोड, कम लेटेंसी (latency) और बेहतर उपयोगकर्ता अनुभव के रूप में मिलता है।

इसके कुछ पहलुओं (trade-offs) पर ध्यान देना ज़रूरी है:

  • Request-only model – Neon Functions उन स्ट्रीम्स को संभालता है जो एक सक्रिय अनुरोध (active request) से जुड़े रहते हैं। वे बैकग्राउंड जॉब्स जिन्हें अनुरोध के समाप्त होने के बाद भी चलना चाहिए, उनके लिए अभी भी Inngest जैसे अलग शेड्यूलर या समान वर्कफ़्लो इंजन की आवश्यकता होगी।
  • Cold starts – जो फंक्शन्स निष्क्रिय (idle) होते हैं, वे स्केल होकर शून्य (zero) पर आ सकते हैं, इसलिए अगले अनुरोध में cold-start की देरी हो सकती है। एक सक्रिय स्ट्रीम scaling down को रोकती है, लेकिन निष्क्रियता के बाद पहले अनुरोध में अभी भी स्टार्ट-अप लागत (start-up cost) चुकानी पड़ती है।

आगे क्या देखने को मिलेगा

निष्कर्ष: Neon Functions उस टाइमआउट सीमा (timeout ceiling) को हटा देता है जिसने लंबे समय से AI डेवलपर्स को वैकल्पिक समाधानों (workarounds) के लिए मजबूर किया है। अनुरोध को तब तक खुला रखकर जब तक एजेंट को सोचने और बात करने की आवश्यकता हो, Neon स्ट्रीमिंग AI agents को किसी भी अन्य serverless function की तरह तैनात (deploy) करना सरल बनाता है।