Claude Code Routines बनाम GitHub Actions: एजेंट्स को कहाँ शेड्यूल करें

Claude Code Routines, जिन्हें Anthropic ने अप्रैल 2026 में लॉन्च किया, एक सहेजा हुआ Claude Code कॉन्फ़िगरेशन हैं: एक प्रॉम्प्ट, एक या अधिक रिपॉजिटरीज़, और कनेक्टर्स, एक बार पैकेज किए गए और Anthropic द्वारा प्रबंधित क्लाउड इंफ्रास्ट्रक्चर पर स्वचालित रूप से चलाए जाते हैं। आधिकारिक दस्तावेज़ तीन ट्रिगर प्रकार दिखाते हैं: शेड्यूल्ड कैडेंस, API (बियरर टोकन के साथ HTTP POST), और GitHub इवेंट्स। GitHub Actions इसके विपरीत, आप जो स्क्रिप्ट्स लिखते हैं उन्हें GitHub-होस्टेड रनर्स पर निष्पादित करते हैं। दोनों एक शेड्यूल पर AI एजेंट्स चला सकते हैं। वे एक जैसी चीज़ नहीं हैं, और गलत को चुनने से आपको पैसा या YAML-से जूझने के घंटे खर्च होते हैं। यह पोस्ट निर्णय को दिखाती है, ब्लॉग कतार वर्कर को चलाती है, और विफलता पुनरुद्धार को कवर करती है।

क्लाउड Routines, डेस्कटॉप, सेशन लूप्स, या Actions चुनें

चार होस्टिंग विकल्प मौजूद हैं। वे परस्पर विनिमेय नहीं हैं।

क्लाउड Routines Anthropic के इंफ्रास्ट्रक्चर पर निष्पादित होते हैं, चाहे आपका लैपटॉप चालू हो या नहीं। दस्तावेज़ के अनुसार, प्रत्येक रूटीन एक शेड्यूल किए गए ट्रिगर, एक API ट्रिगर, या एक GitHub इवेंट ट्रिगर ले सकता है, और आप सभी तीन को एक रूटीन पर संयोजित कर सकते हैं। व्यापार-बंद: हर निष्पादन एक ताज़ा क्लोन करता है, इसलिए स्थानीय फ़ाइलें कभी उपलब्ध नहीं होती हैं।

डेस्कटॉप शेड्यूल किए गए कार्य आपकी मशीन पर चलते हैं। उनके पास आपकी स्थानीय फ़ाइल सिस्टम, स्थानीय डेटाबेस, और .env फ़ाइलों तक पूर्ण पहुंच है। यदि मशीन बंद है, तो कार्य नहीं चलता। बस इतना ही।

सेशन-स्कोप्ड शेड्यूलिंग (CronCreate, CronList, CronDelete टूल्स) केवल एक खुले CLI सेशन के अंदर संचालित होती है। ये सेशन शेड्यूलिंग टूल्स हैं, क्लाउड routines API नहीं। जब सेशन समाप्त होता है तो ये गायब हो जाते हैं।

GitHub Actions जिसमें एक cron ट्रिगर है, एक वर्कफ़्लो YAML फ़ाइल है जो GitHub एक होस्टेड रनर पर निष्पादित करता है। सार्वजनिक रिपॉजिटरीज़ के लिए मुफ़्त, निजी लोगों के लिए सस्ता, नियतात्मक, और आपके कोडबेस के साथ गहराई से एकीकृत। यदि आप पहले से GitHub में नहीं हैं तो ओवरहेड वास्तविक है, लेकिन जो डेवलपर्स करते हैं उनके लिए, यह न्यूनतम है।

तो: आप कैसे चुनते हैं?

1. कार्य चलता है, चाहे आपकी मशीन चालू हो या नहीं, और इसे वास्तविक AI तर्क की आवश्यकता है (सारांश, ड्राफ्टिंग, ट्रायजिंग)? क्लाउड Routine।
2. कार्य को आपकी स्थानीय .env, एक स्थानीय डेटाबेस, या स्थानीय टूलिंग की आवश्यकता है? डेस्कटॉप शेड्यूल किया गया कार्य।
3. कार्य एक CI/CD पाइपलाइन है, PR इवेंट हैंडलर, या एक नियतात्मक स्क्रिप्ट जो एक API को कॉल करती है और Slack पर पोस्ट करती है? GitHub Actions, संभवतः एक छोटी Python स्क्रिप्ट के साथ और कोई LLM बिल्कुल नहीं।
4. कार्य खोजपूर्ण है और एक एकल सेशन के अंदर रहता है जो आप पहले से चला रहे हैं? सेशन लूप।

AI Magicx की व्याख्या इसे स्पष्ट रूप से प्रस्तुत करती है: यदि आपका रूटीन "एक API को कॉल करें, रूपांतरित करें, Slack पर पोस्ट करें," तो 10-लाइन Python स्क्रिप्ट के साथ GitHub Actions सस्ता और सरल है। Routines सही विकल्प बन जाते हैं जब कार्य वास्तव में Claude के तर्क से लाभान्वित होता है: यह तय करना कि क्या रिपोर्ट करना है, एक आख्यान लिखना, गुणवत्ता की समीक्षा करना।

होस्ट द्वारा दृढ़ता, स्थानीय फ़ाइलें, और क्रेडेंशियल्स

यह वह जगह है जहां ऑपरेटर्स को नुकसान होता है। नीचे दी गई तालिका आधिकारिक दस्तावेज़ों और कम्युनिटी रिसर्च से जानकारी का उपयोग करती है, न कि दावा किए गए टेस्ट परिणामों से।

Shareuhack के 2026 राइट-अप में एक विशिष्ट समस्या का ध्यान दिलाया गया है जो उद्धृत करने लायक है:

"हर Cloud Routine निष्पादन Anthropic के क्लाउड एनवायरनमेंट में ताज़ा क्लोन करता है, यह आपकी स्थानीय .env.local, स्थानीय डेटाबेस, या अन्य स्थानीय स्टेट तक नहीं पहुंच सकता।"

और एक और: क्लाउड रूटीन्स में नेटवर्क एक्सेस डिफ़ॉल्ट रूप से "trusted" पर सेट है, जिसे कुछ API सीधे अस्वीकार करते हैं। अगर आप ClickUp या किसी ऐसे API को कॉल कर रहे हैं जो trusted-mode रिक्वेस्ट्स को ड्रॉप करता है, तो रूटीन की एनवायरनमेंट सेटिंग्स में नेटवर्क एक्सेस को "full" में बदलें। इसमें एक छोटा सुरक्षा ट्रेड-ऑफ है, इसलिए इसे अपने रिपो की संवेदनशीलता के खिलाफ तौलें।

GitHub Actions के लिए, सीक्रेट्स रिपोजिटरी की Secrets सेटिंग्स में रहते हैं और रनटाइम पर एनवायरनमेंट वेरिएबल्स के रूप में इंजेक्ट किए जाते हैं। anthropics/claude-code-action@v1 एक्शन, जो Claude Agent SDK पर बना है, उन्हें स्वचालित रूप से उठाता है। आप --model, --max-turns, और --allowedTools को claude_args इनपुट के माध्यम से पास करते हैं ताकि एजेंट को वास्तव में क्या कर सकते हैं इसे नियंत्रित किया जा सके।

वर्तमान ब्लॉग क्यू वर्कर को पढ़ें

ब्लॉग क्यू वर्कर एक रूटीन (या समकक्ष शेड्यूल्ड जॉब) है जो क्यू से एक पोस्ट लेता है, कंटेंट जेनरेट करता है, और इसे पूर्ण के रूप में चिह्नित करता है। यहां संरचना है जैसी कि वर्तमान में है, इस बारे में स्पष्ट चेतावनियों के साथ कि कोड वास्तव में क्या करता है बनाम आप क्या मान सकते हैं।

सशर्त दावा: कार्यकर्ता यह जांचता है कि क्या कोई पोस्ट पहले से दावा की जा चुकी है इससे पहले कि वह इसे उठाए। यह दोनों निष्पादनों को एक ही समय में एक ही आइटम को लेने से रोकता है, कम से कम सामान्य परिस्थिति में। वर्तमान कोड में जो नहीं है वह है stale-claim recovery। अगर कोई कार्यकर्ता चलते समय मर जाता है और एक पोस्ट "in progress" के रूप में चिह्नित होती है, तो वह पोस्ट तब तक दावा किए हुए रहती है जब तक कोई इसे मैन्युअली रीसेट न करे। इसे exactly-once delivery के रूप में या प्रति दिन एक पोस्ट की गारंटी के रूप में वर्णित न करें; दोनों दावे कोड द्वारा समर्थित होने से बहुत आगे जाते हैं।

कार्यकर्ता आरेख कुछ इस तरह दिखता है:

1. Queue को fetch करें, status = queued के लिए filter करें
2. पहली उपलब्ध पोस्ट को दावा करें (status = in_progress सेट करें, एक timestamp लिखें)
3. दावा की गई पोस्ट की मेटाडेटा के विरुद्ध generation prompt चलाएं
4. सफलता पर: status = published सेट करें, output path लिखें
5. विफलता पर: retry_count को बढ़ाएं, status = queued रीसेट करें (यदि retries बाकी हैं) या status = failed सेट करें

Step 5 वह जगह है जहां अधिकांश टीमें कम निवेश करती हैं। Retry logic को routine prompt में या wrapper script में रहना चाहिए, क्योंकि cloud infrastructure स्वयं एक routine को फिर से नहीं चलाता है जो एक त्रुटि के साथ बाहर निकल जाता है।

यदि आप इस तरह की content pipelines बना रहे हैं और चाहते हैं कि agentic layer आपके लिए संभाली जाए, तो agentic engineering में जो काम हम करते हैं वह बिल्कुल इसी pattern को कवर करता है।

Due Jobs को Schedule करें और Retries को संभालें

CLI के माध्यम से एक routine को schedule करने के लिए Claude Code v2.1.225 या बाद का संस्करण आवश्यक है। v2.1.211 से पहले, CLI ने बिना schedule trigger वाले routines के लिए एक phantom next-run time (वर्ष 1) की रिपोर्ट दी। यदि आप पुरानी logs पढ़ रहे हैं तो यह जानने लायक है।

केवल API या GitHub event triggers वाले एक routine के पास कोई next run time नहीं है। CLI कुछ नहीं दिखाता। यह सही व्यवहार है, कोई bug नहीं।

Retry handling के लिए, आपके पास दो विकल्प हैं:

• Prompt के अंदर retry करें। Prompt को failing step को N बार तक फिर से प्रयास करने के लिए लिखें इससे पहले कि job को failed के रूप में चिह्नित करें। Claude का reasoning एक transient network error और एक genuine content problem के बीच अंतर कर सकता है।
• एक अलग scheduled routine के माध्यम से retry करें। एक lightweight "requeue" routine प्रति घंटा चलता है, उन posts को स्कैन करता है जहां status = queued और retry_count < 3, और main worker को इसके API trigger के माध्यम से फिर से ट्रिगर करता है (per-routine endpoint पर एक bearer token के साथ एक POST)।

दूसरा pattern scale पर अधिक깔끔है। यह retry policy को generation prompt से अलग करता है, और आप मुख्य routine को स्पर्श किए बिना retry limits को समायोजित कर सकते हैं।

Daily run caps और shared subscription usage टीमों के लिए एक वास्तविक constraint हैं, जैसा कि Arcade के enterprise write-up में बताया गया है। उनकी अनुशंसा: काम को एक दैनिक "meta-orchestrator" routine में batch करें और real-time triggers को केवल high-priority events के लिए रक्षित करें।

content pipeline के SEO keyword retrieval पक्ष के लिए, DataForSEO + Claude Code पर जो automation stack हमने प्रलेखित किया है वह अलग से इसे संभालता है और queue schema को डिज़ाइन करने से पहले पढ़ने लायक है।

Stuck Claims को Detect करें और Published Output को Verify करें

Stale claims queue-based pipelines का साइलेंट killer हैं। एक post जो छह घंटे के लिए in_progress में है वह लगभग निश्चित रूप से stuck है, चल नहीं रहा है।

एक detection routine जितना सरल हो सकता है:

• उन posts के लिए query करें जहां status = in_progress और claimed_at < now() - 2 hours
• उन्हें status = queued पर रीसेट करें, worker identifier को शून्य करें, और रीसेट को लॉग करें
• यदि रीसेट काउंट एक threshold से अधिक हो जाए तो Slack या webhook के माध्यम से alert भेजें

इसे मुख्य worker में न मिलाकर एक अलग कम-आवृत्ति routine (हर दो घंटे ठीक है) के रूप में चलाएं। Separation of concerns यहाँ मायने रखता है: मुख्य worker को अपने बाद की सफाई की जिम्मेदारी नहीं लेनी चाहिए।

प्रकाशित output को verify करना एक अलग समस्या है। "Published" एक status flag के रूप में मतलब है database लिखा गया। इसका मतलब यह नहीं है कि पोस्ट साइट पर सही दिखी, readability check पास किया, या indexed हुई। एक verification step को चाहिए:

• लाइव URL को fetch करें और confirm करें कि यह 200 return करता है
• word count या एक lightweight quality signal को एक परिभाषित threshold (अपना स्वयं का नंबर चुनें और इसे एक universal standard नहीं, team heuristic के रूप में label करें) के विरुद्ध check करें
• यदि check विफल हो, status को queued पर revert करें, एक incremented retry_count के साथ और एक verification_failed flag लगाएं

AI Content Humanizer Pipeline में जिस post-publish verification pass का वर्णन किया गया है वह समान है और यदि आप उस layer को build कर रहे हैं तो cross-reference के लायक है।

Operating Cost और Ownership

यह वह जगह है जहाँ "routines simpler हैं" narrative को friction का सामना करना पड़ता है।

Cloud Routines, Anthropic के infrastructure पर चलते हैं और Claude Code session limits को उसी तरह consume करते हैं जैसे एक interactive session करता है। research preview इसे explicit बनाता है: routines अपनी limits को drain करते हैं। एक छोटे indie operator के लिए जो एक दिन में तीन या चार routines चला रहा हो, वह शायद ठीक है। एक team के लिए जो 20+ daily runs को batch कर रहा हो, आप cap से टकराएंगे और architecture around करना होगा।

GitHub Actions public repos के लिए मुक्त है और private वाले के लिए प्रति मिनट priced है। एक Claude Code agent run जो anthropics/claude-code-action@v1 के माध्यम से Actions के अंदर होता है, फिर भी API tokens consume करता है (आपकी Anthropic API rate पर billed), लेकिन आप runner, timeout, और retry logic को पूरी तरह नियंत्रित करते हैं। वह ownership ही बात है।

practice में ownership split:

• Routines own करते हैं: judgment-heavy tasks जिन्हें Claude के reasoning की जरूरत है, tasks जो unattended होने के साथ no infrastructure overhead से चलने चाहिए, GitHub-triggered PR reviews, और Sentry/log triage।
• GitHub Actions own करते हैं: CI/CD pipelines, PR event handling और installation flows, deterministic build-test-deploy sequences, और कोई भी task जहाँ एक 10-line Python script genuinely काम करता है।

न तो एक दूसरे को replace करता है। Shareuhack write-up इसे अच्छी तरह frame करता है: "The optimal combination lets GitHub Actions handle CI/CD while Routines handle the reasoning-intensive parts." वह framing सही है, और यह decision boundary है जिसे bookmark करना लायक है।

FAQ

क्या एक Cloud Routine मेरे repository में वापस write कर सकता है?

हाँ। Routines एक या अधिक repositories से connect होते हैं, और वे connected repo के माध्यम से commits को push और pull requests को open कर सकते हैं। जो वे नहीं कर सकते वह यह है कि files को access करें जो केवल आपकी local machine पर मौजूद हों। जो कुछ भी routine को चाहिए वह repo में होना चाहिए या routine के cloud environment settings में एक environment variable के रूप में configured होना चाहिए।

यदि एक Cloud Routine किसी run के बीच में rate limit से टकराता है तो क्या होता है?

Routine itself rate limit errors पर automatically retry नहीं करता। यदि यह एक error के साथ exit होता है, तो यह अगले scheduled run तक या जब तक आप इसे manually API endpoint के माध्यम से trigger न करें तब तक failed रहता है। retry logic को prompt में build करना (एक rate limit response detect करें, wait करें, re-attempt करें) या एक अलग requeue routine का उपयोग करना दोनों reasonable mitigations हैं।

क्या GitHub App installation CLI web-setup command से अलग है?

हाँ, और यह लोगों को confuse करता है। CLI में /web-setup को चलाना routine को clone access देता है लेकिन GitHub App को install नहीं करता। GitHub event triggers के लिए webhook delivery को अलग GitHub App installation की जरूरत है। Routine setup flow आपको इसके माध्यम से prompt करता है, लेकिन दोनों steps अलग हैं।

क्या GitHub event triggers Routines में research preview के दौरान rate limits के अधीन हैं?

आधिकारिक routines documentation के अनुसार, GitHub webhook events research preview के दौरान per-routine और per-account hourly caps के अधीन हैं। Cap से आगे की events उस विंडो के reset होने तक drop कर दी जाती हैं। अगर आप PR activity में तेज़ उछाल की उम्मीद करते हैं तो उसके अनुसार plan करें।

क्या मैं GitHub Actions workflow में `anthropics/claude-code-action` के साथ skills का उपयोग कर सकता हूँ?

हाँ। prompt input `/skill-name` जैसे skill invocations को स्वीकार करता है। action से पहले एक `actions/checkout` step की जरूरत है ताकि .claude/skills/ में skill files runner पर मौजूद हों। Claude Code में skills और commands अलग-अलग concepts हैं; दोनों को आपस में न मिलाने से पहले आधिकारिक skills docs देख लें।

ऊपर सब कुछ से सबसे महत्वपूर्ण सावधानी यह है: Cloud Routines आपकी Claude Code session limits को बिल्कुल उसी तरह consume करते हैं जैसे interactive sessions करते हैं, और मौजूदा queue worker में कोई stale-claim recovery mechanism नहीं है। production में कुछ भी भेजने से पहले दोनों के लिए design करें।