यह विस्तृत गाइड है। पाँच मिनट के संक्षिप्त परिचय के लिए साथी ब्लॉग पोस्ट पढ़ें।
1. शेड्यूल किए गए एजेंट क्यों मायने रखते हैं
कुछ समय पहले तक, कोई AI कोडिंग एजेंट तभी काम करता था जब कोई उस पर नज़र रखे हुए हो। आप टर्मिनल खोलते, उसे टास्क देते, उसकी कार्रवाइयों को मंज़ूरी देते और नतीजा पढ़ते। सेशन बंद करते ही काम रुक जाता था। यह मॉडल खोजपरक काम के लिए ठीक है, लेकिन इंजीनियरिंग का बहुत-सा काम न तो खोजपरक होता है और न ही अत्यावश्यक। वह बार-बार दोहराया जाने वाला होता है: रात भर में आए इश्यू की छँटाई, यह जाँचना कि डॉक्यूमेंटेशन अब भी API से मेल खाता है, हर पुल रिक्वेस्ट को एक ही चेकलिस्ट पर परखना, रिलीज़ विंडो बंद होने से पहले डिप्लॉयमेंट का सत्यापन।
जो टीमें चाहती थीं कि कोई एजेंट यह काम बिना निगरानी के करे, उन्हें सारा ढाँचा खुद बनाना पड़ता था। आम विकल्प थे GitHub Actions में एक cron जॉब, किसी अलमारी में चालू छोड़ी गई एक फ़ालतू मशीन, या Trigger.dev या n8n जैसा कोई वर्कफ़्लो इंजन जिसमें ऊपर से एजेंट कॉल जोड़ दी गई हो। हर तरीका काम करता है, लेकिन हर एक उस चीज़ के इर्द-गिर्द इन्फ़्रास्ट्रक्चर, क्रेडेंशियल, लागत और रखरखाव जोड़ देता है जो असल में बस एक निर्देश है: "यह हर रात करो और बताओ कि क्या मिला।"
Routines यह सारा ढाँचा हटा देते हैं। शेड्यूल, कंप्यूट, रिपॉज़िटरी चेकआउट और ऑडिट ट्रेल — सब कुछ Claude Code के भीतर ही रहता है।
2. रूटीन क्या है
Anthropic रूटीन को एक सहेजे गए Claude Code कॉन्फ़िगरेशन के रूप में परिभाषित करता है। इसके पाँच हिस्से होते हैं:
- प्रॉम्प्ट। वह निर्देश जिसे Claude हर रन पर पूरा करता है। चूँकि सवालों का जवाब देने के लिए कोई मौजूद नहीं होता, इसलिए यह आत्मनिर्भर होना चाहिए और स्पष्ट बताना चाहिए कि "पूरा" होना कैसा दिखता है। मॉडल भी आप यहीं चुनते हैं, और वही मॉडल हर रन में इस्तेमाल होता है।
- रिपॉज़िटरी। एक या अधिक GitHub रिपॉज़िटरी। हर रन की शुरुआत में हर रिपॉज़िटरी नए सिरे से क्लोन होती है, उसकी डिफ़ॉल्ट ब्रांच से, जब तक प्रॉम्प्ट कुछ और न कहे।
- क्लाउड एनवायरनमेंट। यह नेटवर्क एक्सेस, एनवायरनमेंट वेरिएबल और डिपेंडेंसी इंस्टॉल करने वाली एक वैकल्पिक सेटअप स्क्रिप्ट को नियंत्रित करता है। सेटअप का परिणाम कैश होता है, इसलिए वह हर बार दोबारा नहीं चलता।
- कनेक्टर। आपके claude.ai खाते पर मौजूद MCP इंटीग्रेशन, जैसे Slack, Linear या Google Drive, जिनसे रूटीन पढ़ और लिख सकता है।
- ट्रिगर। इनमें से एक या अधिक: शेड्यूल, API और GitHub इवेंट। एक ही रूटीन तीनों को जोड़ सकता है।
हर रन एक पूर्ण Claude Code क्लाउड सेशन होता है। यह शेल कमांड चला सकता है, क्लोन की गई रिपॉज़िटरी में कमिट किए गए स्किल का उपयोग कर सकता है और शामिल किए गए कनेक्टरों के हर टूल को कॉल कर सकता है। कोई परमिशन-मोड चयनकर्ता नहीं है और कुछ भी मंज़ूरी का इंतज़ार नहीं करता। यही स्वायत्तता इसका उद्देश्य है, और इसी वजह से दायरा तय करना अहम है (देखें खंड 8)।
3. तीन प्रकार के ट्रिगर
3.1 शेड्यूल
सबसे सरल ट्रिगर रूटीन को एक पूर्व-निर्धारित अंतराल पर (हर घंटे, रोज़ाना, कार्यदिवसों पर या साप्ताहिक) या भविष्य के किसी एक तय समय पर चलाता है। कुछ बातें जानने लायक हैं:
- स्थानीय समय। आप समय अपने टाइम ज़ोन में दर्ज करते हैं और Claude Code उसे बदल देता है, इसलिए 09:00 का रन आपकी दीवार घड़ी के 09:00 पर ही चलता है, क्लाउड हार्डवेयर चाहे कहीं भी हो। शुरुआती कुछ थर्ड-पार्टी गाइड में कहा गया था कि शेड्यूल केवल UTC में होते हैं। Anthropic का डॉक्यूमेंटेशन इससे अलग बात कहता है।
- ठीक घंटे की शुरुआत से बचें। ठीक घंटे पर शेड्यूल किए गए रन कई मिनट देर से शुरू हो सकते हैं। 09:00 के बजाय 09:07 चुनने से समय ज़्यादा अनुमानित रहता है।
- कस्टम cron। जिन अंतरालों को प्रीसेट कवर नहीं करते, जैसे हर दो घंटे या महीने की पहली तारीख, उनके लिए सबसे नज़दीकी प्रीसेट चुनें और फिर CLI में
/schedule updateचलाकर cron एक्सप्रेशन सेट करें। न्यूनतम अंतराल एक घंटा है; इससे अधिक बार चलने वाली कोई भी सेटिंग अस्वीकार कर दी जाती है। - एक-बार वाले रन। समय को सामान्य भाषा में बताएँ, उदाहरण के लिए
/schedule in 2 weeks, open a cleanup PR that removes the feature flag। सहेजने से पहले Claude सटीक टाइमस्टैम्प की पुष्टि करता है। चलने के बाद रूटीन खुद को निष्क्रिय कर लेता है और उस पर Ran का निशान लग जाता है। एक-बार वाले रन दैनिक रन सीमा में नहीं गिने जाते।
3.2 API
API ट्रिगर रूटीन को उसका अपना HTTPS एंडपॉइंट देता है। कोई भी सिस्टम जो प्रमाणीकृत POST रिक्वेस्ट भेज सकता है, एक रन शुरू कर सकता है: कोई अलर्टिंग टूल, डिप्लॉयमेंट पाइपलाइन या आंतरिक एडमिन पेज। टोकन वेब UI में बनता है, केवल एक बार दिखाया जाता है, सिर्फ़ उसी रूटीन तक सीमित होता है, और इसे कभी भी दोबारा बनाया या रद्द किया जा सकता है।
curl -X POST https://api.anthropic.com/v1/claude_code/routines/<ROUTINE_TRIGGER_ID>/fire \
-H "Authorization: Bearer <ROUTINE_TOKEN>" \
-H "anthropic-beta: experimental-cc-routine-2026-04-01" \
-H "anthropic-version: 2023-06-01" \
-H "Content-Type: application/json" \
-d '{"text": "Error rate on checkout-api above 5% for 10 minutes."}'
रिस्पॉन्स में एक सेशन ID और सेशन URL होता है जिसे खोलकर आप रन को लाइव देख सकते हैं। वैकल्पिक text फ़ील्ड रन-विशिष्ट संदर्भ ले जाता है। सुरक्षा के प्रति सजग टीमों को ध्यान देना चाहिए कि Claude Code इस टेक्स्ट को एक <routine-fire-payload> ब्लॉक में लपेटता है और इसे अविश्वसनीय डेटा के रूप में लेबल करता है। Claude इसके अंदर के निर्देशों का पालन तब तक नहीं करेगा जब तक रूटीन का अपना सहेजा गया प्रॉम्प्ट उसे पेलोड इस्तेमाल करने को न कहे। अगर आपका रूटीन किसी अलर्ट के विवरण पर कार्रवाई के लिए बना है, तो प्रॉम्प्ट में यह स्पष्ट लिखा होना चाहिए, उदाहरण के लिए: "Investigate the alert described in the routine-fire-payload block." इस डिज़ाइन का अर्थ है कि लीक हुए टोकन से कोई रन तो शुरू कर सकता है, लेकिन रूटीन के निर्देश दोबारा नहीं लिख सकता।
एंडपॉइंट एक तारीख-युक्त बीटा हेडर के पीछे है। Anthropic के अनुसार ब्रेकिंग बदलाव नए हेडर संस्करणों के तहत आएँगे, और पिछले दो संस्करण काम करते रहेंगे ताकि कॉल करने वालों को माइग्रेट करने का समय मिल सके।
3.3 GitHub इवेंट
GitHub ट्रिगर किसी कनेक्टेड रिपॉज़िटरी पर मेल खाने वाला इवेंट होने पर हर बार एक नया सेशन शुरू करता है। इसके लिए उस रिपॉज़िटरी पर Claude GitHub App इंस्टॉल होना ज़रूरी है। दो इवेंट श्रेणियाँ समर्थित हैं:
- पुल रिक्वेस्ट: खोला गया, बंद किया गया, असाइन किया गया, लेबल लगाया गया, सिंक्रनाइज़ किया गया और अन्य अपडेट।
- रिलीज़: बनाई गई, प्रकाशित की गई, संपादित की गई या हटाई गई।
फ़िल्टर तय करते हैं कि कौन-से इवेंट गिने जाएँ। आप लेखक, शीर्षक, बॉडी, बेस ब्रांच, हेड ब्रांच, लेबल, ड्राफ़्ट स्थिति और मर्ज स्थिति पर फ़िल्टर कर सकते हैं, इन ऑपरेटरों के साथ: equals, contains, starts with, is one of, is not one of और matches regex। सभी शर्तें पूरी होनी चाहिए। एक आम चूक: matches regex पूरे फ़ील्ड को जाँचता है, इसलिए "hotfix" वाले किसी भी शीर्षक को पकड़ने के लिए आपको .*hotfix.* चाहिए, न कि hotfix।
हर इवेंट अपना स्वतंत्र सेशन बनाता है, इसलिए एक ही पुल रिक्वेस्ट पर दो पुश का मतलब दो रन। प्रीव्यू के दौरान GitHub इवेंट पर प्रति रूटीन और प्रति खाता घंटेवार सीमाएँ भी लागू हैं। सीमा से ऊपर के इवेंट विंडो रीसेट होने तक छोड़ दिए जाते हैं।
4. रूटीन बनाना, चरण दर चरण
आप तीन जगहों से रूटीन बना सकते हैं: वेब पर claude.ai/code/routines, Claude Desktop ऐप के Code टैब का Routines सेक्शन, या CLI। तीनों एक ही खाते में लिखते हैं, इसलिए एक जगह बनाया गया रूटीन बाकी जगहों पर तुरंत दिखाई देता है।
4.1 वेब पर
claude.ai/code/routinesखोलें और New routine चुनें।- इसे नाम दें और प्रॉम्प्ट लिखें। मॉडल चुनें।
- वे रिपॉज़िटरी जोड़ें जिनमें Claude को काम करना है।
- एक क्लाउड एनवायरनमेंट चुनें। Default एनवायरनमेंट में Trusted नेटवर्क एक्सेस होता है, जो आम पैकेज रजिस्ट्री, क्लाउड प्रोवाइडर API और डेवलपमेंट डोमेन की अनुमति देता है। अगर रूटीन को आपकी अपनी सेवाओं तक पहुँचना है, तो पहले एनवायरनमेंट के अनुमत डोमेन समायोजित करें।
- एक या अधिक ट्रिगर चुनें। API ट्रिगर के लिए पहले रूटीन सहेजें; URL और टोकन उसके बाद बनते हैं।
- कनेक्टरों की समीक्षा करें। आपके सभी जुड़े हुए कनेक्टर डिफ़ॉल्ट रूप से शामिल होते हैं, और Claude बिना पूछे उनके हर टूल का उपयोग कर सकता है, लिखने वाली कार्रवाइयों सहित। जो कुछ भी टास्क के लिए ज़रूरी न हो, उसे हटा दें।
- Create चुनें, फिर शेड्यूल पर निर्भर होने से पहले टेस्ट के लिए Run now चुनें।
4.2 CLI से
किसी भी लोकल Claude Code सेशन में, /schedule (उपनाम /routines) बातचीत के ज़रिए एक शेड्यूल्ड रूटीन बनाता है। Claude अंतराल, रिपॉज़िटरी और प्रॉम्प्ट के बारे में पूछता है, फिर उसे आपके खाते में सहेज देता है।
/schedule daily PR review at 9am
/schedule tomorrow at 9am, summarise yesterday's merged PRs
/schedule list
/schedule update
/schedule run
/schedule why did my nightly review do nothing this morning?
आख़िरी उदाहरण ख़ास तौर पर उपयोगी है। Claude रूटीन के हाल के रन सूचीबद्ध करता है, संबंधित लॉग पढ़ता है और बताता है कि क्या हुआ, टूल त्रुटियों और अनुमति अस्वीकृतियों सहित। हाल के CLI संस्करण GitHub App इंस्टॉल होने के बाद बातचीत के ज़रिए GitHub ट्रिगर भी जोड़ सकते हैं। हालाँकि, API टोकन केवल वेब पर ही बनाए या रद्द किए जा सकते हैं।
अगर /schedule पहचाना नहीं जाता, तो कारण लगभग हमेशा प्रमाणीकरण होता है। Routines के लिए claude.ai सब्सक्रिप्शन लॉगिन चाहिए। Console API key, ANTHROPIC_API_KEY एनवायरनमेंट वेरिएबल, या Amazon Bedrock जैसे क्लाउड-प्रोवाइडर लॉगिन से यह कमांड छिप जाता है। Team और Enterprise प्लान पर कोई Owner पूरे संगठन के लिए रूटीन बंद भी कर सकता है।
5. ऐसे प्रॉम्प्ट लिखना जो बिना निगरानी वाले रन में टिके रहें
रूटीन का प्रॉम्प्ट किसी चैट संदेश की बजाय एक रनबुक के ज़्यादा क़रीब है। अस्पष्टता दूर करने के लिए कोई मौजूद नहीं होता, इसलिए अस्पष्ट निर्देश अस्पष्ट नतीजे देते हैं, या उससे भी बुरा, आत्मविश्वास से की गई ऐसी कार्रवाइयाँ जो आप नहीं चाहते थे। तुलना करें:
"हमारी रिपॉज़िटरी देखो और बताओ कि क्या चल रहा है।"
"acme/webapp में पिछले 24 घंटों में खोली गई या अपडेट की गई पुल रिक्वेस्ट सूचीबद्ध करो। हर एक के लिए लेखक, CI हरा है या नहीं, और कोई अनसुलझे रिव्यू थ्रेड दर्ज करो। किसी PR पर टिप्पणी या बदलाव मत करो। नतीजों की तालिका के साथ #eng-daily में एक Slack संदेश पोस्ट करो, फिर पाँच दिन से पुरानी PR को 'Stale' के तहत अलग से सूचीबद्ध करो। अगर कोई PR नहीं है, तो 'No PR activity' पोस्ट करो और रुक जाओ।"
एक अच्छा रूटीन प्रॉम्प्ट बताता है:
- दायरा: कौन-सी रिपॉज़िटरी, कौन-सी समय अवधि और कौन-से आइटम।
- अनुमत कार्रवाइयाँ: Claude क्या बदल सकता है और, उतना ही ज़रूरी, किसे छूना नहीं है।
- आउटपुट: सटीक गंतव्य और प्रारूप, जैसे ड्राफ़्ट PR, Slack चैनल या ट्रैकर टिप्पणी।
- रुकने की शर्तें: करने को कुछ न हो तो क्या करना है, और कब हार मान लेनी है।
- पेलोड का प्रबंधन: API ट्रिगर के लिए, fire टेक्स्ट का उपयोग करना है या नहीं और कैसे।
उम्मीद रखें कि नए रूटीन को पहले हफ़्ते में दो-तीन बार सुधारना पड़ेगा। केवल स्टेटस बैज नहीं, ट्रांसक्रिप्ट पढ़ें। Anthropic स्पष्ट कहता है कि हरे स्टेटस का मतलब केवल इतना है कि सेशन बिना किसी इन्फ़्रास्ट्रक्चर त्रुटि के शुरू हुआ और समाप्त हुआ। इसका मतलब यह नहीं कि टास्क सफल रहा।
6. सब-रूटीन (sub-routines): एक ही रन के भीतर काम को संरचित करना
Anthropic "सब-रूटीन" नाम का कोई फ़ीचर नहीं देता। Workstation में हम यह शब्द एक डिज़ाइन पैटर्न के लिए इस्तेमाल करते हैं जो लंबे, बिना निगरानी वाले रन को कहीं अधिक भरोसेमंद बनाता है: रूटीन का प्रॉम्प्ट एक ऑर्केस्ट्रेटर की तरह काम करता है, और हर सुपरिभाषित चरण को किसी सबएजेंट या रिपॉज़िटरी में कमिट किए गए किसी स्किल को सौंप देता है।
यह Claude Code के दो बुनियादी घटकों की वजह से काम करता है जो आपकी रिपॉज़िटरी के साथ चलते हैं:
- सबएजेंट
.claude/agents/में YAML फ़्रंट मैटर वाली Markdown फ़ाइलें हैं। हर एक का अपना सिस्टम प्रॉम्प्ट, टूल अनुमति-सूची और वैकल्पिक मॉडल होता है, और वह अपनी अलग कॉन्टेक्स्ट विंडो में चलता है। कॉल करने वाले के पास केवल एक सारांश लौटता है। सबएजेंट समानांतर चल सकते हैं, और डिफ़ॉल्ट रूप से खुद भी तीन स्तर गहराई तक काम सौंप सकते हैं। - स्किल
.claude/skills/में पुन: प्रयोज्य प्रक्रियाओं को पैकेज करते हैं, जैसे आपकी रिलीज़-नोट शैली या सुरक्षा समीक्षा चेकलिस्ट, जिन्हें Claude ज़रूरत पड़ने पर लोड करता है। रूटीन क्लोन की गई रिपॉज़िटरी में कमिट किए गए स्किल का उपयोग करते हैं।
इस तरह बना एक रात्रिकालीन मेंटेनेंस रूटीन कुछ ऐसा दिख सकता है:
# Routine prompt (orchestrator)
1. Use the issue-triager subagent to label and assign issues opened since the last run.
2. Pick the single highest-priority bug labelled "good-first-fix".
3. Use the bug-fixer subagent to implement a fix on a claude/ branch.
4. Use the test-runner subagent to run the test suite; if it fails twice, stop and report.
5. Open ONE draft PR, using the release-notes skill for the description.
6. Post a three-line summary to #eng-nightly.
# .claude/agents/issue-triager.md
---
name: issue-triager
description: Labels and assigns new issues. Never edits code.
tools: Read, Grep, Glob
model: haiku
---
You triage GitHub issues. Apply area labels from CODEOWNERS and
assign the owning team. Return a table of issue, label and owner.
फ़ायदे व्यावहारिक हैं। हर सहायक केवल वही देखता है जिसकी उसे ज़रूरत है, इसलिए लंबे रन के दौरान ऑर्केस्ट्रेटर का कॉन्टेक्स्ट छोटा और केंद्रित रहता है। हर चरण के लिए टूल अनुमतियाँ सीमित होती हैं: ऊपर वाला ट्राइएजर फ़ाइलें संपादित कर ही नहीं सकता। यांत्रिक चरणों को सस्ते मॉडल संभाल सकते हैं। और क्योंकि सबएजेंट और स्किल वर्ज़न कंट्रोल में रहते हैं, रूटीन के व्यवहार में होने वाले बदलाव किसी भी अन्य बदलाव की तरह कोड रिव्यू से गुज़रते हैं।
7. को-रूटीन (co-routines): आपस में सहयोग करने वाले रूटीन
यहाँ भी, "को-रूटीन" हमारा शब्द है, Anthropic का कोई फ़ीचर नहीं। हम इसका उपयोग ऐसे कई स्वतंत्र रूटीन के लिए करते हैं जो एक-दूसरे को काम सौंपते हैं, ठीक वैसे जैसे प्रोडक्शन लाइन में एक पुर्ज़ा एक स्टेशन से अगले स्टेशन तक जाता है। रूटीन एक-दूसरे को सीधे कॉल नहीं कर सकते और उनकी कोई साझा मेमोरी नहीं होती। इसके बजाय, एक रूटीन एक टिकाऊ आर्टिफ़ैक्ट बनाता है जिस पर दूसरे रूटीन का ट्रिगर नज़र रखता है।
एक सामान्य शृंखला:
- रूटीन A (शेड्यूल) कार्यदिवसों की रातों में बैकलॉग की छँटाई करता है और एक
claude/fix-…ब्रांच से ड्राफ़्ट PR खोलता है। - रूटीन B (GitHub,
pull_request.opened) उन हेड ब्रांचों तक फ़िल्टर किया गया है जोclaude/से शुरू होती हैं। यह टीम की रिव्यू चेकलिस्ट लागू करता है और PR पर लेबल लगाता है। - एक इंसान समीक्षा करके मर्ज करता है। यही मंज़ूरी का गेट है।
- रूटीन C (GitHub,
pull_request.closed, merged = true) डॉक्यूमेंटेशन अपडेट करता है या बदलाव को किसी सहोदर SDK में पोर्ट करता है और एक फ़ॉलो-अप PR खोलता है। - रूटीन D (API) को रिलीज़ के बाद डिप्लॉयमेंट पाइपलाइन कॉल करती है। यह स्मोक चेक चलाता है और go या no-go पोस्ट करता है। no-go होने पर यह एक ट्रैकर इश्यू दर्ज करता है, जिसे रूटीन A अगली रात उठा लेता है।
काम सौंपने के चैनल, सबसे अधिक से सबसे कम संरचित क्रम में:
- GitHub इवेंट: मूल, फ़िल्टर करने योग्य और पूरी तरह ऑडिट करने योग्य।
- लेबल और ब्रांच नामकरण परंपराएँ: बिना कोई ग्लू कोड लिखे काम को रूट करें।
- API कॉल: CI, मॉनिटरिंग या आंतरिक टूल से, जिनमें पेलोड को अविश्वसनीय संदर्भ माना जाता है।
- साझा ट्रैकर या आर्टिफ़ैक्ट: कोई Linear इश्यू या स्टेटस पेज जिसे अगला शेड्यूल्ड रन पढ़ता है।
को-रूटीन सावधानी से डिज़ाइन करें। फ़िल्टर का उपयोग करें ताकि कोई रूटीन कभी अपने ही आउटपुट पर न चले, उदाहरण के लिए उसके द्वारा बनाए गए लेखकों या ब्रांचों को बाहर रखकर। कोड लिखने वाले किसी भी रूटीन और उसे शिप करने वाले किसी भी रूटीन के बीच एक मानवीय मर्ज रखें। याद रखें कि हर चरण उसी खाता-स्तरीय दैनिक रन सीमा और GitHub इवेंट सीमाओं से खर्च होता है। अगर आप कई रूटीन में ब्रांचिंग लॉजिक, रीट्राई और फ़ैन-आउट बनाने लगें, तो आप इस पैटर्न से आगे निकल चुके हैं, और एक समर्पित वर्कफ़्लो इंजन बेहतर टूल है।
8. सुरक्षा और गवर्नेंस
- रूटीन आपके रूप में काम करते हैं। रूटीन किसी व्यक्तिगत claude.ai खाते के होते हैं और टीम के साथियों के साथ साझा नहीं होते। कमिट और पुल रिक्वेस्ट आपकी GitHub पहचान के साथ जाते हैं, और कनेक्टर कार्रवाइयाँ आपके लिंक किए गए खातों का उपयोग करती हैं। रूटीन को ऐसा पर्सनल एक्सेस टोकन समझें जिसके साथ एक दिमाग़ जुड़ा है।
- ब्रांच सुरक्षा। Claude डिफ़ॉल्ट रूप से
claude/उपसर्ग वाली ब्रांचों पर पुश करता है। यह संरक्षित ब्रांचों पर, किसी और की खुली PR वाली ब्रांचों पर, और दूसरों के कमिट वाली ब्रांचों पर पुश करने से मना कर देता है। - न्यूनतम विशेषाधिकार। अनावश्यक कनेक्टर हटा दें। जब तक किसी विशेष डोमेन की ज़रूरत न हो, नेटवर्क एक्सेस Trusted पर ही रखें; ब्लॉक की गई रिक्वेस्ट
403औरx-deny-reason: host_not_allowedके साथ विफल होती हैं। Pro और Max प्लान पर API keys को सामान्य वेरिएबल की बजाय एनवायरनमेंट API credentials के रूप में सहेजें, क्योंकि सामान्य वेरिएबल एनवायरनमेंट का उपयोग करने वाले हर व्यक्ति को दिखते हैं। - अविश्वसनीय इनपुट। API पेलोड और Run now टेक्स्ट अविश्वसनीय लेबल के साथ आते हैं। रन के दौरान लाई गई सामग्री, जैसे इश्यू बॉडी और वेब पेज, पर सामान्य प्रॉम्प्ट-इंजेक्शन सुरक्षा लागू रहती है। ऐसे प्रॉम्प्ट लिखें जो Claude को बताएँ कि किस पर भरोसा करना है।
- कनेक्शन की सेहत। अगर GitHub कनेक्शन की अवधि समाप्त हो जाती है, तो 72 घंटे तक रन छोड़ दिए जाते हैं और फिर रूटीन खुद को तब तक बंद कर लेता है जब तक आप दोबारा कनेक्ट न करें।
- संगठनात्मक नियंत्रण। Team और Enterprise के Owner एडमिन सेटिंग्स से सभी सदस्यों के लिए रूटीन बंद कर सकते हैं।
9. प्लान, उपयोग और सीमाएँ
| प्लान | लॉन्च के समय दैनिक रूटीन रन |
|---|---|
| Pro | 5 |
| Max | 15 |
| Team और Enterprise | 25 |
रूटीन इंटरैक्टिव सेशन की तरह ही सब्सक्रिप्शन उपयोग खर्च करते हैं। दैनिक सीमा उसके अतिरिक्त लागू होती है। आपका मौजूदा आवंटन claude.ai/code/routines पर दिखता है और प्रीव्यू के दौरान बदल सकता है। उपयोग क्रेडिट सक्षम होने पर सीमा से अधिक रन मीटर्ड ओवरेज के रूप में जारी रहते हैं; उनके बिना अतिरिक्त रन विंडो रीसेट होने तक अस्वीकार कर दिए जाते हैं। एक-बार वाले शेड्यूल्ड रन सीमा में नहीं गिने जाते। सब्सक्रिप्शन रुके रहने के दौरान उसके रूटीन भी रुके रहते हैं।
10. रूटीन की अन्य शेड्यूलिंग विकल्पों से तुलना
10.1 Claude Code के भीतर
| Routines (क्लाउड) | Desktop शेड्यूल्ड टास्क | /loop |
|
|---|---|---|---|
| कहाँ चलता है | Anthropic क्लाउड | आपकी मशीन | आपकी मशीन |
| मशीन चालू होनी चाहिए | नहीं | हाँ | हाँ |
| सेशन खुला होना चाहिए | नहीं | नहीं | हाँ |
| लोकल फ़ाइलें | नहीं (नया क्लोन) | हाँ | हाँ |
| अनुमति प्रॉम्प्ट | कोई नहीं (स्वायत्त) | कॉन्फ़िगर करने योग्य | सेशन से विरासत में |
| न्यूनतम अंतराल | 1 घंटा | 1 मिनट | 1 मिनट |
| सबसे उपयुक्त | भरोसेमंद, बिना निगरानी वाला काम | लोकल टूल की ज़रूरत वाले टास्क | सेशन के दौरान पोलिंग |
/loop टास्क सेशन तक सीमित होते हैं और सात दिन बाद समाप्त हो जाते हैं। काम करते समय किसी बिल्ड या पुल रिक्वेस्ट पर नज़र रखने के लिए ये आदर्श हैं, लेकिन ये रूटीन का विकल्प नहीं हैं।
10.2 Claude Code के बाहर
- GitHub Actions सस्ता है, कोड के साथ ही रहता है और रनर पर पूरा नियंत्रण देता है। इसकी क़ीमत है YAML, सीक्रेट्स प्रबंधन और रनर का रखरखाव। निर्धारक बिल्ड चरणों के लिए Actions चुनें, और विवेक की ज़रूरत वाले काम के लिए रूटीन।
- वर्कफ़्लो इंजन, जैसे Trigger.dev, रीट्राई, फ़ैन-आउट और लंबे समय तक चलने वाले ऑर्केस्ट्रेशन को संभालते हैं, लेकिन ऑर्केस्ट्रेशन आपको कोड में लिखना पड़ता है। इनका उपयोग तब करें जब वर्कफ़्लो ही उत्पाद हो।
- इंटीग्रेशन प्लेटफ़ॉर्म, जैसे n8n और Zapier, SaaS टूल के बीच डेटा ले जाने में माहिर हैं। रूटीन कोड, लॉग और दस्तावेज़ों पर तर्क करने में माहिर हैं। दोनों अच्छी तरह साथ काम करते हैं: कोई n8n फ़्लो किसी रूटीन के API एंडपॉइंट को कॉल कर सकता है।
11. उपयोग के मामले जो अच्छी तरह काम करते हैं
- बैकलॉग की देखरेख: रात में लेबलिंग, स्वामित्व तय करना और सुबह का सारांश।
- अलर्ट ट्राइएज: मॉनिटरिंग API ट्रिगर को कॉल करती है, और Claude स्टैक ट्रेस को हाल के कमिट से जोड़कर एक ड्राफ़्ट फ़िक्स खोलता है।
- अनुकूलित कोड रिव्यू: हर ready-for-review PR पर आपकी अपनी चेकलिस्ट।
- डिप्लॉय सत्यापन: हर रिलीज़ के बाद स्मोक चेक और लॉग स्कैन, अंत में go या no-go।
- डॉक्यूमेंटेशन का भटकाव: मर्ज हुई PR का साप्ताहिक स्कैन और उन डॉक्स के लिए अपडेट PR जो बदले हुए API का उल्लेख करते हैं।
- लाइब्रेरी पोर्टिंग: एक SDK में मर्ज हुए बदलावों को किसी दूसरी भाषा के सहोदर SDK में दोहराना।
- डिपेंडेंसी की साफ़-सफ़ाई: पुराने पैकेजों की साप्ताहिक समीक्षा और एक अकेली, टेस्ट की गई अपग्रेड PR।
रूटीन एक घंटे से कम अंतराल वाले काम, बीच रन में मानवीय निर्णय की ज़रूरत वाले टास्क, और रीट्राई वाले जटिल बहु-शाखा वर्कफ़्लो के लिए कम उपयुक्त हैं।
12. समुदाय ने इसे कैसे लिया
प्रतिक्रिया मिली-जुली रही है लेकिन ज़्यादातर सकारात्मक। InfoQ ने ऐसे इंजीनियरों को उद्धृत किया जो webhooks के ज़रिए AI को सीधे ऑब्ज़र्वेबिलिटी डैशबोर्ड और CI वर्कफ़्लो से जोड़ने को लेकर उत्साहित थे। दूसरे लोग संशय में थे। उन्होंने Claude की उन पुरानी शेड्यूलिंग सुविधाओं की ओर इशारा किया जो केवल उपयोगकर्ता की अपनी मशीन पर चलती थीं, और तर्क दिया कि नई सुविधाओं से पहले विश्वसनीयता, अपटाइम और कोटा सीमाओं पर ध्यान दिया जाना चाहिए। हमारा अनुभव यह है कि रूटीन सुरक्षा के लिहाज़ से अच्छी तरह डिज़ाइन किए गए हैं, ख़ास तौर पर अविश्वसनीय पेलोड के प्रबंधन और ब्रांच सुरक्षा में। मुख्य परिचालन जोखिम हैं ज़रूरत से ज़्यादा व्यापक कनेक्टर और पर्याप्त रूप से विशिष्ट न होने वाले प्रॉम्प्ट।
13. Workstation इसका उपयोग कैसे करता है
Workstation में हम DevOps, वित्तीय संचालन और ग्राहक वर्कफ़्लो में क्लाइंट्स के लिए एजेंटिक ऑटोमेशन चलाते हैं। रूटीन हमारे दृष्टिकोण में अच्छी तरह फ़िट होते हैं: बुनियादी ढाँचे के लिए निर्धारक इन्फ़्रास्ट्रक्चर, विवेक के लिए AI, और प्रोडक्शन तक कुछ भी पहुँचने से पहले मानवीय मंज़ूरी का गेट। अगर आप रूटीन शृंखलाएँ, सबएजेंट लाइब्रेरी या उनके आसपास का गवर्नेंस डिज़ाइन करने में मदद चाहते हैं, तो हमारी टीम से बात करें।
14. मुख्य निष्कर्ष
- रूटीन एक सहेजा गया प्रॉम्प्ट, रिपॉज़िटरी, एनवायरनमेंट, कनेक्टर और ट्रिगर है, जो क्लाउड में स्वायत्त रूप से चलता है।
- ट्रिगर एक शेड्यूल (न्यूनतम एक घंटा, स्थानीय समय), एक API कॉल (bearer टोकन, अविश्वसनीय पेलोड) या एक GitHub पुल रिक्वेस्ट या रिलीज़ इवेंट हो सकता है।
- Pro, Max, Team और Enterprise पर उपलब्ध, सामान्य उपयोग के अतिरिक्त दैनिक रन सीमाओं के साथ। यह फ़ीचर अभी भी रिसर्च प्रीव्यू में है।
- एक लंबे रन को केंद्रित और न्यूनतम-विशेषाधिकार वाला रखने के लिए सब-रूटीन (सबएजेंट और स्किल) का उपयोग करें।
- बहु-चरणीय पाइपलाइनों के लिए को-रूटीन (PR, लेबल और API कॉल के ज़रिए काम सौंपने वाले रूटीन) का उपयोग करें, बीच में एक मानवीय मर्ज गेट के साथ।
- कनेक्टर और नेटवर्क एक्सेस का दायरा सख़्ती से सीमित रखें, प्रॉम्प्ट रनबुक की तरह लिखें, और ट्रांसक्रिप्ट पढ़ें।
स्रोत और आगे पढ़ने के लिए
- Anthropic: Introducing routines in Claude Code (14 अप्रैल 2026)
- Claude Code Docs: Automate work with routines
- Claude Code Docs: Run prompts on a schedule (/loop)
- Claude Code Docs: Subagents
- Claude Platform Docs: Trigger a routine through the API
- InfoQ: Anthropic Introduces Routines for Claude Code Automation
- MindStudio: Claude Code Routines: How to Run Scheduled AI Agents Without a Server
- Medium पर Tahir: What is Claude Code Routines?
Routines रिसर्च प्रीव्यू में हैं। व्यवहार, सीमाएँ और API बदल सकते हैं। इस गाइड के तथ्य 25 सितंबर 2026 तक Anthropic के प्रकाशित डॉक्यूमेंटेशन पर आधारित हैं।