विषय-सूची

Claude Code का "Projects" एक ऐसा फ़ीचर है जिसमें Claude एक ही बातचीत के भीतर काम को थ्रेड में बाँटता है और उन्हें क्लाउड में समानांतर चलाता है। यह कैसे काम करता है और इस्तेमाल की शर्तें क्या हैं, यह मैंने Projects क्या है में समझाया था। यह लेख उसी की अगली कड़ी है: इससे एक पूरी वेबसाइट बनवाकर देखने का असली ब्योरा।

मैंने इसे 26 से 28 सितंबर 2026 के बीच आज़माया, जब Projects पब्लिक बीटा में था (Pro और Max वालों के लिए धीरे-धीरे जारी हो रहा था; आधिकारिक दस्तावेज़)। स्क्रीन और व्यवहार आगे बदल सकते हैं। यहाँ जो लिखा है, वह उस समय सचमुच हुई घटनाएँ हैं, और वे आँकड़े हैं जिन्हें मैंने स्क्रीन, उपयोग रिपोर्ट और रिपॉज़िटरी के रिकॉर्ड से जाँचा।

पहले निष्कर्ष — इस्तेमाल करके क्या समझ आया

26–28 सितंबर 2026 के असली आँकड़े (प्रोजेक्ट की उपयोग रिपोर्ट और रिपॉज़िटरी का रिकॉर्ड)

क्या बना

11 PR

10 थ्रेड, क़रीब 23,000 लाइनें। इंसान के सोते समय भी काम चलता रहा।

लगा समय

क़रीब 20 घंटे

बनाने से आख़िरी मर्ज तक। इनमें क़रीब 7 घंटे रात के थे।

लगे टोकन

क़रीब 19 करोड़

97.7% कैश से पढ़े गए। काम की मात्रा के हिसाब से अपनी मशीन के Claude Code जितनी ही खपत।

नतीजा

80% तैयार ढाँचा

लाइव करने से पहले काम के बँटवारे की दरार और असली डेटा पर बग मिले।

एक वाक्य में कहूँ तो: विकास का काम हैरानी की हद तक अपने-आप आगे बढ़ता है। पर हाथ में तैयार उत्पाद नहीं, एक कच्चा ढाँचा आता है, और सिर्फ़ SSH से पहुँचने वाले सर्वर पर डिप्लॉय करते समय बात अटक जाती है। आगे अच्छी और बुरी दोनों बातें उसी क्रम में लिख रहा हूँ जिसमें वे हुईं।

1. क्या बनवाया — शर्तें, और शुरू में ही एक ईमानदार स्वीकारोक्ति

विषय था लोकल LLM की "ज़रूरी मेमोरी" खोजने वाली एक डेटाबेस साइट। "क्या यह मॉडल मेरे PC पर चलेगा?" इस सवाल का जवाब देने के लिए यह Hugging Face से क्वांटाइज़्ड फ़ाइलों के आकार जुटाती है, हर कॉन्टेक्स्ट लंबाई पर ज़रूरी मेमोरी गिनती है, और GPU या Mac की मेमोरी से उल्टा खोजने देती है। यह प्रोजेक्ट इतना छोटा भी नहीं कि परख अधूरी रहे, और इसमें ऐसे हिस्से हैं जो समानांतर बाँटे जा सकते हैं (डेटा जुटाना, गणना, पेज, उल्टी खोज, SEO), इसलिए यह Projects की परख के लिए ठीक बैठा।

मदइस बार की शर्तें
क्या बनाना थालोकल LLM की ज़रूरी मेमोरी का डेटाबेस (जापानी भाषा की साइट)।
तकनीकLaravel 13, PHP 8.5, MySQL 5.7। होस्टिंग ऐसी शेयर्ड होस्टिंग पर जहाँ सिर्फ़ SSH से पहुँचा जा सकता है।
रिपॉज़िटरीgithub.com की प्राइवेट रिपॉज़िटरी। प्रोजेक्ट के थ्रेड सिर्फ़ उन्हीं github.com रिपॉज़िटरी पर काम कर सकते हैं जिन पर Claude GitHub App इंस्टॉल हो, इसलिए मैंने सिर्फ़ Claude के लिए एक नया GitHub अकाउंट बनाया।
प्लानMax (20x)।
मॉडलथ्रेड आम तौर पर Sonnet के medium effort पर चले; समीक्षा और गणना जैसे जिन कामों में ग़लती भारी पड़ती, सिर्फ़ उनके लिए समन्वयक ने Opus चुना। समन्वयक (coordinator) ख़ुद अपने डिफ़ॉल्ट Opus, low पर रहा।

⚠️ पहले ही मान लेता हूँ: शुरुआती आधे हिस्से में मैंने इसके हाथ बाँध रखे थे

मेरे पहले प्रोजेक्ट निर्देशों में "कोई भी थ्रेड शुरू करने से पहले प्रस्ताव रखो और मेरी हाँ का इंतज़ार करो", "एक साथ ज़्यादा से ज़्यादा 3 थ्रेड", "main में मर्ज इंसान मंज़ूर करेगा" जैसे हर क़दम पर इंसानी मंज़ूरी डालने वाले नियम थे। मैंने इन्हें सुरक्षा के लिए रखा था, पर इन्होंने इस फ़ीचर की असली ख़ूबी — Claude से काम बँटवाना और आगे बढ़वाना — ख़ुद ही बंद कर दी। बीच में मैंने निर्देश बदलकर काम उसे सौंप दिया, और अध्याय 4 में उससे पहले और बाद की तुलना है। पहले हिस्से की कुछ असुविधा फ़ीचर की नहीं, मेरे निर्देशों की वजह से थी।

2. शुरू करने के कदम, और पाँच जगह जहाँ मैं अटका

शुरू करने के कदम अपने-आप में छोटे हैं: डेस्कटॉप ऐप के Code टैब में "Projects" → "New" चुनिए, नाम, लक्ष्य और रिपॉज़िटरी भरिए और बना दीजिए। फिर भी उसके आगे-पीछे मैं इन पाँच जगहों पर अटका।

① GitHub App का दायरा

अनुमति वाले पेज पर शुरू से "All repositories" चुना रहता है। अलग अकाउंट नहीं है तो "Only select repositories" तक सीमित कीजिए, क्योंकि थ्रेड उसी मालिक की दूसरी रिपॉज़िटरी ख़ुद जोड़ सकते हैं।

② बनते ही एक बार चल पड़ता है

पहला प्रोजेक्ट बनते ही Claude ख़ुद एक थ्रेड खोलकर रिपॉज़िटरी पढ़ने लगता है। यह निर्देश चिपकाने से पहले ही चल जाता है, इसलिए सुझाए गए थ्रेड अंग्रेज़ी में आए।

③ डिफ़ॉल्ट Opus है

थ्रेड का डिफ़ॉल्ट मॉडल Opus है (मेरी स्क्रीन पर effort medium था; आधिकारिक दस्तावेज़ high बताते हैं)। यह सीमा सबसे तेज़ी से खाता है, इसलिए बनाते ही सेटिंग → "General" में थ्रेड का मॉडल जाँच लीजिए।

④ नेटवर्क की अनुमति

डिफ़ॉल्ट अनुमति-सूची में Hugging Face या हार्डवेयर कंपनियों की साइटें नहीं हैं। *.nvidia.com सिर्फ़ सबडोमेन से मेल खाता है; मुख्य nvidia.com के लिए अलग पंक्ति चाहिए थी।

⑤ बदलाव चल रहे थ्रेड तक नहीं पहुँचते

माहौल या प्रोजेक्ट निर्देशों में बदलाव नए थ्रेड से लागू होते हैं (आधिकारिक दस्तावेज़ में भी साफ़ लिखा है)। जो थ्रेड रुक गए थे, उन्हें मैंने समन्वयक से नए थ्रेड में आगे बढ़वाया।

② के बारे में एक बात और: बनाने के ठीक बाद बातचीत में यह सूचना दिखी — "Up to $100 of initial usage, including the automatic setup, won't count towards your usage limits"। मतलब शुरुआती इस्तेमाल में $100 तक का हिस्सा आम उपयोग-सीमा में नहीं गिना जाता, और उपयोग वाली स्क्रीन पर भी यह "प्रोजेक्ट सेटअप क्रेडिट (समाप्त होने में क़रीब 24 घंटे)" के रूप में दिखा। 28 सितंबर तक यह सुविधा आधिकारिक दस्तावेज़ के Projects वाले पेज पर नहीं लिखी है। यह असल में कैसे घटा, वह अध्याय 6 में है।

माहौल की सेटिंग में मैं मौजूदा माहौल को बदलते समय उलझा। "Add cloud environment" (माहौल जोड़ें) से जाने पर नए माहौल का पेज खुलता है, और पहले मैंने अनुमत डोमेन सेटअप स्क्रिप्ट वाले खाने में लिख दिए। मौजूदा माहौल को बदलने के लिए सूची में उस पर माउस ले जाइए और जो गियर आइकन दिखे, उसे क्लिक कीजिए (आधिकारिक दस्तावेज़ में यही तरीक़ा है, पर सिर्फ़ स्क्रीन देखकर यह समझना मुश्किल है)।

3. क़रीब 20 घंटे का ब्योरा — मेरे सोते समय क्या हुआ

यह प्रोजेक्ट बनाने (26 सितंबर, रात क़रीब 22:00 बजे) से आख़िरी PR मर्ज होने (अगले दिन 27 सितंबर, शाम क़रीब 17:30 बजे) तक का सिलसिला है। सारे समय जापान के समय (JST) में हैं।

26 तारीख़ 22:10–23:50　नींव और समीक्षा

नींव वाले थ्रेड (Sonnet) ने Laravel का ढाँचा, DB डिज़ाइन और नियमों का दस्तावेज़ बनाकर PR खोला। जब एक दूसरे थ्रेड से Opus पर समीक्षा करवाई, तो उसने सचमुच कंटेनर में MySQL 5.7 चलाकर परखा और एक बग पकड़ा: रिकॉर्ड के समय वाला कॉलम हर बार पंक्ति अपडेट होने पर मौजूदा समय से बदल जाता था (MySQL 5.7 पहले TIMESTAMP कॉलम पर अपने-आप अपडेट जोड़ देता है; सैंपल डेटा वाले टेस्ट में यह दिखता ही नहीं)। CI का प्रस्ताव भी इसी समय बना, और इंसान की मंज़ूरी से PR #1 मर्ज हुआ।

27 तारीख़ 0:00–7:30　रात में 3 थ्रेड समानांतर

डेटा जुटाना (Opus), ज़रूरी मेमोरी की गणना (Opus), और SEO व साझा लेआउट (Sonnet) — तीनों एक साथ चले, और सुबह तक सब "समीक्षा के इंतज़ार" में थे। थ्रेड समन्वयक के ज़रिये आपस में तालमेल बिठा रहे थे, यह सबसे दिलचस्प लगा: गणना वाले थ्रेड ने लेआउट के इस्तेमाल के बारे में पूछा और लेआउट वाले थ्रेड ने जवाब दिया। गणना वाले थ्रेड को जो समस्या मिली — "जिन मॉडलों के लिए उपयोग की शर्तें मानना ज़रूरी है, उनकी कॉन्फ़िग फ़ाइल नहीं मिलती (401)" — वह डेटा जुटाने वाले थ्रेड तक पहुँची और वहीं सुलझाई गई।

27 तारीख़ 7:30–8:50　टकराव सुलझाना

थ्रेड समानांतर में एक ही फ़ाइल (रूटिंग की परिभाषा) बदल रहे थे, इसलिए एक PR मर्ज होने के बाद अगला PR टकरा गया। पहली बार समन्वयक ने मर्ज को भाँपकर ख़ुद ही टकराव सुलझाने का निर्देश दिया। दूसरी बार समन्वयक कुछ नहीं बोला; थ्रेड के कार्ड पर "Resolve conflicts" (टकराव सुलझाएँ) का बटन आया और उसे दबाने पर सुलझाना शुरू हुआ। हर बार प्रतिक्रिया एक जैसी नहीं होती।

27 तारीख़ 8:50–11:30　पहुँच से बाहर की साइटों पर रुकना

GPU और Mac मॉडलों का डेटा भरने वाला थ्रेड क्लाउड से हार्डवेयर कंपनियों की आधिकारिक साइटों तक नहीं पहुँच सका, और अंदाज़े से डेटा भरने के बजाय रुककर तीन विकल्पों वाला कार्ड दिखाया (अनुमति बढ़ाओ / इंसान मान दे / इंसान के PC पर खोजो)। अनुमति-सूची ठीक करके नए थ्रेड में आगे बढ़वाने पर उसने आधिकारिक पेजों से 25 मॉडल भरे। इसी दौरान थ्रेड ने ख़ुद पकड़ा कि पेज का सारांश बनाने वाला टूल ऐसे प्रोडक्ट के नाम गढ़ रहा था जो असल में हैं ही नहीं, और उसके बाद वह पेज का मूल HTML सीधे जाँचने के तरीक़े पर चला गया।

27 तारीख़ 17:00–17:30　काम सौंपा तो ख़ुद चल पड़ा

प्रोजेक्ट निर्देशों को "काम सौंपने" वाले रूप में बदलते ही, मेरे कुछ कहे बिना समन्वयक ने एलान किया — "मैंने काम करने के नए तरीक़े वाले निर्देश पढ़ लिए हैं। अब से अगला काम मैं ख़ुद तय करके आगे बढ़ाऊँगा" — और बचे हुए PR मर्ज करने से लेकर मॉडलों का डेटा जोड़ने (2 थ्रेड) तक सब ख़ुद तय करके किया।

एक बुरी बात भी दर्ज कर दूँ। डेटा जुटाने की नींव बनाते समय थ्रेड ने बाहरी सेवा की रेट-लिमिट समझने के लिए Hugging Face के API को लगातार 520 बार कॉल किया। समीक्षा वाले थ्रेड ने इसे "उचित नहीं" ठहराया और बाहरी API के इस्तेमाल के नियम दस्तावेज़ में लिखे; उसके बाद डेटा जुटाने वाले थ्रेड ने पूरे काम में सिर्फ़ 8 बार कॉल किया। अपने भरोसे छोड़ दें तो यह बाहरी सेवाओं पर पड़ने वाले बोझ का ध्यान ख़ुद से नहीं रखता, इसलिए इसे निर्देशों में लिख देना फ़ायदेमंद है।

4. हर क़दम पर मंज़ूरी बनाम पूरा भरोसा

जैसा अध्याय 1 में लिखा, पहले हिस्से में मैंने इसे हर क़दम पर इंसानी मंज़ूरी वाले निर्देशों से चलाया, और 27 तारीख़ को 17 बजे निर्देश बदलकर काम इसे सौंप दिया। व्यवहार साफ़ बदल गया।

मौक़ापहला हिस्सा: हर क़दम पर मंज़ूरीदूसरा हिस्सा: काम सौंपने के बाद
थ्रेड शुरू करनापहली बार "प्रस्ताव रखो और इंतज़ार करो" का पालन किए बिना फ़ौरन शुरू कर दिया। संदेश में "मेरी हाँ के बिना शुरू मत करना" दोहराने पर माना।समन्वयक ने ख़ुद तय करके शुरू किया।
मर्जहर बार इंसान ने GitHub पर बटन दबाया (7 बार)।CI पास होने पर थ्रेड ने ख़ुद मर्ज किया (4 बार)।
अगला कामइंसान ने तय करके कहा।समन्वयक ने TODO में से चुनकर नया थ्रेड खोला।
इंसान की ज़रूरतमर्ज, टकराव का बटन, माहौल की सेटिंग, संदेश पहुँचाना — स्क्रीनों के बीच बार-बार आना-जाना।लगभग नहीं (सिर्फ़ जब माहौल की सेटिंग बदलनी हो)।

काम सौंपते समय दो बातों का ध्यान रखना पड़ा। पहली, बदले हुए निर्देश उस समय चल रहे थ्रेड तक नहीं पहुँचते। समन्वयक ने ख़ुद समझाया कि "यह थ्रेड निर्देश बदलने से पहले शुरू हुआ था, इसलिए इसे नए निर्देश नहीं दिखते"। दूसरी, प्रोजेक्ट की मेमोरी में बचे पुराने नियम को थ्रेड मिटा नहीं सका। "मर्ज सिर्फ़ इंसान करेगा" वाला पुराना नोट बदलने की कोशिश सुरक्षा जाँच में रोक दी गई। पुराने नोट इंसान को ख़ुद सेटिंग के "Memory" (मेमोरी) से मिटाने पड़ते हैं।

आख़िर में जिन निर्देशों पर बात टिकी, उनका ढाँचा यह है।

यह प्रोजेक्ट ○○ बनाता है और चलाता है।
काम का तरीक़ा तुम्हारे ज़िम्मे: थ्रेड खोलना, उनकी गिनती, मॉडल और क्रम समन्वयक तय कर सकता है।
CI पास हो चुके PR मर्ज कर सकते हो। टकराव ख़ुद सुलझाओ।

इंसान से सिर्फ़ ये पूछो:
- जिसमें पैसा लगे (पेड API, पेड सेवाएँ)
- जब कोई गोपनीय जानकारी (API key, पासवर्ड) चाहिए
- प्रोडक्शन पर डिप्लॉय या प्रोडक्शन डेटा में बदलाव
- जब दिशा को लेकर दो रास्ते हों और दोनों तर्कसंगत हों
- जब ज़रूरी चीज़ तक पहुँच न हो (अंदाज़े या नक़ली डेटा से मत भरो)

बाहरी API की रेट-लिमिट का पालन करो, और जाँच-पड़ताल के लिए ढेरों कॉल मत करो।

हालाँकि बाद में जो समझ आया, उसके हिसाब से "CI की सेटिंग और डिप्लॉय स्क्रिप्ट में बदलाव इंसान मंज़ूर करेगा" भी जोड़ देने की सलाह दूँगा। जिस थ्रेड को काम सौंपा गया है वह CI की सेटिंग भी बदल सकता है, और डिप्लॉय के तंत्र के साथ मिलकर इससे ऐसा रास्ता बन जाता है जिससे बिना जाँच के प्रोडक्शन तक बदलाव पहुँच जाए (अध्याय 7)।

5. लाइव करने पर दिखी गुणवत्ता — सारे टेस्ट पास थे

प्रोजेक्ट में बनी चीज़ को मैंने अपनी मशीन के रोज़ वाले Claude Code को सौंपा और प्रोडक्शन पर डाला। डालते ही पहला एहसास था "कुछ ख़ास नहीं"। वजह यह थी कि मॉडलों का एक भी पेज नहीं था। कारण खोजने पर समानांतर विकास की ख़ास दरार दिखी।

ज़िम्मेदारियों की सीमा पर खुली दरार — "क्या इसे दिखाया जा सकता है" यह किसी ने तय नहीं किया

डेटा जुटाने वाला थ्रेड

PR में लिखा "दिखाया जा सकता है या नहीं, यह तय करना पेज वाले का काम है", और यह जाँच नहीं बनाई

पेज वाला थ्रेड

सिर्फ़ "जो दिखाने लायक़ नहीं, उसे मत दिखाओ" वाला हिस्सा बनाया

नतीजा

"दिखाने लायक़" का निशान लगाने वाला हिस्सा कहीं नहीं था, इसलिए कितना भी डेटा डालो, दिखने वाले 0

10 थ्रेड, सौ से ज़्यादा टेस्ट, Opus की समीक्षा और CI — किसी ने भी यह कमी नहीं पकड़ी। वजह यह कि हर थ्रेड अपनी ज़िम्मेदारी के भीतर सही था। शुरू से आख़िर तक पूरा रास्ता देखने वाला कोई न हो, तो बँटवारे की सीमाओं पर दरारें खुल जाती हैं।

असली डेटा डालने पर दो समस्याएँ और निकलीं।

  • क्वांटाइज़ेशन की तालिका में ऐसी फ़ाइलें मिल गई थीं जो मुख्य मॉडल की नहीं थीं। आगे का अनुमान लगाने वाले सहायक मॉडल (MTP, EAGLE आदि) और LoRA फ़ाइलें मुख्य मॉडल के क्वांटाइज़ेशन में गिनी जा रही थीं, और एक 12B मॉडल की तालिका में सबसे ऊपर "Q8_0 0.47GB" की पंक्ति दिख रही थी (असली Q8_0 12.7GB है)। ठीक करने पर 56 रिपॉज़िटरी की 195 फ़ाइलें सहायक श्रेणी में चली गईं।
  • सबसे नए और सबसे ज़्यादा माँग वाले मॉडलों की ज़रूरी मेमोरी "गणना संभव नहीं" आ रही थी। बनाते समय का सूत्र नई पीढ़ी की आर्किटेक्चर (जैसे वे जिनमें अलग-अलग लेयर अलग तरीक़े से मेमोरी रखती हैं) को नहीं संभालता था। साइट की सबसे बड़ी ख़ूबी ठीक उन्हीं पेजों पर ग़ायब थी जिन्हें सबसे ज़्यादा देखा जाता।

दोनों ही मामलों में टेस्ट सिर्फ़ "सैंपल डेटा" पर बने थे, इसलिए ये प्रोडक्शन में असली डेटा डालने पर ही सामने आए। अपनी मशीन के Claude Code से जो ठीक किया और उसमें जितना समय लगा, वह नीचे है (28 सितंबर, 17:21 से 22:54 तक, 13 कमिट)।

क्या ठीक कियाकैसे पकड़ में आया
प्राइवेसी पॉलिसी का पेज नहीं था (विज्ञापन लगाने से पहले ज़रूरी)सर्वर संभालने वाले की समीक्षा
दिखाने लायक़ तय करने (मॉडल को उसकी श्रृंखला से जोड़ने) का पूरा हिस्सा ही नहीं थाप्रोडक्शन में 0 मॉडल
प्रोडक्शन में sitemap.xml पर एरर (500), एरर-सूचना वाले ईमेल नहीं जा रहे थेप्रोडक्शन में जाँच
संपर्क फ़ॉर्म में अलग कैरेक्टर एन्कोडिंग वाला इनपुट आने पर एरर (500)प्रोडक्शन में जाँच
सहायक मॉडलों की फ़ाइलों का मिल जाना, नई आर्किटेक्चर की ज़रूरी मेमोरीअसली डेटा वाले पेजों को आँख से देखना

दूसरी तरफ़, अच्छी बातें भी साफ़ थीं। पेज तेज़ खुलते थे (मुख्य पेज क़रीब 0.1 सेकंड), फ़ाइलों के आकार Hugging Face के असली मान थे, और जिन मॉडलों को सूत्र संभालता था उनकी ज़रूरी मेमोरी सूत्र से मेल खाती थी। टाइटल, स्ट्रक्चर्ड डेटा, sitemap और llms.txt जैसा SEO का बारीक काम भी शुरू से मौजूद था। कुल मिलाकर मेरा आकलन यह है: ढाँचा और बारीकियाँ अच्छी बनी थीं; कमी "जोड़ों" और "असली डेटा" में थी।

6. खपत और ख़र्च — 19 करोड़ टोकन का हिसाब

प्रोजेक्ट सेटिंग की "Usage" स्क्रीन पर थ्रेड-वार और मॉडल-वार टोकन दिखते हैं। ऊपर दाईं ओर के बटन से इसे सीधे टेक्स्ट के रूप में कॉपी भी किया जा सकता है। 27 सितंबर, 11:47 की रिपोर्ट में आँकड़े ये थे।

मदमान
थ्रेड की संख्या10
कुल टोकन19.18 करोड़ (इनपुट 3.17 लाख / आउटपुट 5.74 लाख / कैश रीड 18.74 करोड़ / कैश राइट 35 लाख)
कैश हिट दर98%
कोड में बदलाव+23,531 लाइनें / −302 लाइनें (PR खोलने वाले 8 थ्रेड)
समन्वयक (coordinator)33 लाख (कुल का 2%)
सबसे ज़्यादा खपत वाला थ्रेडSEO और साझा लेआउट (Sonnet) 5.05 करोड़ (26%)

19 करोड़ बड़ी संख्या लगती है, पर इसका 97.7% कैश से पढ़ा गया था। थ्रेड हर क़दम पर अब तक की पूरी बातचीत दोबारा पढ़ता है, इसलिए जब एक थ्रेड सैकड़ों क़दम उठाता है तो आँकड़े ऐसे ही बनते हैं। समन्वयक का अतिरिक्त हिस्सा 2% था, यानी प्रबंधन की लागत बहुत कम रही।

तुलना के लिए मैंने "पढ़े गए टोकन ÷ निकाले गए टोकन" का अनुपात अपनी मशीन के Claude Code (मेरे PC के पिछले 3 दिन) से मिलाया: प्रोजेक्ट में यह क़रीब 330 था और अपनी मशीन पर क़रीब 340। काम की मात्रा के हिसाब से खपत, अपनी मशीन के सेशन जितनी ही है। Projects भारी इसलिए लगता है, ऐसा मेरा अनुमान है, कि समानांतर काम एक साथ तेज़ी से आगे बढ़ता है और खपत थोड़े समय में सिमट जाती है (काम की प्रकृति अलग है, इसलिए यह मोटी तुलना है)।

ख़र्च के मोर्चे पर मैं सेटअप क्रेडिट ($100) के घटने का सिलसिला देख पाया।

प्रोजेक्ट सेटअप क्रेडिट ($100) का इस्तेमाल

बनाने के ठीक बाद (अपने-आप चला एक दौर)1%
नींव बनने के बाद6%
रात के 3 थ्रेड के बाद32%
5 समानांतर कामों के बाद78%
काम सौंपने के बाद का अतिरिक्त कामपूरा ख़त्म (100%)

स्रोत: डेस्कटॉप ऐप का उपयोग प्रदर्शन (26–27 सितंबर 2026)। इस दौरान Max की साप्ताहिक उपयोग-सीमा नहीं बढ़ी।

यह क्रेडिट API की दरों पर गिनी गई रक़म के क़रीब चल रहा था। 11:47 की रिपोर्ट को Anthropic की आधिकारिक दरों (Pricing: Sonnet 5 — इनपुट $2, आउटपुट $10, कैश रीड $0.20; Opus 5.5 — इनपुट $4, आउटपुट $20, कैश रीड $0.20; सब प्रति 10 लाख टोकन) से गिनने पर क़रीब $58–65 आता है, जो उस समय दिख रहे आँकड़े (78% = $78) से मोटे तौर पर मेल खाता है। यानी "$100 तक" का मतलब है उतना काम, जिसके लिए API पर $100 चुकाने पड़ते, और Max के फ़िक्स्ड-रेट प्लान के हिसाब से यह कोई बहुत बड़ी मात्रा नहीं है। वैसे, क्लाउड सेशन के लिए अलग से मिला क्रेडिट (Max पर $250) के लेने वाले पेज पर लिखा था "Projects इसमें शामिल नहीं", और सचमुच उसमें से एक डॉलर भी नहीं घटा।

7. प्रोडक्शन पर डिप्लॉय करने में क्यों अटका

सबसे ज़्यादा मुश्किल बनी चीज़ को प्रोडक्शन पर डालने में आई। वजह यह थी कि होस्टिंग ऐसी शेयर्ड होस्टिंग पर थी जहाँ सिर्फ़ SSH से पहुँचा जा सकता है।

  • क्लाउड के थ्रेड प्रोडक्शन सर्वर तक नहीं पहुँचते (SSH key सिर्फ़ मेरी मशीन पर है)।
  • अपनी मशीन पर चलाने के लिए प्रोजेक्ट का "Work locally" (लोकल रूप से काम) इस्तेमाल होता है। अंदर से यह Remote Control है, और इसके लिए डेस्कटॉप ऐप में "Use this computer from your phone and claude.ai" चालू करना पड़ता है।
  • पर इस सेटिंग का दायरा उन सब फ़ोल्डरों की सूची है जिन्हें अब तक Claude Code में खोला गया है, और यह अपने-आप बनती है। मेरे माहौल में ऐसे 22 फ़ोल्डर थे, जिनमें से एक ऐसा पैरेंट फ़ोल्डर था जिसके भीतर दर्जनों प्रोजेक्ट थे। जब तक यह चालू है, ये सब दूर से काम शुरू किए जा सकने वाले निशाने बन जाते हैं, और फ़ोल्डर के नाम, पाथ और रिपॉज़िटरी के URL भी Anthropic को भेजे जाते हैं। सिर्फ़ एक फ़ोल्डर तक सीमित रखने का अलग तरीक़ा है: टर्मिनल में उस फ़ोल्डर में जाकर claude remote-control चलाना।

इसलिए मैंने डिप्लॉय के कुछ तरीक़ों पर विचार किया।

तरीक़ाकैसे काम करता हैआकलन
Work locally (Remote Control)अपनी मशीन पर चल रहा थ्रेड SSH से डिप्लॉय करेखुलने वाले फ़ोल्डरों का दायरा बढ़ जाता है। हर बार चालू-बंद करना झंझट है।
PC पर हमेशा चलने वाला रनर (GitHub Actions का सेल्फ़-होस्टेड रनर)main अपडेट होते ही अपनी मशीन पर डिप्लॉय का काम चलेअगर थ्रेड वर्कफ़्लो बदलकर मर्ज कर सकते हों, तो यह अपनी मशीन पर कोई भी काम चलवाने का दरवाज़ा बन जाता है। नहीं अपनाया।
webhook से सर्वर को ख़बर देनाGitHub की सूचना मिलने पर सर्वर ख़ुद कोड खींचेबाहर से कॉल किया जा सकने वाला एक नया URL खोलना पड़ता है। सर्वर संभालने वाले की समीक्षा में टाल दिया।
सर्वर समय-समय पर ख़ुद खींचेसर्वर का cron GitHub जाँचे, रीड-ओनली key से कोड लेकर लागू करेबाहर से घुसने का कोई रास्ता नहीं बनता, सुरक्षित है। पर इस मोड़ पर मैंने इसे अपने रोज़ के लोकल तरीक़े पर ले जाने का फ़ैसला किया।

आख़िरकार मैंने प्रोजेक्ट को आर्काइव कर दिया और जो बना था उसे अपनी मशीन के रोज़ वाले Claude Code के तरीक़े पर ले आया। मेरा फ़ैसला यह था कि इसे बाक़ी साइटों वाले डिप्लॉय तंत्र पर चढ़ाना, नया तंत्र जोड़ने से ज़्यादा सुरक्षित है।

पीछे मुड़कर देखूँ तो Projects को ऐसी होस्टिंग के साथ सोचना बेहतर है जहाँ "GitHub में मर्ज होते ही अपने-आप डिप्लॉय" हो जाए। मसलन Vercel में सिर्फ़ GitHub से जोड़ देने पर डिप्लॉय तक सब अपने-आप हो जाता है, और इस बार जैसी रुकावट नहीं आती। हाँ, Vercel का मुफ़्त Hobby प्लान सिर्फ़ ग़ैर-व्यावसायिक इस्तेमाल के लिए है, और Google AdSense जैसे विज्ञापन लगाने हों तो पेड Pro (महीने का $20 से) चाहिए (Fair Use Guidelines)। इस बार जैसी PHP और MySQL वाली साइट के साथ इसका मेल भी अच्छा नहीं बैठता। तकनीक और होस्टिंग, दोनों शुरुआत में ही साथ तय कर लेना ज़रूरी है।

अपनी मशीन को दूर से चलवाने के जोखिम और रोज़ के Claude Code से इसका फ़र्क़, मैं एक अलग लेख में विस्तार से समझाने की योजना बना रहा हूँ। फ़ोन से अपनी मशीन का सेशन चलाने का तरीक़ा Remote Control वाले लेख में है।

8. किस काम के लिए ठीक है, किसके लिए नहीं

ठीक बैठता है

  • नई चीज़ जिसे अलग-अलग स्वतंत्र हिस्सों में बाँटा जा सके
  • काम जो आपके सोते समय या बाहर रहते हुए आगे बढ़ता रहे
  • ऐसी होस्टिंग जो GitHub से जुड़कर अपने-आप डिप्लॉय कर दे
  • जब सौंपे जाने वाले काम का दायरा शुरू में ही लिखकर तय किया जा सके

ठीक नहीं बैठता

  • ऐसा सर्वर जहाँ डिप्लॉय के लिए SSH और आपकी मशीन की key चाहिए
  • पहले से चल रहा काम जो आपकी मशीन के जाँच-टूल या अपनी प्रक्रियाओं पर गहराई से टिका हो
  • GitHub के बाहर रखी रिपॉज़िटरी
  • एक ही सेशन में निपट जाने वाले छोटे काम (क्लाउड सेशन काफ़ी है)

इस अनुभव से, शुरू करने से पहले जाँच लेने लायक़ बातें।

  • होस्टिंग: क्या GitHub में मर्ज होते ही अपने-आप डिप्लॉय होता है? अगर SSH चाहिए, तो पहले से तय कर लें कि सर्वर ख़ुद कोड खींचेगा या कोई और तरीक़ा होगा।
  • GitHub की अनुमतियाँ: Claude GitHub App किस दायरे में इंस्टॉल हो। अलग अकाउंट बनाइए, या रिपॉज़िटरी सीमित कीजिए।
  • सौंपने का दायरा: प्रोजेक्ट निर्देशों में सिर्फ़ वे बातें लिखिए जो इंसान से पूछनी हैं। CI और डिप्लॉय की सेटिंग के बदलाव मंज़ूरी से ही होने दीजिए।
  • नेटवर्क: बाहरी API या साइटें इस्तेमाल करनी हों, तो अनुमति-सूची में मुख्य डोमेन और सबडोमेन दोनों डालिए।
  • असली डेटा से जाँच: सैंपल डेटा वाले टेस्ट पास होने पर निश्चिंत मत होइए। आख़िर में एक थ्रेड ऐसा खोलिए जो प्रोडक्शन जैसा डेटा शुरू से आख़िर तक चलाकर देखे।
  • उपयोग-सीमा: थ्रेड का डिफ़ॉल्ट मॉडल जाँच लीजिए। पहले 24 घंटे में $100 तक का सेटअप क्रेडिट मिलता है।

सारांश

Projects ने "इंसान काम बाँटे, पीछे लगा रहे और हर बार वही पृष्ठभूमि दोबारा समझाए" वाली मेहनत सचमुच अपने सिर ले ली। रात में 3 काम समानांतर आगे बढ़े, थ्रेड आपस में तालमेल बिठाते रहे, और काम सौंप देने पर मर्ज और अगले काम का फ़ैसला भी ख़ुद करने लगे। काम की मात्रा के हिसाब से टोकन भी अपनी मशीन के Claude Code जितने ही लगे।

दूसरी तरफ़, हाथ में आता है एक कच्चा ढाँचा। काम को समानांतर बाँटने पर ज़िम्मेदारियों की सीमाओं पर दरारें खुलती हैं। सैंपल डेटा वाले सारे टेस्ट पास होने पर भी असली डेटा डालते ही बग निकलते हैं। और सिर्फ़ SSH से पहुँचने वाले सर्वर पर डिप्लॉय के साथ इसका मेल ख़राब है। इस्तेमाल करें तो तीन बातें पकड़कर रखिए — होस्टिंग GitHub से जुड़ी हो, सौंपने का दायरा शुरू में लिख दीजिए, और आख़िर में "असली डेटा से शुरू से आख़िर तक जाँचने" वाला एक थ्रेड खोलिए — तो इस बार जैसे चक्कर से बचा जा सकता है।

FAQ

Q. Projects का ख़र्च कितना है?

A. अलग से कोई शुल्क नहीं है; यह Pro या Max की आम उपयोग-सीमा से ही घटता है। इस बार उसके अलावा पहले क़रीब 24 घंटे के लिए एक "सेटअप क्रेडिट" मिला, जिसमें $100 तक का इस्तेमाल उपयोग-सीमा में नहीं गिना गया (यह स्क्रीन पर दिखा था; 28 सितंबर तक आधिकारिक दस्तावेज़ में इसका ज़िक्र नहीं है)। 10 थ्रेड और 11 PR के काम में क़रीब 19 करोड़ टोकन लगे और यह क्रेडिट पूरा ख़त्म हो गया। API की दरों में बदलें तो यह क़रीब $100 जितना काम है।

Q. क्या सच में PC बंद करने पर भी काम चलता रहता है?

A. हाँ। क्लाउड में चलने वाले थ्रेड PC बंद करने या स्लीप में डालने पर भी चलते रहे। इस बार भी रात के क़रीब 7 घंटों में 3 काम पूरे हो गए थे। हाँ, "Work locally" (लोकल रूप से काम) से अपनी मशीन पर खोले गए थ्रेड सिर्फ़ तब तक चलते हैं जब तक PC जागा हुआ है।

Q. क्या GitHub के बाहर की रिपॉज़िटरी के साथ भी चलता है?

A. कोड पर काम करने वाले थ्रेड के लिए ऐसी github.com रिपॉज़िटरी चाहिए जिस पर Claude GitHub App इंस्टॉल हो। इस बार कोड मेरे अपने git सर्वर पर था, इसलिए मैंने Claude के लिए अलग GitHub अकाउंट बनाकर वहाँ शुरू किया और आख़िर में सब अपनी मशीन पर वापस ले आया।

Q. बीच में प्रोजेक्ट के निर्देश बदलें तो क्या होता है?

A. समन्वयक पर यह तुरंत लागू हुआ, और मेरे कुछ कहे बिना काम का तरीक़ा बदल गया। पर उस समय चल रहे थ्रेड तक यह नहीं पहुँचता, इसलिए ज़रूरत हो तो नए थ्रेड में काम आगे बढ़वाइए। प्रोजेक्ट की मेमोरी में बचे पुराने नियम इंसान को सेटिंग से ख़ुद मिटाने पड़े।

Q. क्या "Work locally" सुरक्षित है?

A. कनेक्शन सिर्फ़ PC से बाहर की ओर जाने वाला एन्क्रिप्टेड कनेक्शन होता है, और कोई भी आने वाला पोर्ट नहीं खुलता। पर डेस्कटॉप ऐप की सेटिंग चालू करते ही इस्तेमाल के इतिहास से बनी फ़ोल्डर-सूची (इस बार 22 फ़ोल्डर, जिनमें एक पैरेंट फ़ोल्डर के भीतर के दर्जनों प्रोजेक्ट भी थे) दूर से काम शुरू किए जा सकने वाले निशाने बन जाती है। इसे सिर्फ़ इस्तेमाल के समय चालू रखना और लॉग-इन वाले अकाउंट का दो-चरणीय सत्यापन जाँच लेना — ऐसी सावधानियाँ ज़रूरी हैं।

Q. क्या बनी हुई चीज़ सीधे इस्तेमाल की जा सकती है?

A. इस बार नहीं। ढाँचा और SEO का काम अच्छा था, पर ज़िम्मेदारियों की सीमा वाला पूरा हिस्सा ग़ायब था, और असली डेटा पर बग भी निकले। लाइव करने से पहले असली डेटा डालकर पूरे सिस्टम को शुरू से आख़िर तक जाँचने का चरण ज़रूरी है।