# Alejandro Rioja — HI > Alejandro Rioja — AI agent systems for founders. Plus posts on growth, marketing, sales, ops, and business from inside live P&Ls. Site: https://alejandrorioja.com/hi/ Author: Alejandro Rioja Language: hi --- ## Claude Fable 5 के शुरुआती अनुभव: एक ऑपरेटर का नज़रिया Source: https://alejandrorioja.com/hi/claude-fable-5-first-impressions/ Published: 2026-06-12 Updated: 2026-06-12 Tags: AI Agents TL;DR: Fable 5 Anthropic का सबसे सक्षम मॉडल है और कठिन, लंबे-दौर वाले एजेंट काम में यह साफ़ झलकता है — लेकिन यह डिफ़ॉल्ट अपग्रेड नहीं है। यह प्रति टोकन ज़्यादा महंगा है, एक नया tokenizer इस्तेमाल करता है जो आपके टोकन काउंट को ~30% फुला देता है, हमेशा-ऑन thinking चलाता है जिसे आप बंद नहीं कर सकते, और classifier स्तर पर रिक्वेस्ट ठुकरा सकता है। ज़्यादातर वर्कलोड के लिए Opus 4.8 ही सही चुनाव है। Fable 5 तब उठाइए जब काम सचमुच कठिन हो। ## विषय-सूची _जून 2026 में अपडेटेड।_ **TL;DR:** Fable 5 Anthropic का सबसे सक्षम मॉडल है और कठिन, लंबे-दौर वाले एजेंट काम में यह साफ़ झलकता है — लेकिन यह डिफ़ॉल्ट अपग्रेड नहीं है। यह प्रति टोकन ज़्यादा महंगा है, एक नया tokenizer इस्तेमाल करता है जो आपके टोकन काउंट को ~30% फुला देता है, हमेशा-ऑन thinking चलाता है जिसे आप बंद नहीं कर सकते, और classifier स्तर पर रिक्वेस्ट ठुकरा सकता है। ज़्यादातर वर्कलोड के लिए Opus 4.8 ही सही चुनाव है। Fable 5 तब उठाइए जब काम सचमुच कठिन हो। **[ऑपरेटर का नज़रिया]** मैं एक कंसल्टिंग ब्रांड और एक पिकलबॉल फैसिलिटी के पार 30+ प्रोडक्शन एजेंट चलाता हूँ, तो मेरे लिए कोई नया फ्लैगशिप मॉडल कोई बेंचमार्क नहीं — यह एक खर्च की लाइन और एक माइग्रेशन है। यहाँ बताता हूँ कि जब मैंने सचमुच Fable 5 को उनमें से कुछ एजेंट्स में जोड़ा तो क्या बदला, और कहाँ मैंने Opus 4.8 को यथावत रहने दिया। ## Fable 5 असल में है क्या [Claude](/recommends/claude) Fable 5 सबसे सक्षम मॉडल है जिसे Anthropic ने व्यापक रूप से उतारा है। इसका निशाना स्पेक्ट्रम का सबसे मांगभरा सिरा है: गहरी तर्कक्षमता और लंबे-दौर वाला एजेंटिक काम — वे रन जहाँ एक एजेंट को दर्जनों tool calls के पार एक प्लान को थामे रखना होता है, बिना सूत्र खोए। API सरफेस लगभग Opus 4.7/4.8 जैसा ही है, जिसने इसे टेस्ट करना आसान बना दिया। डिफ़ॉल्ट रूप से 1M-token का कॉन्टेक्स्ट विंडो, प्रति रिक्वेस्ट 128K आउटपुट टोकन तक। अगर आपने हालिया Opus लाइन पर कुछ भी बनाया है, तो रिक्वेस्ट का ढाँचा जाना-पहचाना लगेगा। फ़र्क ब्योरों में है, और ब्योरे ही वहाँ हैं जहाँ पैसा और चौंकाने वाली बातें छिपी हैं। एक नामकरण नोट ताकि आप उलझें नहीं: **Mythos 5** वही मॉडल है — वही क्षमताएँ, वही कीमत, वही व्यवहार — जो सिर्फ़ Anthropic के Project Glasswing प्रोग्राम के ज़रिए उपलब्ध है। अगर आप उस प्रोग्राम में नहीं हैं, तो जो मॉडल आपको चाहिए वह है `claude-fable-5`। नीचे लिखी हर बात दोनों पर लागू होती है। ## जहाँ यह सचमुच बेहतर है मैंने सबसे पहले अपना सबसे कठिन एजेंट टास्क इस पर फेंका: एक मल्टी-स्टेप रिसर्च-और-संश्लेषण रन जो ढेर सारे स्रोत पढ़ता है, दावों को आपस में जाँचता है, और एक हवाला-सहित ब्रीफ़ लिखता है। यह ऐसा काम है जहाँ कमज़ोर मॉडल भटक जाते हैं — दस tool calls के बाद वे यह पकड़ खो देते हैं कि कौन-सा दावा किस स्रोत से आया। Fable 5 ने सूत्र थामे रखा। संश्लेषण ज़्यादा कसा हुआ था, हवाले सही दावों से जुड़े रहे, और इसने दो स्रोतों के बीच ऐसे दो विरोधाभास पकड़े जिन्हें मेरा Opus 4.8 वर्ज़न चुपचाप औसत में मिला रहा था। लंबी, संरचित तर्कक्षमता पर यह सचमुच एक कदम ऊपर है — कोई मामूली बेंचमार्क उछाल नहीं। यही इसका ईमानदार पक्ष है। अगर आपके एजेंट का फेल्योर मोड है "कठिन 10% पर बिखर जाना," तो Fable 5 उस फ़ासले को कम करता है। अगर आपका एजेंट न्यूज़लेटर सारांशित कर रहा है या सोशल पोस्ट ड्राफ़्ट कर रहा है, तो आपको फ़र्क महसूस नहीं होगा — और आप ऐसी क्षमता के पैसे चुकाएँगे जिसे आप इस्तेमाल ही नहीं कर रहे। ## वह कॉस्ट वाला झटका जिसके बारे में कोई आगाह नहीं करता यह वही चीज़ है जो आपको काटेगी अगर आप रिलीज़ नोट्स बस सरसरी तौर पर पढ़ते हैं। Fable 5 एक **नए tokenizer** के साथ आता है, और वही कॉन्टेंट Opus लाइन के मुक़ाबले लगभग **30% ज़्यादा टोकन** में टोकनाइज़ होता है। इसे दोबारा पढ़िए, क्योंकि यह कीमत के साथ मिलकर बढ़ता है। Fable 5 की कीमत शुरू से ही Opus-टियर से ऊपर है ($10 प्रति मिलियन input token, $50 प्रति मिलियन output)। अब हर प्रॉम्प्ट और कम्प्लीशन के ऊपर ~30% का टोकन फुलाव जोड़ दीजिए। एक अपरिवर्तित वर्कलोड — वही प्रॉम्प्ट, वही आउटपुट — माइग्रेशन के बाद काफ़ी ज़्यादा खर्च करा सकता है, इससे पहले कि आपने एजेंट के काम में एक भी चीज़ बदली हो। तो अपने पुराने आँकड़े दोबारा मत इस्तेमाल कीजिए। आपकी `max_tokens` सेटिंग्स, आपके कॉन्टेक्स्ट-विंडो बजट, आपके प्रति-रन कॉस्ट अनुमान — ये सब एक अलग tokenizer पर मापे गए थे। अच्छी ख़बर: token-counting endpoint **दोनों** tokenizers के तहत काउंट लौटाता है जब आप `model: "claude-fable-5"` पास करते हैं, तो कुछ भी पलटने से पहले आप अपने असली प्रॉम्प्ट पर डेल्टा माप सकते हैं। ```bash # Measure the tokenizer delta on YOUR prompt before migrating. # The response includes input_tokens (new) AND input_tokens_prior_tokenizer (old). curl https://api.anthropic.com/v1/messages/count_tokens \ -H "x-api-key: $ANTHROPIC_API_KEY" \ -H "anthropic-version: 2023-06-01" \ -H "content-type: application/json" \ -d '{ "model": "claude-fable-5", "messages": [{"role":"user","content":""}] }' ``` मैंने यह सबसे पहले अपने सबसे भारी प्रॉम्प्ट पर चलाया। डेल्टा एकसमान नहीं था — यह कॉन्टेंट के हिसाब से बदलता है — पर "~30% ज़्यादा के लिए बजट रखो, फिर कीमत प्रीमियम जोड़ो" सही मानसिक मॉडल साबित हुआ। ## Thinking हमेशा ऑन रहता है — और आप इसे बंद नहीं कर सकते Fable 5 पर, adaptive thinking हमेशा चलता रहता है। Opus लाइन के मुक़ाबले एकमात्र नया ब्रेकिंग चेंज: अगर आप एक स्पष्ट `thinking: {type: "disabled"}` भेजते हैं, तो आपको 400 मिलता है। उपाय सरल है — बस `thinking` पैरामीटर को पूरी तरह छोड़ दीजिए — लेकिन अगर आपके पास ऐसा कोड था जो सस्ते, तेज़ कॉल के लिए thinking को स्पष्ट रूप से बंद करता था, तो वह कोड अब error देगा। आपको कच्ची chain of thought भी वापस नहीं मिलती। Fable 5 इसे सुरक्षित रखता है: आपको सामान्य `thinking` ब्लॉक मिलते हैं, और आप `display: "summarized"` के साथ एक पढ़ने योग्य सारांश माँग सकते हैं, पर बिना छने तर्क को कभी उजागर नहीं किया जाता। ज़्यादातर ऐप्स के लिए यह कोई मुद्दा नहीं — अगर आपको दृश्यता चाहिए तो सारांश पढ़ लीजिए। जहाँ यह मायने रखता है वह है **मल्टी-टर्न एजेंट**: जब आप उसी मॉडल पर बातचीत जारी रखते हैं, तो आपको thinking ब्लॉक **बिना बदले** वापस पास करने होते हैं। उन्हें हटाइए या एडिट कीजिए तो टर्न टूट जाता है। अगर आप एजेंट लूप बना रहे हैं, तो thinking ब्लॉक को ऐसे अपारदर्शी टोकन मानिए जिन्हें आप हू-ब-हू आगे ले जाते हैं। ## Refusals अब एक control-flow समस्या हैं यह वह बदलाव है जो सबसे ज़्यादा असर डालता है कि आप मॉडल के इर्द-गिर्द कोड कैसे लिखते हैं। Fable 5 आने वाली रिक्वेस्ट्स पर safety classifiers चलाता है, जो मुख्यतः रिसर्च बायोलॉजी और अधिकांश साइबरसिक्योरिटी कॉन्टेंट को निशाना बनाते हैं। जब कोई रिक्वेस्ट अस्वीकार होती है, तो आपको `stop_reason: "refusal"` के साथ एक **सफल HTTP 200** मिलता है — कोई error नहीं, कोई exception नहीं। `content` array खाली हो सकता है। अगर आपका कोड पहले `stop_reason` जाँचे बिना `response.content[0].text` करता है, तो जिस दिन कोई रिक्वेस्ट ठुकराई जाएगी, यह क्रैश कर जाएगा। और सौम्य आसपास के काम — वैध security tooling, लाइफ-साइंसेज़ टास्क — कभी-कभार false positive में फँस सकते हैं, तो यह सिर्फ़ संदिग्ध काम करने वालों की समस्या नहीं है। नियम यह है: **`stop_reason` पर ब्रांच करो, कभी `stop_details` पर नहीं।** ```typescript const res = await client.messages.create({ model: "claude-fable-5", max_tokens: 1024, messages, }); if (res.stop_reason === "refusal") { // classifiers declined — content is empty or partial. Don't read content[0]. await handleRefusal(res); } else { console.log(res.content[0].text); } ``` प्रोडक्शन के लिए एक साफ़-सुथरा रास्ता है: एक सर्वर-साइड `fallbacks` पैरामीटर (बीटा में) जो किसी ठुकराई गई रिक्वेस्ट को उसी राउंड ट्रिप में `claude-opus-4-8` पर अपने-आप दोबारा कोशिश करता है, क्रेडिट-शैली री-प्राइसिंग लागू करके। अगर आप एजेंट बिना निगरानी के चला रहे हैं, तो इसे जोड़ दीजिए ताकि एक अकेला false-positive refusal पूरे रन को मृत-छोर तक न ले जाए। यह वही सबक है जो एजेंट्स के बारे में मैं बार-बार सीखता रहता हूँ जो [प्रोडक्शन में फेल होते रहते हैं](/blog/why-your-ai-agent-keeps-failing-in-production-and-how-to-fix-it): मॉडल का ज़्यादा स्मार्ट होना उसके edge cases को संभालने की ज़रूरत खत्म नहीं करता — यह बस edge cases को इधर-उधर खिसका देता है। ## माइग्रेशन के दो और ब्योरे कुछ छोटी चीज़ें जिन्होंने मेरा वक़्त खाया ताकि वे आपका न खाएँ: - **कोई assistant prefill नहीं।** अगर आप आख़िरी assistant टर्न को prefill करके आउटपुट को दिशा दे रहे थे, तो वह पैटर्न अब नहीं रहा। इसके बजाय structured outputs (`output_config.format`) या सिस्टम-प्रॉम्प्ट निर्देश इस्तेमाल कीजिए। - **30-दिन का डेटा रिटेंशन अनिवार्य है।** Fable 5 zero-data-retention के तहत उपलब्ध नहीं है। अगर आप अनुपालन कारणों से ZDR पर हैं, तो Fable 5 दायरे से बाहर है और Opus 4.8 आपकी सीमा बना रहता है। माइग्रेशन की योजना बनाने से *पहले* इसे जाँच लीजिए, बाद में नहीं। ## क्या आपको सचमुच स्विच करना चाहिए? इसके साथ रहने के बाद यह रहा मेरा ऑपरेटर वाला फ़ैसला। **Fable 5 डिफ़ॉल्ट "नवीनतम मॉडल पर अपग्रेड करो" लक्ष्य नहीं है — Opus 4.8 है।** यह लोगों को चौंकाता है, पर यही सही ढाँचा है। Opus 4.8, 4.7 से बस एक मॉडल-ID की अदला-बदली है जिसमें कोई नया ब्रेकिंग चेंज नहीं, यह सस्ता है, और एजेंट के अत्यधिक बहुसंख्यक काम के लिए आउटपुट गुणवत्ता में यह अप्रभेद्य है। Fable 5 सचमुच कठिन काम पर अपनी जगह अर्जित करता है: लंबे-दौर वाले एजेंट जिन्हें कई कदमों के पार सुसंगत रहना होता है, गहरा बहु-स्रोत तर्क, वे रन जहाँ जिस विफलता को आप मारने की कोशिश कर रहे हैं वह सूक्ष्म है। उनके लिए क्षमता असली है और प्रीमियम के लायक है। बाक़ी हर चीज़ के लिए — कॉन्टेंट ड्राफ़्टिंग, क्लासिफिकेशन, रूटिंग, सारांशीकरण — आप ऐसी गुणवत्ता के लिए ज़्यादा कीमत पर ज़्यादा टोकन चुका रहे हैं जिसे आप महसूस ही नहीं कर सकते। आख़िरकार मैं दोनों चलाने लगा। मेरा रिसर्च-और-संश्लेषण एजेंट Fable 5 पर चला गया। बाक़ी सब Opus 4.8 पर रहा। यही बँटवारा पूरा मुद्दा है: मॉडल हर काम के हिसाब से चुनिए, फ़ैशन के हिसाब से नहीं। अगर आप एजेंट्स का एक बेड़ा चलाते हैं, तो वही अनुशासन लागू होता है जिसके बारे में मैंने [मेरे 2026 ऑपरेटर स्टैक](/blog/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack) में लिखा था — कठिन काम को महंगे मॉडल पर भेजिए और आसान काम के लिए ज़्यादा भुगतान करना बंद कीजिए। ## ऑपरेटर का अंतिम निचोड़ किसी और चीज़ को छूने से पहले Fable 5 को अपने एकमात्र सबसे कठिन काम पर टेस्ट कीजिए — वहीं यह कीमत वसूल करता है, और अगर यह वहाँ सुई नहीं हिलाता, तो कहीं नहीं हिलाएगा। token-counter को अपने असली प्रॉम्प्ट के ख़िलाफ़ चलाइए ताकि ~30% tokenizer फुलाव और कीमत प्रीमियम इनवॉइस पर आपको न चौंकाएँ। जहाँ कहीं Fable 5 प्रोडक्शन को छूता है वहाँ एक `stop_reason: "refusal"` जाँच (या Opus 4.8 की ओर सर्वर-साइड fallback) जोड़ दीजिए। फिर सोच-समझकर रूट कीजिए: कठिन 10% के लिए Fable 5, बाक़ी के लिए Opus 4.8। सबसे अच्छा मॉडल सबसे सक्षम वाला नहीं — वह है जो काम से मेल खाता हो। --- ## AI एजेंट्स के लिए शुरुआती गाइड: Cowork, Codex और वे टूल्स जो वाकई काम करते हैं Source: https://alejandrorioja.com/hi/ai-agents-for-beginners-cowork-codex-guide/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Productivity, AI TL;DR: AI एजेंट्स चैटबॉट्स से एक कदम आगे हैं: आप उन्हें सरल भाषा में लक्ष्य देते हैं और वे काम करते हैं — फाइलें पढ़ना, ड्राफ्ट बनाना, व्यवस्थित करना, कोड लिखना और चलाना। Cowork नो-कोड शुरुआती रास्ता है; Codex और Claude Code कोडबेस से काम करने वालों के लिए हैं। जरूरी कौशल प्रोग्रामिंग सीखना नहीं, बल्कि स्पष्ट और सीमित निर्देश लिखना है। ## Table of contents _जून 2026 को अपडेट किया गया।_ **TL;DR:** AI एजेंट्स चैटबॉट्स से एक कदम आगे हैं: आप उन्हें सरल भाषा में लक्ष्य देते हैं और वे काम करते हैं — फाइलें पढ़ना, ड्राफ्ट बनाना, व्यवस्थित करना, कोड लिखना और चलाना, और अपने नतीजे खुद जांचना। **Cowork** गैर-तकनीकी लोगों के लिए नो-कोड शुरुआती रास्ता है; **Codex** और **Claude Code** कोडबेस से काम करने वालों के लिए हैं। एकमात्र जरूरी कौशल प्रोग्रामिंग सीखना नहीं, बल्कि स्पष्ट और सीमित निर्देश लिखना है। **[लेखक की टिप्पणी]** मैं रोज 30 से ज्यादा कोडेड एजेंट्स चलाता हूं, लेकिन ज्यादातर लोगों को कोड के बिना भी 80% मूल्य मिल सकता है। उन्हें बस एक स्पष्ट निर्देश और उसे चलाने की जगह चाहिए। यह गाइड वह परिचय है जो मैं किसी ऐसे समझदार दोस्त को देता जिसने कभी एक लाइन कोड नहीं लिखी। ## "AI एजेंट" असल में क्या होता है चैटबॉट एक सवाल का जवाब देता है। **एजेंट** एक काम पूरा करता है। फर्क यह है कि एजेंट एक लूप में काम कर सकता है — दस्तावेज पढ़ना, यह तय करना कि आगे क्या करना है, फाइल लिखना, कमांड चलाना, नतीजा जांचना, जो गलत है उसे ठीक करना — बिना आपको हर कदम पर मार्गदर्शन किए। सीधे शब्दों में: आप नहीं पूछते "इस स्प्रेडशीट को कैसे साफ करूं?" आप कहते हैं "यह रही स्प्रेडशीट — डुप्लीकेट हटाओ, तारीखों का फॉर्मेट ठीक करो, और जिन पंक्तियों में ईमेल नहीं है उन्हें चिह्नित करो," और एजेंट यह करके साफ की हुई फाइल आपको दे देता है। *सलाह* से *पूरा काम* तक की यह बदलाव — यही पूरी बात है। ## टूल्स की दो फैमिली इस दुनिया में दो दरवाजे हैं, और आपको केवल वह चाहिए जो आपके काम से मेल खाता हो। ### दरवाजा 1: नो-कोड एजेंट्स (अगर आप कोड नहीं लिखते तो यहाँ से शुरू करें) **Claude Cowork** एक वर्कस्पेस है जहाँ आप Claude को एक लक्ष्य और सामग्री देते हैं — फाइलें, लिंक, नोट्स — और वह वह आउटपुट तैयार करता है जिसे आप समीक्षा करके इस्तेमाल करते हैं: एक ड्राफ्ट, सारांश, योजना, साफ की हुई स्प्रेडशीट। आप निर्देश लिखते हैं, कोड नहीं। इसे "एक बहुत काबिल सहायक जो तेज पढ़ता है और कभी थकता नहीं" मानें, न कि "प्रोग्रामिंग टूल।" मार्केटर्स, संस्थापकों, ऑपरेटर्स, लेखकों, विश्लेषकों — जिनका काम मुख्यतः दस्तावेज, रिसर्च और फैसले हैं — उनके लिए यही सही शुरुआती बिंदु है। ### दरवाजा 2: कोडिंग एजेंट्स (जब कोडबेस शामिल हो तो इनका उपयोग करें) **OpenAI Codex** और **Claude Code** ऐसे एजेंट हैं जो वहाँ रहते हैं जहाँ सॉफ्टवेयर बनाया जाता है — टर्मिनल, IDE या क्लाउड। आप एक बदलाव बताते हैं ("डार्क-मोड टॉगल जोड़ो," "यह फेल हो रहा टेस्ट ठीक करो," "इस फाइल को नए API पर माइग्रेट करो") और एजेंट कोड एडिट करता है, चलाता है, और तब तक दोहराता है जब तक काम हो जाए। आप फिर भी सब कुछ देखते हैं; एजेंट टाइपिंग करता है। इन्हें इस्तेमाल करने के लिए सीनियर इंजीनियर होने की जरूरत नहीं। बहुत से गैर-डेवलपर कोडिंग एजेंट्स का उपयोग छोटी वेबसाइट बनाने, स्प्रेडशीट को स्क्रिप्ट के रूप में ऑटोमेट करने और उन टूल्स के बग्स ठीक करने के लिए करते हैं जो उन्होंने नहीं लिखे। लेकिन एक असली लर्निंग कर्व है, इसलिए ज्यादातर शुरुआती लोगों के लिए दरवाजा 1 से शुरू करना और जब कोई ऐसा काम आए जिसमें सच में कोड चाहिए तभी दरवाजा 2 की तरफ जाना बेहतर है। ## आपकी पहली जीत (आज ही करें) कोई एक छोटा, परेशान करने वाला काम चुनें जो आप अक्सर करते हैं। अच्छे पहले विकल्प: - एक अव्यवस्थित मीटिंग ट्रांसक्रिप्ट को साफ नोट्स और एक एक्शन आइटम्स लिस्ट में बदलना। - एक लंबे PDF को 5 बुलेट पॉइंट्स और पूछने लायक 3 सवालों में सारांशित करना। - एक कच्चे ईमेल को दोबारा लिखना ताकि वह स्पष्ट, गर्मजोशी भरा और 120 शब्दों से कम हो। फिर वह स्ट्रक्चर इस्तेमाल करें जो एजेंट्स को भरोसेमंद बनाता है — **भूमिका → इनपुट → सटीक निर्देश → सीमा → एक जांच**: > आप मेरे सहायक हैं। नीचे एक [मीटिंग ट्रांसक्रिप्ट / PDF / ईमेल ड्राफ्ट] पेस्ट किया है। यह करें: [इसे बोल्ड \"एक्शन आइटम्स\" लिस्ट के साथ साफ नोट्स में बदलें / 5 बुलेट्स + 3 फॉलो-अप सवालों में सारांशित करें / इसे स्पष्ट, गर्मजोशी भरा और 120 शब्दों से कम करने के लिए दोबारा लिखें]। मेरी आवाज बनाए रखें। शुरू करने से पहले कोई एक सवाल पूछें अगर कुछ अस्पष्ट हो। > > [यहाँ अपनी सामग्री पेस्ट करें] बस। आपने एक काम डेलिगेट कर दिया। स्ट्रक्चर ही पूरा खेल है — और यह Cowork, ChatGPT, या किसी कोडिंग एजेंट में समान रूप से काम करता है। ## चार-भाग वाला प्रॉम्प्ट जो एजेंट्स को भरोसेमंद बनाता है शुरुआती लोग सोचते हैं कि रहस्य कोई जादुई वाक्यांश है। ऐसा नहीं है। रहस्य है विशिष्टता। हर भरोसेमंद एजेंट निर्देश के चार भाग होते हैं: 1. **भूमिका** — इस काम के लिए एजेंट कौन है ("आप मेरे रिसर्च सहायक हैं")। 2. **संदर्भ** — सामग्री और *क्यों* ("मैं एक फिनटेक संस्थापक के साथ सेल्स कॉल की तैयारी कर रहा हूं")। 3. **काम** — सटीक, सीमित कार्रवाई ("तीन हालिया फंडिंग राउंड के तथ्य निकालें और दो शुरुआती सवाल ड्राफ्ट करें")। 4. **सीमाएं + एक जांच** — फॉर्मेट, लंबाई, टोन, और अनुमान लगाने से पहले पूछने का निर्देश ("केवल बुलेट्स, स्रोत बताएं, अगर कंपनी अस्पष्ट हो तो एक स्पष्टीकरण प्रश्न पूछें")। अस्पष्ट इनपुट, अस्पष्ट आउटपुट। एजेंट जितना अधिक *कर सकता है*, आपकी स्पष्टता उतनी ही महत्वपूर्ण है — एक चैटबॉट जो गलत समझता है वह एक वाक्य बर्बाद करता है; एक एजेंट जो गलत समझता है वह एक दोपहर के काम को बर्बाद करता है जिसे आपको वापस करना पड़ता है। ## शुरुआती गलतियाँ जो छोड़ें - **इसे सर्च इंजन की तरह इस्तेमाल करना।** एक लाइन के सवाल मत पूछें। इसे असली फाइलों के साथ असली काम दें। - **सीमा छोड़ना।** "मुझे एक प्लान लिखो" आपको टेक्स्ट की दीवार देगा। "तीन फेज और हर काम के लिए जिम्मेदार व्यक्ति के साथ एक पेज का प्लान लिखो" आपको कुछ काम का देगा। - **जांच न मांगना।** "कुछ अस्पष्ट हो तो एक सवाल पूछें" जोड़ें और आप एजेंट के चलने से *पहले* गलतफहमियां पकड़ेंगे, बाद में नहीं। - **महत्वपूर्ण कोड पर कोडिंग एजेंट्स को बिना निगरानी चलने देना।** diff देखें। एजेंट तेज और अधिकतर सही होते हैं, लेकिन "अधिकतर" उस वाक्य में काम कर रहा है — जो कुछ भी शिप होता है उसमें इंसान को लूप में रखें। - **बहुत जल्दी दरवाजा 2 की तरफ जाना।** अगर आपका काम दस्तावेज और फैसले हैं, तो आपको कभी टर्मिनल खोलने की जरूरत नहीं। ## अपना पहला टूल कैसे चुनें - **आपका काम दस्तावेज, रिसर्च और लेखन है** → **Cowork** से शुरू करें (या जो चैट प्रोडक्ट आप पहले से पेमेंट करते हैं, उसे एजेंट मोड में इस्तेमाल करें)। - **आप सॉफ्टवेयर बनाना या ठीक करना चाहते हैं** → **Claude Code** या **OpenAI Codex**। - **आप नियमित, बिना हस्तक्षेप का काम चाहते हैं** (रोज का डाइजेस्ट, हफ्ते की रिपोर्ट) → एक बार प्रॉम्प्ट मैन्युअली सीख लें, फिर **[शेड्यूल्ड टास्क्स](https://alejandrorioja.com/how-to-use-claude-scheduled-tasks/)** पर जाएं। ## AI एजेंट्स शुरुआती FAQ — 2026 ### क्या AI एजेंट्स इस्तेमाल करने के लिए कोडिंग जाननी चाहिए? नहीं। Claude Cowork जैसे नो-कोड एजेंट्स गैर-तकनीकी उपयोगकर्ताओं के लिए बने हैं — आप सरल भाषा में निर्देश लिखते हैं। Codex और Claude Code जैसे कोडिंग एजेंट्स में लर्निंग कर्व है, लेकिन उन्हें भी तेजी से ऐसे लोग इस्तेमाल कर रहे हैं जो खुद को प्रोग्रामर नहीं मानते। नो-कोड से शुरू करें, कोड की तरफ तभी जाएं जब काम को इसकी जरूरत हो। ### चैटबॉट और AI एजेंट में क्या फर्क है? चैटबॉट सवालों का जवाब देता है; एजेंट काम पूरा करता है। एजेंट एक लूप में क्रियाओं की श्रृंखला ले सकता है — पढ़ना, तय करना, करना, जांचना, ठीक करना — सलाह के बजाय पूरा काम तैयार करता है। व्यवहार में वही प्रोडक्ट अक्सर दोनों करता है; "एजेंट मोड" एजेंट का व्यवहार है। ### क्या Cowork Codex से बेहतर है? वे अलग-अलग कामों के लिए हैं, बेहतर या बुरे नहीं। Cowork दस्तावेजों, रिसर्च और ऑपरेशन के लिए नो-कोड वर्कस्पेस है। Codex (और Claude Code) सॉफ्टवेयर बनाने और ठीक करने के लिए कोडिंग एजेंट हैं। वह चुनें जो आपके काम से मेल खाता हो। ### AI एजेंट से अच्छे नतीजे कैसे मिलते हैं? विशिष्टता। चार-भाग वाला स्ट्रक्चर इस्तेमाल करें: भूमिका, संदर्भ, सटीक काम, और सीमाएं प्लस एक जांच। इसे असली सामग्री दें, बताएं आप कौन सा फॉर्मेट चाहते हैं, और शुरू करने से पहले अस्पष्टताएं बताने को कहें। स्पष्ट निर्देश किसी भी "जादुई प्रॉम्प्ट" से ज्यादा मायने रखते हैं। ### क्या AI एजेंट्स को अकेले चलने देना सुरक्षित है? कम जोखिम वाले, पलटे जा सकने वाले कामों के लिए (ड्राफ्टिंग, सारांश, व्यवस्थित करना), हाँ — आउटपुट की समीक्षा करें और आगे बढ़ें। जो कुछ भी असली सिस्टम बदलता है (कोड शिप करना, मैसेज भेजना, डेटा मिटाना), उसके लिए इंसान को लूप में रखें और एजेंट के काम करने से पहले समीक्षा करें। उलटाने की क्षमता सही पैमाना है: जितना आसान कुछ उलटना हो, उतनी ज्यादा स्वायत्तता वह सुरक्षित रूप से रख सकता है। **संबंधित पढ़ाई:** [ChatGPT के जवाबों में कैसे उद्धृत हों](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) · [llms.txt प्लेबुक](https://alejandrorioja.com/llms-txt-playbook/) · [Claude शेड्यूल्ड टास्क्स कैसे इस्तेमाल करें](https://alejandrorioja.com/how-to-use-claude-scheduled-tasks/) --- **क्या आप चाहते हैं कि एजेंट्स आपके बिजनेस में काम करें?** मैं ऑपरेटर टीमों के लिए AI एजेंट सिस्टम बनाता हूं — [संपर्क करें](https://alejandrorioja.com/contact/) या इस बारे में [मेरे सोचने के तरीके](https://alejandrorioja.com/seo-tips/) के बारे में और पढ़ें। --- ## Anthropic पैसे कैसे कमाता है? Claude का बिज़नेस मॉडल समझाया Source: https://alejandrorioja.com/hi/how-does-anthropic-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business, AI TL;DR: Anthropic अपने Claude AI मॉडलों तक पहुँच पाँच मुख्य चैनलों के माध्यम से बेचता है: एक उपयोग-आधारित API (आप प्रति टोकन भुगतान करते हैं), उपभोक्ता सदस्यताएँ (Claude Pro और Max), एंटरप्राइज़ प्लान (Team और Enterprise सीट), डेवलपर्स के लिए Claude Code, और Amazon Bedrock तथा Google Vertex जैसे क्लाउड मार्केटप्लेस के माध्यम से वितरण। API और एंटरप्राइज़ बिज़नेस — उपभोक्ता ऐप नहीं — सबसे बड़े राजस्व चालक हैं। ## Table of contents _जून 2026 में अपडेट किया गया।_ **TL;DR:** Anthropic अपने Claude AI मॉडलों तक पहुँच पाँच मुख्य चैनलों के माध्यम से बेचता है: एक **उपयोग-आधारित API** (आप प्रति टोकन भुगतान करते हैं), **उपभोक्ता सदस्यताएँ** (Claude Pro और Max), **एंटरप्राइज़ प्लान** (Team और Enterprise सीट), डेवलपर्स के लिए **Claude Code**, और Amazon Bedrock तथा Google Vertex AI जैसे **क्लाउड मार्केटप्लेस के माध्यम से वितरण**। उपभोक्ता चैट ऐप नहीं बल्कि API और एंटरप्राइज़ बिज़नेस — सबसे बड़े राजस्व चालक हैं। **[ऑपरेटर की टिप्पणी]** मैं हर दिन Anthropic के API पर विकास करता हूँ, इसलिए मैं बिज़नेस को मीटर के अंदर से देखता हूँ। समझने वाली बात यह है: Anthropic एक उपभोक्ता प्रवेश द्वार वाली B2B कंपनी है। आप जो चैट ऐप उपयोग करते हैं वह मार्केटिंग और एक राजस्व लाइन है; असली पैसा उन डेवलपर्स और उद्यमों में है जो API के माध्यम से टोकन मापते हैं और बड़े पैमाने पर सीट के लिए भुगतान करते हैं। ## Anthropic क्या है Anthropic एक AI सुरक्षा और अनुसंधान कंपनी है, जिसकी स्थापना 2021 में हुई, जो बड़े भाषा मॉडल के **Claude** परिवार का निर्माण करती है। यह उन मॉडलों को — और उनके आसपास के टूल्स को — उपभोक्ताओं, डेवलपर्स और उद्यमों को बेचती है। यह एक निजी कंपनी है, जिसे Amazon और Google सहित रणनीतिक निवेशकों का भारी समर्थन प्राप्त है, जो क्लाउड और वितरण भागीदारों के रूप में भी काम करते हैं। उत्पाद एक सेवा के रूप में बुद्धिमत्ता है: आप बॉक्स में सॉफ्टवेयर नहीं खरीदते, आप एक ऐसे मॉडल तक पहुँच किराये पर लेते हैं जो आपकी ओर से पढ़ता, लिखता, तर्क करता और कार्य करता है। नीचे दिया गया प्रत्येक चैनल उसी मूल संपत्ति के चारों ओर एक अलग आवरण है। ## Anthropic पैसे कैसे कमाता है? ### 1. API (उपयोग-आधारित, मुख्य इंजन) बिज़नेस की नींव। डेवलपर्स और कंपनियाँ API के माध्यम से Claude को कॉल करती हैं और **प्रति टोकन** भुगतान करती हैं — लगभग, इनपुट और आउटपुट में टेक्स्ट के प्रत्येक खंड के लिए। कीमत मॉडल की क्षमता के साथ बढ़ती है: - **Claude Opus** (सबसे सक्षम स्तर) सबसे महंगा है — प्रति मिलियन इनपुट टोकन कुछ डॉलर के क्रम में और आउटपुट के लिए उससे कई गुना अधिक। - **Claude Sonnet** (संतुलित कार्यशील मॉडल) बीच में है। - **Claude Haiku** (तेज, सस्ता स्तर) सबसे कम कीमत पर है, उच्च-मात्रा वाले सरल कार्यों के लिए। आउटपुट टोकन इनपुट टोकन से अधिक महंगे होते हैं, और लंबे संदर्भ, प्रॉम्प्ट कैशिंग और बैच प्रोसेसिंग जैसी सुविधाओं की अपनी कीमत होती है। मुख्य गतिशीलता: **राजस्व सीधे उपयोग के साथ बढ़ता है**। एक स्टार्टअप जो Claude को अपने उत्पाद में एम्बेड करता है और लाखों उपयोगकर्ताओं तक बढ़ता है, Anthropic द्वारा नया अनुबंध हस्ताक्षर किए बिना हर महीने अधिक API राजस्व उत्पन्न करता है। यह उपयोग-आधारित मॉडल ही कारण है कि AI लैब्स "रन-रेट राजस्व" के इतनी तेज़ी से बढ़ने की बात करते हैं — यह ग्राहकों की अपनी वृद्धि के साथ चक्रवृद्धि होती है। ### 2. उपभोक्ता सदस्यताएँ (Claude Pro और Max) Claude ऐप्स (वेब, डेस्कटॉप, मोबाइल) मुफ़्त में आज़माने के लिए उपलब्ध हैं, उन लोगों के लिए भुगतान वाले स्तर हैं जो इन्हें भारी मात्रा में उपयोग करते हैं: - **Claude Pro** — उच्च उपयोग सीमाओं, सर्वश्रेष्ठ मॉडलों तक पहुँच, और बड़े संदर्भ और प्राथमिकता पहुँच जैसी सुविधाओं के लिए एक निश्चित मासिक शुल्क। - **Claude Max** — उन पावर उपयोगकर्ताओं के लिए अधिक कीमत वाला स्तर जो Pro की सीमाओं तक पहुँचते हैं, जिसमें काफी अधिक उपयोग की गुंजाइश होती है। यह Anthropic का सबसे दृश्यमान हिस्सा है, लेकिन एक ऐसी कंपनी के लिए जिसके ग्राहक ज़्यादातर अन्य व्यवसाय हैं, यह API और एंटरप्राइज़ लाइनों की तुलना में छोटा हिस्सा है। इसका रणनीतिक मूल्य राजस्व स्रोत जितना ही एक फनल और ब्रांड सतह के रूप में है। ### 3. एंटरप्राइज़ (Team और Enterprise सीट) यहाँ बहुत सारा स्थायी पैसा है। कंपनियाँ संगठनों के लिए बनाए गए प्लान के साथ **प्रति-सीट** आधार पर अपने कर्मचारियों के लिए Claude खरीदती हैं: - **Team** — छोटी कंपनियों के लिए: पूल्ड उपयोग, केंद्रीय बिलिंग, सहयोग सुविधाएँ। - **Enterprise** — बड़े संगठनों के लिए: उच्च सुरक्षा और अनुपालन, एकल साइन-ऑन, बड़े संदर्भ विंडो, व्यवस्थापक नियंत्रण और उपयोग गारंटी। एंटरप्राइज़ सौदे आवर्ती होते हैं, समय के साथ विस्तार करते हैं (अधिक सीट, अधिक उपयोग), और उस तरह की स्विचिंग लागत के साथ आते हैं जो राजस्व को टिकाऊ बनाती है। यह मॉडल के ऊपर स्तरित क्लासिक SaaS गतिविधि है। ### 4. Claude Code (डेवलपर टूलिंग) **Claude Code** Anthropic का एजेंटिक कोडिंग टूल है — एक एजेंट जो आपके टर्मिनल, IDE या क्लाउड में कोड लिखता, संपादित करता और चलाता है। इसे उन्हीं सदस्यता और उपयोग रेल के माध्यम से मुद्रीकृत किया जाता है (यह Pro/Max/Team/Enterprise स्तरों में शामिल है और आपके प्लान के विरुद्ध मापा जाता है)। रणनीतिक रूप से, यह दो काम करता है: यह अपने आप में एक राजस्व लाइन है, और यह बहुत अधिक उच्च-मूल्य वाले टोकन उपयोग को चलाता है, क्योंकि कोडिंग एजेंट मॉडल क्षमता का बड़ा हिस्सा उपभोग करते हैं। ### 5. क्लाउड-मार्केटप्लेस वितरण (AWS, Google और अन्य) Anthropic केवल Claude को सीधे नहीं बेचता — यह बड़े क्लाउड प्लेटफॉर्म के माध्यम से भी वितरित करता है: - **Amazon Bedrock** और **Claude Platform on AWS** — AWS पर पहले से मौजूद ग्राहक Amazon के इंफ्रास्ट्रक्चर और बिलिंग के माध्यम से Claude तक पहुँचते हैं। - **Google Vertex AI** और **Microsoft Foundry** — Google Cloud और Microsoft के प्लेटफॉर्म पर वही विचार। ये चैनल उद्यमों तक वहाँ पहुँचते हैं जहाँ उनका क्लाउड खर्च और खरीद पहले से ही होती है, जो Claude को अपनाने के लिए घर्षण को कम करता है। राजस्व प्लेटफॉर्म के साथ साझा किया जाता है, लेकिन पहुँच बहुत बड़ी है — और Amazon और Google के गहरे निवेश इन साझेदारियों को केवल व्यावसायिक नहीं बल्कि रणनीतिक बनाते हैं। ### 6. उभरता हुआ एजेंट प्लेटफॉर्म तेजी से, Anthropic केवल कच्चे मॉडल कॉल नहीं बल्कि **एजेंट इंफ्रास्ट्रक्चर** भी बेचता है — प्रबंधित सेवाएँ जहाँ Anthropic एजेंट लूप चलाता है और उस वातावरण को होस्ट करता है जिसमें एजेंट कार्य निष्पादित करते हैं। जैसे-जैसे अधिक ग्राहक "मॉडल से प्रश्न पूछने" से "एजेंट को काम करवाने" की ओर जाते हैं, यह उच्च-स्तरीय परत प्रति-टोकन कोर के ऊपर मूल्य प्राप्त करने की एक नई जगह बन जाती है। ## क्या Anthropic लाभदायक है? Anthropic निजी है और ऑडिट किए गए वित्तीय विवरण प्रकाशित नहीं करता, लेकिन सार्वजनिक तस्वीर इसके प्रतिस्पर्धियों जैसी ही है: **राजस्व बेहद तेज़ी से बढ़ रहा है**, जबकि कंपनी कंप्यूट (मॉडल प्रशिक्षण और सर्विंग) और अनुसंधान प्रतिभा पर भारी मात्रा में खर्च करती है। अन्य फ्रंटियर AI लैब्स की तरह, यह एक भारी-निवेश चरण में है जहाँ वर्तमान लाभ नहीं बल्कि शीर्ष-रेखा वृद्धि मुख्य बिंदु है। निवेशक जो दांव लगा रहे हैं वह यह है कि जैसे-जैसे AI अधिक सॉफ़्टवेयर में बुना जाता है, उपयोग-आधारित राजस्व चक्रवृद्धि होता रहेगा और अंततः कंप्यूट की लागत से आगे निकल जाएगा। ## OpenAI से यह कैसे तुलना करता है आकार समान हैं — दोनों उपभोक्ता सदस्यताओं, उपयोग-आधारित API, एंटरप्राइज़ सीट और डेवलपर टूल के माध्यम से मुद्रीकरण करते हैं। अंतर ज़ोर और साझेदारी में है: Anthropic डेवलपर/एंटरप्राइज़ API पर ज़ोर देता है और Amazon और Google द्वारा समर्थित है; OpenAI का उपभोक्ता आधार बड़ा है और Microsoft के साथ गहरी साझेदारी है। यदि आप तुलना का दूसरा पक्ष देखना चाहते हैं, तो देखें [OpenAI पैसे कैसे कमाता है](https://alejandrorioja.com/how-does-openai-make-money/)। ## Anthropic का राजस्व मॉडल — 2026 FAQ ### Anthropic का मुख्य राजस्व स्रोत क्या है? **उपयोग-आधारित API** और **एंटरप्राइज़ अनुबंध** सबसे बड़े चालक हैं। डेवलपर्स और कंपनियाँ Claude को कॉल करने के लिए प्रति टोकन भुगतान करती हैं, और संगठन अपनी टीमों के लिए प्रति-सीट प्लान खरीदते हैं। उपभोक्ता Claude सदस्यता सबसे दृश्यमान उत्पाद है लेकिन बिज़नेस लाइनों की तुलना में राजस्व का छोटा हिस्सा है। ### Claude API मूल्य निर्धारण कैसे काम करता है? आप प्रति टोकन भुगतान करते हैं — इनपुट और आउटपुट टेक्स्ट के खंडों में मापे जाते हैं। अधिक सक्षम मॉडल (Opus) संतुलित (Sonnet) या तेज़ (Haiku) मॉडल की तुलना में प्रति टोकन अधिक महंगे होते हैं, और आउटपुट टोकन इनपुट से अधिक महंगे होते हैं। लंबे संदर्भ, प्रॉम्प्ट कैशिंग और बैच प्रोसेसिंग जैसी सुविधाओं की अपनी कीमत होती है। राजस्व सीधे इस बात से बढ़ता है कि ग्राहक मॉडलों का कितना उपयोग करते हैं। ### क्या Anthropic सार्वजनिक रूप से कारोबार करता है? नहीं। Anthropic Amazon और Google सहित रणनीतिक और उद्यम निवेशकों द्वारा समर्थित एक निजी कंपनी है। इसके शेयर सार्वजनिक शेयर बाजारों पर उपलब्ध नहीं हैं, और कोई पुष्टि किया गया IPO नहीं है। ### क्या Anthropic मुफ्त Claude ऐप से पैसे कमाता है? मुफ्त उपयोगकर्ताओं से सीधे नहीं — मुफ्त स्तर एक फनल है। पैसा तब आता है जब मुफ्त उपयोगकर्ता **Pro** या **Max** में अपग्रेड करते हैं, जब टीमें **एंटरप्राइज़ सीट** खरीदती हैं, और विशेष रूप से जब डेवलपर्स **API** पर निर्माण करते हैं। मुफ्त ऐप का काम पहुँच और ब्रांड है; भुगतान किए गए स्तर और API वह जगह हैं जहाँ यह रूपांतरित होता है। ### Anthropic के सबसे बड़े ग्राहक कौन हैं? मुख्य रूप से अन्य व्यवसाय: सॉफ्टवेयर कंपनियाँ जो API के माध्यम से अपने उत्पादों में Claude को एम्बेड करती हैं, और उद्यम जो Claude को कर्मचारियों के लिए रोल आउट करते हैं। AWS, Google और Microsoft के माध्यम से क्लाउड-मार्केटप्लेस वितरण बड़े एंटरप्राइज़ ग्राहकों को भी आकर्षित करता है जो अपने मौजूदा क्लाउड प्रदाताओं के माध्यम से खरीदते हैं। **संबंधित पठन:** [OpenAI पैसे कैसे कमाता है](https://alejandrorioja.com/how-does-openai-make-money/) · [AI एजेंट के लिए शुरुआती मार्गदर्शिका](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) · [ChatGPT उत्तरों में कैसे उद्धृत किया जाए](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) --- ## संक्षिप्त संस्करण Anthropic अपने Claude मॉडलों तक पहुँच किराये पर देता है। डेवलपर्स API के माध्यम से प्रति टोकन भुगतान करते हैं, उपभोक्ता Pro और Max के लिए मासिक भुगतान करते हैं, कंपनियाँ Team और Enterprise के लिए प्रति सीट भुगतान करती हैं, इंजीनियर उन्हीं प्लान पर Claude Code का उपयोग करते हैं, और क्लाउड दिग्गज (AWS, Google, Microsoft) अपने मार्केटप्लेस के माध्यम से उद्यमों को Claude पुनः बेचते हैं। यह एक उपभोक्ता प्रवेश द्वार वाला B2B बिज़नेस है — और मीटर, न कि चैट ऐप, वह जगह है जहाँ पैसा है। --- ## OpenAI पैसे कैसे कमाता है? ChatGPT और API बिज़नेस मॉडल Source: https://alejandrorioja.com/hi/how-does-openai-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business, AI TL;DR: OpenAI चार मुख्य तरीकों से पैसे कमाता है: ChatGPT सब्सक्रिप्शन (Plus, Pro, Team, Enterprise, Edu), एक उपयोग-आधारित API जहाँ डेवलपर्स प्रति टोकन भुगतान करते हैं, बड़े एंटरप्राइज़ अनुबंध, और Microsoft साझेदारी (वितरण के साथ-साथ राजस्व-साझाकरण समझौता)। अधिकांश AI लैब्स के विपरीत, OpenAI का उपभोक्ता सब्सक्रिप्शन व्यवसाय उसका सबसे बड़ा एकल राजस्व स्रोत है — ChatGPT का विशाल पैमाना ही इसका इंजन है। ## Table of contents _जून 2026 में अपडेट किया गया।_ **TL;DR:** OpenAI चार मुख्य तरीकों से पैसे कमाता है: **ChatGPT सब्सक्रिप्शन** (Plus, Pro, Team, Enterprise, Edu), एक **उपयोग-आधारित API** जहाँ डेवलपर्स प्रति टोकन भुगतान करते हैं, बड़े **एंटरप्राइज़ अनुबंध**, और **Microsoft साझेदारी** (वितरण के साथ-साथ राजस्व-साझाकरण समझौता)। अधिकांश AI लैब्स के विपरीत, OpenAI का उपभोक्ता सब्सक्रिप्शन व्यवसाय उसका सबसे बड़ा एकल राजस्व स्रोत है — ChatGPT का विशाल पैमाना ही इसका इंजन है। **[ऑपरेटर की नज़र]** OpenAI एक विशिष्ट एंटरप्राइज़ AI कंपनी का उलटा है: इसने पहले एक उपभोक्ता घटना बनाई और उसके बाद डेवलपर/एंटरप्राइज़ व्यवसाय खड़ा किया। ChatGPT के सैकड़ों करोड़ उपयोगकर्ता ब्रांड भी हैं और पैसे बनाने की मशीन भी। इस क्षेत्र में बाकी सभी चाहते हैं कि उनके पास भी ऐसा ही टॉप-ऑफ-फनल हो। ## OpenAI क्या है? OpenAI वह AI रिसर्च कंपनी है जिसने **ChatGPT** और **GPT** मॉडल परिवार बनाए, साथ ही Sora वीडियो मॉडल, इमेज जनरेशन, और Codex कोडिंग एजेंट जैसे उत्पाद भी। 2015 में स्थापित, इसने मुख्यधारा में पहचान तब बनाई जब 2022 के अंत में ChatGPT लॉन्च हुआ और इतिहास में सबसे तेज़ी से बढ़ने वाले उपभोक्ता उत्पादों में से एक बन गया। इसकी संरचना असामान्य है: यह एक गैर-लाभकारी संस्था के रूप में शुरू हुई और फिर फ्रंटियर मॉडल प्रशिक्षण के लिए आवश्यक भारी पूंजी जुटाने हेतु एक सीमित-लाभ वाली व्यावसायिक शाखा बनाई। यह सार्वजनिक रूप से सूचीबद्ध नहीं है और **Microsoft** के साथ एक गहरी, बहु-वर्षीय साझेदारी है जो कम्प्यूट, वितरण और पूंजी प्रदान करती है। उत्पाद, हर AI लैब की तरह, इंटेलिजेंस-ऐज़-ए-सर्विस है — उपभोक्ता, डेवलपर और एंटरप्राइज़ चैनलों के ज़रिए बेचा जाता है। ## OpenAI पैसे कैसे कमाता है? ### 1. ChatGPT सब्सक्रिप्शन (सबसे बड़ी लाइन) यही वो चीज़ है जो OpenAI को अपने प्रतिस्पर्धियों से अलग करती है। ChatGPT मुफ़्त में उपयोग किया जा सकता है, लेकिन पेड टियर्स इसके विशाल उपयोगकर्ता आधार के एक हिस्से को आवर्ती राजस्व में बदलते हैं: - **ChatGPT Plus** — सर्वश्रेष्ठ मॉडल्स तक पहुँच, उच्च सीमाएँ और प्रीमियम सुविधाओं के लिए मासिक फ्लैट शुल्क। मास-मार्केट टियर। - **ChatGPT Pro** — उन पावर यूज़र्स के लिए उच्च-मूल्य टियर जो अधिकतम उपयोग और सबसे शक्तिशाली मॉडल सेटिंग्स चाहते हैं। - **ChatGPT Team** — साझा वर्कस्पेस और एडमिन टूल्स के साथ छोटे व्यवसायों के लिए प्रति-सीट प्लान। - **ChatGPT Enterprise** — बड़े संगठनों के लिए: उन्नत सुरक्षा, अनुपालन, SSO, बड़ा संदर्भ, और उपयोग गारंटी। - **ChatGPT Edu** — विश्वविद्यालयों और स्कूलों के लिए तैयार किया गया संस्करण। चूँकि ChatGPT साप्ताहिक सैकड़ों करोड़ उपयोगकर्ताओं तक पहुँचता है, यहाँ तक कि पेड प्लान में एकल अंक कम रूपांतरण दर भी एक विशाल सब्सक्रिप्शन व्यवसाय बनाती है। यह उपभोक्ता पैमाना OpenAI का परिभाषित लाभ है, और सब्सक्रिप्शन को उसके सबसे बड़े राजस्व स्रोत के रूप में रिपोर्ट किया जाता है। ### 2. API (उपयोग-आधारित, डेवलपर्स के लिए) डेवलपर्स और कंपनियाँ OpenAI के मॉडल्स को अपने उत्पादों में शामिल करती हैं और **प्रति टोकन** — संसाधित टेक्स्ट (या इमेज, या ऑडियो) के प्रत्येक हिस्से के लिए भुगतान करती हैं। कीमतें मॉडल क्षमता के साथ बढ़ती हैं: फ्लैगशिप रीज़निंग मॉडल्स छोटे, तेज़, सस्ते मॉडल्स की तुलना में प्रति टोकन अधिक महंगे होते हैं, और आउटपुट की कीमत इनपुट से अधिक होती है। API GPT पर निर्माण करने वाली हर कंपनी को एक मीटर्ड ग्राहक में बदल देता है जिसका बिल उसके अपने उपयोग के साथ बढ़ता है। यह वही संयोजन गतिशीलता है जिस पर हर AI लैब निर्भर करती है: एक स्टार्टअप जो OpenAI को एम्बेड करता है और लाखों उपयोगकर्ताओं तक बढ़ता है, बिना किसी नए अनुबंध के हर महीने अधिक API राजस्व उत्पन्न करता है। ### 3. एंटरप्राइज़ अनुबंध सेल्फ-सर्व API और Team प्लान से परे, OpenAI बड़ी कंपनियों के साथ बड़े, कस्टम सौदे करता है — बल्क उपयोग, समर्पित क्षमता, कस्टम समर्थन, और सुरक्षा/अनुपालन प्रतिबद्धताएँ। ये आवर्ती हैं, समय के साथ विस्तारित होते हैं, और एक बार जब कोई कंपनी मॉडल्स के ऊपर महत्वपूर्ण वर्कफ़्लो बनाती है तो ये स्थायी हो जाते हैं। यह एंटरप्राइज़ मोशन उपभोक्ता व्यवसाय के साथ-साथ बैठता है और एक प्रमुख विकास क्षेत्र है। ### 4. Microsoft साझेदारी Microsoft OpenAI का सबसे बड़ा रणनीतिक भागीदार है। यह रिश्ता कई अक्षों पर काम करता है: - **कम्प्यूट** — Microsoft का Azure क्लाउड उस अधिकांश इन्फ्रास्ट्रक्चर प्रदान करता है जिस पर OpenAI मॉडल्स को ट्रेन और सर्व करता है। - **वितरण** — OpenAI के मॉडल्स Microsoft के प्लेटफ़ॉर्म (Azure के AI सेवाएँ, Copilot उत्पाद) के ज़रिए पेश किए जाते हैं, जो GPT को Microsoft के विशाल एंटरप्राइज़ ग्राहक आधार के सामने रखते हैं। - **राजस्व साझाकरण** — दोनों कंपनियाँ अपने व्यावसायिक समझौते के तहत राजस्व साझा करती हैं, और Microsoft ने OpenAI में भारी निवेश किया है। यह साझेदारी आंशिक रूप से पूंजी है और आंशिक रूप से गो-टू-मार्केट: यह OpenAI को उन एंटरप्राइज़ तक पहुँच देती है जिन तक सीधे बेचने में वर्षों लग जाते। ### 5. नए और समीपवर्ती उत्पाद OpenAI उस सतह का विस्तार करता रहता है जिसे वह मोनेटाइज़ कर सकता है: - **Codex** — इसका एजेंटिक कोडिंग टूल, सब्सक्रिप्शन और API उपयोग के ज़रिए मोनेटाइज़ किया गया (और भारी टोकन खपत का एक चालक)। - **Sora** — वीडियो जनरेशन, पेड टियर्स के अंदर और एक स्वतंत्र उत्पाद के रूप में पेश किया गया। - **इमेज जनरेशन और अन्य मोडैलिटी** — सब्सक्रिप्शन में बंडल और API के ज़रिए मीटर्ड। - **एक डेवलपर/एजेंट इकोसिस्टम** — कस्टम GPTs, एक एजेंट्स प्लेटफ़ॉर्म, और टूल्स जो व्यवसायों को OpenAI के मॉडल्स के ऊपर निर्माण करने देते हैं। इनमें से हर एक उसी मूल संपत्ति के आसपास एक और आवरण है, जिसका उद्देश्य उपयोगकर्ताओं और डेवलपर्स की भुगतान इच्छा का अधिक हिस्सा पकड़ना है। ## क्या OpenAI लाभदायक है? OpenAI निजी है और ऑडिटेड वित्तीय विवरण प्रकाशित नहीं करता। व्यापक रूप से रिपोर्ट की गई तस्वीर: **राजस्व बहुत बड़ा है और तेज़ी से बढ़ रहा है**, लेकिन लागत भी है — फ्रंटियर मॉडल्स को ट्रेन करना और सैकड़ों करोड़ उपयोगकर्ताओं की सेवा करने में चौंका देने वाली मात्रा में कम्प्यूट की खपत होती है। अपने समकक्षों की तरह, OpenAI भारी-निवेश के चरण में है जहाँ प्राथमिकता विकास और क्षमता है, न कि अल्पकालिक लाभ। दांव यह है कि पैमाना और बढ़ता एंटरप्राइज़ अपनाना अंततः कम्प्यूट लागत से आगे निकल जाएगा। ## Anthropic से तुलना निर्माण खंड समान हैं — उपभोक्ता सब्सक्रिप्शन, उपयोग-आधारित API, एंटरप्राइज़ सौदे, कोडिंग टूल्स — लेकिन जोर अलग है। OpenAI का परिभाषित किनारा **उपभोक्ता पैमाना** (ChatGPT) और उसकी **Microsoft** साझेदारी है; Anthropic **डेवलपर/एंटरप्राइज़ API** पर अधिक ध्यान देता है और Amazon और Google द्वारा समर्थित है। तुलना के दूसरे पक्ष के लिए, देखें [Anthropic पैसे कैसे कमाता है](https://alejandrorioja.com/how-does-anthropic-make-money/)। ## OpenAI राजस्व मॉडल — 2026 FAQ ### OpenAI का सबसे बड़ा राजस्व स्रोत क्या है? **ChatGPT सब्सक्रिप्शन।** चूँकि ChatGPT सैकड़ों करोड़ उपयोगकर्ताओं तक पहुँचता है, इसके पेड टियर्स (Plus, Pro, Team, Enterprise, Edu) OpenAI की सबसे बड़ी एकल राजस्व लाइन बनाते हैं — एक AI लैब के लिए असामान्य प्रोफ़ाइल, जिनमें से अधिकांश उपभोक्ताओं की तुलना में API और एंटरप्राइज़ से अधिक कमाते हैं। ### OpenAI का API पैसे कैसे कमाता है? डेवलपर्स अपने ऐप्स में OpenAI के मॉडल्स का उपयोग करने के लिए **प्रति टोकन** भुगतान करते हैं — संसाधित प्रत्येक टेक्स्ट, इमेज या ऑडियो के हिस्से के लिए। अधिक सक्षम मॉडल्स प्रति टोकन अधिक लागत लेते हैं, और आउटपुट की कीमत इनपुट से अधिक होती है। ग्राहकों का अपना उपयोग बढ़ने के साथ राजस्व स्वचालित रूप से बढ़ता है। ### क्या OpenAI सार्वजनिक रूप से कारोबार करता है? क्या मैं OpenAI स्टॉक खरीद सकता हूँ? नहीं। OpenAI निजी तौर पर आयोजित है और इसके शेयर सार्वजनिक एक्सचेंजों पर उपलब्ध नहीं हैं। अधिकांश लोग सीधे निवेश नहीं कर सकते। Microsoft अपनी साझेदारी के माध्यम से एक बड़ी हिस्सेदारी रखता है, लेकिन यह OpenAI के सार्वजनिक होने जैसा नहीं है। ### Microsoft साझेदारी OpenAI को पैसे कैसे कमाती है? Microsoft Azure कम्प्यूट प्रदान करता है, अपने उत्पादों और क्लाउड के माध्यम से एक विशाल एंटरप्राइज़ आधार को OpenAI के मॉडल्स वितरित करता है, और दोनों अपने व्यावसायिक समझौते के तहत राजस्व साझा करते हैं। Microsoft ने OpenAI में भारी निवेश भी किया है। यह एक वित्तपोषण स्रोत और एक वितरण चैनल दोनों है। ### क्या OpenAI मुफ़्त ChatGPT उपयोगकर्ताओं से पैसे कमाता है? सीधे तौर पर नहीं — मुफ़्त टियर एक फनल है। राजस्व तब आता है जब मुफ़्त उपयोगकर्ता **Plus** या **Pro** में अपग्रेड करते हैं, जब व्यवसाय **Team** या **Enterprise** सीटें खरीदते हैं, और जब डेवलपर्स **API** पर निर्माण करते हैं। मुफ़्त उत्पाद की भूमिका पहुँच है; पेड टियर्स और API उसे परिवर्तित करते हैं। **संबंधित पठन:** [Anthropic पैसे कैसे कमाता है](https://alejandrorioja.com/how-does-anthropic-make-money/) · [SpaceX पैसे कैसे कमाता है](https://alejandrorioja.com/how-does-spacex-make-money/) · [AI एजेंट्स के लिए शुरुआती गाइड](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) --- ## संक्षिप्त संस्करण OpenAI ChatGPT के विशाल उपयोगकर्ता आधार को सब्सक्रिप्शन राजस्व (Plus, Pro, Team, Enterprise) में बदलता है, API के माध्यम से डेवलपर्स से प्रति टोकन शुल्क लेता है, बड़े एंटरप्राइज़ सौदे करता है, और कम्प्यूट, वितरण और साझा राजस्व के लिए Microsoft पर निर्भर करता है। इसकी परिभाषित विशेषता उपभोक्ता पैमाना है — अधिकांश AI लैब्स पहले डेवलपर्स को मोनेटाइज़ करती हैं; OpenAI ने पहले एक उपभोक्ता घटना बनाई और उसके पीछे एक व्यवसाय। --- ## SpaceX पैसा कैसे कमाता है? लॉन्च, Starlink और IPO का सवाल Source: https://alejandrorioja.com/hi/how-does-spacex-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business TL;DR: SpaceX तीन तरीकों से पैसा कमाता है: लॉन्च सेवाएं (पुन:उपयोगी Falcon रॉकेट पर ऑर्बिट की सीटें बेचना), Starlink (उपभोक्ता, एंटरप्राइज़, समुद्री/विमानन और सरकारी सैटेलाइट इंटरनेट) और सरकारी अनुबंध (NASA क्रू और कार्गो, चंद्र लैंडर, राष्ट्रीय सुरक्षा लॉन्च)। Starlink अब सबसे बड़ा राजस्व चालक है। SpaceX निजी रहता है; SpaceX का खुद का IPO जल्द नहीं आने वाला, हालांकि Starlink का भविष्य में स्पिन-ऑफ लंबे समय से चर्चा में है। ## Table of contents _जून 2026 में अपडेट किया गया।_ **TL;DR:** SpaceX तीन तरीकों से पैसा कमाता है: **लॉन्च सेवाएं** (पुन:उपयोगी Falcon रॉकेट पर ऑर्बिट की सीटें बेचना), **Starlink** (उपभोक्ता, एंटरप्राइज़, समुद्री/विमानन और सरकारी सैटेलाइट इंटरनेट) और **सरकारी अनुबंध** (NASA क्रू और कार्गो, चंद्र लैंडर, राष्ट्रीय सुरक्षा लॉन्च)। Starlink अब सबसे बड़ा राजस्व चालक है। SpaceX निजी रहता है; SpaceX का खुद का IPO जल्द नहीं आने वाला, हालांकि Starlink का भविष्य में स्पिन-ऑफ लंबे समय से चर्चा में है और बार-बार ठंडा पड़ा है। **[ऑपरेटर का नजरिया]** SpaceX आधुनिक समय का सबसे स्पष्ट उदाहरण है — एक ऐसी कंपनी जिसने हार्ड-टेक की खाई (पुन:उपयोगी रॉकेट) का उपयोग करके उसके ऊपर सॉफ़्टवेयर-अर्थव्यवस्था वाला व्यवसाय (सैटेलाइट इंटरनेट) खड़ा किया। लॉन्च व्यवसाय अस्तित्व का अधिकार कमाता है; Starlink वह जगह है जहां नियमित, स्केलेबल पैसा है। यही एक वाक्य में पूरी कहानी है। ## SpaceX क्या है SpaceX (स्पेस एक्सप्लोरेशन टेक्नोलॉजीज कॉर्प.) रॉकेट और अंतरिक्ष यान डिज़ाइन करता, बनाता और उड़ाता है, और Starlink सैटेलाइट इंटरनेट नेटवर्क संचालित करता है। 2002 में मानवता को बहु-ग्रहीय बनाने के दीर्घकालिक लक्ष्य के साथ स्थापित, यह कुछ ऐसा करके दुनिया का प्रमुख लॉन्च प्रदाता बन गया जो किसी और ने इस पैमाने पर नहीं किया: एक कक्षीय रॉकेट की पहली स्टेज को उतारना और फिर से उपयोग करना, जिसने अंतरिक्ष तक पहुंचने की लागत को ध्वस्त कर दिया। यह लागत लाभ हर चीज़ का इंजन है। सस्ते, बार-बार और भरोसेमंद लॉन्च ही वह चीज़ है जो 7,000 से अधिक सैटेलाइट के नक्षत्र को आर्थिक रूप से संभव बनाते हैं — और यह नक्षत्र ही एक असमान, परियोजना-आधारित लॉन्च व्यवसाय को नियमित-राजस्व व्यवसाय में बदलता है। ## SpaceX पैसा कैसे कमाता है? ### 1. लॉन्च सेवाएं मूल व्यवसाय। SpaceX तीन प्रकार के ग्राहकों को लॉन्च बेचता है: - **वाणिज्यिक सैटेलाइट ऑपरेटर** — जिन कंपनियों को कक्षा में पेलोड चाहिए, वे समर्पित लॉन्च के लिए या **राइडशेयर** मिशन में एक स्लॉट के लिए भुगतान करती हैं (एक रॉकेट पर कई छोटे सैटेलाइट, प्रति किलोग्राम कीमत पर)। - **सरकार और सैन्य** — राष्ट्रीय सुरक्षा पेलोड और विज्ञान मिशन, अक्सर विश्वसनीयता और आश्वासन के लिए प्रीमियम पर। - **अन्य अंतरिक्ष कंपनियां** — जिनमें तेजी से प्रतिस्पर्धी भी शामिल हैं जो अभी भी SpaceX पर निर्भर हैं क्योंकि यह सबसे सस्ती और सबसे उपलब्ध सवारी है। यूनिट अर्थव्यवस्था **पुन:उपयोगिता** के कारण काम करती है: एक ही फर्स्ट-स्टेज बूस्टर कई बार उड़ता है, इसलिए एक लॉन्च की सीमांत लागत कीमत से काफी कम होती है। Falcon 9 वर्कहॉर्स है; Falcon Heavy सबसे भारी पेलोड संभालता है। ### 2. Starlink (नियमित-राजस्व मशीन) Starlink हजारों निम्न-पृथ्वी-कक्षा सैटेलाइट का एक नक्षत्र है जो उन जगहों पर हाई-स्पीड इंटरनेट पहुंचाता है जहां स्थलीय ब्रॉडबैंड नहीं पहुंच पाता। यह अब SpaceX का वह हिस्सा है जो एक वास्तविक सदस्यता व्यवसाय जैसा दिखता है, कई परतों के साथ: - **उपभोक्ता** — परिवार एक डिश (हार्डवेयर) और मासिक सदस्यता के लिए भुगतान करते हैं। - **एंटरप्राइज़ और मोबिलिटी** — व्यवसायों, समुद्री (जहाज, नौका) और **विमानन** (एयरलाइनों के साथ इन-फ्लाइट Wi-Fi सौदे) के लिए उच्च-कीमत वाली योजनाएं। - **सरकार** — **Starshield** सहित, जो सैन्य और सरकारी ग्राहकों को बेचा जाने वाला रक्षा-उन्मुख वेरिएंट है। - **डायरेक्ट-टू-सेल** — मोबाइल कैरियर के साथ साझेदारी जो डेड ज़ोन में सामान्य फोन पर सीधे सैटेलाइट कनेक्टिविटी प्रदान करती है। Starlink लाखों ग्राहकों के बीच हार्डवेयर बिक्री (टर्मिनल) को मासिक नियमित राजस्व (सदस्यता) के साथ जोड़ता है — ग्रहीय पैमाने पर क्लासिक रेजर-एंड-ब्लेड आकार। इसीलिए अधिकांश अनुमान अब Starlink को लॉन्च से आगे SpaceX की सबसे बड़ी राजस्व लाइन के रूप में रखते हैं। ### 3. सरकारी अनुबंध एक अलग, बहुत बड़ा बकेट जो लॉन्च के साथ ओवरलैप करता है लेकिन अलग करने लायक है: - **NASA** — SpaceX **Commercial Crew** कार्यक्रम (Crew Dragon) के तहत अंतर्राष्ट्रीय अंतरिक्ष स्टेशन पर अंतरिक्ष यात्री उड़ाता है और **Cargo Dragon** से उसे आपूर्ति करता है। इसने NASA की चंद्र महत्वाकांक्षाओं के लिए **Starship**-आधारित मानव लैंडिंग सिस्टम बनाने का अनुबंध भी जीता। - **राष्ट्रीय सुरक्षा** — रक्षा और खुफिया पेलोड के लिए नियमित लॉन्च अनुबंध। ये अनुबंध उच्च-मूल्य, बहु-वर्षीय हैं और बहुत सारे विकास को वित्त पोषित करते हैं जो वाणिज्यिक पक्ष को लाभ देता है। ### 4. Starship (भविष्य का इंजन, अभी तक लाभ केंद्र नहीं) Starship SpaceX का पूरी तरह से पुन:उपयोगी, सुपर-हेवी-लिफ्ट वाहन है — Falcon का दीर्घकालिक प्रतिस्थापन और चंद्र/मंगल मिशन और Starlink सैटेलाइट की अगली, बड़ी पीढ़ी दोनों के लिए महत्वपूर्ण। आज यह अन्य तीन व्यवसायों द्वारा वित्त पोषित एक लागत केंद्र है। यदि यह नियमित उड़ान तक पहुंचता है, तो यह लॉन्च लागत को फिर से नाटकीय रूप से कम करता है और बहुत बड़ी Starlink तैनाती को अनलॉक करता है — निवेशक वास्तव में यही दांव लगा रहे हैं। ## क्या SpaceX लाभदायक है? SpaceX निजी है और ऑडिटेड वित्तीय रिपोर्ट प्रकाशित नहीं करता, इसलिए कोई भी सटीक बात एक अनुमान है। व्यापक रूप से रिपोर्ट की गई तस्वीर: पुन:उपयोगिता के कारण प्रति-मिशन आधार पर लॉन्च लाभदायक है, और जैसे-जैसे इसका ग्राहक आधार बढ़ा, Starlink कैश-फ्लो-पॉजिटिव क्षेत्र में आ गया। कंपनी Starship विकास में वापस भारी रकम डालती है, इसलिए "लाभ" काफी हद तक इस बात पर निर्भर करता है कि आप उस R&D को कैसे मानते हैं। प्रगति की दिशा — एक प्रमुख लॉन्च व्यवसाय के ऊपर बढ़ता हुआ Starlink नियमित राजस्व — कंपनी के विशाल निजी मूल्यांकन का समर्थन करती है। ## IPO का सवाल यही वह हिस्सा है जो सभी पूछते हैं, तो यहां ईमानदार संस्करण है। **SpaceX का जल्द IPO होने की उम्मीद नहीं है।** Elon Musk ने बार-बार कहा है कि जब तक Starship और मंगल कार्यक्रम पूंजी-गहन और दीर्घकालिक हैं, वे SpaceX को निजी रखना पसंद करते हैं — सार्वजनिक बाजार का तिमाही दबाव दशकों लंबे मिशन के साथ फिट नहीं बैठता। इसके बजाय, SpaceX आवधिक **टेंडर ऑफर** (कंपनी एक निर्धारित कीमत पर शेयर बिक्री की सुविधा देती है) के माध्यम से कर्मचारियों और शुरुआती निवेशकों को तरलता प्रदान करती है, जो लोगों को सार्वजनिक लिस्टिंग के बिना कैश आउट करने देता है। ये द्वितीयक बिक्री ही हेडलाइन मूल्यांकन आंकड़े उत्पन्न करती है — SpaceX को हाल के राउंड में सैकड़ों अरब डॉलर पर मूल्यांकित किया गया है। **Starlink स्पिन-ऑफ IPO लंबे समय से चर्चा में है** — Musk ने खुद वर्षों पहले सुझाव दिया था कि एक बार Starlink का राजस्व सुचारू और अनुमानित हो जाए तो यह अंततः सार्वजनिक हो सकता है। लेकिन उन्होंने निकट-अवधि के समय-सीमा पर बार-बार ठंडा पानी डाला है। 2026 तक, Starlink का IPO नहीं हुआ है, और कोई पुष्टि की गई तारीख नहीं है। किसी भी "Starlink IPO तारीख" की हेडलाइन को संदेह से देखें जब तक कि यह कंपनी से न आए। ## निष्कर्ष SpaceX का मॉडल एक स्टैक है: पुन:उपयोगी लॉन्च एक लागत खाई बनाता है, वह खाई Starlink को आर्थिक रूप से संभव बनाती है, Starlink पूरी चीज़ को एक नियमित-राजस्व व्यवसाय में बदलती है, और सरकारी अनुबंध अग्रिम कार्य (Starship) को वित्त देते हैं जो फिर से लागत वक्र को रीसेट करता है। यह अपनी पसंद से निजी रहता है, IPO के बजाय टेंडर ऑफर का उपयोग करते हुए — और सार्वजनिक बाजारों का सबसे संभावित रास्ता एक भविष्य की Starlink लिस्टिंग है, न कि समग्र रूप से SpaceX, जब कंपनी तय करे कि समय सही है। ## SpaceX राजस्व मॉडल — 2026 FAQ ### SpaceX का सबसे बड़ा राजस्व स्रोत क्या है? अधिकांश अनुमान अब **Starlink** को लॉन्च सेवाओं से आगे SpaceX की सबसे बड़ी राजस्व लाइन के रूप में रखते हैं, जो लाखों उपभोक्ता, एंटरप्राइज़, मोबिलिटी और सरकारी सदस्यता के साथ-साथ टर्मिनल हार्डवेयर बिक्री द्वारा संचालित है। लॉन्च सेवाएं बड़ी और प्रति-मिशन अत्यधिक लाभदायक बनी हुई हैं, लेकिन Starlink का नियमित मॉडल तेज़ी से स्केल होता है। ### क्या SpaceX सार्वजनिक रूप से कारोबार करता है? क्या मैं SpaceX स्टॉक खरीद सकता हूं? नहीं। SpaceX एक निजी कंपनी है और इसके शेयर सार्वजनिक स्टॉक एक्सचेंज पर उपलब्ध नहीं हैं। अधिकांश लोग सीधे निवेश नहीं कर सकते; पहुंच आम तौर पर निजी राउंड या टेंडर ऑफर में भाग लेने वाले कर्मचारियों और मान्यता प्राप्त निवेशकों तक सीमित है। ऐसे "SpaceX स्टॉक" प्रस्तावों से सावधान रहें जो अन्यथा सुझाते हैं। ### क्या SpaceX या Starlink IPO करेंगे? SpaceX के निकट भविष्य में सार्वजनिक होने की उम्मीद नहीं है — Musk ने कहा है कि वे Starship/मंगल पूंजी-गहन चरण के दौरान इसे निजी रखना चाहते हैं। **Starlink** IPO को वर्षों से एक संभावना के रूप में चर्चा में लाया गया है जब इसका राजस्व अनुमानित हो जाए, लेकिन 2026 तक कोई पुष्टि की गई तारीख नहीं है। किसी भी विशिष्ट "IPO तारीख" दावे को संदेह के साथ माना जाना चाहिए जब तक कि यह कंपनी से न हो। ### Starlink पैसा कैसे कमाता है? Starlink ग्राहकों से एक सैटेलाइट डिश (हार्डवेयर) और एक मासिक सदस्यता शुल्क लेता है, उपभोक्ता, व्यवसाय, समुद्री, विमानन और सरकारी स्तर पर — रक्षा-केंद्रित Starshield और डायरेक्ट-टू-सेल कैरियर साझेदारी सहित। यह रेजर-एंड-ब्लेड मॉडल है: पहले हार्डवेयर, फिर नियमित राजस्व। ### पुन:उपयोगिता SpaceX के लाभ में कैसे मदद करती है? एक ही रॉकेट बूस्टर को कई बार उतारना और फिर से उड़ाना प्रत्येक लॉन्च की सीमांत लागत को वसूले गए मूल्य से काफी नीचे कर देता है। यह लागत लाभ ही SpaceX को सबसे सस्ता लॉन्च प्रदाता बनाता है और कई हजार सैटेलाइट के Starlink नक्षत्र को तैनात करना आर्थिक रूप से व्यवहार्य बनाता है। **संबंधित पठन:** [Uber पैसा कैसे कमाता है](https://alejandrorioja.com/how-does-uber-make-money/) · [Shopify पैसा कैसे कमाता है](https://alejandrorioja.com/how-shopify-makes-money/) · [PayPal पैसा कैसे कमाता है](https://alejandrorioja.com/how-does-paypal-make-money/) --- ## संक्षिप्त संस्करण SpaceX सस्ते में ऑर्बिट की सीटें बेचता है क्योंकि यह अपने रॉकेट को फिर से उपयोग करता है, फिर उस लागत लाभ का उपयोग Starlink चलाने के लिए करता है — एक सैटेलाइट इंटरनेट सदस्यता व्यवसाय जो अब इसका सबसे बड़ा कमाई करने वाला है — जबकि सरकारी अनुबंध अगली पीढ़ी के Starship को वित्त देते हैं। यह जानबूझकर निजी रहता है; SpaceX का नहीं बल्कि Starlink का IPO सार्वजनिक बाजारों तक की सबसे संभावित अंतिम राह है। --- ## Claude के शेड्यूल्ड टास्क कैसे उपयोग करें: cron के साथ दोहराए जाने वाले काम को स्वचालित करें Source: https://alejandrorioja.com/hi/how-to-use-claude-scheduled-tasks/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Productivity, AI TL;DR: शेड्यूल्ड टास्क एक बार के Claude प्रॉम्प्ट को दोहराए जाने वाले काम में बदल देते हैं: यह cron-स्टाइल शेड्यूल पर चलता है, काम करता है और नतीजा देता है। व्यक्तिगत दोहराए जाने वाले प्रॉम्प्ट (सुबह का डाइजेस्ट, साप्ताहिक सारांश) के लिए Claude ऐप और क्लाउड में चलने वाले डेवलपर ऑटोमेशन के लिए Claude Code रूटीन या Managed Agents डिप्लॉयमेंट का उपयोग करें। फायदा उस काम को स्वचालित करने में है जो आप अन्यथा हर दिन या हर हफ्ते हाथ से करते। ## Table of contents _जून 2026 में अपडेट किया गया।_ **TL;DR:** शेड्यूल्ड टास्क एक बार के Claude प्रॉम्प्ट को दोहराए जाने वाले काम में बदल देते हैं: यह cron-स्टाइल शेड्यूल पर चलता है, काम करता है और नतीजा देता है। व्यक्तिगत दोहराए जाने वाले प्रॉम्प्ट (सुबह का डाइजेस्ट, साप्ताहिक सारांश) के लिए **Claude ऐप** और क्लाउड में चलने वाले डेवलपर ऑटोमेशन के लिए **Claude Code रूटीन** या **Managed Agents डिप्लॉयमेंट** का उपयोग करें। फायदा उस काम को स्वचालित करने में है जो आप अन्यथा हर दिन या हर हफ्ते हाथ से दोहराते। **[ऑपरेटर्स के लिए]** सबसे अधिक लीवरेज वाले ऑटोमेशन चकाचौंध नहीं करते — ये वो छोटे दोहराए जाने वाले काम हैं जो चुपचाप हर दिन 20 मिनट खा जाते हैं। शेड्यूल्ड टास्क इन्हें एक बार Claude को सौंपने और कभी न सोचने का तरीका है। मैं कई चलाता हूँ: सुबह प्रतिस्पर्धी स्कैन, रात में PR स्टेटस चेक, साप्ताहिक कंटेंट-पाइपलाइन ड्राफ्ट। किसी को सेट करने में 10 मिनट से ज़्यादा नहीं लगे। ## शेड्यूल्ड टास्क क्या है एक सामान्य Claude सेशन सिंक्रोनस होता है: आप टाइप करते हैं, वो जवाब देता है, आप वहाँ होते हैं। **शेड्यूल्ड टास्क** असिंक्रोनस और दोहराया जाने वाला होता है: आप एक प्रॉम्प्ट (या पूरा एजेंट वर्कफ्लो) प्लस एक शेड्यूल परिभाषित करते हैं, और Claude इसे खुद से चलाता है — हर कार्यदिवस सुबह 7 बजे, हर सोमवार, हर घंटे — और जब हो जाए तो नतीजा आपको देता है। अंदर से यह एक cron जॉब है जिसके केंद्र में एक LLM है। APIs जोड़ने के लिए आपको कोड लिखने की ज़रूरत नहीं; आप सामान्य भाषा में नतीजा बताते हैं और एजेंट हर बार चलने पर खुद कदम तय करता है। ## तीन जगहें जहाँ आप इन्हें सेट करेंगे एक बटन नहीं है — तीन सतहें हैं, इस पर निर्भर कि आप कौन हैं। ### 1. Claude ऐप (सभी के लिए) कंज्यूमर Claude ऐप दोहराए जाने वाले टास्क सपोर्ट करते हैं: आप प्रॉम्प्ट और कैडेंस सेव करते हैं, Claude इसे शेड्यूल पर चलाता है और नतीजे के साथ नोटिफाई करता है। यह नो-कोड रास्ता है — रोज़ाना ब्रीफिंग, बार-बार रिसर्च पुल, "हर सुबह मेरे अनपढ़े न्यूज़लेटर सारांशित करो" जैसे काम के लिए आदर्श। अगर आप डेवलपर नहीं हैं, यहीं से शुरू करें। ### 2. Claude Code रूटीन (टर्मिनल में रहने वालों के लिए) अगर आप **Claude Code** उपयोग करते हैं, तो आप एक प्रॉम्प्ट या स्लैश कमांड को cron कैडेंस पर क्लाउड एजेंट के रूप में चलाने के लिए शेड्यूल कर सकते हैं — एक "रूटीन"। यह आपके रेपो या वर्कस्पेस पर सर्वर-साइड चलता है, इसलिए जब लैपटॉप बंद हो तब भी काम करता है। सामान्य उपयोग: खुले pull requests देखना, रात का lint-और-fix पास चलाना, हर सुबह रिव्यू के लिए एक ड्राफ्ट पोस्ट बनाना। आप शेड्यूल और टास्क परिभाषित करते हैं; Claude Code फायरिंग और रन रिकॉर्ड संभालता है। ### 3. Managed Agents डिप्लॉयमेंट (प्रोडक्ट बनाने वाले डेवलपर्स के लिए) Claude API पर बनाने वाली टीमों के लिए, **शेड्यूल्ड डिप्लॉयमेंट** एक एजेंट को बार-बार cron शेड्यूल पर चलाते हैं — हर फायरिंग एक सेशन शुरू करती है जो स्वायत्त रूप से काम करती है (रात का कंप्लायंस स्कैन, साप्ताहिक रिपोर्ट, हर घंटे की निगरानी)। आपको सफलताओं और विफलताओं की ऑडिट के लिए प्रति-फायरिंग रन रिकॉर्ड मिलता है। यह उसी विचार का प्रोग्रामेटिक, प्रोडक्शन-ग्रेड वर्शन है। ## शेड्यूल के बारे में कैसे सोचें तीनों एक ही मानसिक मॉडल उपयोग करते हैं — **कौन सा टास्क, कितनी बार, आउटपुट के साथ क्या करें**: 1. **टास्क** — इसे ऐसे लिखें जैसे आप कोई भी अच्छा एजेंट प्रॉम्प्ट लिखते: भूमिका, संदर्भ, सटीक कार्य, बाधाएं और एक जांच। शेड्यूल्ड टास्क रन के बीच में स्पष्टीकरण नहीं पूछ सकता, इसलिए इसे *पहले से पूरी तरह निर्दिष्ट* होना चाहिए। यह इंटरेक्टिव उपयोग से सबसे बड़ा अंतर है। 2. **कैडेंस** — दैनिक, साप्ताहिक, प्रति घंटे, केवल कार्यदिवस, आपके टाइमज़ोन में एक विशिष्ट समय। इसे मिलाएं कि असली चीज़ कितनी तेज़ी से बदलती है; साप्ताहिक-अपडेट स्रोत का "दैनिक" डाइजेस्ट बर्बाद रन हैं। 3. **डिलीवरी** — नतीजा कहाँ पहुँचता है (नोटिफिकेशन, फाइल, मैसेज, ड्राफ्ट)। यह पहले से तय करें ताकि आउटपुट आते ही उपयोगी हो। ## ऐसे पैटर्न जो वाकई फायदेमंद हैं - **सुबह का डाइजेस्ट।** "हर कार्यदिवस सुबह 7 बजे, [विषयों] पर नवीनतम जानकारी लो, तीन महत्वपूर्ण बातें सारांशित करो और मुझे 5-बुलेट ब्रीफ भेजो।" 20 मिनट के मैनुअल स्कैनिंग की जगह लेता है। - **साप्ताहिक रिपोर्ट।** "हर सोमवार, [मेट्रिक्स] को एक पेज के सारांश में संकलित करो जिसमें क्या बदला और क्यों शामिल हो।" बार-बार की उबाऊ काम को रिव्यू में बदलता है। - **रात का कार्यकर्ता।** एक कोडिंग रूटीन जो सोते समय एक लंबा, अच्छी तरह से निर्दिष्ट काम चलाता है — रिफैक्टर, टेस्ट स्वीप, डेटा क्लीनअप — ताकि आप एक समीक्षा योग्य नतीजे के साथ जागें। - **मॉनिटर।** "हर घंटे [चीज़] जांचो; मुझे केवल तब संदेश करो जब [शर्त] सच हो।" सबसे अच्छे ऑटोमेशन ज़्यादातर चुप रहते हैं और केवल तब बोलते हैं जब मायने रखता है। ## प्रोडक्शन में चलाने से मिले सेटअप टिप्स - **प्रॉम्प्ट अत्यधिक विस्तृत लिखें।** रन के बीच में स्पष्टीकरण के सवाल संभव नहीं हैं। फ़ॉर्मैट, स्रोत, बाधाएं और एज केस में क्या करना है, बताएं। - **मैनुअल टेस्ट से शुरू करें।** एक बार हाथ से सटीक प्रॉम्प्ट चलाएं। अगर यह इंटरेक्टिव रूप से वो देता है जो आप चाहते हैं, तो शेड्यूल करें। नहीं तो पहले प्रॉम्प्ट ठीक करें — एक बुरे प्रॉम्प्ट को शेड्यूल करना बस विश्वसनीय रूप से बुरा आउटपुट देता है। - **कैडेंस को परिवर्तन दर से मिलाएं।** ऐसी चीज़ पर प्रति घंटे न चलाएं जो साप्ताहिक अपडेट होती है। - **जब दांव ऊँचे हों तो आउटपुट को ड्राफ्ट रखें।** दुनिया में बाहर जाने वाली किसी भी चीज़ के लिए — एक पब्लिश्ड पोस्ट, भेजा गया ईमेल — टास्क को लाइव एक्शन के बजाय आपकी समीक्षा के लिए *ड्राफ्ट* बनाने दें। पूरी तरह स्वायत्त "बस करो" को कम-दांव, पलटने योग्य काम के लिए रखें। - **पहले कुछ रन देखें।** शेड्यूल्ड जॉब ड्रिफ्ट होते हैं — एक स्रोत फ़ॉर्मैट बदलता है, एक फीड शांत हो जाता है। शुरुआती रन रिकॉर्ड जांचें, फिर भरोसा करें। ## Claude शेड्यूल्ड टास्क — 2026 FAQ ### Claude के शेड्यूल्ड टास्क क्या हैं? ये दोहराए जाने वाले काम हैं: आप एक प्रॉम्प्ट या एजेंट वर्कफ्लो प्लस cron-स्टाइल शेड्यूल परिभाषित करते हैं, और Claude इसे स्वचालित रूप से चलाता है — दैनिक, साप्ताहिक, प्रति घंटे — बिना आपके कीबोर्ड पर होने के नतीजा देता है। ये कंज्यूमर Claude ऐप (व्यक्तिगत दोहराए जाने वाले प्रॉम्प्ट के लिए), Claude Code (क्लाउड रूटीन के रूप में) और Claude API (Managed Agents डिप्लॉयमेंट के रूप में) में मौजूद हैं। ### क्या मुझे इन्हें उपयोग करने के लिए डेवलपर होना चाहिए? नहीं। Claude ऐप बिना कोड के दोहराए जाने वाले टास्क सपोर्ट करता है — बस एक सेव किया प्रॉम्प्ट और एक कैडेंस। Claude Code रूटीन और Managed Agents डिप्लॉयमेंट कोड और प्रोडक्ट वर्कफ्लो को स्वचालित करने के लिए डेवलपर-फेसिंग वर्शन हैं। ### शेड्यूल्ड टास्क एक सामान्य Claude चैट से कैसे अलग है? एक सामान्य चैट इंटरेक्टिव है — आप फॉलो-अप सवालों का जवाब देने के लिए वहाँ हैं। शेड्यूल्ड टास्क स्वायत्त और दोहराया जाने वाला है, इसलिए प्रॉम्प्ट पहले से पूरी तरह निर्दिष्ट होना चाहिए; Claude रन के बीच में आपसे सवाल पूछने के लिए रुक नहीं सकता। यह शेड्यूल पर फायर होता है, काम पूरा करता है और नतीजा आपको देता है। ### पहला शेड्यूल्ड टास्क क्या होना चाहिए? एक सुबह का डाइजेस्ट। "हर कार्यदिवस सुबह 7 बजे, [आपके विषयों] पर नवीनतम जानकारी पाँच बुलेट में सारांशित करो।" यह कम-दांव है, जांचना आसान है, और तुरंत एक दोहराई जाने वाली मैनुअल चोर की जगह लेता है — कुछ बड़ा स्वचालित करने से पहले वर्कफ्लो सीखने का परफेक्ट टेम्पलेट। ### क्या शेड्यूल्ड टास्क वास्तविक क्रियाएं कर सकता है, जैसे ईमेल भेजना? हाँ, लेकिन सोच-समझकर करें। पलटने योग्य, कम-दांव वाले काम के लिए, इसे करने दें। बाहर की ओर मुख करने वाली या पलटने में मुश्किल चीज़ों के लिए, स्वचालित रूप से फायर करने के बजाय टास्क को आपके अप्रूवल के लिए ड्राफ्ट बनाने दें — खासकर बिना निगरानी के रन पर। पलटने की क्षमता ही यह तय करने का सही टेस्ट है कि कितनी स्वायत्तता दें। **संबंधित पठन:** [AI एजेंट्स के लिए शुरुआती गाइड](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) · [Anthropic पैसे कैसे कमाता है](https://alejandrorioja.com/how-does-anthropic-make-money/) · [ChatGPT के जवाबों में उद्धृत कैसे हों](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) --- **अपने दोहराए जाने वाले काम को चलाने वाला शेड्यूल्ड एजेंट सिस्टम चाहते हैं?** यही वो है जो मैं बनाता हूँ — [संपर्क करें](https://alejandrorioja.com/contact/)। --- ## AI एजेंट की लागत का गणित: Haiku कब Sonnet को मात देता है (और कब नहीं) Source: https://alejandrorioja.com/hi/ai-agent-cost-math-when-haiku-beats-sonnet/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: Sonnet के बजाय Claude Haiku चुनने से प्रति-कॉल लागत में नाटकीय कटौती हो सकती है, पर केवल तब जब टास्क कम सफलता-दर को सह सके। असली मापदंड प्रति-कॉल लागत नहीं है — यह प्रति-सफल-परिणाम लागत है, जिसमें रीट्राई और मानव सफ़ाई शामिल है। मैं डिफ़ॉल्ट से नहीं, टास्क के हिसाब से राउट करता हूँ। ## विषय-सूची _जून 2026 में अपडेट किया गया।_ **सारांश:** Sonnet के बजाय Claude Haiku चुनने से प्रति-कॉल लागत एक परिमाण-कोटि (order of magnitude) तक घट सकती है, पर केवल तब जब टास्क Haiku की कम सफलता-दर को सह सके। जो मापदंड मायने रखता है वह है **प्रति-सफल-परिणाम लागत** — कॉल लागत जोड़ रीट्राई जोड़ मानव सफ़ाई — न कि प्रति-टोकन का दिखावटी दाम। मैं हर टास्क के हिसाब से राउट करता हूँ, और मेरे उच्च-मात्रा वाले चरणों का एक बड़ा हिस्सा Haiku पर चलता है जबकि निर्णय वाले काम Sonnet पर रहते हैं। **ऑपरेटर का नज़रिया:** मैं 100 से ज़्यादा एजेंट चलाता हूँ, और इन्फ़रेंस एक असली ख़र्च-मद है। पर मैंने ऐसी टीमें देखी हैं जो हर चीज़ को सबसे सस्ते मॉडल पर ठूँसकर "पैसा बचातीं" और फिर वह लागत रीट्राई, एस्केलेशन और नाराज़ ग्राहकों के रूप में चुकातीं। लागत-गणित तभी काम करता है जब आप पूरे फ़नल को मापें। सबसे सस्ता मॉडल वह नहीं है जिसका प्रति-टोकन दाम सबसे कम हो। वह है जिसकी काम को सही ढंग से पूरा करने की कुल लागत सबसे कम हो। ये अलग-अलग आँकड़े हैं, और इनके बीच का फ़ासला ही वह जगह है जहाँ एजेंट की ज़्यादातर लागत-संबंधी निर्णय गड़बड़ा जाते हैं। ## टोकन की अर्थव्यवस्था, सीधे शब्दों में Anthropic, Claude के लिए प्रति दस लाख टोकन शुल्क लेता है, इनपुट और आउटपुट अलग-अलग बिल होते हैं, और आउटपुट की लागत इनपुट से कई गुना ज़्यादा होती है। सटीक आँकड़े समय के साथ बदलते हैं, इसलिए Anthropic की मौजूदा क़ीमत देखें — पर निर्णय को जो चलाता है वह है **संरचना**: - **Haiku** सस्ता, तेज़ स्तर है — परिवार में अब तक की सबसे कम प्रति-टोकन लागत। - **Sonnet** बीच में बैठता है — Haiku से काफ़ी महँगा, Opus से काफ़ी सस्ता। - **Opus** सबसे कठिन तर्क के लिए प्रीमियम स्तर है। इससे दो बातें निकलती हैं। पहली, जनरेटिव टास्क में आउटपुट टोकन लागत पर हावी रहते हैं, इसलिए एक बातूनी मॉडल समान प्रति-टोकन दर पर भी ज़्यादा महँगा पड़ता है। दूसरी, Haiku और Sonnet के बीच प्रति-टोकन फ़ासला इतना बड़ा है कि उच्च-मात्रा वाले चरण पर वह बिल में ज़रूर दिखता है। यह Haiku के *पक्ष* में तर्क है। अब इसके ख़िलाफ़ तर्क। ## असल में जो मापदंड मायने रखता है: प्रति-सफल-परिणाम लागत प्रति-कॉल लागत एक दिखावटी आँकड़ा है। यह रहा वह सूत्र जो मैं सचमुच इस्तेमाल करता हूँ: ``` प्रति_सफलता_लागत = (कॉल_लागत × प्रयास) + सफ़ाई_लागत ÷ सफलता_दर ``` जहाँ `प्रयास` रीट्राई को गिनता है, और `सफ़ाई_लागत` वह अपेक्षित लागत है जो किसी इंसान द्वारा छूटी हुई विफलताओं को ठीक करने में लगती है। देखिए यह तुलना के साथ क्या करता है। मान लीजिए Haiku प्रति कॉल Sonnet की लगभग दसवें हिस्से की लागत है। अगर किसी टास्क पर Haiku 80% बार सफल होता है और Sonnet 98% बार, तो प्रति-कॉल बचत बहुत बड़ी दिखती है। पर अगर Haiku की हर विफलता एक रीट्राई छेड़ती है और 10 में से 1 को अब भी एक इंसान की ज़रूरत होती है जिसका असली पैसा लगता है, तो सफ़ाई वाला पद टोकन की बचत को निगल सकता है। कम-जोखिम, उच्च-मात्रा वाले टास्क पर गणित ज़बरदस्त ढंग से Haiku के पक्ष में है। ऐसे टास्क पर जहाँ एक विफलता ग़लत ग्राहक को ईमेल भेज दे, यह पूरी तरह पलट सकता है। आप यह निर्णय हर मॉडल की सफलता-दर मापे बिना नहीं ले सकते — और ठीक यही [eval हार्नेस](/the-eval-harness-i-use-to-ship-ai-agents/) आपको देता है। वही eval सेट दोनों मॉडलों पर चलाइए और एक ही पैमाने पर सफलता-दरें पढ़िए। ## जहाँ Haiku निर्णायक रूप से जीतता है Haiku तब सही चुनाव है जब टास्क **सीमित, संरचित और सत्यापन-योग्य** हो: - **वर्गीकरण और राउटिंग** — "क्या यह आने वाला संदेश बुकिंग है, शिकायत है, या स्पैम?" तीन ख़ाने, सत्यापन आसान, लगातार चलता है। दिन भर Haiku। - **स्कीमा के साथ निष्कर्षण** — किसी टेक्स्ट से एक तारीख़, एक नाम, एक राशि निकालना, Zod से सत्यापित। अगर आउटपुट पार्स हो जाता है, तो वह लगभग निश्चित रूप से सही है। - **छोटे री-राइट और फ़ॉर्मेटिंग** — लहजे में फेरबदल, ज्ञात-अच्छे इनपुट का सारांश, डेटा का सामान्यीकरण। - **पहली-छँटाई फ़िल्टरिंग** — Haiku ट्राइएज करता है, और केवल अस्पष्ट मामले ही Sonnet तक एस्केलेट होते हैं। यह सबसे ज़्यादा लीवरेज वाला पैटर्न है। साझा सूत्र: Haiku की ग़लती की लागत कम है और ग़लती पकड़ना सस्ता है। जब सत्यापन सस्ता हो और जोखिम कम हो, तो सस्ता मॉडल जीतता है। ## जहाँ Sonnet अपनी क़ीमत वसूल करता है Sonnet (और कभी-कभी Opus) तब सार्थक है जब टास्क **खुला, बहु-चरणीय, या ग़लत होने पर महँगा** हो: - **मल्टी-टूल एजेंट लूप** जहाँ एक ग़लत टूल कॉल झड़ी की तरह फैल जाती है। उच्च तर्क-विश्वसनीयता चरणों में जुड़ती जाती है — [मल्टी-एजेंट ऑर्केस्ट्रेशन](/multi-agent-orchestration-patterns-queues-state-handoffs/) में जिन ऑर्केस्ट्रेशन पैटर्न की मैं बात करता हूँ, वे इस पर टिके हैं कि मॉडल कहानी का सिरा न खोए। - **ग्राहक-सामना करने वाला जनरेशन** जहाँ ख़राब आउटपुट भरोसे की क़ीमत वसूलता है, सिर्फ़ एक रीट्राई की नहीं। - **हर वह चीज़ जहाँ सत्यापन ख़ुद ही कठिन हो।** अगर आप सस्ते में नहीं बता सकते कि आउटपुट सही है या नहीं, तो आप ऐसे मॉडल का जोखिम नहीं उठा सकते जो अक्सर ग़लत हो। यहाँ एक विफलता की क़ीमत एक रीट्राई नहीं है — इसकी क़ीमत है एक रिफ़ंड, एक छिटका हुआ ग्राहक, या मेरा समय। उसके सामने, प्रति-टोकन का अधिभार राउंडिंग की मामूली त्रुटि है। ## वह राउटिंग नियम जो मैं सचमुच लागू करता हूँ मैं हर एजेंट के लिए एक मॉडल नहीं चुनता। मैं एजेंट के भीतर हर **टास्क** के हिसाब से राउट करता हूँ, आम तौर पर एक सस्ता क्लासिफ़ायर तय करता है कि नीचे का कौन-सा मॉडल काम सँभालेगा: ```typescript function pickModel(task: Task): string { // सस्ता, सत्यापन-योग्य, उच्च-मात्रा → Haiku if (task.type === "classify" || task.type === "extract") { return "claude-haiku"; } // खुला या ग्राहक-सामना करने वाला → Sonnet if (task.customerFacing || task.steps > 2) { return "claude-sonnet"; } return "claude-sonnet"; // डिफ़ॉल्ट रूप से सुरक्षित विकल्प } ``` यहाँ दो सिद्धांत कूटबद्ध हैं। **डिफ़ॉल्ट सुरक्षित मॉडल रखें**, सस्ता नहीं — आप लागत को एक चलते-फिरते आधार से *नीचे* की ओर अनुकूलित करते हैं, कभी विश्वसनीयता को एक टूटे आधार से *ऊपर* की ओर नहीं। और **एस्केलेट करें, जुआ न खेलें**: आसान 80% Haiku को सँभालने दें और कठिन 20% Sonnet को सौंप दें। यह संकर तरीक़ा लगभग हमेशा हर चीज़ को किसी एक मॉडल पर अकेले चलाने को मात देता है। इसके ऊपर लगाने के लिए प्रॉम्प्ट कैशिंग भी है: अगर आपका सिस्टम प्रॉम्प्ट बड़ा है और दोबारा इस्तेमाल होता है, तो कैशिंग स्तर की परवाह किए बिना इनपुट लागत को काफ़ी घटा देती है, जो कभी-कभी Sonnet को इतना सस्ता बना देता है कि Haiku वाला सवाल ही बेमानी हो जाता है। ## मेरे अपने स्टैक से एक हल किया हुआ उदाहरण एक उच्च-मात्रा वाले इनबाउंड ट्राइएज चरण को लीजिए। यह हज़ारों बार चलता है, टास्क तीन-तरफ़ा वर्गीकरण है, और एक चूक का बस इतना मतलब है कि आइटम एक समीक्षा क़तार में जा गिरता है — पकड़ना सस्ता, जोखिम कम। यह पाठ्यपुस्तक जैसा Haiku टास्क है, और इसे Sonnet से हटाने पर उस चरण की लागत में उल्लेखनीय कटौती हुई, बिना उस परिणाम पर किसी मापे-जाने-योग्य असर के जो मायने रखता था। अब वह चरण लीजिए जो ग्राहक को असली जवाब का मसौदा तैयार करता है। कम मात्रा, खुला, और एक ख़राब मसौदा बाहर जाने पर भरोसे की क़ीमत वसूलता है। वह Sonnet पर ही रहता है। वही एजेंट, दो मॉडल, जोखिम के हिसाब से राउट किए गए। मैं दोनों के प्रति-रन लागत और सफलता मापदंडों पर नज़र रखता हूँ, जैसा मैं [मैं कैसे मापता हूँ कि कोई AI एजेंट सचमुच काम कर रहा है या नहीं](/how-i-measure-whether-an-ai-agent-is-actually-working/) में बताता हूँ — और मैं किसी चरण को एक स्तर नीचे तभी धकेलता हूँ जब eval कहे कि सस्ता मॉडल सफलता-दर बनाए रखता है। ## अक्सर पूछे जाने वाले सवाल ### क्या व्यवहार में Claude Haiku हमेशा Sonnet से सस्ता होता है? प्रति टोकन, हाँ — बड़े अंतर से। प्रति सफल-परिणाम, हमेशा नहीं। अगर Haiku की कम सफलता-दर रीट्राई और मानव सफ़ाई छेड़ती है, तो उन टास्क पर जहाँ ग़लतियाँ पकड़ना या ठीक करना महँगा हो, कुल लागत Sonnet से ज़्यादा हो सकती है। ### किसी दिए गए टास्क के लिए मैं Haiku और Sonnet के बीच कैसे तय करूँ? टास्क को दो धुरियों पर अंक दीजिए: आउटपुट कितना सत्यापन-योग्य है और एक ग़लती कितनी महँगी है। सत्यापन में सस्ता, कम-जोखिम, उच्च-मात्रा वाला काम Haiku को जाता है; खुला, ग्राहक-सामना करने वाला, या सत्यापन में कठिन काम Sonnet को जाता है। एजेंट के हिसाब से नहीं, टास्क के हिसाब से राउट कीजिए। ### वह एकमात्र लागत-मापदंड क्या है जिस पर मुझे नज़र रखनी चाहिए? प्रति-सफल-परिणाम लागत — कॉल लागत गुणा प्रयास जोड़ अपेक्षित सफ़ाई लागत, भाग सफलता-दर। अकेले प्रति-कॉल दाम रीट्राई और मानव समय को छिपा देता है, और वहीं सस्ते मॉडल चुपके से महँगे पड़ने लगते हैं। ### क्या मैं एक ही एजेंट में दोनों मॉडल इस्तेमाल कर सकता हूँ? हाँ, और आम तौर पर आपको करना चाहिए। सबसे मज़बूत पैटर्न एक सस्ता पहला दौर है (Haiku वर्गीकृत करता है या फ़िल्टर करता है) जो केवल अस्पष्ट मामलों को Sonnet तक एस्केलेट करता है। यह संकर तरीक़ा आम तौर पर हर चीज़ को एक ही स्तर पर चलाने को मात देता है। --- ## प्रोडक्शन में AI एजेंट को डीबग कैसे करें (एक फील्ड गाइड) Source: https://alejandrorioja.com/hi/how-to-debug-an-ai-agent-in-production/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: प्रोडक्शन AI एजेंट को डीबग करना ज़्यादातर यह पहचानने के बारे में है कि कौन-सी लेयर फेल हुई — प्रॉम्प्ट, टूल, मॉडल, या ऑर्केस्ट्रेशन। मैं हर स्टेप को एक ट्रेस ID के साथ लॉग करता हूँ, बिल्कुल वही इनपुट रिप्ले करता हूँ, और बाइसेक्ट करता हूँ। मेरे एजेंट्स में, ~70% 'AI बग' दरअसल प्लंबिंग के बग निकलते हैं, मॉडल के नहीं। ## विषय-सूची _जून 2026 में अपडेटेड।_ **TL;DR:** प्रोडक्शन AI एजेंट को डीबग करना ज़्यादातर यह पहचानने के बारे में है कि कौन-सी लेयर फेल हुई — प्रॉम्प्ट, टूल कॉल, मॉडल आउटपुट, या ऑर्केस्ट्रेशन। मैं हर स्टेप को एक ट्रेस ID के साथ लॉग करता हूँ, बिल्कुल वही इनपुट रिप्ले करता हूँ, और वहीं से बाइसेक्ट करता हूँ। मेरे एजेंट्स में, जो "AI बग" जैसा दिखता है उसका करीब 70% प्लंबिंग निकलता है: एक खराब फ़ॉर्मेट वाला टूल रिज़ल्ट, एक कटा हुआ इनपुट, एक चुपचाप निगल लिया गया एक्सेप्शन। **ऑपरेटर की नज़र:** मैं 100 से ज़्यादा प्रोडक्शन एजेंट चलाता हूँ — Pickleland के लिए बुकिंग फ्लो, कंटेंट पाइपलाइन, इनबॉक्स ट्रायाजर। वे वैसे ही टूटते हैं जैसे हर सॉफ़्टवेयर टूटता है, साथ में कुछ नए तरीकों से भी। यह वही फील्ड गाइड है जो काश मेरे पास होती: टोकन की दीवार को घूरे बिना गड़बड़ करने वाली लेयर को कैसे ढूँढें। जब कोई एजेंट प्रोडक्शन में गलत व्यवहार करता है, तो प्रवृत्ति होती है मॉडल को दोष देने की। "Claude ने हैल्युसिनेट किया।" कभी-कभी सच। आमतौर पर नहीं। मॉडल पाँच या छह की स्टैक में एक लेयर है, और बग कहीं ज़्यादा बार उस लेयर में होता है जो आपने लिखी, बजाय उसके जो Anthropic ने भेजी। यह पोस्ट वह व्यवस्थित तरीका है जिससे मैं इसे ढूँढता हूँ। ## कुछ भी डीबग करने से पहले हर रन को ट्रेस करने योग्य बनाएँ जो आप देख नहीं सकते, उसे आप डीबग नहीं कर सकते। सबसे ज़्यादा लाभ देने वाली चीज़ जो आप कर सकते हैं — किसी भी खास बग के सामने आने से पहले — वह है हर एजेंट रन में एक ट्रेस ID जोड़ना और उसके उठाए गए हर स्टेप को लॉग करना। एक "स्टेप" वह सब कुछ है जो किसी सीमा को पार करता है: आने वाला ट्रिगर, हर मॉडल कॉल (पूरे मैसेज ऐरे के साथ), हर टूल कॉल (आर्गुमेंट्स के साथ), हर टूल रिज़ल्ट, और अंतिम आउटपुट। इन्हें ट्रेस ID से कीड स्ट्रक्चर्ड JSON के रूप में लॉग करें। ```typescript function logStep(traceId: string, step: string, payload: unknown) { console.log(JSON.stringify({ traceId, step, // "trigger" | "model_call" | "tool_call" | "tool_result" | "output" ts: Date.now(), payload, })); } ``` Cloudflare Workers पर मैं इन्हें एक क्यू में और एक टेबल में भेजता हूँ; लोकल में ये stdout पर जाते हैं। नियम अटल है: अगर कोई स्टेप लॉग नहीं हुआ, तो डीबगिंग की दृष्टि से वह हुआ ही नहीं। यह उस इंस्ट्रुमेंटेशन को दर्शाता है जिसका वर्णन मैं [जिस एजेंट स्टैक का मैं इस्तेमाल करता हूँ](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) में करता हूँ — ट्रेस ID वह रीढ़ है जिस पर बाकी सब कुछ टँगा होता है। ## लेयर को अलग करें: प्रॉम्प्ट, टूल, मॉडल, या ऑर्केस्ट्रेशन एक बार आपके पास ट्रेस हो, तो डीबगिंग एक बाइसेक्शन बन जाती है। चार लेयर हैं और बग ज़्यादातर समय उनमें से ठीक एक में रहता है। ### 1. इनपुट लेयर (सबसे आम दोषी) फेल हुई मॉडल कॉल में गया हुआ बिल्कुल वही `messages` ऐरे निकालें। पुनर्निर्माण नहीं — लॉग से अक्षरशः पेलोड। फिर इसे ऐसे पढ़ें जैसे कोई अजनबी पढ़ता। मेरे "मॉडल ने निर्देश नज़रअंदाज़ किए" वाले आधे बग दरअसल ये होते हैं: - एक टूल रिज़ल्ट जो `"[object Object]"` के रूप में वापस आया क्योंकि कुछ गलत तरीके से स्ट्रिंगिफ़ाई हो गया। - एक इनपुट जो वाक्य के बीच में कट गया क्योंकि उसने कॉन्टेक्स्ट विंडो को फोड़ दिया और एक भोली स्लाइस ने उसे काट दिया। - एक वैरिएबल जो `undefined` के रूप में इंटरपोलेट हुआ और चुपचाप प्रॉम्प्ट को ज़हरीला कर गया। अगर इनपुट गलत है, तो मॉडल ने कचरे पर अपना काम बखूबी किया। प्लंबिंग ठीक करें। ### 2. टूल लेयर अगर इनपुट साफ़ दिखता है, तो जाँचें कि कहीं किसी टूल ने ऐसी कोई एरर तो नहीं लौटाई जिसे एजेंट ने सफलता मान लिया। एक क्लासिक: एक API `{ "error": "rate limited" }` बॉडी के साथ `200` लौटाती है, आपका टूल रैपर बॉडी की जाँच नहीं करता, और एजेंट आत्मविश्वास से एक एरर मैसेज पर कार्रवाई कर देता है। टूल रिज़ल्ट को कच्चा लॉग करें और उनके आकार को असर्ट करें। ### 3. मॉडल लेयर 1 और 2 को खारिज करने के बाद ही मैं मॉडल पर शक करता हूँ। तब भी, "मॉडल बग" का आमतौर पर मतलब होता है "मेरा प्रॉम्प्ट अस्पष्ट है।" बिल्कुल वही फेल हुआ इनपुट लें, उसे उसी मॉडल और टेम्परेचर के विरुद्ध एक बार-इस्तेमाल स्क्रिप्ट में डालें, और देखें कि क्या यह दोहराता है। अगर दोहराता है, तो समाधान प्रॉम्प्ट का काम है या एक [कसी हुई eval](/the-eval-harness-i-use-to-ship-ai-agents/), न कि घबराहट में मॉडल बदलना। ### 4. ऑर्केस्ट्रेशन लेयर अगर कोई एकल स्टेप अकेले में ठीक है पर मल्टी-स्टेप रन फेल हो जाता है, तो बग हैंडऑफ़ में है — स्टेप्स के बीच खोई हुई स्टेट, एक रेस कंडीशन, एक रीट्राई जिसने किसी नॉन-आइडेम्पोटेंट एक्शन को दोबारा चला दिया। ये सबसे घातक होते हैं और मैं इनके पैटर्न [मल्टी-एजेंट ऑर्केस्ट्रेशन पैटर्न](/multi-agent-orchestration-patterns-queues-state-handoffs/) में कवर करता हूँ। ## नॉन-डिटर्मिनिज़्म से लड़ने के बजाय उसे दोहराएँ जो चीज़ एजेंट्स को अनडीबगेबल महसूस कराती है वह है नॉन-डिटर्मिनिज़्म: एक ही इनपुट अलग-अलग रन में अलग आउटपुट देता है। आप इसे काबू कर सकते हैं। पहला, **जो फिक्स कर सकते हैं, करें।** डीबग करते समय `temperature: 0` सेट करें। यह Claude को पूरी तरह डिटर्मिनिस्टिक नहीं बनाएगा, पर वैरिएंस को इतना तेज़ी से संकरा कर देता है कि आप असली बग को सैंपलिंग नॉइज़ से अलग बता सकें। दूसरा, **इसे N बार चलाएँ।** अगर कोई फ़ेल्योर हर 20 रन में 1 बार दोहराता है, तो बिल्कुल वही इनपुट 50 बार लूप करें और हर आउटपुट कैप्चर करें। अब आपके पास एक सैंपल है, एक किस्सा नहीं। एक बग जो 5% बार चलता है, वह असली बग है — आपको उसे देखने के लिए बस वॉल्यूम चाहिए। ```bash for i in $(seq 1 50); do node replay.mjs --trace=abc123 >> runs.jsonl done # फिर फ़ेल्योर गिनें grep -c '"status":"fail"' runs.jsonl ``` तीसरा, **पास और फेल हुए रन का डिफ़ करें।** टेम्परेचर फिक्स और इनपुट समान होने पर, आउटपुट में अंतर का मतलब है इनपुट में कोई अंतर जिसे आपने अभी तक नहीं पकड़ा — प्रॉम्प्ट में कोई टाइमस्टैम्प, कोई टूल रिज़ल्ट जो बदलता है, कोई रिट्रीव किया गया डॉक्यूमेंट जो बदल गया। ## एक रिप्ले हार्नेस बनाएँ ताकि आप प्रोडक्शन में डीबग करना बंद कर दें लाइव एजेंट को फिर से ट्रिगर करके डीबग करना धीमा और जोखिम भरा है — यह असली ईमेल भेजता है, असली कोर्ट बुक करता है। इसके बजाय, ट्रेस कैप्चर करें और उसे ऑफ़लाइन रिप्ले करें। रिप्ले हार्नेस एक लॉग किया हुआ ट्रेस लोड करता है, किसी भी स्टेप के लिए बिल्कुल वही इनपुट दोबारा बनाता है, और सिर्फ़ उसी स्टेप को मॉडल के विरुद्ध फिर से चलाता है। चूँकि आपने पूरा `messages` ऐरे लॉग किया, इसलिए आपको अपस्ट्रीम सिस्टम की बिल्कुल ज़रूरत नहीं। यह प्रोडक्शन के 10 मिनट के राउंड-ट्रिप को 2 सेकंड के लोकल लूप में बदल देता है, और यह मेरे डीबगिंग वर्कफ़्लो में सबसे बड़ी तेज़ी है। एक अच्छा रिप्ले हार्नेस आपको **म्यूटेट और री-रन** करने भी देता है: सिस्टम प्रॉम्प्ट की एक लाइन बदलें, वही 50 फेल हुए ट्रेस रिप्ले करें, और देखें कि अब कितने पास होते हैं। यही डीबगिंग से eval तक का पुल है — एक बार आपके पास फेल हुए ट्रेस का एक कॉर्पस हो, तो आपके पास एक रिग्रेशन सूट की शुरुआत है। ## उन मेट्रिक्स पर नज़र रखें जो वाकई टूटने की भविष्यवाणी करते हैं कुछ फ़ेल्योर कभी एक्सेप्शन नहीं फेंकते। एजेंट चलता है, कुछ विश्वसनीय लौटाता है, और चुपचाप गलत काम कर जाता है। उन्हें पकड़ने के लिए आप सिर्फ़ एरर रेट नहीं, बल्कि व्यवहारगत मेट्रिक्स पर नज़र रखते हैं: - **टूल-कॉल सक्सेस रेट** प्रति टूल। यहाँ गिरावट अक्सर एक दिखाई देने वाली फ़ेल्योर से पहले आती है। - **आउटपुट स्कीमा वैलिडिटी** — कितने % आउटपुट अपेक्षित स्ट्रक्चर के विरुद्ध पार्स होते हैं। मैं हर आउटपुट को Zod से वैलिडेट करता हूँ और जब वैलिडिटी गिरती है तो अलर्ट देता हूँ। - **लूप लंबाई** — प्रति रन स्टेप्स की औसत संख्या। अचानक स्पाइक आमतौर पर मतलब होता है कि एजेंट रीट्राई में फँस गया है। - **प्रति रन लागत** — एक बेकाबू लूप शिकायत के रूप में दिखने से पहले लागत स्पाइक के रूप में दिखता है। (जब लागत मायने रखती है, तो [Haiku बनाम Sonnet का गणित](/ai-agent-cost-math-when-haiku-beats-sonnet) जानने लायक है।) मैं इन्हें वैसे ही ट्रैक करता हूँ जैसे बाकी सब कुछ — देखें [मैं कैसे मापता हूँ कि कोई AI एजेंट वाकई काम कर रहा है या नहीं](/how-i-measure-whether-an-ai-agent-is-actually-working/)। एक मूक फ़ेल्योर को पकड़ने वाला मेट्रिक, शोरगुल वाली फ़ेल्योर पकड़ने वाले दस मेट्रिक्स के बराबर है। ## 5-मिनट का ट्राएज चेकलिस्ट जब कोई एजेंट टूटता है और मैं समय की दौड़ में होता हूँ, तो मैं यह क्रम में चलाता हूँ: 1. फेल हुए रन का **ट्रेस ID हासिल करें।** 2. फेल हुए स्टेप का **बिल्कुल वही इनपुट पढ़ें।** क्या यह सुगठित है? (यहाँ ~50% मामले हल हो जाते हैं।) 3. उस ट्रेस में **टूल रिज़ल्ट्स की जाँच करें** कि कहीं सफलता के भेस में कोई एरर तो नहीं। 4. `temperature: 0` पर **स्टेप को ऑफ़लाइन रिप्ले करें।** क्या यह दोहराता है? 5. **अगर दोहराता है,** तो यह प्रॉम्प्ट/मॉडल का मसला है — ठीक करें और ट्रेस कॉर्पस फिर से चलाएँ। **अगर नहीं,** तो यह नॉन-डिटर्मिनिज़्म या कोई स्टेट/ऑर्केस्ट्रेशन बग है — इसे 50× लूप करके इसकी विशेषता पहचानें। अनुशासित आइसोलेशन हर बार चतुर प्रॉम्प्टिंग को हरा देता है। मॉडल शायद ही कभी समस्या होता है; उसके इर्द-गिर्द का सिस्टम आमतौर पर होता है। ## अक्सर पूछे जाने वाले प्रश्न ### मैं ऐसे AI एजेंट को कैसे डीबग करूँ जो सिर्फ़ कभी-कभी फेल होता है? एक लॉग किए हुए ट्रेस से बिल्कुल वही इनपुट कैप्चर करें और उसे टेम्परेचर 0 पर 50+ बार रिप्ले करें। रुक-रुक कर होने वाले फ़ेल्योर कम फायरिंग-रेट वाले असली बग हैं — वॉल्यूम किस्से को एक पुनरुत्पाद्य सैंपल में बदल देता है जिसे आप डिफ़ करके ठीक कर सकते हैं। ### बग आमतौर पर मॉडल में होता है या मेरे कोड में? मेरे प्रोडक्शन एजेंट्स में, दिखने वाले "AI बग" का करीब 70% प्लंबिंग होता है: खराब फ़ॉर्मेट वाले टूल रिज़ल्ट, कटे हुए इनपुट, निगले गए एक्सेप्शन, या स्टेप्स के बीच खोई हुई स्टेट। मॉडल पर शक करने से पहले इनपुट और टूल लेयर को खारिज करें। ### एजेंट्स डीबग करने के लिए मुझे न्यूनतम कितनी लॉगिंग चाहिए? हर रन पर एक ट्रेस ID, साथ ही ट्रिगर, हर मॉडल कॉल (पूरा मैसेज ऐरे), हर टूल कॉल और उसका कच्चा रिज़ल्ट, और अंतिम आउटपुट के स्ट्रक्चर्ड लॉग। अगर कोई स्टेप लॉग नहीं है, तो आप उसे डीबग नहीं कर सकते। ### मैं लाइव प्रोडक्शन के विरुद्ध डीबग करना कैसे बंद करूँ? एक रिप्ले हार्नेस बनाएँ जो एक लॉग किया हुआ ट्रेस लोड करे और कैप्चर किए गए इनपुट का इस्तेमाल करके किसी भी एकल स्टेप को ऑफ़लाइन फिर से चलाए। यह एक धीमे, जोखिम भरे प्रोडक्शन राउंड-ट्रिप को एक तेज़ लोकल लूप में बदल देता है और आपके रिग्रेशन सूट का बीज बन जाता है। --- ## कैसे मापें कि AI सर्च सचमुच आपको ट्रैफ़िक भेज रहा है या नहीं Source: https://alejandrorioja.com/hi/how-to-measure-ai-search-traffic/ Published: 2026-06-08 Tags: GEO, Analytics TL;DR: अधिकांश AI-सर्च ट्रैफ़िक chatgpt.com, perplexity.ai और claude.ai से रेफ़रल की एक पतली धारा के रूप में दिखता है — लेकिन बड़ा असर डार्क है: लोग AI का जवाब पढ़ते हैं और कभी क्लिक नहीं करते। मैं दोनों मापता हूँ, क्लिक के लिए रेफ़रर और प्रभाव के लिए ब्रांड-सर्च में उछाल का उपयोग करते हुए। ## विषय-सूची _जून 2026 में अपडेटेड।_ **TL;DR:** अधिकांश AI-सर्च ट्रैफ़िक `chatgpt.com`, `perplexity.ai` और `claude.ai` से रेफ़रल की एक पतली धारा के रूप में आता है — जब आप जान लें कि कहाँ देखना है तो गिनना आसान है। लेकिन बड़ा असर **डार्क** है: लोग AI का जवाब पढ़ते हैं, आपके ब्रांड को आत्मसात करते हैं, और कभी क्लिक नहीं करते। मैं क्लिक को रेफ़रर सेगमेंट से और प्रभाव को ब्रांड-सर्च उछाल, डायरेक्ट-ट्रैफ़िक बदलाव और साइटेशन निगरानी से ट्रैक करता हूँ। केवल क्लिक गिनना AI सर्च को बुरी तरह कम आँकता है। **ऑपरेटर का नज़रिया:** मैं एक कंटेंट इंजन चलाता हूँ और रोज़ इसके एनालिटिक्स पर नज़र रखता हूँ। "क्या AI सर्च ट्रैफ़िक भेज रहा है?" इस सवाल का एक निराशाजनक जवाब है: हाँ, लेकिन अधिकांश मूल्य आपकी सेशन रिपोर्ट में नहीं दिखता। यहाँ मैं बताता हूँ कि जो हिस्सा दिखता है उसे कैसे मापें और जो नहीं दिखता उसका अनुमान कैसे लगाएँ। हर कोई एक नंबर चाहता है — "ChatGPT मुझे कितना ट्रैफ़िक भेज रहा है?"। ईमानदार जवाब यह है कि AI सर्च दो बहुत अलग प्रभाव पैदा करता है, और आपको दो अलग मापों की ज़रूरत है। इन्हें गड्डमड्ड कर दें तो या तो आप घबरा जाएँगे (क्लिक बहुत छोटे दिखते हैं) या खुद को धोखा देंगे (आप असली असर चूक जाएँगे)। ## प्रभाव 1: सीधे रेफ़रल — गिनने योग्य, और जितना आप उम्मीद करते हैं उससे छोटे जब कोई ChatGPT, Perplexity, या Claude के जवाब के भीतर किसी साइटेशन पर क्लिक करता है, तो आपका एनालिटिक्स एक रेफ़रर दर्ज करता है। ये असली, श्रेय-योग्य सेशन हैं। GA4 या किसी भी एनालिटिक्स टूल में, एक सेगमेंट बनाएँ जो AI इंजनों को पकड़ ले: ``` session source matches any of: chatgpt.com chat.openai.com perplexity.ai claude.ai gemini.google.com copilot.microsoft.com ``` इसे "AI सर्च" चैनल के रूप में सहेजें और समय के साथ देखें। कुछ चेतावनियाँ जो लोगों को मात देती हैं: - **रेफ़रर रिसते हैं।** कुछ AI सतहें रेफ़रर को हटा देती हैं या बिगाड़ देती हैं, इसलिए असली AI क्लिकों का एक हिस्सा इसके बजाय "डायरेक्ट" में आ गिरता है। आपकी रेफ़रल गिनती एक न्यूनतम सीमा है, सच्चाई नहीं। - **जवाब के इंप्रेशन के मुकाबले वॉल्यूम कम है।** AI इंजन सवाल का जवाब पेज पर ही दे देते हैं; केवल जिज्ञासु अल्पसंख्यक ही क्लिक करके आता है। रोज़ के मुट्ठी भर रेफ़रल उन कहीं ज़्यादा लोगों के अनुरूप हो सकते हैं जिन्होंने आपको साइट किया हुआ देखा। तो रेफ़रल सेगमेंट ज़रूरी है पर पर्याप्त नहीं। यह आपको बताता है कि AI सर्च *कुछ* ट्रैफ़िक भेज रहा है। यह प्रभाव को बुरी तरह कम गिनता है। ## प्रभाव 2: डार्क प्रभाव — बड़ा, और देखने में मुश्किल आधा हिस्सा असली कार्रवाई ज़ीरो-क्लिक है। कोई ChatGPT से एक सवाल पूछता है, आपका ब्रांड जवाब में एक अनुशंसित स्रोत के रूप में आता है, और वह कभी क्लिक नहीं करता — वह बस आपको याद रखता है। यह बाद में एक **ब्रांडेड सर्च** या एक **डायरेक्ट विज़िट** के रूप में दिखता है, जिसका श्रेय किसी को नहीं मिलता। यह वही गतिशीलता है जिसने फ़ीचर्ड स्निपेट्स को मापना निराशाजनक बना दिया था, बस बढ़ी हुई। आप डार्क प्रभाव को सीधे नहीं माप सकते, पर आप इसका त्रिकोणीयन कर सकते हैं: 1. **ब्रांडेड सर्च वॉल्यूम।** Google Search Console में अपने नाम/ब्रांड की खोजों को समय के साथ ट्रैक करें। यदि आप AI इंजनों द्वारा साइट किए जाने लगते हैं और बिना किसी मेल खाते अभियान के आपके ब्रांडेड इंप्रेशन बढ़ते हैं, तो वह उछाल AI प्रभाव की उँगलियों की छाप है। 2. **डायरेक्ट-ट्रैफ़िक प्रवृत्ति।** "डायरेक्ट" सेशनों में लगातार उछाल जो किसी अभियान का अनुसरण नहीं करता, अक्सर अपने रेफ़रर से वंचित AI रेफ़रल को, साथ ही AI उल्लेख के बाद आपको सीधे टाइप करने वाले लोगों को दर्शाता है। 3. **सहायक रूपांतरण।** देखें कि क्या AI-सर्च सेशन, भले ही दुर्लभ हों, रूपांतरण यात्राओं में *पहले* स्पर्श के रूप में दिखते हैं। एक चैनल जो लास्ट-क्लिक से छोटा है, फ़र्स्ट-टच से सार्थक हो सकता है। इनमें से कोई भी साफ़ नंबर नहीं है। मिलकर वे आपको बताते हैं कि डार्क आधा हिस्सा हिल रहा है या नहीं। ## क्लिक ही नहीं, साइटेशन ट्रैक करें यहाँ वह मीट्रिक है जिसकी मुझे AI सर्च के लिए सबसे ज़्यादा परवाह है, और यह आपके एनालिटिक्स में बिल्कुल नहीं है: **क्या मुझे साइट किया जा रहा है, और किन क्वेरीज़ के लिए?** अपने व्यवसाय के लिए मायने रखने वाली 20-40 क्वेरीज़ की एक सूची बनाए रखें और उन्हें एक शेड्यूल पर ChatGPT, Perplexity और Claude के माध्यम से चलाएँ — साप्ताहिक पर्याप्त से अधिक है। हर क्वेरी और इंजन के लिए दर्ज करें: क्या आप साइट किए गए हैं, और किस स्थान पर? यह रैंक ट्रैकिंग का GEO समकक्ष है, और यह अग्रणी संकेतक है। साइटेशन डाउनस्ट्रीम ट्रैफ़िक और ब्रांड उछाल से *पहले* हिलते हैं, इसलिए यहीं आप देखते हैं कि आपका [स्थानीय व्यवसाय के लिए GEO कार्य](/geo-for-local-business-getting-a-brick-and-mortar-cited-by-ai-search/) असर कर रहा है या नहीं। मैंने एक छोटा एजेंट बनाया जो ये जाँचें चलाता है और परिणाम दर्ज करता है — एक बार जब आपके पास एजेंट स्टैक हो तो यह मामूली काम है। यदि आप हाथ से करना पसंद करें, तो एक स्प्रेडशीट और साप्ताहिक 30-मिनट का दौर शुरुआत के लिए ठीक काम करता है। यह कार्यप्रणाली मेरे [ChatGPT बनाम Google साइटेशन टेस्ट](/chatgpt-search-vs-google-50-term-test/) को प्रतिबिंबित करती है, बस एक बार के बजाय लगातार चलाई जाती है। ## डैशबोर्ड बनाएँ: चार नंबर, साप्ताहिक मैं मीट्रिक्स में नहीं डूबता। AI सर्च के लिए मैं चार चीज़ें देखता हूँ और उन्हें साप्ताहिक रूप से समीक्षा करता हूँ: 1. **AI रेफ़रल सेशन** — रेफ़रर सेगमेंट से गिनने योग्य क्लिक। प्रवृत्ति, निरपेक्ष मान नहीं। 2. **साइटेशन कवरेज** — मेरी ट्रैक की गई क्वेरीज़ का % जहाँ मैं तीनों इंजनों में साइट किया जाता हूँ। अग्रणी संकेतक। 3. **ब्रांडेड सर्च इंप्रेशन** — Search Console से, डार्क-प्रभाव प्रॉक्सी के रूप में। 4. **AI-स्रोत रूपांतरण** — भले छोटे हों, क्या AI सेशन कभी कोई रूपांतरण यात्रा शुरू करते हैं। यदि साइटेशन कवरेज बढ़ रहा है जबकि रेफ़रल सेशन सपाट रहते हैं, तो यह *असफलता नहीं* है — आमतौर पर इसका मतलब है कि डार्क आधा हिस्सा बढ़ रहा है और ब्रांडेड-सर्च नंबर को इसके पीछे आना चाहिए। यदि साइटेशन कवरेज गिर रहा है, तो यह एक शुरुआती चेतावनी है जिस पर किसी भी ट्रैफ़िक नंबर के हिलने से पहले कार्रवाई करनी चाहिए। यह वही "अग्रणी संकेतक मापें" अनुशासन है जो मैं एजेंटों पर लागू करता हूँ [मैं कैसे मापता हूँ कि एक AI एजेंट सचमुच काम कर रहा है](/how-i-measure-whether-an-ai-agent-is-actually-working/) में। ## नंबरों का क्या करें मापन तभी उपयोगी है जब वह बदले कि आप क्या करते हैं। प्लेबुक: - **किसी क्वेरी के लिए साइटेशन कवरेज कम है जिसकी आपको परवाह है?** यह एक कंटेंट + [schema](/schema-markup-for-ai-engines-the-types-that-punch-above-their-weight/) समस्या है। पेज या तो मौजूद ही नहीं है, या निष्कर्षण के लिए संरचित नहीं है, या जवाब में खींचे जाने लायक पर्याप्त आधिकारिक नहीं है। - **साइट किए गए पर कोई रेफ़रल ट्रैफ़िक नहीं?** अपेक्षित और ठीक है — AI सर्च ब्रांड का काम कर रहा है, क्लिक का नहीं। क्लिक के पीछे भागकर इसे "ठीक" न करें; साइट किया गया स्रोत बनने पर दाँव लगाएँ। - **एक इंजन से रेफ़रल पर दूसरों से नहीं?** इंजन स्रोतों पर ज़ोरदार ढंग से भिन्न होते हैं (मैंने ChatGPT और Google के बीच ~40% ओवरलैप मापा)। एक द्वारा साइट किया जाना आपको दूसरे नहीं दिलाता — हर इंजन की कवरेज पर अलग से काम करें। ## श्रेय की ईमानदारी पर एक नोट जो परिशुद्धता आपके पास नहीं है उसका दावा करने के आग्रह का विरोध करें। 2026 में AI-सर्च मापन त्रिकोणीयन है, श्रेय नहीं। जो भी आपको "ChatGPT ने आपको X डॉलर भेजे" जैसा एक साफ़ नंबर बेच रहा है, वह जो जाना जा सकता है उसे बढ़ा-चढ़ाकर बता रहा है, क्योंकि रेफ़रर रिसते हैं और सबसे बड़ा असर डिज़ाइन से ही ज़ीरो-क्लिक है। सही रुख: जो गिन सकते हैं गिनें, जो नहीं गिन सकते उसके लिए प्रॉक्सी देखें, और प्रवृत्ति पर निर्णय लें। प्रवृत्ति भरोसेमंद है, तब भी जब निरपेक्ष नंबर नहीं। ## अक्सर पूछे जाने वाले प्रश्न ### मैं GA4 में ChatGPT या Perplexity से ट्रैफ़िक कैसे देखूँ? एक चैनल/सेगमेंट बनाएँ जो AI इंजन डोमेन — chatgpt.com, chat.openai.com, perplexity.ai, claude.ai, gemini.google.com, copilot.microsoft.com — को सेशन स्रोत के रूप में मिलाए। यह क्लिक-थ्रू रेफ़रल पकड़ता है, हालाँकि कुछ "डायरेक्ट" में हट जाते हैं, इसलिए गिनती को एक न्यूनतम सीमा मानें। ### मेरा AI-सर्च रेफ़रल ट्रैफ़िक इतना कम क्यों है? क्योंकि AI सर्च ज़्यादातर ज़ीरो-क्लिक है — इंजन पेज पर ही जवाब दे देता है और केवल अल्पसंख्यक क्लिक करता है। कम रेफ़रल गिनतियाँ अक्सर कहीं बड़े साइटेशन इंप्रेशन के साथ मेल खाती हैं। उस हिस्से को देखने के लिए जो रेफ़रल चूकते हैं, साइटेशन और ब्रांडेड-सर्च उछाल मापें। ### AI सर्च के लिए सबसे अच्छा अग्रणी संकेतक क्या है? साइटेशन कवरेज: आपकी ट्रैक की गई व्यवसाय-महत्वपूर्ण क्वेरीज़ का प्रतिशत जहाँ आप ChatGPT, Perplexity और Claude में साइट किए जाते हैं। यह ट्रैफ़िक और ब्रांड उछाल से पहले हिलता है, इसलिए यह आपको जल्दी बता देता है कि आपका GEO कार्य असर कर रहा है या नहीं। ### क्या मैं AI सर्च से सटीक राजस्व श्रेय पा सकता हूँ? नहीं, 2026 में भरोसेमंद ढंग से नहीं। रेफ़रर डायरेक्ट में रिस जाते हैं और अधिकांश असर डिज़ाइन से ज़ीरो-क्लिक है। AI-सर्च मापन को त्रिकोणीयन मानें — क्लिक गिनें, ब्रांडेड-सर्च और डायरेक्ट-ट्रैफ़िक प्रॉक्सी देखें, और एक झूठी-सटीक डॉलर राशि के बजाय प्रवृत्ति पर निर्णय लें। --- ## मल्टी-एजेंट ऑर्केस्ट्रेशन पैटर्न: क्यू, स्टेट और हैंडऑफ़ Source: https://alejandrorioja.com/hi/multi-agent-orchestration-patterns-queues-state-handoffs/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: भरोसेमंद मल्टी-एजेंट सिस्टम चतुर प्रॉम्प्ट से नहीं बनते — वे डिस्ट्रिब्यूटेड सिस्टम के उबाऊ अनुशासन से बनते हैं: एजेंटों के बीच टिकाऊ क्यू, मॉडल के बाहर रखा गया स्टेट, और ऐसे आइडम्पोटेंट हैंडऑफ़ जो रीट्राई झेल जाते हैं। मॉडल वर्कर है; क्यू रीढ़ की हड्डी है। ## विषय-सूची _जून 2026 में अपडेट किया गया।_ **संक्षेप में:** भरोसेमंद मल्टी-एजेंट सिस्टम चतुर प्रॉम्प्ट से नहीं जीते जाते — वे डिस्ट्रिब्यूटेड सिस्टम के उबाऊ अनुशासन से जीते जाते हैं। एजेंटों के बीच एक टिकाऊ **क्यू** रखें, **स्टेट को मॉडल के बाहर** रखें, और हर **हैंडऑफ़ को आइडम्पोटेंट** बनाएँ ताकि कोई रीट्राई दोबारा कार्रवाई न कर सके। मॉडल वर्कर है; क्यू रीढ़ की हड्डी है। इन तीनों को सही कर लें और ऑर्केस्ट्रेशन डरावना नहीं रह जाता। **ऑपरेटर का नज़रिया:** मेरे 100 से ज़्यादा एजेंटों में अधिकतर सिंगल-स्टेप हैं। जो नहीं हैं — वे पाइपलाइन जो पहले क्लासिफ़ाई करती हैं, फिर एनरिच करती हैं, फिर कार्रवाई करती हैं — वे तभी भरोसेमंद बनीं जब मैंने "प्रॉम्प्ट चेन" सोचना बंद किया और "LLM वर्कर वाली जॉब क्यू" सोचना शुरू किया। यह आर्किटेक्चर है, प्रॉम्प्ट इंजीनियरिंग नहीं। "मल्टी-एजेंट" सुनने में ऐसा लगता है जैसे एजेंट आपस में बात करते हों। व्यवहार में, भरोसेमंद संस्करण इसका उलटा है: एजेंट सीधे संवाद करते ही नहीं। वे एक क्यू पर संदेश छोड़ते हैं और एक क्यू से काम उठाते हैं, और ऑर्केस्ट्रेशन उनके बीच की पाइपलाइन (प्लंबिंग) में बसता है। ये वे पैटर्न हैं जो प्रोडक्शन में टिके रहते हैं। ## पैटर्न 1: हर एजेंट के बीच एक टिकाऊ क्यू रखें पहली प्रवृत्ति होती है एजेंट A के भीतर से सीधे एजेंट B को कॉल करना। ऐसा न करें। सीधी कॉल दोनों को जोड़ देती हैं: अगर B धीमा है, A रुक जाता है; अगर B विफल होता है, A का काम खो जाता है; अगर आपको B को स्केल करना है, तो A को छुए बिना नहीं कर सकते। इसके बजाय, A अपना काम पूरा करता है और B के लिए एक **संदेश क्यू में डालता है**। B एक अलग वर्कर है जो क्यू को अपनी गति से खाली करता है। ```typescript // एजेंट A समाप्त करता है और क्यू के ज़रिए हैंडऑफ़ करता है — B को कोई सीधी कॉल नहीं await env.ENRICH_QUEUE.send({ traceId, type: "enrich", payload: classifierResult, }); // A का काम पूरा हुआ। B इसे स्वतंत्र रूप से उठाएगा। ``` Cloudflare पर मैं ठीक इसी के लिए Workers Queues इस्तेमाल करता हूँ — वही प्रिमिटिव जो [जिस एजेंट स्टैक का मैं इस्तेमाल करता हूँ](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) के पीछे हैं। क्यू आपको मुफ़्त में चार चीज़ें देती है: **बफ़रिंग** (B बंद हो सकता है फिर भी काम नहीं खोता), **रीट्राई** (विफल संदेश दोबारा भेजे जाते हैं), **बैकप्रेशर** (बढ़ोतरी क्रैश की बजाय क्यू में जमा होती है), और **डिकपलिंग** (A को छुए बिना B को स्केल या रीडिप्लॉय करें)। इनमें से हर एक वह चीज़ है जिसे वरना आपको हाथ से बनाना पड़ता और गलती करनी पड़ती। ## पैटर्न 2: स्टेट को हमेशा मॉडल के बाहर रखें सबसे आम मल्टी-एजेंट बग यह मान लेना है कि मॉडल को चरणों के बीच कुछ याद रहता है। नहीं रहता। हर मॉडल कॉल स्टेटलेस है; एकमात्र स्मृति वही है जो आप प्रॉम्प्ट में डालते हैं। इसलिए "यह जॉब पाइपलाइन में कहाँ है" के लिए सत्य का स्रोत एक डेटाबेस में बसना चाहिए, बातचीत में नहीं। मैं एक ही जॉब रिकॉर्ड रखता हूँ जिसे हर एजेंट पढ़ता और अपडेट करता है: ```typescript interface JobState { traceId: string; stage: "classified" | "enriched" | "acted" | "done" | "failed"; data: Record; attempts: number; updatedAt: number; } ``` हर एजेंट वही लूप चलाता है: जॉब स्टेट **पढ़ो**, अपना काम करो, नया स्टेट **लिखो**, अगला चरण क्यू में डालो। मॉडल कभी स्टेट नहीं रखता — वह संबंधित हिस्सा इनपुट के रूप में पाता है और एक परिणाम लौटाता है। यही सिस्टम को रीस्टार्ट-योग्य बनाता है: अगर कोई वर्कर जॉब के बीच मर जाए, तो स्टेट रिकॉर्ड अब भी ठीक-ठीक बताता है कि चीज़ें कहाँ थीं, और दोबारा भेजा गया क्यू संदेश वहीं से आगे बढ़ाता है। यह डिबगिंग को भी संभालने लायक बनाता है, क्योंकि स्टेट टेबल हर जॉब की यात्रा का एक क्वेरी-योग्य रिकॉर्ड है — वही इंस्ट्रूमेंटेशन मानसिकता जो [मैं कैसे मापता हूँ कि कोई एजेंट सचमुच काम कर रहा है या नहीं](/how-i-measure-whether-an-ai-agent-is-actually-working/) में है। ## पैटर्न 3: हर हैंडऑफ़ को आइडम्पोटेंट बनाएँ क्यू *कम-से-कम-एक-बार* डिलीवरी की गारंटी देती हैं, ठीक एक बार की नहीं। इसका मतलब है कि एक संदेश दो बार पहुँच सकता है — नेटवर्क झटके, रीट्राई, रीडिप्लॉय। अगर आपके एजेंट की कार्रवाई आइडम्पोटेंट नहीं है, तो दोहरी डिलीवरी दोहरी कार्रवाई करती है: दो पुष्टि-ईमेल, दो बुकिंग, दो चार्ज। यह ऑर्केस्ट्रेशन बग की सबसे बुरी श्रेणी है, और यही वह है जिसे टीमें प्रोडक्शन में खोजती हैं। हल यह है कि कार्रवाइयों को एक की (key) से आइडम्पोटेंट बनाया जाए: ```typescript async function handleEnrich(msg: QueueMessage, env: Env) { const job = await getJob(env, msg.traceId); if (job.stage !== "classified") { // इस चरण से आगे पहले ही प्रोसेस हो चुका — यह डुप्लिकेट डिलीवरी है। छोड़ दें। return; } const result = await enrich(job.data); await advanceJob(env, msg.traceId, "enriched", result); await env.ACT_QUEUE.send({ traceId: msg.traceId, type: "act" }); } ``` चरण-जाँच ऑपरेशन को दो बार चलाने के लिए सुरक्षित बना देती है: दूसरी डिलीवरी देखती है कि जॉब पहले ही आगे बढ़ चुका है और कुछ नहीं करती। बाहरी साइड-इफ़ेक्ट (ईमेल भेजना, कार्ड चार्ज करना) के लिए, डाउनस्ट्रीम API को एक आइडम्पोटेंसी की पास करें ताकि *वह* भी डीडुप्लिकेट करे। मान लें कि हर संदेश दो बार पहुँचेगा और इस तरह डिज़ाइन करें कि वह हानिरहित हो — क्योंकि आख़िरकार ऐसा होगा। ## पैटर्न 4: ऑर्केस्ट्रेटर बनाम कोरियोग्राफ़ी — सोच-समझकर चुनें फ़्लो को जोड़ने के दो तरीके हैं, और सही चुनाव जटिलता पर निर्भर करता है। **कोरियोग्राफ़ी** (जो मैं डिफ़ॉल्ट रूप से अपनाता हूँ): हर एजेंट केवल अगला चरण जानता है और उसे क्यू में डालता है। फ़्लो श्रृंखला से उभरता है। सरल, विकेंद्रित, बढ़ाने में आसान — एक क्यू डालकर एक चरण जोड़ें। नुकसान यह है कि कोई एक जगह पूरे फ़्लो का वर्णन नहीं करती, इसलिए एक जटिल पाइपलाइन के बारे में सोचना कठिन हो सकता है। **ऑर्केस्ट्रेशन** (एक केंद्रीय समन्वयक): एक ऑर्केस्ट्रेटर फ़्लो का स्वामी होता है, हर एजेंट को बारी-बारी से कॉल करता है, और परिणामों के आधार पर तय करता है कि आगे क्या। पूरा फ़्लो एक पठनीय जगह में बसता है और ब्रांचिंग लॉजिक स्पष्ट होता है। कीमत है एक केंद्रीय घटक जिसे स्वयं टिकाऊ होना चाहिए — अगर ऑर्केस्ट्रेटर का अपना स्टेट बाहर नहीं रखा गया (पैटर्न 2), तो वह एकल विफलता-बिंदु बन जाता है। मेरा नियम: **जब तक ब्रांचिंग जटिल न हो जाए तब तक कोरियोग्राफ़ी, फिर एक टिकाऊ ऑर्केस्ट्रेटर।** एक रैखिक तीन-चरण पाइपलाइन कोरियोग्राफ़ी है। शर्तीय रूटिंग, समानांतर फ़ैन-आउट, और जॉइन वाले फ़्लो को एक ऐसा ऑर्केस्ट्रेटर चाहिए जिसका स्टेट डेटाबेस में बसता हो ताकि वह क्रैश के बाद फिर से शुरू हो सके। ## पैटर्न 5: टुकड़े खोए बिना फ़ैन-आउट, फ़ैन-इन जब एक जॉब N समानांतर उप-कार्य जन्म देता है (50 रिकॉर्ड एनरिच करना, 20 दस्तावेज़ सारांशित करना) और जारी रखने से पहले आपको उन सबका इंतज़ार करना होता है, तो आपको एक **जॉइन** चाहिए। तरकीब है जॉब स्टेट में एक काउंटर: 1. पैरेंट N चाइल्ड संदेश क्यू में डालता है और जॉब रिकॉर्ड में `expected: N, completed: 0` लिखता है। 2. हर चाइल्ड अपना काम करता है और `completed` को **परमाणविक रूप से बढ़ाता** है। 3. जो चाइल्ड `completed` को `expected` के बराबर तक पहुँचाता है, वह अगला चरण क्यू में डालता है। परमाणविक वृद्धि भार-वहन करने वाली है — इसके बिना, एक साथ ख़त्म होने वाले दो चाइल्ड दोनों सोच सकते हैं कि वे आख़िरी नहीं हैं, और जॉइन कभी ट्रिगर नहीं होता। ऐसा काउंटर इस्तेमाल करें जिसे डेटास्टोर परमाणविक रूप से बढ़ा सके, या एक ट्रांज़ैक्शन। यह पैटर्न आपको पाइपलाइन के महँगे बीच के हिस्से को समानांतर करने देता है (अक्सर Haiku-सस्ता काम — देखें [Haiku बनाम Sonnet की लागत-गणित](/ai-agent-cost-math-when-haiku-beats-sonnet)) जबकि अंत में एक साफ़ जॉइन बनाए रखता है। ## जो मैं छोड़ दूँगा इनमें से कुछ भी करने के लिए आपको एक भारी-भरकम एजेंट फ़्रेमवर्क की ज़रूरत नहीं है। क्यू, एक स्टेट टेबल, और आइडम्पोटेंसी कीज़ ऐसी प्रिमिटिव हैं जो हर प्लेटफ़ॉर्म के पास पहले से हैं। मैंने टीमों को विस्तृत मल्टी-एजेंट फ़्रेमवर्क की ओर हाथ बढ़ाते देखा है ताकि वे वे सुविधाएँ पा सकें जो एक क्यू मुफ़्त देती है, और एक ऐसा ब्लैक बॉक्स विरासत में पा लेते हैं जिसे डिबग करना उस पाइपलाइन से कठिन है जिसे उसने बदला। उबाऊ प्रिमिटिव से शुरू करें। किसी फ़्रेमवर्क की ओर तभी हाथ बढ़ाएँ जब आपने कोई ठोस दर्द महसूस किया हो जिसे वह हल करता है। सारांश: एजेंट स्टेटलेस वर्कर हैं, क्यू टिकाऊ रीढ़ की हड्डी हैं, स्टेट एक डेटाबेस में बसता है, और हर हैंडऑफ़ दो बार चलाने के लिए सुरक्षित है। बस यही पूरा खेल है। ## अक्सर पूछे जाने वाले प्रश्न ### क्या एजेंटों को एक-दूसरे को सीधे कॉल करना चाहिए या क्यू से गुज़रना चाहिए? क्यू से। सीधी कॉल एजेंटों को जोड़ देती हैं — एक की विफलता या सुस्ती दूसरे तक फैलती है, और आप स्वतंत्र रूप से स्केल या रीडिप्लॉय नहीं कर सकते। एक टिकाऊ क्यू आपको बफ़रिंग, रीट्राई, बैकप्रेशर, और डिकपलिंग मुफ़्त में देती है। ### मल्टी-एजेंट स्टेट कहाँ बसना चाहिए? मॉडल के बाहर, एक डेटाबेस में, एक जॉब रिकॉर्ड के रूप में जिसे हर एजेंट पढ़ता और अपडेट करता है। मॉडल कॉल स्टेटलेस होती हैं, इसलिए पाइपलाइन प्रगति के लिए सत्य का स्रोत बाहरी होना चाहिए — यही सिस्टम को क्रैश के बाद रीस्टार्ट-योग्य बनाता है। ### मैं किसी एजेंट को एक ही जॉब पर दो बार कार्रवाई करने से कैसे रोकूँ? हैंडऑफ़ को आइडम्पोटेंट बनाएँ। कार्रवाई से पहले जॉब का चरण जाँचें और अगर वह पहले ही आगे बढ़ चुका हो तो कुछ न करें, और बाहरी API को आइडम्पोटेंसी कीज़ पास करें। क्यू कम-से-कम-एक-बार डिलीवर करती हैं, इसलिए मान लें कि हर संदेश दो बार आ सकता है और इस तरह डिज़ाइन करें कि डुप्लिकेट हानिरहित हों। ### क्या मुझे एक मल्टी-एजेंट फ़्रेमवर्क चाहिए? आमतौर पर नहीं। टिकाऊ क्यू, एक स्टेट टेबल, और आइडम्पोटेंसी कीज़ अधिकांश प्रोडक्शन ज़रूरतों को उन प्रिमिटिव से पूरा कर देती हैं जो आपका प्लेटफ़ॉर्म पहले से देता है। फ़्रेमवर्क तभी अपनाएँ जब आप किसी ठोस समस्या से टकराएँ जिसे वह अनोखे ढंग से हल करता है, डिफ़ॉल्ट रूप से नहीं। --- ## वह इवैल हार्नेस जिससे मैं बिना डर के AI एजेंट शिप करता हूँ Source: https://alejandrorioja.com/hi/the-eval-harness-i-use-to-ship-ai-agents/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: बिना डर के एजेंट शिप करना एक ही चीज़ से आता है: एक इवैल हार्नेस। ग्रेडेड टेस्ट केस का एक तय सेट, अपने आप स्कोर किया गया (असर्शन्स के साथ एक LLM जज), हर प्रॉम्प्ट या मॉडल बदलाव से पहले चलाया गया। अगर स्कोर टिका रहे, तो शिप करो। टेस्ट सेट असली प्रोडक्शन विफलताओं से बनाया जाता है। ## विषय-सूची _जून 2026 में अपडेट किया गया।_ **संक्षेप:** किसी लाइव एजेंट पर मैं प्रॉम्प्ट बदल सकता हूँ या मॉडल अदल-बदल सकता हूँ और साँस रोके बिना — इसकी वजह एक ही है: एक **इवैल हार्नेस**। ग्रेडेड टेस्ट केस का एक तय सेट, अपने आप स्कोर किया गया — जहाँ मैं लिख सकता हूँ वहाँ कठोर असर्शन्स, और जहाँ नहीं वहाँ एक LLM जज — हर बदलाव से पहले चलाया गया। स्कोर टिका रहे, मैं शिप करता हूँ। स्कोर गिरे, तो नहीं। टेस्ट सेट सिंथेटिक नहीं है; यह असली प्रोडक्शन विफलताओं से बनाया जाता है, इसलिए हर बग एक स्थायी रिग्रेशन टेस्ट बन जाता है। **ऑपरेटर का नज़रिया:** 100 से ज़्यादा एजेंटों में, जिन्हें मैं भरोसे के साथ छूता हूँ और जिनसे मैं डरता हूँ — उनके बीच फ़र्क यही है कि उनमें इवैल हैं या नहीं। इवैल हार्नेस न होने का मतलब है हर प्रॉम्प्ट छेड़छाड़ एक जुआ है। एक इवैल हार्नेस "मुझे लगता है यह बेहतर है" को "यह नापने लायक 4 अंक बेहतर है और इसने कुछ नहीं तोड़ा" में बदल देता है। पूरा ताला यही खुलता है। आप बिना टेस्ट के कोड शिप नहीं करेंगे। लोग बिना इवैल के लगातार एजेंट शिप करते हैं, और फिर हैरान होते हैं कि एक "नन्हीं प्रॉम्प्ट छेड़छाड़" ने प्रोडक्शन क्यों तोड़ दिया। इवैल हार्नेस ग़ैर-नियतात्मक सॉफ़्टवेयर के लिए टेस्ट सूट है। यह रही वह जिसे मैं सचमुच चलाता हूँ। ## असली विफलताओं से बने टेस्ट सेट से शुरू करें हार्नेस अपने टेस्ट केस जितना ही अच्छा होता है, और सबसे अच्छे टेस्ट केस प्रोडक्शन से आते हैं, आपकी कल्पना से नहीं। हर बार जब कोई एजेंट असल दुनिया में विफल होता है, मैं ठीक वही इनपुट पकड़ लेता हूँ (मैं हर रन को एक ट्रेस ID के साथ लॉग करता हूँ — देखें [प्रोडक्शन में एजेंट को डीबग कैसे करें](/how-to-debug-an-ai-agent-in-production)) और उसे एक इवैल केस में बदल देता हूँ: ```typescript interface EvalCase { id: string; input: AgentInput; // ठीक वही प्रोडक्शन इनपुट expected?: string; // ग्राउंड ट्रुथ, जब कोई हो assertions: Assertion[]; // कठोर जाँचें जो पास होनी ही चाहिए rubric?: string; // LLM जज के लिए, जब आउटपुट खुला-छोर हो } ``` यहाँ दो अभ्यास मायने रखते हैं। **प्रोडक्शन से खींचें**, ताकि आपके इवैल वही टेस्ट करें जो सचमुच टूटता है, न कि वह जो आपने अनुमान लगाया था। और **पूरे दायरे को ढकें** — सुखद रास्ता, किनारे के मामले, प्रतिकूल इनपुट, और वे खाली/विकृत इनपुट जो चुपचाप विफलताएँ पैदा करते हैं। अच्छी तरह चुने गए 30 से 50 केस का टेस्ट सेट 500 आलसी केसों से कहीं ज़्यादा पकड़ता है। मैं 40 ऐसे केस रखना पसंद करूँगा जो हर एक किसी असली विफलता-तरीके को दर्शाते हों, बजाय हज़ार ऐसे जो सब एक ही आसान रास्ता टेस्ट करते हों। ## पहले असर्शन्स से स्कोर करें, फिर एक LLM जज से हर आउटपुट को स्कोर करने के लिए मॉडल की ज़रूरत नहीं होती। मैं सबसे सस्ते स्कोरर की ओर बढ़ता हूँ जो काम कर जाए। हर संरचित चीज़ के लिए **कठोर असर्शन्स**। क्या आउटपुट वैध JSON के रूप में पार्स होता है? क्या उसमें ज़रूरी फ़ील्ड है? क्या निकाली गई तारीख दायरे में है? क्या उसने सही आर्ग्युमेंट्स के साथ सही टूल बुलाया? ये नियतात्मक, मुफ़्त, और दो-टूक हैं — जितने लिख सकें, उतने लिखें। ```typescript const assertions: Assertion[] = [ (out) => isValidJSON(out), (out) => parse(out).category in ALLOWED_CATEGORIES, (out) => parse(out).confidence >= 0 && parse(out).confidence <= 1, ]; ``` खुले-छोर बाक़ी हिस्से के लिए **एक LLM जज** — लहजा, उपयोगिता, "क्या इसने सचमुच सवाल का जवाब दिया"। यहाँ आप किसी मॉडल को इनपुट, आउटपुट और एक रुब्रिक देते हैं, और स्कोर करने को कहते हैं। दो नियम जज को ईमानदार रखते हैं: रुब्रिक को **विशिष्ट** बनाएँ (वर्णित एंकरों वाला 1–5 पैमाना "गुणवत्ता आँको" से बेहतर है), और जज के रूप में एक **मज़बूत मॉडल** इस्तेमाल करें — आँकना एक तर्क-कार्य है, इसलिए यह वह जगह है जहाँ मैं ख़ुशी से Sonnet का दाम चुकाता हूँ, भले ही एजेंट ख़ुद [लागत के गणित](/ai-agent-cost-math-when-haiku-beats-sonnet) के अनुसार Haiku पर चल रहा हो। धुँधली रुब्रिक या कमज़ोर जज आपको ऐसा शोर देता है जो संकेत जैसा दिखता है। ## हर बदलाव से पहले हार्नेस चलाएँ हार्नेस एक सवाल का जवाब देने के लिए मौजूद है: *क्या इस बदलाव ने एजेंट को बेहतर बनाया या बदतर?* इसलिए मैं इसे हर प्रॉम्प्ट संपादन, मॉडल अदला-बदली, या टूल बदलाव से पहले चलाता हूँ। ```bash # main पर बेसलाइन npm run eval -- --suite=booking-agent > baseline.json # बदलाव करें, फिर दोबारा चलाएँ npm run eval -- --suite=booking-agent > candidate.json # तुलना करें npm run eval:diff baseline.json candidate.json ``` डिफ़ कुल स्कोर, हर केस का पास/फेल, और — सबसे अहम — **कौन-से ख़ास केस रिग्रेस हुए** यह दिखाता है। एक कुल स्कोर जो तब ऊपर चढ़ता है जब तीन केस चुपचाप टूट रहे हों, सुधार नहीं है; यह एक सौदा है जिसे मैं देखना और मंज़ूर करना चाहता हूँ, ऐसा नहीं जो चुपके से निकल जाए। हर केस के डिफ़ पर नज़र रखना ही वह तरीका है जिससे आप "एक चीज़ ठीक की, दो और तोड़ दीं" से बचते हैं — वही विफलता-तरीका जो लोगों को अपने ही प्रॉम्प्ट से डरा देता है। ## एक रिग्रेशन गेट लगाएँ और उसे रोकने दें जब आप हार्नेस पर भरोसा कर लें, तो उसे एक गेट के रूप में प्रोडक्शन तक के रास्ते में जोड़ दें। मेरा नियम दो-टूक है: **जो बदलाव स्कोर को बेसलाइन सीमा से नीचे गिरा दे, वह शिप नहीं होता।** "बाद में देख लूँगा" नहीं — वह रोक दिया जाता है, ठीक एक विफल CI टेस्ट की तरह। ```typescript const PASS_THRESHOLD = 0.90; // 90% केस पास होने चाहिए if (candidate.passRate < PASS_THRESHOLD || candidate.passRate < baseline.passRate) { throw new Error(`Eval regression: ${candidate.passRate} < ${baseline.passRate}`); } ``` यही वह चीज़ है जो इवैल को एक "अच्छा-हो-तो-सही" से उस चीज़ में बदल देती है जो आपको तेज़ चलने देती है। गेट ही "बिना डर के शिप करना" को शब्दशः सच बनाता है: किसी बुरे बदलाव का सबसे बुरा हाल एक लाल इवैल रन है, प्रोडक्शन घटना नहीं। और क्योंकि हर बार कुछ टूटने पर टेस्ट सेट बढ़ता है, गेट समय के साथ अपने-आप सख़्त और ज़्यादा सुरक्षात्मक होता जाता है। ## स्कोरिंग में ग़ैर-नियतात्मकता का हिसाब रखें एक बारीकी जो लोगों को गिरा देती है: एक ही इनपुट अलग-अलग रन में अलग स्कोर पा सकता है क्योंकि मॉडल अलग तरह से सैंपल करता है। अगर आप हर केस को एक बार चलाते हैं, तो आपको भूतिया रिग्रेशन दिखेंगे — एक केस जो "टूटा" वह असल में महज़ सैंपलिंग शोर है। दो उपाय। विचलन घटाने के लिए इवैल को **`temperature: 0`** पर चलाएँ (यह उसे पूरी तरह ख़त्म नहीं करेगा)। और जिन केसों को आपने टिमटिमाते देखा हो, उन्हें **N बार चलाएँ और पास दर लें**, एक अकेला पास/फेल नहीं। जो केस 10 में से 9 बार पास होता है वह उससे बेहतर हालत में है जो 10 में से 5 बार पास होता है, भले ही दोनों एक अकेला हरा रन दिखा सकें। यह वही "किस्से से ज़्यादा मात्रा" वाला सिद्धांत है जो मैं [रुक-रुक कर होने वाली विफलताओं को डीबग करते](/how-to-debug-an-ai-agent-in-production) समय इस्तेमाल करता हूँ — एक रन एक राय है, पचास रन डेटा हैं। ## प्रोडक्शन मॉनिटरिंग से लूप बंद करें इवैल हार्नेस ज्ञात केसों के विरुद्ध टेस्ट करता है। प्रोडक्शन नए केस फेंकता है। तो लूप यह है: लाइव व्यवहार पर नज़र रखें, एक नया विफलता-तरीका पकड़ें, उसे एक इवैल केस में बदलें, ठीक करें, और अब वह स्थायी रूप से सुरक्षित है। मॉनिटरिंग का पहलू — लाइव ट्रैफ़िक पर सफलता दर, आउटपुट वैधता, और प्रति रन लागत ट्रैक करना — वह है जिसे मैं [मैं कैसे नापता हूँ कि कोई AI एजेंट सचमुच काम कर रहा है या नहीं](/how-i-measure-whether-an-ai-agent-is-actually-working/) में बताता हूँ। इवैल और मॉनिटरिंग एक ही तंत्र के दो हिस्से हैं: मॉनिटरिंग बग ढूँढती है, इवैल यह पक्का करती हैं कि वे मरे रहें। वह फ़ीडबैक लूप ही असली उत्पाद है। कोई भी अकेला इवैल सेट बासी पड़ जाता है; पर एक *प्रक्रिया* जो हर प्रोडक्शन विफलता को एक स्थायी टेस्ट में बदल देती है, हर हफ़्ते मज़बूत होती जाती है। इसी तरह एक एजेंट "छूने में डरावना" से उस चीज़ में बदल जाता है जिसे मैं किसी शुक्रवार की दोपहर बिना झिझके रीफ़ैक्टर कर दूँ। ## अक्सर पूछे जाने वाले सवाल ### एक AI एजेंट इवैल सेट में क्या जाता है? असली प्रोडक्शन इनपुट को ग्रेडेड केसों में बदला गया — सुखद रास्ता, किनारे के मामले, प्रतिकूल और विकृत इनपुट — हर एक के साथ कठोर असर्शन्स और, खुले-छोर आउटपुट के लिए, एक LLM-जज रुब्रिक। असल विफलताओं से लिए गए 30 से 50 केस सैकड़ों सिंथेटिक केसों को मात देते हैं जो सब आसान रास्ता टेस्ट करते हैं। ### क्या मुझे एजेंट आउटपुट आँकने के लिए LLM इस्तेमाल करना चाहिए? जहाँ भी आउटपुट संरचित हो (वैध JSON, सही फ़ील्ड, सही टूल कॉल) वहाँ कठोर असर्शन्स इस्तेमाल करें — वे मुफ़्त और नियतात्मक हैं। लहजे और उपयोगिता जैसी खुले-छोर ख़ूबियों के लिए एक LLM जज बचाकर रखें, एक विशिष्ट रुब्रिक और एक मज़बूत जज मॉडल के साथ, ताकि आपको संकेत मिले, शोर नहीं। ### मैं किसी प्रॉम्प्ट बदलाव को प्रोडक्शन चुपचाप तोड़ने से कैसे रोकूँ? हर बदलाव से पहले इवैल हार्नेस चलाएँ और एक बेसलाइन के विरुद्ध डिफ़ करें, सिर्फ़ कुल स्कोर नहीं, बल्कि हर केस के रिग्रेशन पर नज़र रखें। फिर परिणाम पर डिप्लॉय को गेट करें ताकि कोई भी बदलाव जो बेसलाइन सीमा से नीचे गिरे, एक विफल टेस्ट की तरह रोक दिया जाए। ### इवैल में ग़ैर-नियतात्मकता को मैं कैसे संभालूँ? विचलन घटाने के लिए तापमान 0 पर चलाएँ, और जो केस टिमटिमाते हैं उन्हें कई बार चलाएँ और एक अकेले रन के बजाय पास दर से स्कोर करें। जो केस 10 में से 9 बार पास होता है वह उससे ज़्यादा स्वस्थ है जो 10 में से 5 बार पास होता है, भले ही एक अकेला रन दोनों को हरा दिखाए। --- ## AI एजेंट से अपना न्यूज़लेटर कैसे ऑटोमेट करें Source: https://alejandrorioja.com/hi/how-to-automate-your-newsletter-with-an-ai-agent/ Published: 2026-06-06 Updated: 2026-06-06 Tags: AI Agents, Growth TL;DR: Claude एजेंट मेरी कंटेंट क्यू पढ़ता है, सप्ताह का सबसे मज़बूत एंगल चुनता है, मेरी आवाज़ में न्यूज़लेटर का ड्राफ्ट बनाता है, एंगेजमेंट टियर के अनुसार लिस्ट सेगमेंट करता है, और Kit API के ज़रिए भेजने का शेड्यूल बनाता है — बिना मेरे एडिटर खोले। मैं एक रेंडर किया हुआ प्रीव्यू देखता हूँ और अप्रूव दबाता हूँ। कठिन क्रिएटिव काम मेरा है; मैकेनिकल एग्जीक्यूशन एजेंट का। ## विषय सूची _जून 2026 में अपडेट किया गया।_ **TL;DR:** Claude एजेंट मेरी कंटेंट क्यू पढ़ता है, सप्ताह का सबसे मज़बूत एंगल चुनता है, मेरी आवाज़ में न्यूज़लेटर का ड्राफ्ट बनाता है, एंगेजमेंट टियर के अनुसार लिस्ट सेगमेंट करता है, और Kit API के ज़रिए भेजने का शेड्यूल बनाता है — बिना मेरे एडिटर खोले। मैं एक रेंडर किया हुआ प्रीव्यू देखता हूँ और अप्रूव दबाता हूँ। कठिन क्रिएटिव काम मेरा है; मैकेनिकल एग्जीक्यूशन एजेंट का। **[ऑपरेटर नोट]** जो न्यूज़लेटर लगातार भेजी जाती है, वह उससे बेहतर है जो "बेहतर" है लेकिन इंस्पिरेशन आने पर ही भेजी जाती है। बाधा एग्जीक्यूशन का ओवरहेड था, विचार नहीं। मेरे पास विचार थे; हर हफ्ते उन्हें फॉर्मेट, शेड्यूल और सेगमेंट करने की बैंडविड्थ नहीं थी। एजेंट ने वह गैप खत्म कर दिया। ## अधिकतर न्यूज़लेटर वर्कफ्लो में असली बॉटलनेक न्यूज़लेटर ऑटोमेशन की अधिकतर सलाह गलत चीज़ पर फोकस करती है: वेलकम सीक्वेंस, ऑटोमेशन, टैगिंग लॉजिक। यह ठीक है, लेकिन हफ्ते-दर-हफ्ते कंटेंट बनाने की समस्या नहीं सुलझाती। असली रुकावट यह है: आप जानते हैं क्या कहना है, लेकिन बैठकर उसे फॉर्मेट करना, सब्जेक्ट लाइन के वेरिएंट लिखना, सही सेगमेंट चुनना, और सही समय पर शेड्यूल करना हर हफ्ते 2-3 घंटे का कॉन्टेक्स्ट-स्विचिंग खर्च करता है। 52 हफ्तों से गुणा करें तो आपने पूरा एक कार्य-सप्ताह सिर्फ न्यूज़लेटर *भेजने* में बिताया। एजेंट "मुझे पता है इस हफ्ते का एंगल क्या है" के बाद हर कदम संभालता है। ## मैं जो स्टैक यूज़ कर रहा हूँ - **[Kit](/recommends/convertkit)** (पहले ConvertKit) — ईमेल प्लेटफ़ॉर्म। उत्कृष्ट API, मज़बूत सब्सक्राइबर टैगिंग, साफ एनालिटिक्स। एजेंट-फ्रेंडली API ने मुझे कन्विंस किया। - **Claude (Anthropic SDK)** — जनरेशन लेयर - **Cloudflare Workers** — शेड्यूल्ड ट्रिगर (हर मंगलवार सुबह 8 बजे CT चलता है) - **Airtable** — कंटेंट क्यू और अप्रूवल इनबॉक्स अगर आप Kit पर नहीं हैं, तो वही पैटर्न किसी भी प्लेटफ़ॉर्म के साथ काम करता है जिसके पास ब्रॉडकास्ट बनाने और शेड्यूल करने के लिए REST API हो। ## स्टेप 1: कंटेंट क्यू एजेंट को "हम किस बारे में लिख रहे हैं" के लिए एक सच्चे स्रोत की ज़रूरत है। मेरी [Airtable](/recommends/airtable) टेबल है जिसमें कॉलम हैं: - `Topic` — एंगल या सवाल - `Status` — Queue / Approved / Sent - `Tier` — सभी सब्सक्राइबर के लिए या केवल एंगेज्ड सब्सक्राइबर के लिए - `Notes` — कोई भी बाधाएं (यह टोन अवॉइड करें, यह लिंक शामिल करें, आदि) हर हफ्ते, मैं क्यू में 2-3 टॉपिक जोड़ने में 10 मिनट बिताता हूँ। यही मेरा क्रिएटिव इनपुट है। बाकी एजेंट का काम है। ## स्टेप 2: ड्राफ्ट एजेंट ```typescript // workers/newsletter-agent/index.ts import Anthropic from "@anthropic-ai/sdk"; import Airtable from "airtable"; const client = new Anthropic(); const VOICE_SYSTEM = `You are writing a weekly newsletter for Alejandro Rioja's subscribers. His audience: founders and operators interested in AI agents, SEO, and growing a one-person business. Voice: direct, first-person, practitioner. No hype, no "exciting times," no excessive bullet lists. Structure every newsletter as: 1. One-sentence hook (the problem or observation) 2. The core insight (3–5 paragraphs, no headers, conversational) 3. One concrete action the reader can take this week 4. A short sign-off (2 sentences max) Subject line: specific, outcome-oriented, under 50 chars. No clickbait. Return JSON: { "subject": "...", "preheader": "...", "body": "..." }`; async function getNextTopic(): Promise<{ id: string; topic: string; notes: string; tier: string }> { const base = new Airtable({ apiKey: process.env.AIRTABLE_API_KEY }).base(process.env.AIRTABLE_BASE_ID!); const records = await base("Newsletter Queue") .select({ filterByFormula: "{Status} = 'Queue'", sort: [{ field: "Created", direction: "asc" }], maxRecords: 1 }) .firstPage(); if (!records.length) throw new Error("Queue is empty. Add topics."); const r = records[0]; return { id: r.id, topic: r.get("Topic") as string, notes: (r.get("Notes") as string) ?? "", tier: (r.get("Tier") as string) ?? "all" }; } async function draftNewsletter(topic: string, notes: string): Promise<{ subject: string; preheader: string; body: string }> { const msg = await client.messages.create({ model: "claude-sonnet-4-6", max_tokens: 2048, system: VOICE_SYSTEM, messages: [{ role: "user", content: `Write this week's newsletter on: "${topic}". Additional notes: ${notes || "none"}` }], }); const text = (msg.content[0] as any).text.replace(/```json\n?/, "").replace(/```/, "").trim(); return JSON.parse(text); } async function scheduleWithKit(draft: { subject: string; preheader: string; body: string }, tier: string): Promise { const segmentId = tier === "engaged" ? process.env.KIT_ENGAGED_SEGMENT_ID : null; const sendAt = new Date(); sendAt.setDate(sendAt.getDate() + ((4 - sendAt.getDay() + 7) % 7)); // next Thursday sendAt.setHours(9, 0, 0, 0); // 9am CT const payload: any = { broadcast: { subject: draft.subject, content: draft.body, description: draft.preheader, send_at: sendAt.toISOString(), email_layout_template: "minimal", }, }; if (segmentId) payload.broadcast.segment_id = segmentId; const res = await fetch("https://api.kit.com/v4/broadcasts", { method: "POST", headers: { "Content-Type": "application/json", "X-Kit-Api-Key": process.env.KIT_API_KEY! }, body: JSON.stringify(payload), }); const data = await res.json(); return data.broadcast?.id ?? ""; } export default { async scheduled(_event: ScheduledEvent, env: Env) { // Inject env vars Object.assign(process.env, env); const { id, topic, notes, tier } = await getNextTopic(); const draft = await draftNewsletter(topic, notes); const broadcastId = await scheduleWithKit(draft, tier); // Mark as Approved in Airtable (not Sent — human reviews the Kit preview before confirm) const base = new Airtable({ apiKey: env.AIRTABLE_API_KEY }).base(env.AIRTABLE_BASE_ID); await base("Newsletter Queue").update(id, { Status: "Approved", KitBroadcastId: broadcastId }); console.log(`Scheduled broadcast ${broadcastId} for topic: ${topic}`); }, }; ``` ## स्टेप 3: अप्रूवल स्टेप एजेंट Kit के ड्राफ्ट स्टेट में ब्रॉडकास्ट बनाता है और Airtable रिकॉर्ड को "Approved" मार्क करता है। Kit मुझे प्रीव्यू लिंक के साथ नोटिफिकेशन भेजता है। मैं उस पर क्लिक करता हूँ, पढ़ता हूँ, और अगर सही लगे तो भेजने की पुष्टि करता हूँ। अगर बदलाव चाहूँ, तो Kit में सीधे एडिट करता हूँ। यही वह गेट है जो एजेंट को आउटबाउंड ईमेल में पूरी तरह ऑटोनॉमस होने से रोकता है। मैं ड्राफ्ट पर लगभग 90% समय भरोसा करता हूँ। रिव्यू में जो 10% पकड़ता हूँ — थोड़ा गलत टोन, एक स्टैट जिसे वेरिफाई करना हो, एक लिंक जोड़ना हो — वह 3 मिनट की रिव्यू की कीमत पर है। ## एजेंट जो संभालता है जो मैं दोबारा नहीं करना चाहता - सब्जेक्ट लाइन वेरिएंट लिखना और सबसे अच्छा चुनना - प्रीहेडर टेक्स्ट फॉर्मेट करना - सही भेजने का समय कैलकुलेट करना (मेरा ऑडियंस गुरुवार सुबह खोलता है; एजेंट यह जानता है) - टॉपिक के टियर के आधार पर सही से सेगमेंट करना - रिकॉर्ड रखने के लिए सब कुछ Airtable में लॉग करना ## मेरे पास जो अभी भी है *आइडिया*। क्यू में टॉपिक मेरा है। एंगल मेरा है। एजेंट एक स्पष्ट ब्रीफ का शानदार एग्जीक्यूटर है; यह स्ट्रैटेजी लेयर नहीं है। अगर मैंने क्यू में बुरा टॉपिक डाला, तो मुझे बुरे टॉपिक के बारे में अच्छी तरह लिखी न्यूज़लेटर मिलेगी। इसके अलावा: पहले रिव्यू का गेट। हर भेजने से पहले मेरी नज़र उस पर जाती है। यह नहीं बदलेगा। ## ऑपरेटर की बॉटम लाइन अगर आप न्यूज़लेटर मैकेनिक्स पर हफ्ते में एक घंटे से ज़्यादा खर्च कर रहे हैं — फॉर्मेटिंग, शेड्यूलिंग, सेगमेंटिंग — तो आपको इसे ऑटोमेट करना चाहिए। Kit API क्लीन है, Worker cron ट्रिगर रॉक-सॉलिड है, और Claude ड्राफ्ट क्वालिटी इतनी ऊँची है कि मैं ~90% पहले ड्राफ्ट बिना बदलाव के अप्रूव कर देता हूँ। Airtable में क्यू बनाएं, Worker कनेक्ट करें, और भेजने की जगह आइडिया बनाने पर वापस आएं। --- ## एक भी नया ब्लॉग पोस्ट लिखे बिना AI सर्च में रैंक कैसे करें Source: https://alejandrorioja.com/hi/how-to-rank-in-ai-search-without-writing-a-single-new-blog-post/ Published: 2026-06-06 Updated: 2026-06-06 Tags: GEO, SEO TL;DR: AI इंजन उस कंटेंट को उद्धृत करते हैं जो सीधे सवालों का जवाब देता है, स्पष्ट लेखकत्व का दावा करता है और ज्ञान को इस तरह संरचित करता है जिससे पुनः प्राप्ति आसान हो। अधिकांश मौजूदा ब्लॉग पोस्ट को पुनर्लेखन नहीं बल्कि संपादन के साथ तीनों मानदंडों को पूरा करने के लिए संशोधित किया जा सकता है। प्लेबुक: एक सीधा TL;DR जोड़ें, एंटिटी सिग्नल को मजबूत करें, FAQ स्कीमा जोड़ें और llms.txt में सबमिट करें। नया कंटेंट वैकल्पिक है; पुनर्संरचना नहीं है। ## विषय सूची _जून 2026 में अपडेट किया गया।_ **TL;DR:** AI इंजन उस कंटेंट को उद्धृत करते हैं जो सीधे सवालों का जवाब देता है, स्पष्ट लेखकत्व का दावा करता है और ज्ञान को इस तरह संरचित करता है जिससे पुनः प्राप्ति आसान हो। अधिकांश मौजूदा ब्लॉग पोस्ट को पुनर्लेखन नहीं बल्कि संपादन के साथ तीनों मानदंडों को पूरा करने के लिए संशोधित किया जा सकता है। प्लेबुक: एक सीधा TL;DR जोड़ें, एंटिटी सिग्नल को मजबूत करें, FAQ स्कीमा जोड़ें और llms.txt में सबमिट करें। नया कंटेंट वैकल्पिक है; पुनर्संरचना नहीं है। **[ऑपरेटर की नज़र]** एक भी नया GEO-लक्षित लेख लिखने से पहले मैंने यह प्रक्रिया 341 मौजूदा पोस्ट पर लागू की। ChatGPT और Perplexity में उद्धरण बढ़े। नए कंटेंट ने लाभ को तेज़ किया — लेकिन मौजूदा कंटेंट ऑडिट वह जगह थी जहां मैंने शुरू किया, और उम्मीद से ज़्यादा तेज़ी से फल मिला। ## AI इंजन आपके मौजूदा कंटेंट को क्यों नहीं उद्धृत करते कुछ नया लिखने से पहले पूछें: जो मेरे पास पहले से है वह क्यों उद्धृत नहीं हो रहा? जवाब लगभग कभी नहीं होता "कंटेंट मौजूद नहीं है।" यह आमतौर पर इनमें से एक होता है: 1. **शीर्ष पर कोई सीधा जवाब नहीं** — पोस्ट जवाब को पैराग्राफ 6 में दफन कर देती है 2. **लेखकत्व सिग्नल कमज़ोर** — कोई स्पष्ट लेखक एंटिटी नहीं, कंटेंट में कोई क्रेडेंशियल नहीं 3. **संरचनात्मक शोर** — लंबे परिचय, अप्रासंगिक खंड, कोई स्पष्ट शीर्षक पदानुक्रम नहीं 4. **कोई मशीन-पठनीय Q&A नहीं** — AI इंजन संरचित प्रश्न-उत्तर जोड़े पसंद करते हैं; अधिकांश ब्लॉग पोस्ट में ये नहीं होते 5. **किसी AI-पठनीय इंडेक्स में नहीं** — कोई llms.txt नहीं, कोई साइटमैप नहीं जो क्रॉलर ढूंढें पांचों मौजूदा कंटेंट पर ठीक करने योग्य हैं। किसी के लिए भी नई पोस्ट की ज़रूरत नहीं। ## चार-चरण रेट्रोफिट प्रक्रिया ### चरण 1: पहले 100 शब्दों में सीधा TL;DR जोड़ें AI इंजन वह करते हैं जो आप स्कैन करते समय करते हैं — गहरे जाने से पहले सीधा जवाब ढूंढते हैं। अगर आपकी पोस्ट किसी कहानी, सवाल या संदर्भ-निर्माण से शुरू होती है, तो मॉडल शायद कभी इतना आगे न पढ़े कि आपका असली जवाब मिले। समाधान: पहले 100 शब्दों में एक **TL;DR** ब्लॉक जोड़ें। प्रारूप: निष्कर्ष → क्यों → बाधा या चेतावनी। दो से चार वाक्य। कोई भराई नहीं। पहले का उदाहरण: > *क्या आपने कभी सोचा है कि कुछ व्यवसाय Google के खोज परिणामों पर हावी क्यों लगते हैं? इस पोस्ट में, हम उन रणनीतियों की खोज करेंगे जो शीर्ष-रैंकिंग साइटें उपयोग करती हैं...* बाद का उदाहरण: > **TL;DR:** 2026 में लोकल SEO के लिए तीन चीज़ें काम करती हैं: Google Business Profile की पूर्णता, डायरेक्टरी में उद्धरण की निरंतरता और NAP डेटा के लिए संरचित स्कीमा। "हर दिन पोस्ट करें" और "100 रिव्यू जल्दी पाएं" जैसी रणनीतियां इन तीन के सामने गौण हैं। सीमा आपके GBP की सटीकता है — पहले उसे ठीक करें। पुनर्लेखन लंबा नहीं है। बस आगे रख दिया गया है। ### चरण 2: एंटिटी सिग्नल को मजबूत करें AI इंजन ज्ञान ग्राफ बनाते हैं। वे जानना चाहते हैं: यह किसने लिखा, यह किस बारे में है और इस विषय पर लेखक विश्वसनीय है? लेखक एंटिटी के लिए: सुनिश्चित करें कि About पेज हर पोस्ट से लिंक है, आपके लेखक स्कीमा में LinkedIn और Twitter के `sameAs` लिंक हैं, और हर पोस्ट की लेखक बायो में विशिष्ट क्रेडेंशियल का उल्लेख है (न कि "मार्केटिंग प्रोफेशनल" — "तीन SaaS कंपनियों के लिए SEO 0 से 100K मासिक आगंतुकों तक चलाया")। विषय एंटिटी के लिए: वे सटीक शब्द उपयोग करें जो आपके दर्शक खोजते हैं। अगर आप "GEO" (जनरेटिव इंजन ऑप्टिमाइजेशन) को कवर कर रहे हैं, तो सिर्फ संक्षिप्त रूप नहीं बल्कि कहीं "जनरेटिव इंजन ऑप्टिमाइजेशन" कहें। मॉडल कंटेंट वर्गीकृत करने के लिए शब्द सह-उपस्थिति का उपयोग करते हैं। ### चरण 3: सवालों का जवाब देने वाली हर पोस्ट में FAQ स्कीमा जोड़ें FAQPage स्कीमा GEO उद्धरण के लिए सबसे अधिक प्रभाव वाला स्कीमा प्रकार है क्योंकि यह उस फ़ॉर्मेट में सवाल को जवाब से स्पष्ट रूप से मैप करता है जिसे मॉडल सीधे पार्स कर सकते हैं। उन 3-5 सवालों को लें जिनका आपकी पोस्ट अंतर्निहित रूप से जवाब देती है और उन्हें स्पष्ट बनाएं: ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "How long does it take to rank in AI search?", "acceptedAnswer": { "@type": "Answer", "text": "Most sites see initial citation improvements within 4–8 weeks of restructuring existing content for direct answers and adding FAQ schema. Brand-new domains take longer — expect 3–6 months before consistent citations appear." } } ] } ``` इसे अपनी पोस्ट के `` में या CMS के स्कीमा फ़ील्ड के ज़रिए जोड़ें। हर प्रमुख AI इंजन इसे क्रॉल और पार्स करता है। ### चरण 4: llms.txt और अपने प्लेटफ़ॉर्म के AI इंडेक्स में सबमिट करें `llms.txt` एक उभरता मानक है — `yoursite.com/llms.txt` पर एक प्लेन-टेक्स्ट फ़ाइल जो AI क्रॉलर को बताती है कि कौन सा कंटेंट उच्च-गुणवत्ता वाला है और इसे कैसे प्राथमिकता दें। यह LLMs के लिए `robots.txt` के समान है। बुनियादी llms.txt: ``` # llms.txt # alejandrorioja.com — AI agents and GEO for operators ## Priority content - /blog/geo-for-local-business (definitive guide, updated monthly) - /blog/schema-markup-for-ai-engines (technical reference) - /blog/how-to-get-cited-by-chatgpt (step-by-step) ## Author Alejandro Rioja — operator, AI agent builder, GEO practitioner. LinkedIn: https://linkedin.com/in/alejandrorioja ``` इसे `lastmod` टाइमस्टैंप वाले साफ साइटमैप के साथ जोड़ें। AI क्रॉलर पुराने दिखने वाले कंटेंट को कम प्राथमिकता देते हैं। ## किन पोस्ट को रेट्रोफिट करना है, इसे कैसे प्राथमिकता दें हर पोस्ट रेट्रोफिट करने लायक नहीं है। अपने पहले दौर को यहां केंद्रित करें: 1. **पोस्ट जो पहले से प्रश्न-प्रारूप कीवर्ड के लिए पेज 1 पर रैंक करती हैं** — ये उद्धृत होने के सबसे करीब हैं; उन्हें सिर्फ संरचना सुधार चाहिए 2. **उन विषयों पर पोस्ट जिन पर आप सत्यापित रूप से विश्वसनीय हैं** — AI इंजन लेखकत्व को भारी वज़न देते हैं; वह पोस्ट जहां आपके क्रेडेंशियल प्रासंगिक हैं, एंटिटी सिग्नल से उद्धरण बढ़त पाती है 3. **सीधे सवाल का जवाब देने वाली पोस्ट बनाम जानकारी देने वाली पोस्ट** — "X कैसे करें" और "X क्या है" सूची पोस्ट या राय टुकड़ों से बेहतर रेट्रोफिट होती हैं अपने Search Console डेटा का उपयोग करें: प्रश्न वाले क्वेरी के लिए फ़िल्टर करें (how, what, why, best way to)। उन क्वेरी के लिए 5-15 पर रैंक करने वाली पोस्ट आपके सर्वोत्तम रेट्रोफिट उम्मीदवार हैं — वे प्रासंगिक हैं लेकिन उद्धृत होने के लिए शीर्ष के पर्याप्त करीब नहीं हैं। ## वह गलती जो अधिकांश लोग करते हैं वे मौजूदा आर्काइव को रेट्रोफिट करने से पहले AI सर्च के लिए अनुकूलित नई पोस्ट लिखते हैं। नया कंटेंट मदद करता है, लेकिन मौजूदा पोस्ट के पास उम्र, बैकलिंक और क्रॉल इतिहास की ताकत है। एक अच्छी तरह से संरचित तीन साल पुरानी पोस्ट महीनों तक उसी विषय पर नई पोस्ट से बेहतर प्रदर्शन करेगी। पहले रेट्रोफिट करें। जहां वास्तविक अंतराल हों — जो सवाल आपकी मौजूदा पोस्ट बिल्कुल नहीं करती — वहां नया कंटेंट लिखें। तभी नया पुराने से बेहतर होता है। ## ऑपरेटर का निष्कर्ष अगर आपके पास 20 से अधिक मौजूदा ब्लॉग पोस्ट हैं, तो आपका GEO काम कंटेंट कैलेंडर नहीं बल्कि ऑडिट और रेट्रोफिट से शुरू होता है। कुछ भी नया लिखने से पहले अपनी शीर्ष 20 पोस्ट पर TL;DR जोड़ें, एंटिटी सिग्नल मजबूत करें, FAQ स्कीमा जोड़ें और llms.txt में सबमिट करें। आप महीनों में नहीं, हफ्तों में उद्धरण सुधार देखेंगे — और आपके पास यह मापने के लिए एक साफ बेसलाइन होगी कि नया कंटेंट वास्तव में सुई को हिलाता है या नहीं। --- ## मैंने एक Claude स्किल बनाई जो मेरे Facebook विज्ञापन चलाती है — यहाँ है कोड Source: https://alejandrorioja.com/hi/i-built-a-claude-skill-that-runs-my-facebook-ads-heres-the-code/ Published: 2026-06-06 Updated: 2026-06-06 Tags: AI Agents TL;DR: मैंने एक Claude स्किल बनाई जो Graph API के माध्यम से मेरे Meta Ads अकाउंट को पढ़ती है, कम प्रदर्शन वाले विज्ञापनों की पहचान करती है, मेरी ब्रांड वॉयस में विज्ञापन कॉपी फिर से लिखती है, और बिना Ads Manager को छुए नए विज्ञापन सेट बनाती है। पूरी चीज़ 300 लाइनों से कम TypeScript में है। ROI तुरंत आया: मैंने साप्ताहिक विज्ञापन प्रबंधन का समय ~3 घंटे से घटाकर लगभग 20 मिनट कर दिया। ## विषय-सूची _जून 2026 में अपडेट।_ **TL;DR:** मैंने एक Claude स्किल बनाई जो Graph API के माध्यम से मेरे Meta Ads अकाउंट को पढ़ती है, कम प्रदर्शन वाले विज्ञापनों की पहचान करती है, मेरी ब्रांड वॉयस में विज्ञापन कॉपी फिर से लिखती है, और बिना Ads Manager को छुए नए विज्ञापन सेट बनाती है। पूरी चीज़ 300 लाइनों से कम TypeScript में है। ROI तुरंत आया: मैंने साप्ताहिक विज्ञापन प्रबंधन का समय ~3 घंटे से घटाकर लगभग 20 मिनट कर दिया। **[ऑपरेटर की नज़र]** मैं Pickleland और अपने कंसल्टिंग ब्रांड के लिए विज्ञापन चलाता हूँ। दो अकाउंट, अलग-अलग ऑडियंस, लगातार क्रिएटिव थकान। मैं रविवार की दोपहरें Ads Manager में ऐसी चीजें करते हुए बिता रहा था जो एक मॉडल को करनी चाहिए। तो मैंने इसे ऑटोमेट कर दिया। ## मैंने Facebook विज्ञापन मैन्युअली प्रबंधित करना क्यों बंद किया Facebook विज्ञापन चलाने का असली काम तीन हिस्सों में बंटता है: 1. **मॉनिटरिंग** — यह जाँचना कि कौन से विज्ञापन सेट पैसे जला रहे हैं बनाम कमा रहे हैं 2. **डायग्नोसिस** — यह पता लगाना कि *क्यों* कुछ कम प्रदर्शन कर रहा है (क्रिएटिव थकान? खराब टार्गेटिंग? लैंडिंग पेज?) 3. **इटरेशन** — नई कॉपी लिखना, नए विज्ञापन सेट बनाना, बजट एडजस्ट करना काम 1 यांत्रिक है। काम 3 ज्यादातर यांत्रिक है (वॉयस की सीमा के साथ)। काम 2 को निर्णय की जरूरत है — और यह एकमात्र ऐसा है जिसमें लूप में इंसान का होना फायदेमंद है। एक Claude स्किल 1 और 3 कर सकती है। मैं काम 2 के आउटपुट की समीक्षा करता हूँ इससे पहले कि कुछ भी पब्लिश हो। यही वह आर्किटेक्चर है जिस पर मैं टिका। ## Meta Graph API सेटअप (यह परेशान करने वाला हिस्सा है) किसी भी कोड से पहले: आपको Meta Business अकाउंट, एक सिस्टम यूज़र और एक स्थायी एक्सेस टोकन चाहिए। Facebook का डेव पोर्टल असुविधाजनक है लेकिन रास्ता यह है: 1. developers.facebook.com पर **Meta App** बनाएँ (प्रकार: Business) 2. **Marketing API** प्रोडक्ट जोड़ें 3. अपने Business Portfolio → Settings → Users → System Users में, एक सिस्टम यूज़र बनाएँ और उसे अपने विज्ञापन अकाउंट पर `ADVERTISER` रोल दें 4. इन परमिशन के साथ टोकन जनरेट करें: `ads_read`, `ads_management`, `business_management` टोकन को `META_ACCESS_TOKEN` के रूप में और अपने विज्ञापन अकाउंट ID (फॉर्मेट: `act_XXXXXXXX`) को `META_AD_ACCOUNT_ID` के रूप में अपनी `.env` में सेव करें। ## स्किल फ़ाइल संरचना ``` .claude/skills/fb-ads/ SKILL.md ← निर्देश जो Claude पढ़ता है index.ts ← असली टूल इम्प्लीमेंटेशन types.ts ← साझा टाइप्स ``` `SKILL.md` वह है जो Claude को बताता है कि स्किल का उपयोग कब और कैसे करना है। मेरी कहती है: ```markdown # Facebook Ads Manager Skill Use this skill when the user says "check my ads", "run ads report", "pause underperformers", or "write new ad copy". Never run this without explicit user instruction — it touches live ad spend. ## What it can do - Pull performance data for all active ad sets (last 7 or 30 days) - Flag ad sets with ROAS < 1.5 or CTR < 0.8% as underperformers - Rewrite ad copy for flagged creatives in Ale's voice - Create new ad sets with revised copy (PAUSED by default — you approve before activating) ## What it will NOT do - Change budgets on live ad sets without explicit confirmation - Activate new ad sets automatically - Delete anything ``` "कभी भी स्वचालित रूप से सक्रिय न करें" की बाधा गैर-परक्राम्य है। यह स्किल चीज़ें PAUSED स्थिति में बनाती है। मैं समीक्षा करता हूँ और मैन्युअली सक्रिय करता हूँ। लाइव विज्ञापन खर्च को छूने वाली किसी भी चीज़ को इंसानी चेकपॉइंट की जरूरत है। ## मुख्य TypeScript कोड (कोड ब्लॉक अंग्रेजी में रहते हैं — केवल आसपास का टेक्स्ट अनुवादित है।) ## मैं इसे रोज़ाना कैसे उपयोग करता हूँ स्किल Claude Code से इनवोक होती है (मेरा डेली टूल)। एक विशिष्ट सोमवार सुबह का सेशन: ``` > check my ads from the last 7 days ``` Claude `runAdsReport(7)` चलाता है, परिणामों को टेबल के रूप में फॉर्मेट करता है, कम प्रदर्शन वालों को फ्लैग करता है, और पूछता है कि क्या मैं रीराइट चाहता हूँ। मैं हाँ कहता हूँ। यह नई कॉपी जनरेट करता है, मुझे दोनों वर्शन साइड-बाय-साइड दिखाता है, और नए क्रिएटिव के साथ PAUSED विज्ञापन सेट बनाता है। मैं उन्हें Ads Manager में समीक्षा करता हूँ, जो मुझे पसंद हैं उन्हें एक्टिवेट करता हूँ, और हारे हुओं को आर्काइव करता हूँ। कुल समय: 20 मिनट। Ads Manager में रविवार की दोपहरें: शून्य। ## यह किसे रिप्लेस नहीं करती स्किल मुझे यह नहीं बता सकती कि प्रोडक्ट-मार्केट फिट की समस्या कॉपी की समस्या के रूप में छुपी है या नहीं। अगर ROAS हर जगह खराब है, तो यह फनल या ऑफर की समस्या है, हेडलाइन की नहीं। Claude टूटे हुए फनल पर ईमानदारी से कॉपी रीराइट करेगा — और रीराइट्स इसे नहीं बचाएँगी। डायग्नोसिस का चरण अभी भी मेरा है। मैं रिपोर्ट पढ़ता हूँ, फनल डेटा देखता हूँ, और तय करता हूँ कि क्या हम क्रिएटिव को इटरेट कर रहे हैं या ऊपरी स्तर पर कुछ हल कर रहे हैं। एजेंट उस निर्णय *के अलावा* सब कुछ में तेज़ है। ## ऑपरेटर का निष्कर्ष अगर आप मैन्युअली विज्ञापन प्रबंधित कर रहे हैं और हफ्ते में दो बार से ज़्यादा Ads Manager को छू रहे हैं, तो आप वे ऑपरेशन कर रहे हैं जो एक स्क्रिप्ट को करने चाहिए। Graph API अच्छी तरह से डॉक्युमेंटेड है और Meta परमिशन फ्लो, हालाँकि परेशान करने वाला है, एक बार का सेटअप है। एक दोपहर में स्किल बनाएँ। पुनः प्राप्त समय का फायदा पहले हफ्ते में दिखता है। --- ## 5 AI टूल्स जो मैं वास्तव में अपना बिजनेस चलाने के लिए उपयोग करता हूं (2026) Source: https://alejandrorioja.com/hi/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack/ Published: 2026-06-06 Updated: 2026-06-06 Tags: AI Agents, Growth TL;DR: पांच टूल्स: Claude (ऑपरेटर लेयर + कोडिंग), Cursor (TypeScript डेवलपमेंट), Airtable (सभी एजेंट्स के लिए डेटा बैकबोन), Kit (न्यूज़लेटर + ईमेल ऑटोमेशन), और Cloudflare Workers (एजेंट होस्टिंग)। मैंने जो कुछ और आज़माया वो इनमें से किसी एक से बदल दिया गया या पूरी तरह काट दिया गया। यही वह स्टैक है जिसे मैं दोबारा बनाऊंगा अगर मुझे आज से शुरू करना हो। ## विषय सूची _जून 2026 में अपडेट किया गया।_ **TL;DR:** पांच टूल्स: Claude (ऑपरेटर लेयर + कोडिंग), Cursor (TypeScript डेवलपमेंट), [Airtable](/recommends/airtable) (सभी एजेंट्स के लिए डेटा बैकबोन), [Kit](/recommends/convertkit) (न्यूज़लेटर + ईमेल ऑटोमेशन), और Cloudflare Workers (एजेंट होस्टिंग)। मैंने जो कुछ और आज़माया वो इनमें से किसी एक से बदल दिया गया या पूरी तरह काट दिया गया। यही वह स्टैक है जिसे मैं दोबारा बनाऊंगा अगर मुझे आज से शुरू करना हो। **[ऑपरेटर की नज़र]** मैं दो बिजनेस चलाता हूं: एक पर्सनल AI कंसल्टिंग ब्रांड (alejandrorioja.com) और Pickleland — Texas के Pflugerville में एक पिकलबॉल सुविधा। अलग-अलग संदर्भ, अलग-अलग दर्शक, अलग-अलग ऑपरेशन। ये पांच टूल्स दोनों को चलाते हैं। मैं इन्हें इसलिए नहीं लिस्ट कर रहा क्योंकि ये ट्रेंडी हैं; बल्कि इसलिए कि मैंने इनके रिप्लेसमेंट को डिलीट कर दिया। ## 1. Claude — ऑपरेटर लेयर Claude (Claude Code और Anthropic SDK के ज़रिए) हर चीज़ का दिमाग है जो चलती है। मैं इसे तीन मोड में उपयोग करता हूं: **Claude Code** मेरा रोज़मर्रा का डेवलपमेंट टूल है। मैं TypeScript लिखता हूं, एजेंट बनाता हूं, इन्फ्रास्ट्रक्चर समस्याओं को डीबग करता हूं, और कंटेंट मैनेज करता हूं — सब Claude Code इंटरफेस से। यह सिर्फ ऑटोकम्पलीट नहीं है; यह एक सहयोगी है जो 500 लाइन की फ़ाइल पढ़ सकता है, इरादे को समझ सकता है, और एक रिफैक्टर सुझा सकता है जो मैंने सोचा नहीं था। **Anthropic SDK** मेरे द्वारा बनाए गए हर एजेंट को पावर देता है। मेरा न्यूज़लेटर एजेंट, मेरी Facebook ads स्किल, मेरा कंटेंट पाइपलाइन, मेरा OG कार्ड जेनरेटर — सब Claude बैकएंड पर। मॉडल की क्वालिटी इतनी अच्छी है कि मैं लगभग 85% समय पहले ड्राफ्ट पर भरोसा करता हूं। **Claude का वॉयस और ब्रांड** जज्मेंट अंडररेटेड है। जब मैं कुछ ऐसा लिखता हूं जो मेरी तरह लगना चाहिए, तो मैंने पाया कि Claude + एक विस्तृत सिस्टम प्रॉम्प्ट मेरे द्वारा टेस्ट किए गए हर दूसरे मॉडल से बेहतर प्रदर्शन करता है। ट्रिक एक विशिष्ट, राय वाला सिस्टम प्रॉम्प्ट है — "एक कैजुअल टोन में लिखो" नहीं बल्कि "Alejandro की तरह लिखो: सीधा, प्रैक्टिशनर, कोई हाइप नहीं, नंबर्ड, फर्स्ट-पर्सन, ईमानदार चेतावनियों के साथ।" मैं Claude Max के लिए भुगतान करता हूं। यह मेरा सबसे ज़्यादा उपयोग किया जाने वाला सब्सक्रिप्शन है, और ROI की कोई तुलना नहीं है। ## 2. Cursor — जहां TypeScript लिखा जाता है Cursor IDE है। मैंने लगभग एक साल पहले VS Code से स्विच किया और पीछे मुड़कर नहीं देखा। Tab कम्पलीशन इतनी तेज़ है कि यह वास्तव में बदल देती है कि मैं कोड कैसे लिखता हूं — मैं एक उच्च स्तर पर सोचता हूं और Cursor को सिंटैक्टिक बॉयलरप्लेट संभालने देता हूं। AI सुझावों के लिए diff व्यू साफ है। मल्टी-फाइल कॉन्टेक्स्ट विंडो का मतलब है कि मैं इसे एक फंक्शन अपडेट करने के लिए कह सकता हूं और यह कॉलर्स को भी अपडेट करता है। मैं आर्किटेक्चर डिसीज़न के लिए Cursor का उपयोग नहीं करता। मैं अभी भी उन्हें कागज़ पर या Claude में स्केच करता हूं। लेकिन एक बार डिज़ाइन स्पष्ट हो जाए, Cursor डिज़ाइन से चलने वाले TypeScript तक सबसे तेज़ रास्ता है। सबसे बड़ा अनलॉक: Cursor + Claude Code पैरेलल में। मैं हाई-लेवल प्लानिंग और एजेंट ऑर्केस्ट्रेशन के लिए Claude Code का उपयोग करता हूं; इम्प्लीमेंटेशन डिटेल वर्क के लिए Cursor। वे कॉन्फ्लिक्ट नहीं करते — वे अलग-अलग ऊंचाइयों को कवर करते हैं। ## 3. Airtable — डेटा बैकबोन मेरा हर AI एजेंट पढ़ने और लिखने के लिए एक जगह चाहता है। वह जगह [Airtable](/recommends/airtable) है। यहाँ बताया गया है कि मैं दोनों बिजनेस में इसका उपयोग किस लिए करता हूं: - **कंटेंट क्यू** — प्रगति में पोस्ट और न्यूज़लेटर टॉपिक्स, स्टेटस ट्रैकिंग के साथ - **बुकिंग रिकॉर्ड** — बुकिंग सिस्टम से सिंक किए गए Pickleland कोर्ट रिज़र्वेशन - **एफिलिएट लिंक कैटलॉग** — 105+ स्लग्स जेनरेशन के समय कंटेंट एजेंट मेटाडेटा पढ़ता है - **एजेंट ऑडिट लॉग** — क्या चला, कब, क्या प्रोड्यूस किया, कोई एरर API साफ और तेज़ है। Airtable हाई-थ्रूपुट वर्कलोड के लिए डेटाबेस नहीं है — लेकिन एजेंट साइड-टेबल्स, रिव्यू क्यू, और ह्यूमन-इन-द-लूप अप्रूवल वर्कफ्लो के लिए, यह बिल्कुल सही टूल है। विजुअल इंटरफेस का मतलब है कि मैं बिना क्वेरी लिखे किसी भी टेबल को इंस्पेक्ट कर सकता हूं। मैंने जो विकल्प आज़माया: Notion डेटाबेस। Notion API धीमा है और डेटा मॉडल एजेंट रीड के लिए अधिक बोझिल है। एजेंट-एडजेसेंट डेटा के लिए Airtable जीतता है। ## 4. Kit — न्यूज़लेटर और ईमेल ऑटोमेशन मैंने [Kit](/recommends/convertkit) (पहले ConvertKit) पर एक कारण से स्विच किया: API वास्तव में अच्छा है। अधिकांश ईमेल प्लेटफॉर्म अपने API को एक बाद का विचार मानते हैं। Kit इसे फर्स्ट-क्लास प्रोडक्ट के रूप में मानता है। मैं ब्रॉडकास्ट बना सकता हूं, शेड्यूल सेंड कर सकता हूं, टैग के आधार पर सेगमेंट कर सकता हूं, और एनालिटिक्स पढ़ सकता हूं — सब प्रोग्रामेटिकली। मेरा न्यूज़लेटर एजेंट बिना मेरे कंपोज़र को छुए यह सब करता है। Kit-विशिष्ट चीज़ें जो मैं उपयोग करता हूं: - **Broadcasts API** — मेरा एजेंट हर हफ्ते प्रोग्रामेटिकली शेड्यूल्ड ब्रॉडकास्ट बनाता है - **सब्सक्राइबर टैगिंग** — मैं व्यवहार से सब्सक्राइबर को टैग करता हूं (आखिरी 5 सेंड खोले = "एंगेज्ड"; 60 दिनों में नहीं खोला = "एट-रिस्क") और मेरा एजेंट सेगमेंट को उसी के अनुसार टारगेट करता है - **फॉर्म्स + लैंडिंग पेजेज़** — साफ, तेज़ लोडिंग, नो-कोड। मैं इन्हें प्रोग्रामेटिकली हैंडल नहीं करता; ये बस काम करते हैं। अगर आप Mailchimp या किसी लीगेसी प्लेटफॉर्म पर हैं: माइग्रेशन इसके लायक है। Mailchimp के API को वह करने के लिए तीन अतिरिक्त कॉल चाहिए जो Kit एक में करता है। ## 5. Cloudflare Workers — जहां एजेंट रहते हैं हर शेड्यूल्ड एजेंट Cloudflare Workers पर चलता है। पिच: ग्लोबल एज डिप्लॉयमेंट, फ्री टियर पर ज़ीरो कोल्ड स्टार्ट, और एक cron ट्रिगर सिस्टम जो वास्तव में काम करता है। मेरे एजेंट को सर्वर की ज़रूरत नहीं। उन्हें एक शेड्यूल्ड फंक्शन चाहिए जो विश्वसनीय रूप से चले, एक्सटर्नल API कॉल कर सके, और मेरे स्केल पर लगभग कुछ भी न लगे। Workers जवाब है। Workers पर जो मेरे पास चल रहा है: - **कंटेंट पाइपलाइन** — EN पोस्ट जेनरेट करता है, 12 ट्रांसलेशन में फैलाता है, OG कार्ड जेनरेट करता है - **न्यूज़लेटर एजेंट** — साप्ताहिक सेंड को ड्राफ्ट और शेड्यूल करता है - **Facebook Ads मॉनिटर** — परफॉर्मेंस पढ़ता है, अंडरपरफॉर्मर को फ्लैग करता है, मुझे नोटिफाई करता है - **Pickleland ऑक्युपेंसी रिपोर्टर** — बुकिंग डेटा पढ़ता है, मुझे दैनिक सारांश भेजता है इन सब की कुल मासिक लागत: ~$5। यह पेड Workers प्लान है। एजेंट cron शेड्यूल पर विश्वसनीय रूप से चलते हैं; मेरे पास छह महीनों में एक फेल हुआ (Meta की तरफ से DNS समस्या, मेरी नहीं)। ## मैंने क्या काटा और क्यों **Zapier** — Workers + संबंधित प्लेटफॉर्म APIs सीधे से बदल दिया। Zapier लेटेंसी जोड़ता है, स्केल पर ज़्यादा लागत करता है, और Workers जैसी कोई सीलिंग नहीं है। **ChatGPT** — Claude का कॉन्टेक्स्ट विंडो, टूल यूज़, और सिस्टम प्रॉम्प्ट क्वालिटी ऑपरेटर यूज़ केस के लिए बेहतर है। मैं त्वरित वेब सर्च के लिए ChatGPT टैब रखता हूं लेकिन इस पर बिल्ड नहीं करता। **Webflow** — अपनी साइट को Astro + Cloudflare Pages पर मूव किया। ज़्यादा कंट्रोल, बेहतर परफॉर्मेंस, बिल्ड प्रोसेस जिसे मैं स्क्रिप्ट कर सकता हूं। **Grammarly** — Claude वो सब करता है जो Grammarly करता है और मेरी आवाज़ को बेहतर रखता है। ## ऑपरेटर का निष्कर्ष ऊपर दिए गए पांच टूल्स न सबसे नए हैं और न सबसे ज़्यादा चर्चित। ये वो हैं जो दो अलग-अलग बिजनेस में दैनिक प्रोडक्शन उपयोग के तहत टिके रहे। अपने स्टैक में कोई नया टूल जोड़ने से पहले पूछें: इन पांच में से कौन यह काम कर सकता है? आप हैरान होंगे कितनी बार जवाब आता है "उनमें से एक पहले से कर सकता है।" --- ## आपका AI एजेंट प्रोडक्शन में बार-बार क्यों विफल होता है (और इसे कैसे ठीक करें) Source: https://alejandrorioja.com/hi/why-your-ai-agent-keeps-failing-in-production-and-how-to-fix-it/ Published: 2026-06-06 Updated: 2026-06-06 Tags: AI Agents TL;DR: अधिकांश प्रोडक्शन एजेंट विफलताएं पांच कारणों से होती हैं: एज केस को हैंडल न करने वाले भंगुर प्रॉम्प्ट, क्षणिक API एरर के लिए रिट्राई लॉजिक की कमी, क्या टूट रहा है यह देखने के लिए ऑब्जर्वेबिलिटी नहीं, कोई एग्जिट कंडीशन न होने वाले रनअवे लूप, और पर्याप्त अस्पष्ट टूल डेफिनेशन जिससे मॉडल गलत को चुनता है। सभी पांच मॉडल या फ्रेमवर्क बदले बिना ठीक करने योग्य हैं। ## विषय सूची _जून 2026 में अपडेट किया गया।_ **TL;DR:** अधिकांश प्रोडक्शन एजेंट विफलताएं पांच कारणों से होती हैं: एज केस को हैंडल न करने वाले भंगुर प्रॉम्प्ट, क्षणिक API एरर के लिए रिट्राई लॉजिक की कमी, क्या टूट रहा है यह देखने के लिए ऑब्जर्वेबिलिटी नहीं, कोई एग्जिट कंडीशन न होने वाले रनअवे लूप, और पर्याप्त अस्पष्ट टूल डेफिनेशन जिससे मॉडल गलत को चुनता है। सभी पांच मॉडल या फ्रेमवर्क बदले बिना ठीक करने योग्य हैं। **[ऑपरेटर की नज़र]** मेरे पास प्रोडक्शन में 30+ एजेंट हैं। मुझे ये सभी विफलताएं हुई हैं। जिन्होंने सबसे ज़्यादा समय जलाया वे विदेशी नहीं थे — वे उबाऊ इन्फ्रास्ट्रक्चर विफलताएं थीं जो मुझे लगती थीं कि मैंने संभाल ली हैं। ## विफलता 1: एज केस इनपुट पर टूटने वाले भंगुर प्रॉम्प्ट आपके टेस्ट केस पर काम करने वाला प्रॉम्प्ट उन इनपुट पर विफल होगा जिनकी आपने उम्मीद नहीं की थी। यह मॉडल लिमिटेशन नहीं है — यह इंस्ट्रक्शन लेखन समस्या है। **लक्षण:** एजेंट बकवास आउटपुट उत्पन्न करता है, गलत टूल कॉल करता है, या जब इनपुट थोड़ा अलग होता है तो मलफॉर्म्ड JSON आउटपुट करता है। **मूल कारण:** आपका सिस्टम प्रॉम्प्ट केवल हैप्पी पाथ का वर्णन करता है। यह मॉडल को नहीं बताता कि डेटा गायब, मलफॉर्म्ड, या अस्पष्ट होने पर क्या करना है। **सुधार:** अपने सिस्टम प्रॉम्प्ट में स्पष्ट एज केस हैंडलिंग जोड़ें: ``` If the input data is missing a required field, return: { "status": "error", "reason": "missing_field", "field": "" } Do NOT attempt to infer or hallucinate missing values. If you are uncertain which tool to call, call no tool and return: { "status": "clarification_needed", "question": "..." } ``` मॉडल एज केस के लिए स्पष्ट निर्देशों का विश्वसनीय रूप से पालन करता है। गलती यह मानना है कि यह गंदे केस को संभालने के लिए हैप्पी-पाथ निर्देशों को सामान्यीकृत करेगा। ## विफलता 2: क्षणिक API एरर के लिए कोई रिट्राई लॉजिक नहीं आपका एजेंट जो भी बाहरी API कॉल करता है वह किसी न किसी समय विफल होगा। Claude API, Meta Graph API, आपका डेटाबेस — सभी 5xx एरर लौटाते हैं, टाइमआउट होते हैं, या रेट-लिमिट होते हैं। अगर आपके एजेंट में रिट्राई लॉजिक नहीं है, तो एक क्षणिक एरर पूरे रन को मार देता है। **लक्षण:** एजेंट रन अलग-अलग चरणों में बेतरतीब ढंग से विफल होते हैं। लॉग 503 या 429 दिखाते हैं, कोई फॉलो-अप प्रयास नहीं। **सुधार:** प्रत्येक बाहरी कॉल को एक्सपोनेंशियल-बैकऑफ रिट्राई में लपेटें: ```typescript async function withRetry(fn: () => Promise, retries = 3, baseDelayMs = 500): Promise { for (let attempt = 0; attempt <= retries; attempt++) { try { return await fn(); } catch (err: any) { const isTransient = err.status === 429 || err.status >= 500 || err.code === "ECONNRESET"; if (!isTransient || attempt === retries) throw err; const delay = baseDelayMs * Math.pow(2, attempt) + Math.random() * 100; await new Promise((r) => setTimeout(r, delay)); } } throw new Error("unreachable"); } // Usage const result = await withRetry(() => client.messages.create({ ... })); ``` एक्सपोनेंशियल बैकऑफ के साथ तीन रिट्राई ~99% क्षणिक विफलताओं को हैंडल करता है। इसे हर बाहरी कॉल में जोड़ें और आपकी आधी यादृच्छिक विफलताएं गायब हो जाएंगी। ## विफलता 3: कोई ऑब्जर्वेबिलिटी नहीं — आप नहीं देख सकते कि क्या टूट रहा है यह प्रोडक्शन में सबसे आम विफलता मोड है और सबसे अधिक समय डिबग करने में लगाने वाला: एजेंट चुपचाप विफल होता है या गलत आउटपुट देता है, और आपको पता नहीं होता कि चेन में कहाँ गलत हुआ। **लक्षण:** आप जानते हैं कि कुछ गड़बड़ है लेकिन चरण की पहचान नहीं कर सकते। आप `console.log` स्टेटमेंट जोड़ते हैं और पुनः उत्पन्न करने की कोशिश में मैन्युअल रूप से फिर से चलाते हैं। **सुधार:** प्रत्येक चरण पर संरचित लॉगिंग, एक रन ID के साथ जो पूरे एग्जीक्यूशन को ट्रेस करता है: ```typescript function createLogger(runId: string, agentName: string) { return { step: (step: string, data: object) => console.log(JSON.stringify({ runId, agent: agentName, step, ts: new Date().toISOString(), ...data })), error: (step: string, err: unknown) => console.error(JSON.stringify({ runId, agent: agentName, step, error: String(err), ts: new Date().toISOString() })), }; } const log = createLogger(crypto.randomUUID(), "newsletter-agent"); log.step("fetch_topic", { topicId: topic.id, topic: topic.name }); // ... do work ... log.step("draft_complete", { subject: draft.subject, wordCount: draft.body.split(" ").length }); ``` अगर आप Cloudflare Workers पर हैं, तो ये लॉग Logpush या Workers Tail में जाते हैं। अगर स्थानीय रूप से या VPS पर चल रहे हैं, तो एक लॉग एग्रीगेटर में पाइप करें। संरचित JSON का मतलब है कि आप `runId` द्वारा फ़िल्टर करके देख सकते हैं कि एकल रन में बिल्कुल क्या हुआ। ## विफलता 4: बिना एग्जिट कंडीशन के रनअवे लूप एजेंटिक लूप — जहां मॉडल टूल कॉल करता है और कंडीशन पूरी होने तक इटरेट करता है — हमेशा चल सकते हैं अगर वह कंडीशन कभी पूरी नहीं होती या मॉडल इसे गलत पहचानता है। **लक्षण:** टाइमआउट से पहले एजेंट API लागत में सैकड़ों डॉलर खर्च करता है। या यह बिना कोई प्रगति किए बार-बार एक ही टूल कॉल चलाता है। **सुधार:** हमेशा एक हार्ड इटरेशन कैप और प्रगति जांच रखें: ```typescript const MAX_ITERATIONS = 10; let iterations = 0; let lastToolCallName = ""; let sameToolCallCount = 0; while (true) { iterations++; if (iterations > MAX_ITERATIONS) { log.error("loop", { reason: "exceeded_max_iterations" }); break; } const response = await client.messages.create({ ... }); // Detect stuck loops: same tool called 3x in a row const toolCall = response.content.find(b => b.type === "tool_use"); if (toolCall?.name === lastToolCallName) { sameToolCallCount++; if (sameToolCallCount >= 3) { log.error("loop", { reason: "stuck_loop", tool: toolCall.name }); break; } } else { sameToolCallCount = 0; lastToolCallName = toolCall?.name ?? ""; } if (response.stop_reason === "end_turn") break; } ``` यह "बहुत लंबे समय तक चला" और "एक ही जगह घूमता रहा" दोनों विफलता मोड को पकड़ता है। कैप हैप्पी पाथ के लिए पर्याप्त उदार होनी चाहिए लेकिन ब्लास्ट रेडियस सीमित करने के लिए पर्याप्त तंग। ## विफलता 5: अस्पष्ट टूल डेफिनेशन जिसे मॉडल गलत हल करता है अगर आप मॉडल को ओवरलैपिंग डिस्क्रिप्शन वाले दो टूल देते हैं, तो यह कभी-कभी गलत को कॉल करेगा। यह विशेष रूप से `search_database` बनाम `get_record` या `send_email` बनाम `create_draft` जैसे टूल के साथ सामान्य है। **लक्षण:** मॉडल टूल की सही श्रेणी को कॉल करता है लेकिन गलत विशिष्ट को चुनता है। या यह गलत संदर्भ में टूल कॉल करता है (जब केवल पढ़ना उचित था तब राइट टूल का उपयोग करना)। **सुधार:** टूल डिस्क्रिप्शन को परस्पर अनन्य बनाएं और स्पष्ट रूप से "कब इसका उपयोग न करें" जोड़ें: ```typescript const tools = [ { name: "get_subscriber", description: "Fetch a single subscriber record by email. Use ONLY when you have a specific email address. Do NOT use for searching or listing subscribers.", input_schema: { ... } }, { name: "search_subscribers", description: "Search subscribers by tag, segment, or status. Use when you need to find subscribers matching a criteria — NOT when you have a specific email address.", input_schema: { ... } } ]; ``` "X होने पर उपयोग न करें" क्लॉज वह हिस्सा है जिसे अधिकांश लोग छोड़ देते हैं। यह सबसे महत्वपूर्ण हिस्सा है। मॉडल सकारात्मक डिस्क्रिप्शन से अनुमान लगाने की तुलना में स्पष्ट नकारात्मक बाधाओं का पालन करने में बेहतर है। ## एक और बात: खराब इनपुट पर अपने एजेंट का परीक्षण करें अधिकांश एजेंट केवल साफ, हैप्पी-पाथ इनपुट पर परीक्षण किए जाते हैं। प्रोडक्शन में गंदे इनपुट होते हैं: खाली स्ट्रिंग, null फ़ील्ड, Unicode एज केस, API रिस्पॉन्स जो 200 लौटाते हैं लेकिन अप्रत्याशित स्कीमा के साथ। एक टेस्ट सूट जोड़ें जो स्पष्ट रूप से परीक्षण करे: - खाली या null इनपुट - अधिकतम अपेक्षित लंबाई पर इनपुट - विशेष अक्षर या गैर-ASCII टेक्स्ट वाले इनपुट - बाहरी API अप्रत्याशित रिस्पॉन्स शेप लौटाते हैं अगर आपका एजेंट इनमें से किसी पर टूटता है, तो इसे लाइव होने से पहले ठीक करें। प्रोडक्शन वातावरण आपके द्वारा की गई हर धारणा को खोजेगा। ## ऑपरेटर का निष्कर्ष प्रोडक्शन में अधिकांश एजेंट विफलताएं इन्फ्रास्ट्रक्चर समस्याएं हैं जो मॉडल समस्याओं के रूप में छुपी हैं। मॉडल स्विच करने से पहले, अपने प्रॉम्प्ट में रिट्राई, संरचित लॉगिंग, लूप कैप और स्पष्ट एज केस हैंडलिंग जोड़ें। अस्पष्ट टूल डेफिनेशन ठीक करें। फिर खराब इनपुट पर टेस्ट करें। मॉडल को दोष देने से पहले यह सब करें — मेरे अनुभव में, मॉडल आमतौर पर बदलने की ज़रूरत वाली आखिरी चीज़ है। --- ## 15 मिनट में अपना पहला AI एजेंट कैसे बनाएं Source: https://alejandrorioja.com/hi/how-to-build-your-first-ai-agent-in-15-minutes/ Published: 2026-06-02 Updated: 2026-06-02 Tags: AI Agents TL;DR: आपको किसी फ्रेमवर्क, कोर्स या पीएचडी की ज़रूरत नहीं है। आपको चाहिए Node.js, Anthropic SDK, और 25 लाइनें TypeScript की। यह ट्यूटोरियल एक असली, काम करने वाला एजेंट बनाता है — एक संरचित कंटेंट सारांशकर्ता जिसे आप उसी सेशन में Cloudflare पर डिप्लॉय कर सकते हैं। एकमात्र पूर्वापेक्षा है एक मुफ़्त API की। ## विषय-सूची _जून 2026 में अपडेटेड।_ **TL;DR:** आपको किसी फ्रेमवर्क, कोर्स या पीएचडी की ज़रूरत नहीं है। आपको चाहिए Node.js, Anthropic SDK, और 25 लाइनें TypeScript की। यह ट्यूटोरियल एक असली, काम करने वाला एजेंट बनाता है — एक संरचित कंटेंट सारांशकर्ता जिसे आप उसी सेशन में Cloudflare पर डिप्लॉय कर सकते हैं। एकमात्र पूर्वापेक्षा है एक मुफ़्त API की। **[ऑपरेटर का नज़रिया]** AI से ऑटोमेट करना चाहने वाले संस्थापकों से मैं सबसे आम जो बात सुनता हूँ वह है "मुझे पहले और सीखना होगा"। नहीं, ऐसा नहीं है। एजेंट पैटर्न सरल है, और इसे समझने का सबसे तेज़ तरीका है एक बनाना। अगर मैं आज शून्य से शुरू करता तो जो सटीक रास्ता अपनाता, वह यहाँ है। ## क्यों ज़्यादातर "AI एजेंट बनाएं" ट्यूटोरियल आपको निराश करते हैं वे या तो Python का इस्तेमाल करते हैं (ML इंजीनियरों के लिए ठीक, बाकी सबके लिए रुकावट), या असली कोड को LangChain जैसे फ्रेमवर्क के पीछे छिपा देते हैं, या कुछ इतना अमूर्त बना देते हैं कि उसे आपके असली काम से जोड़ा ही न जा सके। यह ट्यूटोरियल तीन चीज़ें अलग तरह से करता है: 1. **केवल TypeScript** — अगर आपने कभी JavaScript लिखा है, तो आप इसे फ़ॉलो कर सकते हैं 2. **कोई फ्रेमवर्क नहीं** — आप कोड की हर वह लाइन देखेंगे जो मॉडल को छूती है 3. **एक उपयोगी आउटपुट** — आप एक संरचित सारांशकर्ता बनाएंगे जिसे आप वाकई ग्राहक ईमेल, समीक्षाओं या मीटिंग नोट्स पर इस्तेमाल कर सकते हैं ## आप क्या बना रहे हैं एक **कंटेंट सारांशकर्ता एजेंट**: कोई भी टेक्स्ट ब्लॉक पेस्ट करें, और एक सुसंगत प्रारूप में संरचित सारांश वापस पाएं। एक HTTP अनुरोध अंदर, एक साफ़ सारांश बाहर। इसे पहले प्रोजेक्ट के रूप में क्यों: यह पैटर्न — सिस्टम प्रॉम्प्ट + उपयोगकर्ता इनपुट → संरचित आउटपुट — हर उस एजेंट की नींव है जिसे मैं चलाता हूँ। सिस्टम प्रॉम्प्ट बदलिए और आपके पास एक प्रश्न-उत्तरकर्ता, एक टोन पुनर्लेखक, एक वर्गीकरणकर्ता, या एक मसौदा जनरेटर होगा। इसे एक बार सीख लीजिए और आपने वह 80% सीख लिया जो प्रोडक्शन एजेंट असल में करते हैं। ## पूर्वापेक्षाएँ (2 मिनट) - **Node.js 18+** — `node --version` से जाँचें। ज़रूरत हो तो nodejs.org से इंस्टॉल करें। - **एक Anthropic API की** — [Claude](/recommends/claude) पर साइन अप करें, कंसोल से एक की लें। फ्री टियर काम करता है। - एक टर्मिनल और एक टेक्स्ट एडिटर। कोई Docker नहीं। कोई वर्चुअल एनवायरनमेंट नहीं। कुछ भी `pip install` नहीं। ## चरण 1: प्रोजेक्ट बनाएं (2 मिनट) ```bash mkdir my-first-agent && cd my-first-agent npm init -y npm install @anthropic-ai/sdk npm install -D tsx typescript ``` एजेंट को आसानी से चलाने के लिए `package.json` में एक स्क्रिप्ट जोड़ें: ```json { "scripts": { "agent": "tsx agent.ts" } } ``` ## चरण 2: एजेंट लिखें (5 मिनट) `agent.ts` बनाएं और यह पेस्ट करें: ```typescript import Anthropic from "@anthropic-ai/sdk"; const client = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY, }); const SYSTEM_PROMPT = `You are a precise content summarizer. When given any block of text, return a structured summary in this exact format: **One-line summary:** **Key points:** - - - **Action item (if any):** Be specific. No filler. Under 150 words total.`; async function summarize(text: string): Promise { const message = await client.messages.create({ model: "claude-haiku-4-5", max_tokens: 512, system: SYSTEM_PROMPT, messages: [{ role: "user", content: text }], }); const block = message.content[0]; if (block.type !== "text") throw new Error("Unexpected response type"); return block.text; } const sample = ` Hey team — following up on the Q2 review meeting. We agreed to push the launch to July 15th instead of June 30th due to the payment integration delay. Marketing needs the new landing page copy by June 20th or we can't start the email campaign. Budget for the launch campaign is confirmed at $8,000. Please confirm receipt. `; const result = await summarize(sample); console.log(result); ``` ## चरण 3: इसे चलाएं (1 मिनट) ```bash ANTHROPIC_API_KEY=sk-ant-... npm run agent ``` अपेक्षित आउटपुट: ``` **One-line summary:** Launch pushed to July 15th due to payment delay; landing page copy needed by June 20th to unblock email campaign. **Key points:** - Launch date moved from June 30th to July 15th - Landing page copy deadline: June 20th (blocks email campaign) - Campaign budget confirmed at $8,000 **Action item (if any):** Confirm receipt and deliver landing page copy by June 20th. ``` यह एक काम करने वाला AI एजेंट है। असली इनपुट, कस्टम सिस्टम प्रॉम्प्ट, संरचित आउटपुट। पूरी चीज़ 30 लाइनों का कोड है। ## चरण 4: इसे अपने उपयोग के लिए अनुकूलित करें सिस्टम प्रॉम्प्ट ही एकमात्र चीज़ है जो इस एजेंट को आपका बनाती है। यहाँ तीन तुरंत बदलकर इस्तेमाल किए जा सकने वाले विकल्प हैं: **ग्राहक समीक्षा वर्गीकरणकर्ता:** ```text Classify this customer review as POSITIVE, NEGATIVE, or MIXED. Then extract the main complaint or praise in one sentence. Format: SENTIMENT: