प्लेटफ़ॉर्म का अवलोकन

Orquesta एक सहयोगी प्रॉम्प्ट ऑर्केस्ट्रेशन प्लेटफ़ॉर्म है जो सामान्य भाषा के प्रॉम्प्ट को प्रोडक्शन कोड में बदलता है। आपकी टीम लिखती है कि क्या बनाना है, और AI एजेंट कोड, PR और डिप्लॉयमेंट संभालते हैं।

प्लेटफ़ॉर्म कई निष्पादन मार्गों को सपोर्ट करता है: पूर्ण Claude CLI क्षमताओं के लिए WebSocket से जुड़ा लोकल एजेंट, सीधे SSH निष्पादन वाले क्लाउड VMs, स्वायत्त टास्क रूटिंग के लिए Batuta AI, और थर्ड-पार्टी AI इंटीग्रेशन के लिए External Agents API।

Quick Start

5 मिनट से कम में शुरू करें:

npm install -g orquesta-cli orquesta-agent\norquesta-agent --token YOUR_PROJECT_TOKEN

ऑनबोर्डिंग टूर

नए उपयोगकर्ताओं को डैशबोर्ड पर पहली बार आने पर एक इंटरैक्टिव गाइडेड टूर मिलता है। यह टूर सैंपल डेटा के साथ एक डेमो प्रोजेक्ट बनाता है और प्लेटफ़ॉर्म के 9 मुख्य हिस्सों से परिचित कराता है।

मुख्य अवधारणाएँ

लोकल एजेंट

orquesta-agent पैकेज आपकी लोकल मशीन को WebSocket के ज़रिए Orquesta डैशबोर्ड से जोड़ता है। यह प्रॉम्प्ट प्राप्त करता है, Claude CLI से उन्हें चलाता है और लॉग रियल-टाइम में वापस स्ट्रीम करता है।

# Install globally (orquesta-cli gives the `orquesta` command, orquesta-agent the daemon)\nnpm install -g orquesta-cli orquesta-agent\n\n# Or use npx (not recommended for VMs — can timeout)\nnpx orquesta-agent --token YOUR_TOKEN

प्रोजेक्ट से कनेक्ट करना

डैशबोर्ड से टोकन जनरेट करें (Project → Agent → Setup), फिर:

orquesta-agent --token oat_abc123...

प्रति प्रोजेक्ट मल्टी-एजेंट

एक ही प्रोजेक्ट से कई एजेंट कनेक्ट करें — एक आपके डेव लैपटॉप पर, दूसरा स्टेजिंग पर, तीसरा प्रोडक्शन पर। हर एजेंट का अपना टोकन होता है और वह स्वतंत्र रूप से चलता है।

# Dev laptop
orquesta-agent --token oat_dev_token --name "Dev Laptop"

# Staging server
orquesta-agent --token oat_staging_token --name "Staging VM"

# Production server
orquesta-agent --token oat_prod_token --name "Prod Server"

प्रॉम्प्ट सबमिट करते समय आप एजेंट चयनकर्ता ड्रॉपडाउन से चुन सकते हैं कि उसे कौन-सा एजेंट चलाए। सुविधाएँ:

• हरे संकेतकों के साथ प्रति-एजेंट ऑनलाइन/ऑफ़लाइन स्थिति
• एकाधिक एजेंट ऑनलाइन होने पर एजेंट चयनकर्ता ड्रॉपडाउन
• समानांतर निष्पादन — हर एजेंट प्रॉम्प्ट स्वतंत्र रूप से चलाता है
• --name फ़्लैग से कस्टम एजेंट नाम

एजेंट ये करेगा:

• Orquesta API से टोकन सत्यापित करना
• Supabase Realtime के ज़रिए WebSocket कनेक्शन स्थापित करना
• हर 30 सेकंड में हार्टबीट भेजना
• प्रोजेक्ट चैनल पर EXECUTE कमांड सुनना
• डैशबोर्ड को अपना वर्शन और क्षमताएँ रिपोर्ट करना

प्रॉम्प्ट निष्पादन प्रवाह

जब कोई प्रॉम्प्ट सबमिट किया जाता है:

1. डैशबोर्ड Realtime चैनल पर EXECUTE कमांड ब्रॉडकास्ट करता है
2. एजेंट उसे प्राप्त करके कतार में रखता है (केवल क्रमिक निष्पादन)
3. एजेंट प्रॉम्प्ट के साथ claude CLI प्रोसेस शुरू करता है
4. आउटपुट लॉग एंट्री के रूप में वापस Supabase में स्ट्रीम होता है
5. पूरा होने पर एजेंट स्थिति, git कमिट और टोकन उपयोग रिपोर्ट करता है

कोडिंग इंजन — कौन-सा CLI आपके प्रॉम्प्ट चलाता है

एजेंट में कोई मॉडल नहीं होता। यह मशीन पर पहले से इंस्टॉल और लॉग-इन कोडिंग CLI को शुरू करता है, इसलिए हर प्रॉम्प्ट आपकी सब्सक्रिप्शन पर चलता है। प्रति प्रोजेक्ट इंजन Settings → Agent में, प्रोजेक्ट हेडर के चिप से, या एजेंट कनेक्ट करते समय सेटअप विज़ार्ड में चुनें — विज़ार्ड वही पिकर और वही चिह्न दिखाता है, इसलिए इंजन पहले प्रॉम्प्ट के फ़ेल होने के बाद नहीं, उससे पहले चुना जाता है।

# Cursor's headless agent — install once on the agent machine
curl https://cursor.com/install -fsS | bash
cursor-agent login

# Windows (PowerShell)
irm 'https://cursor.com/install?win32=true' | iex

# AWS Kiro CLI — macOS / Linux, install once on the agent machine
curl -fsSL https://cli.kiro.dev/install | bash
kiro-cli login          # AWS Builder ID (free) or IAM Identity Center
kiro-cli whoami         # what the agent checks to show the login mark

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

दो अलग समस्याओं के लिए Settings → Agent में दो अलग चिह्न होते हैं। ✗ का मतलब है कि इंजन इंस्टॉल नहीं है — एजेंट अपने पास मौजूद अगले इंजन पर फ़ॉलबैक करता है। ! का मतलब है कि वह इंस्टॉल है लेकिन लॉग-इन नहीं है: कोई फ़ॉलबैक नहीं होता, क्योंकि बाइनरी मौजूद है, इसलिए प्रॉम्प्ट चलते हैं और इंजन के अपने ऑथ पर फ़ेल होते हैं, जब तक आप उस मशीन पर उसका लॉगिन नहीं चलाते (cursor-agent login, claude login, kiro-cli login). हर इंजन अपनी क्रेडेंशियल खुद रखता है — Orquesta उसे कभी नहीं देखता और आपकी ओर से लॉग-इन नहीं कर सकता।

IDE Hooks — Claude Code और Cursor सेशन को मिरर करें

ऊपर का फ़्लो dispatch है: Orquesta काम को agent तक भेजता है। Hooks इसकी उलटी दिशा हैं — आप अपने ही IDE में काम करते रहते हैं और Orquesta जो हुआ उसे मिरर करता है। आपके एडिटर में कभी कुछ वापस एक्ज़ीक्यूट नहीं होता, और कोई daemon चलाने की ज़रूरत नहीं है।

इसे हर repo में एक बार चलाएँ। --client के बिना यह दोनों टूल्स को जोड़ देता है:

# Claude Code + Cursor
orquesta-agent init --token oat_abc123...

# Only one of them
orquesta-agent init --token oat_abc123... --client cursor
orquesta-agent init --token oat_abc123... --client claude

यह .orquesta.json (प्रोजेक्ट बाइंडिंग — इसे gitignore में रखें, इसमें raw token होता है) के साथ .claude/settings.json और/या .cursor/hooks.json लिखता है। मौजूदा hooks सुरक्षित रहते हैं; दोबारा init चलाने पर डुप्लिकेट जमा होने के बजाय Orquesta's की एंट्रियाँ अपग्रेड हो जाती हैं।

मिरर किए गए prompts source: terminal और एक Local CLI बैज के साथ आते हैं; उसके बगल का टूल बैज cli_type कॉलम (claude-code या cursor-cli) से तय होता है। ये agent dispatch से बाहर रखे जाते हैं, इसलिए hook वाला सेशन दोबारा कभी एक्ज़ीक्यूट नहीं होता।

समस्या निवारण

डैशबोर्ड

डैशबोर्ड प्रोजेक्ट्स मैनेज करने, prompts सबमिट करने, एक्ज़ीक्यूशन मॉनिटर करने और अपनी टीम के साथ सहयोग करने का केंद्रीय हब है।

Home (/dashboard/home) चैट-फ़र्स्ट व्यू है: स्विचर से प्रोजेक्ट चुनें और उसके agent से बात करें। बायाँ रेल आपकी हिस्ट्री को दिन के हिसाब से समूहित करके दिखाता है — Home चैट, इंटरैक्टिव टर्मिनल सेशन, लोकल hook सेशन और अकेले prompts — और नया अकाउंट यहाँ एक तैयार पहले प्रोजेक्ट और चार-चरण वाली सेटअप चेकलिस्ट (मशीन तैयार, अपना मॉडल चुनें, पहला prompt, किसी को आमंत्रित करें — GitHub, Supabase और बाकी सब Advanced मोड में हैं) के साथ पहुँचता है। हर प्रोजेक्ट का अपना पता है, /dashboard/home/<projectId>। Advanced से आने पर वही प्रोजेक्ट बना रहता है जिस पर आप थे। जब किसी प्रोजेक्ट का इतिहास बन जाता है, तो सुझाव उसी से आते हैं — पहले खुले Auto Agent प्रस्ताव, फिर हाल के काम के अगले कदम। दाईं रेल छिपाई जा सकती है और उसमें Activity पैनल (एजेंट जो टूल चला रहा है, इंटरैक्टिव सेशन की तरह) और Artifacts पैनल (AI द्वारा बदली गई फ़ाइलें और बनाए गए लिंक) हैं। साइडबार का Operator / Advanced स्विच Home और पूरे डैशबोर्ड के बीच ले जाता है; Home केवल यह दिखाता है कि agent कहाँ चलता है, और उसे दोबारा कॉन्फ़िगर करना Advanced मोड में होता है। हर Home चैट एक चैट की तरह काम करती है: Claude CLI पर (agent 0.2.267+) हर चैट एक असली Claude सेशन है, जो हर नए मैसेज के साथ resume होता है, इसलिए Claude पूरी बातचीत याद रखता है — उसने क्या पढ़ा, चलाया और जवाब दिया — और "हाँ, कर दो" का मतलब वही होता है जिस पर अभी चर्चा हुई। अन्य CLIs, पुराने agents, या ऐसी मशीन पर जिसने वह चैट कभी देखी नहीं, मैसेज के साथ चैट के पिछले टर्न भेजे जाते हैं (आख़िरी 8, जगह के हिसाब से छाँटे हुए)। Agent के लॉग्स उसके जवाब के नीचे ही खुलते हैं, काम चलते समय लाइव, चैट छोड़े बिना। वही चैट्स Orquesta Terminal में भी हैं: इसका Operator बटन उन्हें आपके panes के ऊपर फ़ुल-स्क्रीन में खोलता है, ताकि आप Terminal डाउनलोड करके, साइन इन करके और डैशबोर्ड खोले बिना किसी भी प्रोजेक्ट के agent से बात कर सकें। Home अंग्रेज़ी, स्पेनिश और पुर्तगाली में उपलब्ध है। प्रोजेक्ट का Settings → Integrations टैब वह सब कुछ समूहित करता है जिससे वह जुड़ा है — Code (GitHub, लिंक की गई repository और PR फ़ीडबैक लूप के साथ), Ship (Vercel, Supabase), Work intake (Linear, Slack, Telegram) और Talent (Derplins) — हर एक अपनी स्थिति, जिससे वह लिंक है और एक disconnect बटन के साथ; skills और कस्टम सेटअप Advanced के अंतर्गत हैं। पुराना सेटअप विज़ार्ड हटा दिया गया है: ?setup=true वाले लिंक उस टैब पर पहुँचते हैं, या होस्टिंग के लिए VM व्यू पर।

मुफ़्त Orquesta मशीन। Google से साइन इन किए अकाउंट Home से या प्रोजेक्ट बनाते समय एक मुफ़्त क्लाउड मशीन पा सकते हैं, जिसमें agent और orquesta-cli पहले से इंस्टॉल होते हैं और प्रोजेक्ट Batuta पर चलने के लिए सेट होता है। यह 48 घंटे बिना prompts के रहने पर सो जाती है और जब आप कोई भेजते हैं तो अपने-आप जाग जाती है; शुरू होते समय prompt क्यू में इंतज़ार करता है। अतिरिक्त मशीनें सशुल्क हैं, प्रोजेक्ट के Agent टैब से।

Prompts और एक्ज़ीक्यूशन

Prompts टैब वह जगह है जहाँ आप AI agent के लिए काम सबमिट करते हैं। हर prompt में ये शामिल हो सकते हैं:

• कंटेंट — क्या बनाना है, इसका सामान्य भाषा में विवरण
• Tags — bug, feature, refactor, urgent, docs के रूप में वर्गीकृत करें
• असाइनमेंट — किसी विशेष टीम सदस्य को असाइन करें
• प्राथमिकता — ज़रूरी prompts पर स्टार लगाएँ
• Structured Specs — acceptance criteria के साथ bug report, feature spec या improvement टेम्पलेट इस्तेमाल करें

Prompts कई स्रोतों से आ सकते हैं:

प्रबंधन

प्रबंधन सेक्शन में ये शामिल हैं:

• Tickets — Linear इंटीग्रेशन या मैन्युअल रूप से बनाए गए कार्य आइटम ट्रैक करें
• Requirements — AI-सहायता प्राप्त विश्लेषण के साथ प्रोजेक्ट की आवश्यकताएँ परिभाषित और ट्रैक करें
• QA — क्वालिटी एश्योरेंस निर्देश और टेस्ट ट्रैकिंग
• Planning — आइटम्स, माइलस्टोन्स और AI-जनरेटेड ब्रेकडाउन के साथ प्लान बनाएँ

साउंड क्यूज़

डैशबोर्ड नतीजों के लिए छोटे सिंथेसाइज़्ड क्यूज़ बजाता है — रन का पूरा होना या फ़ेल होना, agent का कनेक्ट होना या कटना, और कोई भी चीज़ जो आपके इनपुट का इंतज़ार कर रही हो। Chrome शांत रहता है: मोडल खोलना, स्विच टॉगल करना या टैब बदलना कभी आवाज़ नहीं करता। Agent और चैट के क्यूज़ केवल तभी बजते हैं जब टैब बैकग्राउंड में हो।

इन्हें बंद करें, वॉल्यूम सेट करें, या हर क्यू को Profile → Sound में सुनकर देखें। यह प्राथमिकता हर डिवाइस पर अलग संग्रहीत होती है, और अगर आपका सिस्टम reduced motion माँगता है तो पूरा सेट अपने-आप म्यूट हो जाता है।

लॉग्स और हिस्ट्री

रीयल-टाइम लॉग स्ट्रीमिंग agent एक्ज़ीक्यूशन का हर चरण दिखाती है — चलाए गए कमांड्स, बदली गई फ़ाइलें, git ऑपरेशन्स और बहुत कुछ। लॉग्स स्तर (info, warning, error) और प्रकार (command, output, status, git) के हिसाब से वर्गीकृत होते हैं। History पेज प्रोजेक्ट की सारी गतिविधि की कालानुक्रमिक टाइमलाइन दिखाता है।

लाइव एक्टिविटी

साइड रेल का Activity टैब — टर्मिनल और prompt टाइमलाइन के बगल वाले समेटे जा सकने वाले पैनल का पहला आइकन — सरल भाषा में बताता है कि agent अभी क्या कर रहा है: “public-queries.ts को एडिट किया”, “टेस्ट सूट चला रहा है”। मौजूदा चरण सबसे ऊपर पिन रहता है; उसके नीचे अब तक का हर चरण है, हर फ़ाइल में जुड़ी और हटाई गई पंक्तियों के साथ, और सबसे नीचे एक बदली गई फ़ाइलोंका सारांश।

यह एक इंटरैक्टिव सेशन को सेशन स्ट्रीम से लाइव फ़ॉलो करता है, इसलिए यह orquesta-cli समेत हर CLI के लिए काम करता है, और Prompts टैब में यह चल रहे prompt को फ़ॉलो करता है। यह Logs टैब वाली ही स्ट्रीम है, उन लोगों के लिए पढ़ने योग्य बनाई गई जो टूल आउटपुट नहीं पढ़ना चाहते: बार-बार की फ़ाइल रीड एक पंक्ति में समेट दी जाती हैं, बुककीपिंग चरण छिपा दिए जाते हैं, और फ़ेल हुआ चरण raw payload के बजाय एरर दिखाता है। इसे बनाने के लिए कुछ नया रिकॉर्ड नहीं किया जाता।

हर चरण के साथ एक रंगीन एरिया चिप भी होता है, जो बताता है कि वह क्या बदलता है, न कि किस फ़ाइल को छुआ — Database, API, Interface,Dependencies, Deploy / CI, Config, Tests, Docs, या डिलीट, ड्रॉप और हार्ड रीसेट के लिए लाल Destructive। पैनल के ऊपर की समरी स्ट्रिप इन्हें जोड़ देती है, ताकि “इस रन ने डेटाबेस को तीन बार छुआ” एक भी फ़ाइल खोले बिना पढ़ा जा सके। जो चरण केवल कुछ पढ़ते हैं उनमें कोई चिप नहीं होती, क्योंकि पढ़ने से कुछ नहीं बदलता।

Artifacts — एजेंट की बनाई फ़ाइलें

जब कोई रन खोलने लायक कुछ बनाता है — HTML रिपोर्ट, चार्ट, PDF, CSV, बिल्ड की हुई साइट — तो एजेंट उसे पब्लिश कर सकता है: orquesta-cli में publish_artifact टूल है, और कोई भी CLI फ़ाइल को सीधे.orquesta/artifacts/ में लिख सकता है। प्रॉम्प्ट खत्म होने पर एजेंट (≥ 0.2.273) उन फ़ाइलों को अपलोड करता है और वे Operator के Artifacts कार्ड में सबसे ऊपर डाउनलोड लिंक के साथ दिखती हैं, 30 दिन तक रखी जाती हैं (हर फ़ाइल अधिकतम 25 MB, हर प्रॉम्प्ट 50 फ़ाइलें / 100 MB; .env और key जैसी फ़ाइलें कभी नहीं भेजी जातीं)। ऑन-डिमांड microVM पर यह हमेशा चालू रहता है, क्योंकि उसकी डिस्क सेशन के साथ खत्म हो जाती है। अपनी मशीनों पर यह वैकल्पिक है: Settings → Agent → Artifacts।

हर आर्टिफ़ैक्ट, और इंटरैक्टिव सेशन के Context files पैनल की हर फ़ाइल में दो बटन हैं: Open उसे नए टैब में दिखाता है (HTML, इमेज, PDF और टेक्स्ट डाउनलोड होने के बजाय दिखते हैं; बाकी डाउनलोड होते हैं), और Share एक सार्वजनिक getorquesta.com/share/… लिंक कॉपी करता है जिसे कोई भी बिना अकाउंट खोल सकता है। रेंडरिंग एक अलग स्टोरेज ओरिजिन पर होती है, getorquesta.com पर कभी नहीं, इसलिए AI की बनाई पेज आपके सेशन को छू नहीं सकती। लिंक उसी पंक्ति से रद्द किया जा सकता है, और आर्टिफ़ैक्ट की अवधि खत्म होने पर उसका लिंक भी बंद हो जाता है।

Claude Code के पास publish टूल नहीं है, इसलिए जब वह <antArtifact> ब्लॉक (HTML पेज, SVG, Markdown दस्तावेज़) के साथ जवाब देता है तो वह ब्लॉक prompt पूरा होने के कुछ सेकंड बाद उसी prompt के artifact के रूप में सहेजा जाता है — किसी सेटिंग की ज़रूरत नहीं। नए प्रोजेक्ट सेटअप कार्ड में एक छोटे उपयोग चरण (chat, interactive session, standalone prompts, embed या hook) से शुरू होते हैं जो तय करता है कि प्रोजेक्ट कहाँ खुलेगा; hosting चरण में Orquesta microVM भी है, जिसके हर संगठन के पहले 10 runs मुफ़्त हैं (फिर $0.25/घंटा)।

साइड रेल में Tasks

रेल का Tasks टैब इस प्रोजेक्ट में काम का इंतज़ार कर रही हर चीज़ का एक फ़ीड है — लोकल tickets, प्लान आइटम्स, Linear issues, शेड्यूल किए prompts और आपको असाइन किए prompts — हर एक पर उसके स्रोत का टैग, और स्रोत के हिसाब से फ़िल्टर करने की सुविधा।

Run वही करता है जो आप जिस स्क्रीन पर हैं वहाँ चलाने का मतलब है। इंटरैक्टिव सेशन में यह टास्क को सीधे लाइव टर्मिनल में भेज देता है। Prompts टैब में यह agent को dispatch करता है: जो टास्क पहले से prompt पंक्ति है — लोकल ticket, आपको असाइन किया prompt — वह वहीं चलता है, जिससे रन उसी से जुड़ा रहता है और खत्म होने पर ticket अपने-आप बंद हो जाता है; बाकी सब नया prompt बन जाता है। इसके बगल में, Start टास्क को भेजने के बजाय समीक्षा के लिए prompt बॉक्स में लोड करता है, और Prompt पहले स्टोरी को एक ठोस इम्प्लीमेंटेशन prompt में बदलता है।

मेमोरी और कॉन्टेक्स्ट

Memory पैनल स्थायी प्रोजेक्ट कॉन्टेक्स्ट संग्रहीत करता है जो हर prompt एक्ज़ीक्यूशन में शामिल किया जाता है। इसमें आर्किटेक्चर संबंधी निर्णय, कोडिंग कन्वेंशन, ज्ञात समस्याएँ और प्रोजेक्ट-विशिष्ट जानकारी शामिल है। Memory अपने-आप सारांशित होकर Claude CLI कॉन्टेक्स्ट में इंजेक्ट की जाती है।

ऑटो कॉन्टेक्स्ट

"yes", "deploy" या "do it" जैसे छोटे prompts को पिछले कुछ पूरे हुए टास्क्स का कॉन्टेक्स्ट अपने-आप मिल जाता है। Include Context टॉगल करने की ज़रूरत नहीं — agent को हमेशा पता होता है कि पहले क्या हुआ। लंबे prompts के लिए, स्पष्ट नियंत्रण हेतु Include Context टॉगल का उपयोग करें।

अगर agent को और जानकारी चाहिए तो वह एक्ज़ीक्यूशन के बीच में भी विस्तृत कॉन्टेक्स्ट ला सकता है:

# Agent can call this during execution
curl -s https://getorquesta.com/api/agent/recent-context \
  -H "Authorization: Bearer $ORQUESTA_TOKEN" | jq .

Auto Agent

Auto Agent आपके प्रोजेक्ट का विश्लेषण करता है — प्लान, हाल का काम, memory, खुले tickets — और तय करता है कि आगे क्या बनाना है। यह दो मोड में चलता है, दोनों प्रोजेक्ट के Auto Agent टैब से।

बैकग्राउंड मोड (propose & approve)। स्विच ऑन करें और शेड्यूल चुनें। हर साइकिल में agent प्रस्ताव लिखकर इनबॉक्स में रखता है — शीर्षक, यह क्यों मायने रखता है, चलाने के लिए सटीक prompt, और जोखिम रेटिंग। वह कोई कोड नहीं लिखता और कुछ भी एक्ज़ीक्यूट नहीं करता। आप दिन में एक बार इनबॉक्स देखते हैं, चाहें तो कोई भी prompt एडिट करते हैं, और जो करने लायक हैं उन्हें approve करते हैं; तभी agent काम करता है। अस्वीकृत प्रस्ताव याद रखे जाते हैं, इसलिए वह वही सुझाव दोबारा नहीं देता।

साइकिल सस्ती इसलिए हैं क्योंकि उनमें से ज़्यादातर होती ही नहीं: साइकिल तब छोड़ दी जाती है जब आपका लोकल agent ऑफ़लाइन हो, जब इनबॉक्स में पहले से प्रस्ताव इंतज़ार कर रहे हों (उसे खाली करना आपका काम है — और ढेर लगाना सिर्फ़ शोर है), और जब पिछली साइकिल के बाद कुछ बदला न हो (वही commit, कोई नया prompt नहीं)। तीनों का फ़ैसला डेटाबेस रीड्स से होता है, इसलिए निष्क्रिय प्रोजेक्ट पर नाममात्र का "हर 6 घंटे" बिल्कुल भी tokens खर्च नहीं करता।

Run now (फ़ोरग्राउंड)। मूल लूप, "Run now" के अंतर्गत: agent टास्क चुनता है और आपके देखते-देखते तुरंत उन्हें एक्ज़ीक्यूट करता है, आपके तय किए इटरेशन लिमिट तक। लूप सर्वर-साइड चलता है, इसलिए यह टैब बदलने, ब्राउज़र फ़्रीज़ और deploys के बाद भी चलता रहता है।

Autonomy (क्लिक के बिना चलाएँ)। Settings में, "Run approved work automatically" आपके तय किए लिमिट के भीतर के प्रस्तावों को बिना किसी के Approve क्लिक किए चलने देता है। यह डिफ़ॉल्ट रूप से बंद है और verification command के बिना चालू नहीं होगा — वह कमांड जो साबित करता है कि आपका प्रोजेक्ट अब भी काम करता है (npm test, pytest -q, make check)। जिस काम की कोई समीक्षा नहीं करता और कुछ सत्यापित नहीं करता वह ऑटोमेशन नहीं है, इसलिए Orquesta इसे करने से इनकार करता है।

हर ऑटोनॉमस रन आपके मौजूदा commit से निकली अपनी auto/… ब्रांच पर काम करता है, टास्क करता है, फिर आपका verification command चलाता है। exit 0 पर यह उसी तरह निपटता है जैसा आपके प्रोजेक्ट का git वर्कफ़्लो कहता है — fast-forward और push, या pull request खोलकर base ब्रांच को छोड़ देना। किसी अन्य exit code पर यह ब्रांच को revert करता है, repository को उसी commit पर लौटा देता है जहाँ से उसने शुरू किया था, और प्रस्ताव को विफलता की आख़िरी 100 पंक्तियों के साथ इनबॉक्स में लौटा देता है। यह कभी retry नहीं करता: हर प्रस्ताव के लिए एक मशीनी प्रयास, फिर इंसान तय करता है।

चार सीमाएँ इसे बाँधती हैं। एक जोखिम सीमा और एक आकार सीमा — इनसे ऊपर की हर चीज़ अब भी आपका इंतज़ार करती है, और जिस प्रस्ताव ने अपना जोखिम नहीं बताया उसे medium माना जाता है, इसलिए डिफ़ॉल्ट के तहत वह ब्लॉक रहता है। दो रोलिंग 24-घंटे के बजट, एक टास्क संख्या और एक डॉलर राशि, जो भी पहले खत्म हो (फ़्लैट-रेट मॉडल प्लान में प्रति रन सचमुच कुछ खर्च नहीं होता और $0 रिपोर्ट होता है, इसलिए वहाँ टास्क संख्या ही बाध्यकारी होती है)। और एक सर्किट ब्रेकर जो लगातार N विफलताओं के बाद प्रोजेक्ट को रोक देता है और किसी को चौंकाने वाला ईमेल नहीं भेजता — टैब कारण बताता है, और आप वहीं से इसे फिर शुरू करते हैं।

हर unattended रन "Autonomous runs" के अंतर्गत सूचीबद्ध होता है — उसकी ब्रांच, जिस commit से वह शुरू हुआ, verification exit code, ट्री वापस रखा गया या नहीं, और विफलता का आउटपुट। जो रन फ़ेल हुआ और जिसे revert नहीं किया जा सका, उसे लाल रंग में उजागर किया जाता है — यही वह एकमात्र मामला है जिसके लिए मशीन को देखना ज़रूरी है।

Workstreams (कई स्थायी सवाल, एक प्रोजेक्ट)। एक प्रोजेक्ट का शायद ही कभी एक ही उद्देश्य होता है। "bugs की triage करो", "ग्राहक फ़ीडबैक पढ़कर तय करो कि क्या बनाना है" और "मार्केटिंग और व्यावसायिक कार्रवाई देखो" तीन अलग सवाल हैं, और उन्हें एक साथ पूछने पर मॉडल जो सबसे ज़्यादा समझने योग्य लगे उसी में सिमट जाता है। प्रोजेक्ट के Workstreams पैनल में workstreams बनाएँ और Auto Agent टैब में एक सेलेक्टर आ जाता है: हर स्ट्रीम का अपना शेड्यूल, अपना इनबॉक्स, अपने लिमिट और अपना 24-घंटे का बजट होता है, और हर ब्रेन को बताया जाता है कि उसकी स्ट्रीम किसलिए है और कहा जाता है कि दूसरी स्ट्रीम में हाथ डालने के बजाय कुछ प्रस्तावित न करे।

Workstream किसी डायरेक्टरी की ओर इशारा कर सकती है, पर ज़रूरी नहीं। काम को स्ट्रीम परिभाषित करती है; डायरेक्टरी केवल यह तय करती है कि दो स्ट्रीम एक ही समय चल सकती हैं या नहीं। अलग-अलग डायरेक्टरी की स्ट्रीम समानांतर चलती हैं। एक ही डायरेक्टरी साझा करने वाली स्ट्रीम — और ऐसे प्रोजेक्ट की कोई भी स्ट्रीम जो एक ही फ़ोल्डर है — बारी-बारी चलती हैं, क्योंकि एक वर्किंग ट्री में दो ऑटोनॉमस ब्रांच ऐसी रेस है जिसे कोई नहीं जीतता। प्रोजेक्ट रूट की ओर इंगित स्ट्रीम बाकी सभी के विरुद्ध एक्सक्लूसिव होती है, क्योंकि उसमें वे सब समाए हैं।

वह डायरेक्टरी repository रूट के नीचे हो सकती है — जो स्ट्रीम repo/server की मालिक है वह फिर भी ब्रांच, commit और रोलबैक कर सकती है। फ़ाइलसिस्टम आइसोलेशन के तहत sandbox केवल वर्किंग डायरेक्टरी को writable बनाता है, इसलिए agent आसपास की repository की git डायरेक्टरी भी खोलता है (और worktree के लिए, वह मुख्य repository जिसमें वह ऑब्जेक्ट्स लिखता है)। इसके बिना ऐसी स्ट्रीम कोड एडिट कर सकती थी पर कभी ब्रांच नहीं बना पाती, और एरर किसी सेटिंग के बजाय खराब डिस्क जैसा पढ़ा जाता।

हर स्ट्रीम का एक kind होता है, क्योंकि हर सवाल commit पर खत्म नहीं होता। Code स्ट्रीम repository बदलती है: वह अपनी ब्रांच पर काम करती है, उसे verify command पास करना होता है, और न करने पर रोलबैक हो जाती है। Analysis स्ट्रीम पढ़ती और रिपोर्ट करती है — ग्राहक फ़ीडबैक, एरर लॉग्स, बाज़ार की स्थिति — और उसे verify command की ज़रूरत नहीं, क्योंकि पलटने को कुछ नहीं होता। Action स्ट्रीम repository के बाहर कुछ करती है, जैसे ईमेल भेजना या ticket दर्ज करना, और कभी भी unattended नहीं चलती: autonomy सेटिंग कुछ भी कहे, वह हमेशा किसी इंसान का इंतज़ार करती है। स्ट्रीम को Action पर बदलने से उसकी autonomy भी बंद हो जाती है।

स्वॉर्म व्यू। जब प्रोजेक्ट में दो या अधिक workstreams हों तो Auto Agent टैब उन्हें ग्राफ़ के रूप में दिखाता है: सबसे ऊपर रूट agent, उसके नीचे हर स्ट्रीम के लिए एक नोड, जिस पर kind, डायरेक्टरी, इनबॉक्स और 24-घंटे की गिनती होती है। हरा एज बताता है कि वह स्ट्रीम अभी चल रही है; एम्बर एज बताता है कि वह तैयार है और रुकी हुई है क्योंकि कोई और रन उसकी डायरेक्टरी थामे है — ऊपर वाला क्यू नियम, वर्णन के बजाय दिखाया हुआ। आप व्यू को प्रोजेक्ट सेटिंग्स से या प्रोजेक्ट बनाते समय किसी भी तरफ़ पिन कर सकते हैं, ऐसे प्रोजेक्ट के लिए जो पहली स्ट्रीम बनने से पहले ही स्वॉर्म होगा।

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

आपका टर्मिनल डिफ़ॉल्ट। उसी पैनल में Use as my terminal default है: उस प्रोजेक्ट के इंटरैक्टिव सेशन फिर उसी workstream को पहले से चुनकर खुलते हैं (टर्मिनल में Run in के बगल के स्टार से भी सेट किया जा सकता है)। यह आपकी अपनी प्राथमिकता है, आपके ब्राउज़र में रखी जाती है, टीम के बाकी लोगों को विरासत में नहीं मिलती। टर्मिनल हेडर हमेशा उस workstream का नाम बताता है जिसमें आप हैं (पेज रीलोड करने पर भी), और किसी workstream में शुरू हुआ सेशन उस workstream के विवरण को अपने मिशन के रूप में लोड करके खुलता है, ताकि agent पूछने के बजाय उसी से शुरू करे कि क्या करना है (agent 0.2.265 या बाद का)।

चल रहे सेशन में जुड़ने पर उसका अतीत बना रहता है। जब आप किसी ऐसे सेशन में जुड़ते हैं जो पहले से लाइव है, या किसी के चलते समय पेज रीलोड करते हैं, तो अब तक की बातचीत लाइव स्क्रीन बनने से पहले टर्मिनल के scrollback (और History पैनल) में लोड हो जाती है, इसलिए ऊपर स्क्रोल करने पर सिर्फ़ आख़िरी स्क्रीन नहीं, पहले के टर्न दिखते हैं। केवल Claude सेशन, agent 0.2.266 या बाद का।

ग्राफ़ के नीचे, What the swarm has done हर स्ट्रीम को पिछले चौदह दिनों के एक कालक्रम में मिला देता है — प्रस्ताव और रन आपस में गुँथे हुए, क्योंकि प्रस्ताव और उससे निकला रन एक ही कहानी हैं — पूरी अवधि के कुल योग के साथ: रन, सत्यापित, रोलबैक हुए, और rollback failed बाकी से अलग गिना जाता है, क्योंकि यह आख़िरी वाला बताता है कि मशीन पर एक ब्रांच छूट गई है। किसी भी पंक्ति पर क्लिक करके उस स्ट्रीम पर जाएँ जहाँ से वह आई है।

दैनिक डाइजेस्ट ईमेल उन चीज़ों को सूचीबद्ध करता है जो समीक्षा का इंतज़ार कर रही हैं, और केवल तभी जाता है जब कुछ नया आया हो — अनदेखा किया गया प्रस्ताव कभी रोज़ की टोका-टाकी नहीं बनता।

Meet — agent के साथ वीडियो कॉल

Meet, प्रोजेक्ट के Agent मेन्यू के अंतर्गत, आपके agent के साथ एक-क्लिक वीडियो कॉल है। "Start meet" दबाएँ: डैशबोर्ड पेज के भीतर ही meet.apuchat.com पर कॉल खोलता है और agent को उसमें जुड़ने भेजता है। ज़ोर से बोलें — आपकी आवाज़ आपके ब्राउज़र में ट्रांसक्राइब होती है और agent तक टेक्स्ट के रूप में पहुँचती है; उसके जवाब बोलकर सुनाए जाते हैं और कॉल के बगल के ट्रांसक्रिप्ट में भी दिखते हैं, इसलिए कॉल खत्म होने पर कही गई कोई बात खोती नहीं।

हर प्रोजेक्ट को अपना स्थायी meet रूम मिलता है, जो टीम चैट और कोऑर्डिनेशन चैनलों से अलग है, इसलिए agent केवल उसी कॉल में जगाया जाता है जो आपने शुरू की। "Invite" किसी और को लाने के लिए सुरक्षित लिंक और पासवर्ड दिखाता है; "Open in a new tab" वही कॉल डैशबोर्ड के बाहर चलाता है अगर आपका ब्राउज़र एम्बेडेड पेज में माइक्रोफ़ोन ब्लॉक करता है। जवाब देने के लिए agent का ऑनलाइन होना ज़रूरी है।

पुराने meets। डैशबोर्ड से हुआ हर meet टेक्स्ट के रूप में रिकॉर्ड होता है — किसने क्या कहा, कब — और "Start meet" कार्ड के नीचे उसकी तारीख़, अवधि और पंक्तियों की संख्या के साथ सूचीबद्ध होता है; पूरा ट्रांसक्रिप्ट पढ़ने के लिए कोई भी खोलें। रिकॉर्डिंग केवल ट्रांसक्रिप्ट है (कोई ऑडियो या वीडियो संग्रहीत नहीं होता), और इसे कॉल में मौजूद डैशबोर्ड टैब लिखता है, इसलिए जो meet केवल सामान्य ब्राउज़र टैब से जुड़ा हो वह सहेजा नहीं जाता।

मोबाइल पर। Meet Orquesta ऐप में भी है: कोई प्रोजेक्ट खोलें, "Meet with the agent" टैप करें, और कॉल इसी तरह ऐप के भीतर चलती है, लाइव ट्रांसक्रिप्ट और आपके पुराने meets के साथ। अगर agent dispatch चला देता है पर कमरे में रुकता नहीं, तो कॉल व्यू चुपचाप इंतज़ार करने के बजाय "agent didn't join" कहता है — कुछ प्रोजेक्ट अपने नियमों के कारण कॉल अस्वीकार कर देते हैं, और यह ईमानदारी से सामने रखा जाता है।

Agent कैसे जवाब देता है। आप जो भी कहते हैं उसका जवाब Orquesta की ओर के तेज़ मॉडल से मिलता है, जो वह सब पढ़ता है जो Orquesta को प्रोजेक्ट के बारे में पहले से पता है — उसके नोट्स, हाल के prompts और उनके नतीजे — इसलिए सवालों के जवाब आपकी मशीन को छुए बिना एक-दो सेकंड में मिल जाते हैं। जब आप असली काम माँगते हैं (कोड देखो, टेस्ट चलाओ, लॉग जाँचो, कुछ बदलो), तो वह "एक पल" कहता है और प्रोजेक्ट के agent को एक सामान्य prompt सौंप देता है; जब तक वह चलता है आपको हर आधे मिनट पर छोटा अपडेट सुनाई देता है, और नतीजा आते ही पढ़कर सुनाया जाता है। जब तक आप बोल रहे हों या काम चल रहा हो, agent कॉल में रहता है, और लगभग तीन मिनट की चुप्पी के बाद (अधिकतम 30 मिनट) चला जाता है। दोबारा बोलने पर वह फिर जुड़ जाता है।

Hey Orquesta — आपके सभी प्रोजेक्ट्स में हैंड्स-फ़्री वॉइस

Hey Orquesta (साइडबार में) एक वॉइस कंपेनियन है जो आपकी पहुँच वाले हर प्रोजेक्ट के ऊपर बैठता है — उन समयों के लिए जब आप चल रहे हों या गाड़ी चला रहे हों और स्क्रीन न पढ़ सकें। हैंड्स-फ़्री चालू करें, और वह सुनता है, ज़ोर से जवाब देता है और फिर सुनता है।

• "ehive-dev कैसा चल रहा है?" — Orquesta से पढ़कर बताता है: agent ऑनलाइन है या नहीं, क्या चल रहा है और उसकी ताज़ा लॉग पंक्तियाँ, और हाल में क्या पूरा हुआ। इसके लिए कोई agent नहीं जगाया जाता।
• "ehive-dev के agent से कहो कि टेस्ट चलाए" — उस प्रोजेक्ट पर एक सामान्य prompt बन जाता है, आपके नाम से, और agent तुरंत जगा दिया जाता है। प्रोजेक्ट पर prompts चलाने की अनुमति चाहिए।
• "ehive-dev के खत्म होने पर मुझे ईमेल करो" — चल रहा काम (या जो टास्क आपने अभी माँगा) पूरा होने या फ़ेल होने पर Orquesta आपको नतीजे के छोटे सारांश के साथ ईमेल करता है।

स्पीच रिकग्निशन और वॉइस आपके ब्राउज़र (Chrome, Edge या Safari) में चलते हैं। प्रोजेक्ट्स नाम से मिलाए जाते हैं, इसलिए मिलता-जुलता नाम भी चलता है; अगर दो प्रोजेक्ट मेल खाएँ तो वह पूछता है कि कौन सा। वही एंडपॉइंट, POST /api/companion/turn, डैशबोर्ड सेशन या एक oclt_ CLI token स्वीकार करता है, जो मोबाइल ऐप इस्तेमाल करता है।

Hey Orquesta Pro और Max प्लान में शामिल है — यह आपको तब मिलता है जब आप जिस भी organization के सदस्य हैं उनमें से कोई इनमें से किसी एक पर हो। अन्य प्लान पर स्क्रीन अपग्रेड कार्ड दिखाती है और एंडपॉइंट 402 लौटाता है।

जवाब Grok वॉइस में बोले जाते हैं (फ़ॉलबैक के तौर पर ब्राउज़र वॉइस के साथ), और भाषा स्क्रीन के ES/EN स्विच से चुनी जाती है। हर बातचीत सहेजी जाती है: हिस्ट्री बटन पुरानी बातचीतें सूचीबद्ध करता है और, किसी के भीतर, दिखाता है कि आपके सौंपे काम के साथ हर agent ने क्या किया (लाइव स्थिति और नतीजा)। जब आप पूछते हैं कि वह काम कैसा रहा, तो कंपेनियन अंदाज़ा लगाने के बजाय मौजूदा नतीजा पढ़ता है। पेज हेडर का orb इसे कहीं से भी खोलता है। हैंड्स-फ़्री मोड में बोलते समय माइक्रोफ़ोन खुला रहता है, इसलिए आप किसी भी पल नए अनुरोध के साथ बीच में बोल सकते हैं; सोचते समय वह चुप हो जाने के बजाय छोटा सा "एक पल" कहता है।

टीम सहयोग

Orquesta बारीक अनुमतियों के साथ चार भूमिकाओं को सपोर्ट करता है:

प्रोजेक्ट चैट

हर प्रोजेक्ट में Supabase Realtime से चलने वाली बिल्ट-इन रीयल-टाइम चैट होती है। इसमें थ्रेडेड बातचीत, फ़ाइल अटैचमेंट, रीड रिसीट और टाइपिंग इंडिकेटर शामिल हैं। चैट prompts पर चर्चा करने, आउटपुट की समीक्षा करने और काम का समन्वय करने के लिए आदर्श है।

प्रोजेक्ट एजेंट से पूछें। किसी प्रोजेक्ट की चैट में @agent टाइप करें और वह उस प्रोजेक्ट के अपने इतिहास से जवाब देता है — आखिरी बार क्या चला, कैसा रहा, और अभी क्या बाकी है। वह केवल रिपोर्ट करता है; कुछ भी नहीं चलाता, और सिर्फ़ उसी प्रोजेक्ट के बारे में जानता है जिसमें वह रहता है। हैंडल हर प्रोजेक्ट का अलग होता है — उसे Settings → Agent → Chat Handle में नाम दें (जैसे @elclaudio) — और वह उसी थ्रेड में जवाब देता है जिसमें आपने पूछा था। जवाब सर्वर से आते हैं, इसलिए एजेंट मशीन ऑफ़लाइन होने पर भी वे काम करते हैं।

किसी संदेश को टास्क बनाएँ। किसी भी चैट संदेश पर होवर करें और टास्क आइकन दबाएँ ताकि वह प्लान आइटम के रूप में खुले — शीर्षक और विवरण संदेश से पहले से भर जाते हैं, और आप प्लान तथा असाइनी चुनते हैं। टास्क पर From chat बैज लगा रहता है ताकि आप जान सकें कि बातचीत में क्या उठाया गया था।

मीट शुरू करें। चैट हेडर में Meet बटन प्रोजेक्ट का वीडियो रूम खोलता है और बातचीत में एक Join कार्ड पोस्ट करता है, जिससे पढ़ने वाला कोई भी एक क्लिक में जुड़ सकता है। वीडियो और ऑडियो ब्राउज़र से ब्राउज़र तक जाते हैं — रूम सिर्फ़ सिग्नलिंग ले जाता है, और उसमें कही गई कोई भी बात रिकॉर्ड नहीं होती। Join दबाने पर हर व्यक्ति को अपना लिंक मिलता है, इसीलिए कार्ड एक बटन है, पेस्ट करने वाला URL नहीं।

एजेंट से एजेंट अनुरोध

एक प्रोजेक्ट का एजेंट दूसरे प्रोजेक्ट के एजेंट से पूछ सकता है। किसी संगठन के भीतर एजेंट GET /api/agent/directory से अपने साथियों की सूची देखता है और POST /api/agent/requests से अनुरोध भेजता है: consulta (प्रश्न, दूसरी ओर केवल-पढ़ने के मोड में चलता है, अपने-आप स्वीकृत) या encargo (काम का आदेश, प्रोजेक्ट के Callable टैब में किसी व्यक्ति की स्वीकृति का इंतज़ार करता है)। अनुरोध लक्ष्य प्रोजेक्ट पर एक सामान्य prompt है; पूरा होने पर उत्तर पूछने वाले प्रोजेक्ट में फ़ॉलो-अप prompt के रूप में लौटता है, या वह GET /api/agent/requests/{id} पोल करता है, जो बनाई गई फ़ाइलों के डाउनलोड लिंक भी देता है (हर फ़ाइल 256 MB तक)। शृंखला अधिकतम दो कदम, लूप अस्वीकार, और हर प्रोजेक्ट की दैनिक सीमा है। केवल coordination सक्षम (settings.coordination.enabled) प्रोजेक्ट सूची में आते हैं और एक-दूसरे से पूछ सकते हैं; अनुरोध में वैकल्पिक timeout_min (consulta 30, encargo 240, अधिकतम 720) होता है, जिसके बाद वह रद्द हो जाता है; एजेंट टोकन को स्रोत IP से बाँधा जा सकता है।

स्थायी handle और मालिक को DM। हर प्रोजेक्ट एजेंट के पास कभी न ख़त्म होने वाला @<project>-agent handle हो सकता है, जिसकी अनुमति-सूची में मालिक होता है। किसी निर्णय पर अटका एजेंट POST /api/agent/dm से अनुमति-प्राप्त व्यक्ति को लिखता है; 24 घंटे तक का उत्तर एक prompt बन जाता है जो एजेंट को उसका अपना प्रश्न और उसे भेजने वाला कार्य दिखाता है।

एजेंट पहचान

Settings → Agent Identity वह एकमात्र जगह है जो “यह एजेंट कौन है और उस तक कैसे पहुँचें” का जवाब देती है। एजेंट जिन भी पतों पर जवाब देता है, वे पहले अलग-अलग स्क्रीन पर थे — चैट हैंडल Settings में, Apuchat @handle Coordination में, ईमेल Inbox पेन में — इसलिए पूरी पहचान एक साथ कोई नहीं देख पाता था। यह टैब सब कुछ एक जगह जमा करता है। पहचान हर प्रोजेक्ट की अपनी होती है, और यह टैब केवल owners और admins के लिए है।

एजेंट को उसका अपना ईमेल दें। डिफ़ॉल्ट रूप से एजेंट का ईमेल एक डिस्पोज़ेबल apumail इनबॉक्स होता है, जो किसी बाहरी एजेंट को एक बार की बातचीत के लिए पता देने के लिए सही है और जिस पर आप लगातार संदेश पाना चाहते हैं उसके लिए गलत — apumail उसे 24h निष्क्रिय रहने के बाद छोड़ देता है। यहाँ एक पता सेट करें (apumail द्वारा सर्व किया जाने वाला कोई भी मेलबॉक्स, साथ में उसका inbox token) और वही एजेंट का ईमेल बन जाता है; डिस्पोज़ेबल इनबॉक्स जहाँ है वहीं रहता है और जवाब नहीं रह जाता। token को सेव करने से पहले apumail के सामने सत्यापित किया जाता है, एन्क्रिप्टेड रूप में रखा जाता है, और दोबारा कभी नहीं दिखाया जाता — जो token सिर्फ़ सेव हुआ हो वह बाद में ऐसे मेलबॉक्स के रूप में फ़ेल होता है जो खराब नहीं, खाली दिखता है।

कॉन्फ़िगर किया गया पता ही वह है जिसे प्रोडक्ट इस्तेमाल करता है। एक बार पहचान ईमेल सेट हो जाए, तो इंटरैक्टिव सेशन में Inbox पेन डिस्पोज़ेबल मेलबॉक्स की जगह वही मेलबॉक्स पढ़ता है और अपने Replace/Release बटन हटा लेता है: वे ऐसा पता बनाते जिस पर एजेंट जवाब नहीं देता। पहचान मेलबॉक्स को हटाना यहीं किया जाता है, जहाँ उसे सेट किया गया था।

एक Apuchat callsign, दो नहीं। जिस @handle पर लोग रिंग करते हैं, वही अब वह callsign भी है जो एजेंट coordination चैनलों और वीडियो कॉल में शामिल होते समय इस्तेमाल करता है, इसलिए जिसने भी @your-agent को रिंग किया वह कमरे में मशीन-जनित नाम की जगह @your-agentसे ही मिलता है। अगर हैंडल काम करना बंद कर दे तो एजेंट एक अस्थायी callsign पर लौट आता है और जुड़ना जारी रखता है, और आप प्रकाशित हैंडल को इस टैब से ठीक करते हैं: Renew उसे वहीं का वहीं फिर जिला देता है, और केवल वही हैंडल बदला जाता है जिसे Apuchat ने सचमुच छोड़ दिया हो — पता बदलने पर टैब यह साफ़ बताता है, क्योंकि पुराना पता रखने वाले हर व्यक्ति को सूचित करना ज़रूरी है।

Callable & DM handle कार्ड हर जगह वही एक कार्ड है जहाँ भी वह दिखता है। प्रोजेक्ट बार के Agent मेनू में उसकी अपनी एंट्री है, जहाँ तब जाएँ जब काम कॉल करने वालों को प्रबंधित करना हो, न कि कोई चैनल पढ़ना; वह अब भी Coordination में दिखता है, जहाँ वह हमेशा से रहा है; वह Settings → Agents का एक सेक्शन है, उस मशीन के बगल में जिसे वह रिंग करता है; और वह Agent Identity की Apuchat पंक्ति में समाया हुआ है, ताकि जो व्यक्ति यह पूछने आया कि एजेंट तक कैसे पहुँचें, उसे जवाब पर अमल करने के लिए किसी दूसरे टैब पर न भेजा जाए। एक ही कंपोनेंट चार जगह माउंट होता है, चार कॉपी कभी नहीं, इसलिए वे एक-दूसरे से अलग नहीं हो सकते। मुफ़्त हैंडल 24h बाद समाप्त हो जाता है और इनमें से किसी भी जगह से रिन्यू किया जा सकता है। अगर आप चाहते हैं कि वह कभी समाप्त न हो, तो apuchat.com/account पर एक खरीदें (5 USDC) और उसकी identity key के साथ उसे यहाँ जोड़ें: key को सेव करने से पहले Apuchat के सामने जाँचा जाता है, इसलिए गलत पेस्ट अभी फ़ेल हो जाता है बजाय इसके कि ऐसे हैंडल के रूप में दिखे जो चुपचाप कभी रिंग नहीं होता। जोड़ा गया हैंडल भी मुफ़्त वाले की तरह पुश किया जाता है: Orquesta उस पर अपनी identity key से एक webhook रजिस्टर करता है, इसलिए रिंग लगभग एक सेकंड में एजेंट तक पहुँच जाती है। apuchat.com पर key रोटेट करने से वह webhook रिटायर हो जाता है; तब तक poll cron उस हैंडल को सर्व करता है जब तक आप नई key नहीं जोड़ देते।

हैंडल को भेजा गया संदेश एक prompt है, और जवाब रिप्लाई के रूप में लौटता है। हैंडल की शुरुआत दरवाज़े की घंटी के रूप में हुई थी: वह रिंग इनवाइट को पार्स करता था और एजेंट को वीडियो कॉल में ले जाता था, और जो सादा संदेश इनवाइट नहीं था उसे पढ़ा जाता, बेदिलचस्प पाया जाता और छोड़ दिया जाता — कर्सर समेत, इसलिए बाद में वह दिखता ही नहीं था। बाहर से यह उस एजेंट से अलग नहीं दिखता जो आपको अनदेखा करता है। अब @your-agent को लिखी गई हर चीज़ रिंग जैसे ही caller gate से गुज़रती है, कॉलर के scopes के साथ आपकी अपनी मशीन पर एक prompt बन जाती है, और उसका जवाब भेजने वाले को चैट संदेश के रूप में वापस भेजा जाता है। कार्ड का Messagesसेक्शन ही बातचीत है: हर कॉलर के थ्रेड, एजेंट के जवाब उसके अपने के रूप में चिह्नित, हैंडल के रूप में हाथ से जवाब लिखने का एक बॉक्स, और जिन संदेशों को लौटा दिया गया वे वहीं दिखते हैं उसी एक-क्लिक allow to talk के साथ — जो इनकार आप देख सकते हैं वह उस चुप्पी से बेहतर है जो आप नहीं देख सकते। जवाबों की लंबाई सीमित है और लंबे जवाब डैशबोर्ड की ओर इशारा करते हैं; एक कॉलर के एक समय में अधिकतम तीन संदेशों पर काम हो सकता है, ताकि बिना निगरानी वाला हैंडल किसी की मशीन पर असीमित काम कतार में न लगा सके। बाकी का काम डेटाबेस की दो यूनिकनेस नियम करते हैं: हर आने वाले संदेश के लिए एक रिकॉर्ड, ताकि webhook और मिनट वाला poll दोनों उस पर कार्रवाई न कर सकें, और हर prompt के लिए एक रिप्लाई, ताकि completion hook और बैकस्टॉप cron दोनों जवाब न दे सकें।

उसे कौन रिंग कर सकता है। हैंडल प्रकाशित होता है, और रिंग आपकी अपनी मशीन पर एक prompt चलाती है — इसलिए Apuchat जो हस्ताक्षर भेजता है वह साबित करता है कि संदेश पहुँचा, यह नहीं कि किसने रिंग किया। इसलिए नया हैंडल restricted बनाया जाता है: यह एक allowlist है, और आप उन कॉलर @handles के नाम देते हैं जिन्हें अनुमति है और हर कॉलर के लिए चुनते हैं कि वह क्या माँग सकता है — talk, read code, run commands, deploy / spend। किसी तीसरे पक्ष को बातचीत की अनुमति दी जा सकती है बिना कुछ चलाने की अनुमति दिए, और कॉल के दौरान कही गई कोई बात उस सूची को चौड़ा नहीं करती। जिस व्यक्ति का हैंडल आप पहले से नहीं जान सकते, उसके लिए एक साझा passcode बनाएँ — हम उसे बनाते हैं, आप उसे नहीं चुनते, और वह बनाते समय एक बार दिखाया जाता है क्योंकि हम सिर्फ़ उसकी एन्क्रिप्टेड कॉपी रखते हैं। वे रिंग संदेश में passcode: the-code लिखते हैं और उन्हें वही scopes मिलते हैं जो आपने passcode को दिए थे।

Open to anyone दूसरी सेटिंग है, और यह सोच-समझकर चुनी जाने वाली है: इसे चुनने पर चेतावनी आती है और हर अजनबी को सबसे संकरे अनुदान पर बाँध दिया जाता है, talk केवल, उसे बढ़ाने का कोई तरीका नहीं। “किसी को भी” दिया गया चौड़ा अनुदान ठीक वही है जो यह सेटिंग नहीं बन सकती, इसलिए scope पिकर सिर्फ़ डिफ़ॉल्ट नहीं, लॉक कर दिए जाते हैं। कॉलर अनुमतियों से पहले मौजूद हैंडल open के रूप में पढ़े जाते हैं, और वही सीमा अब उन पर भी लागू होती है। हर रिंग किसी भी स्थिति में लॉग होती है, इसलिए अस्वीकृत कॉलर सर्वर लॉग में गुम होने की जगह allow to talk शॉर्टकट के साथ दिखता है।

चैट का @mention और चैनल सूची यहाँ केवल-पढ़ने योग्य रहती हैं और उस स्क्रीन की ओर इशारा करती हैं जिसके पास उनका स्वामित्व है — एक ही फ़ील्ड के लिए दूसरा कंट्रोल ऐसा दूसरा कंट्रोल है जो पहले से असहमत हो सकता है।

Prompt टिप्पणियाँ

हर prompt पर कोड रिव्यू चर्चा के लिए एक कमेंट थ्रेड होता है। आप @mentions से टीम सदस्यों का उल्लेख कर सकते हैं, AI-जनित कोड पर फ़ीडबैक जोड़ सकते हैं, और merge करने से पहले बदलावों पर चर्चा कर सकते हैं।

प्लानिंग और स्पेक्स

प्लानिंग सिस्टम आपको संरचित प्लान बनाने देता है, जिनके आइटम prompts या टिकट में बदले जा सकते हैं। AI उच्च-स्तरीय विवरणों से प्लान ब्रेकडाउन बना सकता है। संरचित स्पेक्स (बग रिपोर्ट, फ़ीचर अनुरोध, सुधार) में स्वीकृति मानदंड होते हैं जो निष्पादन के दौरान AI का मार्गदर्शन करते हैं।

आइटम चलाना। किसी भी प्लान आइटम पर ▶ दबाएँ ताकि वह एजेंट को prompt के रूप में भेजा जाए। फिर आइटम उस prompt की लाइव स्थिति दिखाता है और सीधे उसी से लिंक होता है, इसलिए प्लान सिर्फ़ वर्णन करने की जगह अपना निष्पादन खुद ट्रैक करता है। पहले से चल रहे आइटम को दो बार डिस्पैच नहीं किया जा सकता; prompt पूरा होने के बाद ▶ उसे दोबारा चलाता है — किसी रन के फ़ेल होने पर उपयोगी।

बोर्ड व्यू। Planning और Tickets दोनों के हेडर में सूची/बोर्ड टॉगल है। Plans आइटम की स्थिति के अनुसार बोर्ड बनाते हैं; Tickets आपकी टीम की असली Linear वर्कफ़्लो स्थितियों के अनुसार — कॉलम वही हैं जो आपकी टीम ने कॉन्फ़िगर किए, Linear के अपने क्रम और रंगों में। टिकट को कॉलमों के बीच खींचने पर स्थिति Linear में वापस लिखी जाती है, और Linear के मूव अस्वीकार करने पर कार्ड वापस लौट जाता है। बोर्ड हमेशा हर टिकट दिखाता है, इसलिए उसके खुले रहने पर स्थिति टैब किनारे हो जाते हैं।

लोकल टिकट संपादित करना। Orquesta में बनाए गए टिकट बाद में भी संपादित, असाइन और आर्काइव किए जा सकते हैं — इसका मामला वह QA पास है जो टिकट बनाता है और फिर सेशन के बीच में पाता है कि शीर्षक गलत था, प्रकार गलत था, या उसे और विवरण चाहिए। ✎ टिकट का शीर्षक, प्रकार और markdown बॉडी खोलता है, जो ठीक वही है जो एजेंट को मिलता है जब आप उसे चलाते हैं। Assignउसे किसी भी प्रोजेक्ट सदस्य को सौंपता है। Archive उसे टिकट सूची और टाइमलाइन से बाहर कर देता है बिना कुछ मिटाए — उसके लॉग, कमेंट और लागत सुरक्षित रहते हैं, और हेडर में Archived आर्काइव किए गए टिकट को वापस दिखाता है ताकि उन्हें रीस्टोर किया जा सके। जिस टिकट को एजेंट अभी चला रहा है उसे केवल दोबारा असाइन किया जा सकता है; संपादन और आर्काइव रन खत्म होने तक रुकते हैं।

लोकल टिकट, Linear के साथ या उसके बिना। कनेक्टेड प्रोजेक्ट लोकल टिकट भी बनाता है — फ़ीडबैक विजेट उन्हें वहीं लिखता है — इसलिए Tickets हेडर में एक Linear / Local स्विच है। दोनों सूचियाँ जान-बूझकर अलग रखी गई हैं: केवल Linear issues को आपकी टीम की वर्कफ़्लो स्थितियों के बीच खींचा जा सकता है, और मिली-जुली सूची ऐसी कार्रवाइयाँ पेश करती जो आधी पंक्तियों पर ही काम करतीं।

लोकल बोर्ड, स्प्रिंट और माइलस्टोन। लोकल टिकटों का अपना बोर्ड है — Backlog, To Do, In Progress, In Review, Done — और उसे Linear की बिल्कुल ज़रूरत नहीं। कार्ड में दो अलग स्थितियाँ होती हैं: रन (draft → pending → running → done) और वह कॉलम जिसमें किसी ने उसे खींचा। जिस कार्ड को किसी ने छुआ नहीं, वह अपना कॉलम रन से लेता है, इसलिए एजेंट पर पूरा होने वाला टिकट अपने आप Done में चला जाता है; एक बार आप उसे खींच दें, तो आपका कॉलम जीतता है और अगला रन उसे वापस नहीं खींचेगा। टिकटों को किसी sprint या milestone के अंतर्गत समूहित करें (दोनों एक ही चीज़ हैं — sprint बस तारीखों वाला होता है) और सूची के ऊपर का चिप done/total और बचे दिन दिखाता है, और अंतिम तिथि बीत जाने पर काम खुला रहने की स्थिति में लाल हो जाता है।

टिकट चलाना। एक से दस लोकल टिकटों के बॉक्स टिक करें और बार उन्हें चलाने के दो तरीके देता है। एकल टिकट अपने आप में चलता है — उसकी अपनी बॉडी ही prompt है, और रन, उसके लॉग और नतीजा उसी टिकट से जुड़े रहते हैं, जिससे रन खत्म होने पर टिकट खुद बंद हो पाता है। Run together एक prompt बनाता है — पहले क्रमांकित सूची ताकि एजेंट पूरे सेट पर योजना बना सके, फिर हर टिकट की बॉडी उसके अपने शीर्षक के नीचे — उसे एजेंट को डिस्पैच करता है और उन कार्डों को In Progress में ले जाता है। Send to session वही prompt बनाता है लेकिन उसे इंटरैक्टिव टर्मिनल को सौंपता है, जहाँ कुछ भी भेजे जाने से पहले वह आपकी समीक्षा के लिए एक बैनर में प्रतीक्षा करता है। इनमें से कोई भी ऐसा टिकट नहीं चलाता जो पहले से चल रहा हो।

टिकट विवरण। लोकल टिकट के शीर्षक पर क्लिक करना — सूची में या बोर्ड पर — उसे खोलता है। बायाँ कॉलम वह टिकट है जैसा एजेंट उसे देखता है: markdown बॉडी, रन का नतीजा या त्रुटि, और कमेंट थ्रेड। दायाँ कॉलम उसके बारे में वह सब है जो टेक्स्ट नहीं है: status, assignee और sprint वहीं संपादित किए जा सकते हैं, और उनके नीचे किसने और कब बनाया, आखिरी बार कब छुआ गया, उसके टैग और वह कहाँ से आया यह दिखता है। जब टिकट चलाया जा चुका हो, तो रन ब्लॉक इंजन और मॉडल, जिस ब्रांच और कमिट पर वह उतरा, और उसकी लागत बताता है। Run, Send to session, Edit और Archive फ़ुटर में हैं, इसलिए पैनल अपने आप में पर्याप्त है — कार्रवाई करने के लिए आपको सूची में वापस जाने की ज़रूरत नहीं।

टिकट खुद बंद होता है। जब रन running पर पहुँचता है तो टिकट In Progress में चला जाता है, और पूरा होने पर Done में — In Review से भी, क्योंकि पूरा हुआ रन आगे की गति है। वह कभी किसी इंसान के किए को पलटता नहीं: Done या Canceled में पड़ा कार्ड कभी दोबारा नहीं खोला जाता, In Review में रखा कार्ड रन के दौरान पीछे नहीं खींचा जाता, और फ़ेल हुआ रन कुछ भी नहीं लिखता, ताकि रीट्राई वहीं से शुरू हो जहाँ आपने छोड़ा था।

स्प्रिंट की तारीखें। स्प्रिंट बनाना आज से शुरू होता है और एक हफ़्ते बाद खत्म होता है, साथ में 1w / 2w / 1m प्रीसेट और दिनों की चलती गिनती है, इसलिए आम मामला एक क्लिक का है। अंतिम तिथि शुरुआत से पहले नहीं हो सकती — सीमा उलटी होने पर Create अक्षम रहता है, ऐसा स्प्रिंट सेव करने की जगह जो पहले ही खत्म हो चुका हो।

Assisted Mode — QA दस्तावेज़ भेजता है, आप diff की समीक्षा करते हैं

Assisted Mode उस क्षण के लिए है जब कोई QA टीममेट पास पूरा करता है और उसके पास निष्कर्षों का एक पन्ना होता है। पूरा दस्तावेज़ प्रोजेक्ट पेज पर Assisted में पेस्ट करें। Orquesta उसे एक ही दस्तावेज़ के रूप में पढ़ता है — निष्कर्षों को आपस में डीडुप्लिकेट और क्रमबद्ध किया जाता है, एक-एक prompt के रूप में नहीं सँभाला जाता — और हर निष्कर्ष को चार फ़ैसलों में से एक में छाँटता है।

वह रेखा जो वह खींचता है स्पष्ट दोष बनाम प्रोडक्ट निर्णय है, कठिनाई कभी नहीं। "Save बटन कुछ नहीं करता" अपने ही लेबल का खंडन करता है, इसलिए वह बिना निगरानी चलता है, भले ही सुधार कठिन हो। "रन खत्म होने पर ग्राहक को ईमेल भेजना चाहिए" ऐसा नया व्यवहार है जिस पर किसी ने सहमति नहीं दी, इसलिए वह किसी इंसान का इंतज़ार करता है — भले ही उसे बनाना मामूली हो।

पहले चलाएँ, बाद में समीक्षा करें। यही auto-evaluate से अंतर है, जो prompt को चलने से पहले रोकता है। यहाँ रिव्यूअर ऐसा diff खोलता है जो पहले से मौजूद है: असली फ़ाइलें, असली लाइन गिनती, असली कमिट। किसी इरादे को मंज़ूर करना और किसी बदलाव को मंज़ूर करना एक जैसी समीक्षा नहीं हैं, और उनमें से सिर्फ़ एक ही ठीक से की जा सकती है।

एक रन, एक ब्रांच, एक PR। रन का हर आइटम एक assisted/YYYYMMDD-xxxxxxxx ब्रांच साझा करता है और सख़्ती से एक समय में एक चलता है। पूरे रन के लिए Auto-deploy सर्वर-साइड अस्वीकृत है — असिस्टेड ब्रांच कभी अपने आप प्रोडक्शन तक नहीं पहुँचती, प्रोजेक्ट की डिप्लॉयमेंट सेटिंग्स चाहे जो हों।

diff गेट। एजेंट का बनाया हर diff अगला आइटम शुरू होने से पहले जाँचा जाता है। माइग्रेशन, क्रेडेंशियल जैसी फ़ाइलें, डिलीशन, बहुत बड़ा बदलाव, या कोई दावा किया गया सुधार जिसने कुछ नहीं बदला, ये सब रन को रोक देते हैं — आइटम N+1 को कभी ऐसे diff पर नहीं लादा जाता जिसे किसी ने पढ़ा नहीं। डिपेंडेंसी, CI, auth और बाइनरी बदलाव कतार रोके बिना रिव्यूअर के लिए फ़्लैग किए जाते हैं। हर फ़्लैग कार्ड पर उस कारण के साथ दिखता है जिससे वह लगा।

कौन क्या करता है। कोई भी प्रोजेक्ट सदस्य रन शुरू कर सकता है — QA के पास ट्रिगर करने का अधिकार है, यही असली मक़सद है। समीक्षा अलग है: वह प्रोजेक्ट owners और admins की है, साथ में हर वह व्यक्ति जिसेAssisted reviewer के रूप में Team → member permissions में चिह्नित किया गया हो। रिव्यूअर को हर रन पर एक सूचना मिलती है और केवल वही एस्केलेट किए गए निष्कर्ष को मंज़ूर, अस्वीकार या कतार में लगा सकते हैं। उत्पत्ति सेशन से दर्ज की जाती है, रिक्वेस्ट बॉडी से नहीं।

“मैं करूँगा” — आइटम खुद लेना। जिस निष्कर्ष को प्रोडक्ट निर्णय चाहिए, उसे वर्णन करने से टर्मिनल में निपटाना अक्सर तेज़ होता है। Needs your call का हर कार्ड मैं करूँगा बटन रखता है: वह आइटम ले लेता है, रन की ब्रांच पर पहले से तैयार इंटरैक्टिव सेशन खोलता है, और सेशन हेडर में आपको यह बता देता है। सीरियल नियम इंसानों पर भी लागू होता है — जब तक आप आइटम थामे हैं एजेंट कुछ डिस्पैच नहीं करता, इसलिए आपके और उसके बदलाव कभी एक ही diff में नहीं उतरते। सेशन खत्म करने पर आपका काम कमिट, पुश और रिपोर्ट होता है, और आइटम असली diff stat और वही गेट फ़्लैग लेकर समीक्षा में पहुँचता है जो एजेंट के बनाए आइटम को मिलते। मन बदल गया? Release उसे Needs your call में वापस रख देता है और कतार को मुक्त करता है।

Assisted API endpoints:

Batuta AI Orchestrator

Batuta, Orquesta का AI दिमाग है — एक बुद्धिमान ऑर्केस्ट्रेटर जो टास्क का विश्लेषण करता है और उन्हें सबसे उपयुक्त निष्पादन विधि तक पहुँचाता है। Max tier ($12/user/mo) पर उपलब्ध।

Batuta LLM — स्मार्ट रूटिंग

batuta-auto एक सिंथेटिक मॉडल id है। अपना prompt उसे भेजें और Batuta सबसे सस्ता वह मॉडल चुनता है जो फिर भी टास्क सँभाल सके — सरल Q&A के लिए Haiku, रोज़मर्रा के कोड के लिए Sonnet, रीफ़ैक्टर, आर्किटेक्चर और लंबे-संदर्भ वाले तर्क के लिए Opus। आप केवल वास्तव में इस्तेमाल हुए अपस्ट्रीम tokens का भुगतान करते हैं, साथ में फ़्लैट सब्सक्रिप्शन। अगर किसी टियर का रूट किया गया मॉडल उपलब्ध न हो (quota सीमा, auth समस्या, प्रोवाइडर आउटेज), तो रिक्वेस्ट अपने आप फ़ॉलबैक चेन के अगले मॉडल पर चली जाती है — आपके वर्कफ़्लो में कोई रुकावट नहीं।

batuta-auto क्यों, खुद मॉडल चुनने की जगह: आम Orquesta उपयोगकर्ता साधारण prompts ("fix typo") और कठिन prompts ("refactor this auth flow") का मिश्रण भेजते हैं। साधारण को Haiku और केवल कठिन को Opus पर रूट करने से खर्च 30–60% घटता है और जो prompts मायने रखते हैं उनकी गुणवत्ता नहीं गिरती। रूटिंग का फ़ैसला prompt को देखते हुए निर्धारक होता है और रिस्पॉन्स हेडर में दिखता है (X-Batuta-Tier, X-Batuta-Routed-To)।

किसी भी OpenAI-संगत क्लाइंट से इस्तेमाल करें (orquesta-cli पहली बार चलाने पर इसे अपने आप कॉन्फ़िगर करता है):

curl https://getorquesta.com/api/v1/chat/completions \
  -H "Authorization: Bearer oclt_YOUR_CLI_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "batuta-auto",
    "messages": [{"role": "user", "content": "Refactor this React component to use hooks: ..."}]
  }'

या कोई खास मॉडल चुनें: claude-opus-4-7, claude-sonnet-4-6, gpt-4o, deepseek-reasoner, grok-4, और पूरी सूची के लिए GET /api/v1/models।

निष्पादन मोड

Routines

Routines सहेजे गए prompt टेम्पलेट हैं जिन्हें एक क्लिक में दोबारा चलाया जा सकता है। डिप्लॉय करने, टेस्ट चलाने, लॉग जाँचने या सुरक्षा स्कैन करने जैसे आम कामों के लिए routines बनाएँ। Routines को मैन्युअली ट्रिगर किया जा सकता है या शेड्यूल किया जा सकता है।

शेड्यूल्ड Prompts (Loop)

अपने लोकल एजेंट के ज़रिए prompts को बार-बार अपने आप चलने के लिए शेड्यूल करें। Claude के /loop कमांड से प्रेरित — cron शेड्यूल सेट करें और Orquesta prompts का समय आने पर उन्हें आपके एजेंट को डिस्पैच करता है।

यह कैसे काम करता है:

1. अपने प्रोजेक्ट → Configuration → Scheduled (Loop टैब) पर जाएँ
2. नाम, prompt सामग्री और cron शेड्यूल के साथ एक शेड्यूल्ड prompt बनाएँ
3. प्लेटफ़ॉर्म हर 2 मिनट में cron endpoint के ज़रिए देय prompts की जाँच करता है
4. prompt का समय आने पर वह Supabase Realtime broadcast के ज़रिए आपके लोकल एजेंट को डिस्पैच होता है
5. एजेंट Claude CLI से prompt चलाता है और नतीजे वापस रिपोर्ट करता है

Cron प्रीसेट:

आवश्यकताएँ:

• शेड्यूल ट्रिगर होने पर आपका लोकल एजेंट चालू होना चाहिए
• प्रति प्रोजेक्ट अधिकतम 20 शेड्यूल्ड प्रॉम्प्ट
• प्रति निष्पादन अधिकतम 10 इटरेशन, टाइमआउट अधिकतम 1 घंटा
• प्रीसेट के साथ कस्टम cron एक्सप्रेशन भी समर्थित हैं

क्लाउड VM

Orquesta आपके प्रोजेक्ट्स के लिए क्लाउड VM प्रोविजन और प्रबंधित कर सकता है, DigitalOcean या AWS EC2 पर। VM सुरक्षा हार्डनिंग, Docker सपोर्ट और SSH एक्सेस के साथ पहले से कॉन्फ़िगर होकर आते हैं।

प्रोवाइडर और साइज़

साइज़ चुनें और प्रोवाइडर उसी से तय हो जाता है — DigitalOcean ड्रॉपलेट (s-1vcpu-1gb, s-1vcpu-2gb, s-2vcpu-4gb) किसी भी DigitalOcean रीजन में चलते हैं, और AWS इंस्टेंस (t3.micro, t3.small, t3.medium) Orquesta के अपने VPC में us-east-1 पर चलते हैं। दोनों पर वही cloud-init बूटस्ट्रैप, एजेंट इंस्टॉल और हार्डनिंग लागू होती है। AWS कंप्यूट, स्टोरेज और पब्लिक IPv4 एड्रेस का बिल अलग से लेता है, इसलिए उतनी ही RAM वाला AWS इंस्टेंस महंगा पड़ता है: ड्रॉपलेट $12–$34/माह और AWS इंस्टेंस $17–$49/माह में चलते हैं, और बिलिंग Stripe के ज़रिए मासिक होती है।

वर्कस्पेस टेम्पलेट और आइडल स्लीप

किसी AWS VM को एक बार सेट अप करें — टूलचेन, चेक-आउट किए गए रेपो, और वे ब्राउज़र जिनमें आपके एजेंट के उपयोग वाले अकाउंट लॉग इन हैं — फिर Save as template पर क्लिक करें। Orquesta डिस्क को एक निजी, एन्क्रिप्टेड मशीन इमेज के रूप में कैप्चर करता है (VM एक बार रीबूट होता है, लगभग एक मिनट), और उसी ऑर्गनाइज़ेशन का कोई भी प्रोजेक्ट Start from के तहत उससे नया VM शुरू कर सकता है। हर क्लोन को अपना एजेंट टोकन और SSH key मिलती है; बाकी सब कुछ कॉपी होता है, लॉग-इन सेशन समेत, इसीलिए कोई टेम्पलेट अपने ऑर्गनाइज़ेशन के बाहर कभी लॉन्च नहीं किया जा सकता (पार्टनर के चाइल्ड ऑर्ग, जिनका स्वामित्व पार्टनर के पास है, एकमात्र अपवाद हैं)। हर नए AWS VM पर एजेंट अपनी मशीन के अलावा किसी भी मशीन पर शुरू होने से मना कर देता है, इसलिए क्लोन कभी स्रोत प्रोजेक्ट के प्रॉम्प्ट नहीं चला सकता।

आइडल स्लीप प्रॉम्प्ट के बिना 1 घंटे से 30 दिन बीतने पर VM को बंद कर देता है; सोया हुआ VM केवल अपनी डिस्क का बिल बनाता है और प्रोजेक्ट को अगला प्रॉम्प्ट मिलते ही वह फिर शुरू हो जाता है। टेम्पलेट केवल अपने स्नैपशॉट स्टोरेज का बिल बनाते हैं — प्रति ऑर्गनाइज़ेशन अधिकतम 10।

SSH एक्सेस

SSH keys AES-256 से एन्क्रिप्ट होकर Supabase में संग्रहीत रहती हैं। प्लेटफ़ॉर्म key प्रबंधन, कनेक्शन सेटअप और कमांड निष्पादन पारदर्शी रूप से संभालता है।

# VM access is managed through the dashboard
# SSH keys are auto-generated and encrypted
# Direct SSH (for debugging):
ssh -i /tmp/orquesta-vm-key -o StrictHostKeyChecking=no user@vm-ip

सुरक्षा हार्डनिंग

प्रोविजन किए गए हर VM में शामिल है:

• UFW फ़ायरवॉल (केवल पोर्ट 22, 80, 443)
• Docker-अवेयर iptables नियम (DOCKER-USER चेन) — Docker डिफ़ॉल्ट रूप से UFW को बायपास करता है
• आउटबाउंड DDoS रेट लिमिटिंग (SYN 50/s, UDP 100/s, ICMP 10/s)
• मैलवेयर डिटेक्शन cron (हर 5 मिनट में)
• orquesta यूज़र के लिए सीमित sudo (केवल व्हाइटलिस्ट किए गए कमांड)
• स्वचालित सुरक्षा पैचिंग

ऑन-डिमांड microVM

कोई प्रोजेक्ट बिना अपनी किसी मशीन के भी चल सकता है: प्रॉम्प्ट आने पर Orquesta एक आइसोलेटेड microVM बूट करता है, उसके अंदर orquesta-cli के साथ स्टॉक एजेंट चलाता है और आखिरी गतिविधि के लगभग 15 मिनट बाद उसे समाप्त होने देता है। मॉडल कॉल आपके ऑर्गनाइज़ेशन के अपने LLM एंडपॉइंट (Orquesta CLI पेज) या आपके Batuta ऐड-ऑन पर जाते हैं — Orquesta microVM में अपना कोई मॉडल क्रेडेंशियल नहीं रखता। बिलिंग microVM के जीवनकाल के प्रति मिनट के हिसाब से होती है और Settings → Agents → On-demand runner में “Usage (30d)” के रूप में दिखती है। सेशनों के बीच कुछ भी सुरक्षित नहीं रहता, इसलिए VM हटाए जाने से पहले एजेंट को अपना काम पुश करना होगा (git, रजिस्ट्री, API)।

• पूरा प्रोजेक्ट — प्रोजेक्ट बनाते समय Start on an Orquesta microVM पर टिक करें, सेटअप के दौरान होस्टिंग विकल्प के रूप में microVM चुनें, या Settings में रनर चालू करें। इसके बाद हर प्रॉम्प्ट वहीं चलता है। प्रोजेक्ट का कोई दूसरा एजेंट ऑनलाइन होने पर यह कभी बूट नहीं होता, इसलिए प्रॉम्प्ट दो बार नहीं चल सकते।
• एक वर्कस्ट्रीम — जो प्रोजेक्ट पहले से लोकल या क्लाउड VM पर चलता है, उसमें वर्कस्ट्रीम बनाते समय Run on a microVM पर टिक करें, या उसके कार्ड पर Run on microVM दबाएँ (या workstreams API को run_on_microvm भेजें)। केवल उसी वर्कस्ट्रीम को लक्षित प्रॉम्प्ट microVM बूट करते हैं; बाकी प्रोजेक्ट के अपने एजेंट के पास जाते रहते हैं। On microVM उसे पहले वाले एजेंट पर वापस ले जाता है।
• मशीन की कॉपी — जो प्रोजेक्ट दिन भर चालू रहने वाले PC पर है, उसके लिए उसी Settings सेक्शन में Copy to microVM (एजेंट ≥ 0.2.272) ऑनलाइन एजेंट से उसका वर्किंग ट्री, अनकमिटेड बदलावों समेत, orquesta/microvm-* ब्रांच पर पुश करवाता है और उसकी .env फ़ाइलें भेजवाता है, जिन्हें Orquesta एन्क्रिप्टेड रखता है और कभी कमिट नहीं करता। 5 MB से बड़ी अनट्रैक्ड फ़ाइलें और key जैसी फ़ाइलें (*.pem, id_rsa, .npmrc, क्रेडेंशियल) छोड़ दी जाती हैं, और केवल दो नवीनतम स्नैपशॉट ब्रांच रखी जाती हैं। ब्रांच, env फ़ाइलें और इंस्टॉल कमांड की समीक्षा करें, फिर Convert to microVM करें; हर बूट पर ये बहाल होते हैं और इंस्टॉल चलता है। इसके बाद PC पर एजेंट बंद कर दें। PC पर 24/7 चलने वाली सेवाएँ नहीं जातीं।

इंटीग्रेशन

एकीकृत वर्कफ़्लो के लिए अपने मौजूदा टूल्स को Orquesta से जोड़ें।

ब्रांच + PR वर्कफ़्लो

डिफ़ॉल्ट रूप से एजेंट प्रोजेक्ट की वर्किंग ब्रांच पर कमिट और पुश करता है। यदि आपकी टीम बदलाव लैंड होने से पहले उनकी समीक्षा करती है, तो कनेक्टेड GitHub कार्ड पर पुल-रिक्वेस्ट बटन खोलें (Configuration → Integrations → GitHub) और New branch + pull request चालू करें।

• New branch + pull request — एजेंट बेस ब्रांच से एक ब्रांच काटता है, वहीं पुश करता है और PR खोलता है। वह बेस ब्रांच पर कभी कमिट नहीं करता और PR को खुद कभी मर्ज नहीं करता।
• Branch prefix — डिफ़ॉल्ट रूप से feature/, इसलिए ब्रांच के नाम feature/add-auth जैसे दिखते हैं।
• Draft PR — हर पुल रिक्वेस्ट को ड्राफ़्ट के रूप में खोलें।
• Base branch — ब्रांच यहीं से काटी जाती हैं और पुल रिक्वेस्ट इसी को लक्षित करती हैं। टॉगल बंद होने पर यह बस वही ब्रांच है जिस पर एजेंट कमिट करता है।
• Additional rules — एजेंट के git निर्देशों में जोड़ा जाने वाला फ़्री टेक्स्ट: कमिट कन्वेंशन, टैग किए जाने वाले रिव्यूअर, जिन फ़ाइलों को छोड़ देना है।

PR पर फ़ेल होती CI और रिव्यू ठीक करें

Orquesta प्रॉम्प्ट द्वारा खोली गई पुल रिक्वेस्ट पहले लाल चेक पर नहीं रुकती। जब उसकी CI फ़ेल होती है, तो प्रोजेक्ट का एजेंट फ़ेल हुए लॉग प्राप्त करता है, उसी ब्रांच पर कोड ठीक करता है, पुश करता है और PR पर टिप्पणी करके बताता है कि उसने क्या बदला — तब तक जब तक CI हरी न हो जाए या प्रयासों की सीमा न आ जाए।

• इसे चालू करें Project Settings → Integrations → Fix failing CI on PRs से। यह कनेक्टेड रिपॉज़िटरी पर एक webhook इंस्टॉल करता है, इसलिए GitHub टोकन को रेपो पर एडमिन अधिकार चाहिए। केवल ओनर और एडमिन के लिए।
• केवल Orquesta द्वारा खोले गए PR को छुआ जाता है: ऐसा PR जिसका URL किसी प्रॉम्प्ट के आउटपुट में दिखता है, या जिसकी ब्रांच किसी Auto Agent रन ने बनाई। हाथ से लिखे गए PR पर कभी कोई कार्रवाई नहीं होती।
• GitHub Actions की विफलताएँ (हर फ़ेल जॉब के लॉग के अंतिम हिस्से के साथ) और Checks API इस्तेमाल करने वाले अन्य CI की विफलताएँ, दोनों समर्थित हैं, हर एक के लिए अलग स्विच के साथ।
• किसी फ़िक्स के चलते समय आने वाली विफलताएँ हर बार नया प्रॉम्प्ट शुरू करने के बजाय एक ही फ़ॉलो-अप में समेट दी जाती हैं, और ऐसे कमिट की विफलता को अनदेखा किया जाता है जिसे नए पुश ने पहले ही बदल दिया हो।
• प्रति PR कॉन्फ़िगर किए गए प्रयासों (डिफ़ॉल्ट 3) के बाद यह रुक जाता है और PR पर यह बता देता है; कार्ड पर रीट्राई बटन है जो उस PR को नया बजट देता है।
• फ़िक्स कभी force-push नहीं करता, कभी दूसरी ब्रांच पर पुश नहीं करता और कभी नया PR नहीं खोलता। यदि आपके वर्किंग ट्री में अनकमिटेड बदलाव हैं, तो फ़िक्स अलग git वर्कट्री में चलता है और उन्हें छुए बिना छोड़ देता है।
• फ़िक्स प्रॉम्प्ट डैशबोर्ड में github टैग के साथ दिखते हैं।

रिव्यू और @orquesta मेंशन। रिव्यू फ़ीडबैक भी उसी लूप से गुज़रता है:

• रिव्यू Off, Only when @orquesta is mentioned (डिफ़ॉल्ट) या Every review on tracked PRs हो सकते हैं। रिव्यू की बॉडी और उसकी इनलाइन टिप्पणियाँ (फ़ाइल और लाइन के साथ) एजेंट को भेजी जाती हैं, जो उसी ब्रांच पर उन्हें संबोधित करता है और PR पर जवाब देता है — या बताता है कि वह असहमत क्यों है।
• रिव्यू या PR टिप्पणी में @orquesta का उल्लेख उन PR पर भी काम करता है जिन्हें Orquesta ने नहीं खोला, और प्रयास समाप्त हो चुके PR को फिर से सक्रिय कर देता है।
• केवल राइट एक्सेस वाले लोगों (ओनर, मेंबर या कोलैबोरेटर) पर ही कार्रवाई होती है। coderabbitai[bot] जैसे रिव्यू बॉट तब तक अनदेखे रहते हैं जब तक आप उन्हें Review bots में सूचीबद्ध न करें। फ़ोर्क से आए PR अनदेखे किए जाते हैं।
• इश्यू (ऑप्ट-इन): किसी इश्यू पर @orquesta टिप्पणी एक नया प्रॉम्प्ट खोलती है जो orquesta/issue-N ब्रांच पर काम करता है, इश्यू को बंद करने वाला PR खोलता है, और इश्यू पर नतीजे के साथ जवाब देता है। प्रति प्रोजेक्ट प्रति घंटे अधिकतम 10 इश्यू प्रॉम्प्ट।
• टिप्पणियाँ कनेक्टेड GitHub अकाउंट से पोस्ट होती हैं और उनमें एक छिपा मार्कर रहता है, इसलिए Orquesta कभी अपनी ही टिप्पणियों पर प्रतिक्रिया नहीं करता। किसी मौजूदा webhook पर रिव्यू या इश्यू सेटिंग बदलने के बाद, यदि कार्ड चेतावनी दे कि GitHub ने अपडेट अस्वीकार कर दिया, तो Repair webhook का उपयोग करें।

Vercel

Linear

Telegram Bot

/auth ott_xxxxx    # Authenticate with one-time token\n/prompt Add dark mode  # Submit a prompt\n/status            # Check current execution\n/deploy            # Trigger deployment

Slack

किसी Slack चैनल को किसी प्रोजेक्ट की ओर पॉइंट किया जा सकता है। आपकी टीम वहाँ जो टाइप करती है वह उस प्रोजेक्ट के अपने एजेंट पर प्रॉम्प्ट बन जाता है, और जवाब उसी चैनल में थ्रेडेड रिप्लाई के रूप में लौटता है — इसलिए बातचीत वहीं रहती है जहाँ टीम पहले से है, और हर कोई अनुरोध और एजेंट ने उस पर क्या किया, दोनों देखता है।

चैनल कनेक्ट करना

1. ऐप इंस्टॉल करें — Organization Settings → Slack → Add to Slack, या प्रोजेक्ट की Settings → Integrations → Slack से। एक इंस्टॉल पूरे वर्कस्पेस को कवर करता है।
2. लिंक कोड जनरेट करें उसी कार्ड में। यह एक घंटे के लिए वैध है और एक बार ही रिडीम हो सकता है।
3. उसे चैनल में रिडीम करें जिसे आप लिंक करना चाहते हैं: /orquesta link ABCD2345।

दोनों हिस्से जान-बूझकर ज़रूरी हैं। Orquesta सेशन साबित करता है कि आप कौन हैं, पर यह नहीं कि आप उस चैनल के सदस्य हैं; स्लैश कमांड साबित करता है कि आप चैनल में हैं, पर यह नहीं कि Orquesta में आप कौन हैं। कोड केवल वही बना सकता है जिसके पास प्रोजेक्ट का एक्सेस है, और उसे केवल वही खर्च कर सकता है जो चैनल के अंदर है।

या Orquesta को चैनल बनाने दें

Slack कार्ड प्रोजेक्ट के लिए एक पब्लिक चैनल भी बना देता है, और उसमें कोड की ज़रूरत पूरी तरह खत्म हो जाती है: ऐप द्वारा बनाए गए चैनल में ऐप पहले से मौजूद होता है, इसलिए साबित करने के लिए कुछ बचता नहीं और चैनल बनते ही लिंक हो जाता है। नाम टाइप करें, देखें कि Slack उसे ठीक-ठीक क्या कहेगा, फिर बनाएँ। केवल ओनर और एडमिन के लिए — यह आपके वर्कस्पेस में लिखता है, Orquesta में नहीं। इसे बनाने वाले व्यक्ति और प्रोजेक्ट के सदस्यों को उसी क्षण उसमें आमंत्रित कर दिया जाता है, उनके Orquesta ईमेल से मिलान करके (इसके लिए users:read.email स्कोप चाहिए); जिनका उस वर्कस्पेस में Slack अकाउंट नहीं है उन्हें छोड़ दिया जाता है।

इसके लिए channels:manage स्कोप चाहिए, जो Slack इंस्टॉल के समय देता है। जिस वर्कस्पेस ने यह सुविधा आने से पहले ऐप इंस्टॉल किया था उसे दोबारा इंस्टॉल करना होगा — तब तक बटन ठीक यही बताता है। यहाँ से प्राइवेट चैनल नहीं बनाए जाते, क्योंकि उसके लिए ऐप जितना माँगता है उससे व्यापक स्कोप चाहिए होगा।

उपयोग

/orquesta Add a rate limit to the login endpoint   # run a prompt
@Orquesta what changed in the last deploy?        # same thing, as a mention
/orquesta status                                  # which project this channel runs, and what is in flight
/orquesta link CODE                               # link this channel to a project
/orquesta unlink                                  # stop this channel reaching the agent
/orquesta help

• चैनल में टाइप किया गया कमांड अपना थ्रेड खोलता है और जवाब वहीं आता है, इसलिए लंबा आउटपुट चैनल को कभी नहीं भरता।
• मौजूदा थ्रेड में ऐप का उल्लेख करने पर वही थ्रेड बना रहता है, और पिछले कुछ टर्न एजेंट को संदर्भ के रूप में दिए जाते हैं।
• Slack से आए प्रॉम्प्ट डैशबोर्ड में slack टैग के साथ पूरे लॉग, diff और लागत के साथ दिखते हैं — Slack का जवाब सारांश है, डैशबोर्ड रिकॉर्ड है।
• प्रति चैनल एक समय में अधिकतम तीन प्रॉम्प्ट चलते हैं; उससे अधिक होने पर ऐप चुपचाप कतार में डालने के बजाय यह बता देता है।
• अंदर और बाहर जाने वाला हर संदेश प्रोजेक्ट के खिलाफ रखा जाता है, इसलिए Slack कार्ड हाल की बातचीत उन लोगों को भी दिखाता है जो वर्कस्पेस में नहीं हैं।

टीम चैट, Slack के साथ मिरर की गई

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

• Organization Settings → Slack इसे ऑर्ग के लिए सेट करता है, हर प्रोजेक्ट के लिए या चुनिंदा कुछ के लिए, और पॉलिसी को पिन कर सकता है ताकि कोई प्रोजेक्ट उसे ओवरराइड न कर सके। केवल ओनर के लिए।
• Project Settings → Integrations → Slack इसे एक प्रोजेक्ट के लिए सेट करता है: ऑर्गनाइज़ेशन का अनुसरण करें, या किसी भी दिशा में उससे असहमत हों।
• चैनल लिंक होने से पहले Slack चुनने पर कुछ मिरर नहीं होता — पैनल काम करता रहता है और एक रिमाइंडर दिखाता है, और चैनल लिंक होते ही दोनों जुड़ जाते हैं।
• मिरर निर्माण से ही लूप-मुक्त है: हर रो अपनी कॉपी का Slack टाइमस्टैम्प संग्रहीत करती है, इसलिए हमारी अपनी पोस्ट का इवेंट के रूप में लौटना और एक डिलीवरी के Slack के तीन तक रीट्राई, दोनों एक ही यूनिक इंडेक्स पर पहुँचते हैं और कुछ नहीं करते। ऐप्स और बॉट के संदेश कभी मिरर होकर अंदर नहीं आते।
• जिस Slack भेजने वाले का Orquesta अकाउंट नहीं है, उसे सदस्य बने बिना नाम से दिखाया जाता है: एजेंट की तरह वे एक लेखक प्रकार हैं, प्रोफ़ाइल नहीं, इसलिए चैनल में टाइप करने से कोई सीट नहीं खर्च करता।
• थ्रेड ब्रिज के पार भी थ्रेड ही रहता है — Orquesta थ्रेड में दिया गया जवाब Slack थ्रेड में जवाब बनता है, और उलटा भी।
• Slack → Orquesta के लिए channels:history स्कोप और message.channels इवेंट सब्सक्रिप्शन चाहिए। उस रिलीज़ से पहले कनेक्ट हुआ वर्कस्पेस एक दिशा में काम करता रहता है और प्रोजेक्ट का Slack कार्ड यह बताता है, री-कनेक्ट बटन के साथ।
• साइडबार बताता है कि स्थिति क्या है: जब चैट Slack के साथ मिरर है तो Team Chat के बगल में Integrated, और जब नहीं है तो Integrate।
• Chat पेज हर लिंक्ड प्रोजेक्ट को Slack मार्क से चिह्नित करता है और उसका चैनल बिल्ट-इन चैनलों के ऊपर सूचीबद्ध करता है, और प्रोजेक्ट का Slack कार्ड हर कनेक्टेड चैनल से लिंक करता है — Orquesta द्वारा बनाए चैनल में ऐप होता है, आप नहीं, और जिस पब्लिक चैनल में आप शामिल नहीं हुए वह तब तक आपके Slack साइडबार से बाहर रहता है जब तक आप उसे खोलकर जुड़ न जाएँ।
• जिस प्रोजेक्ट तक ऑर्ग पॉलिसी पहुँचती है लेकिन जिसका अभी कोई चैनल नहीं है, वह Organization Settings में no channel · add one के रूप में सूचीबद्ध होता है, जो सीधे उस प्रोजेक्ट के Integrations टैब से लिंक करता है — चैनल बनाना या लिंक करना वहीं होता है, ऑर्ग स्तर पर नहीं।

अनुरोध तब तक अस्वीकार किए जाते हैं जब तक रॉ बॉडी पर Slack के अपने सिग्नेचर का सत्यापन न हो जाए और टाइमस्टैम्प पाँच मिनट के भीतर न हो, और हर इनबाउंड इवेंट एक ही बार दर्ज होता है — Slack एक डिलीवरी को तीन बार तक रीट्राई करता है, और रीट्राई उसी टास्क का दूसरा रन नहीं बनना चाहिए। थ्रेड में अप्रूवल बटन अगला कदम हैं और इस रिलीज़ में नहीं हैं।

Derplins

प्रोजेक्ट की टैब पंक्ति के अंत में Hire a prompt specialist चिप Derplins का एक छोटा परिचय खोलती है — प्रॉम्प्ट विशेषज्ञों का एक मार्केटप्लेस जिन्हें आप प्रोजेक्ट पर काम करने के लिए हायर कर सकते हैं — और एक क्लिक में प्रोजेक्ट को लिंक कर देती है (ओनर और एडमिन)। उसके बाद यह हर प्रोजेक्ट सदस्य के Derplins डैशबोर्ड परYour Orquesta projects के तहत सूचीबद्ध होता है, उस पर आवश्यकता प्रकाशित करने के बटन के साथ, और जब Derplins ऑर्डर कोई वर्कस्पेस चुनता है तो उसे सबसे पहले सुझाया जाता है। वहाँ हायर किया गया काम इस प्रोजेक्ट के एजेंट पर चलता है, इसलिए हर प्रॉम्प्ट ऑडिट के लिए अपने पूरे लॉग के साथ यहीं रहता है। चिप का मेनू Derplins खोलता है या प्रोजेक्ट को अनएनरोल करता है।

7ots

• चेहरा और आवाज़ — Settings → Identity आपके 7ots ots सूचीबद्ध करता है; एक चुनें और प्रोजेक्ट का रेज़िडेंट एजेंट उसकी छवि, meet लुक और आवाज़ अपना लेता है। दिमाग Orquesta एजेंट ही रहता है। meet वीडियो कॉल पर एजेंट स्वयं ot के रूप में, 3D में, दिखता है और अपनी आवाज़ में बोलता है (एजेंट 0.2.262+)। आवाज़ तब काम करती है जब ot चालू हो और उसका 7ots अकाउंट Orquesta से जुड़ा हो — कोई डोमेन जोड़ने की ज़रूरत नहीं।
• कनेक्टेड ots — Team टैब में, AI Agent Tokens के नीचे: किसी बाहरी ot को प्रोजेक्ट में आने दें ताकि वह रेज़िडेंट एजेंट से सवाल पूछे या उसे काम सौंपे, प्रति-ot स्कोप के साथ। हर ot अपना चेहरा दिखाता है (7ots द्वारा रेंडर किया गया कैरेक्टर, या उसकी अपलोड की गई तस्वीर), सिर्फ़ नाम नहीं। केवल ओनर और एडमिन के लिए।
• प्रोजेक्ट आइकन — साइडबार, प्रोजेक्ट हेडर और मोबाइल ऐप प्रोजेक्ट की साइट का फ़ेविकॉन, या GitHub ओनर का अवतार दिखाते हैं, जो साइट या रेपो URL बदलने पर रिफ़्रेश होता है।

Orquesta CLI

AI-संचालित कोडिंग असिस्टेंट जो कॉन्फ़िगर करने योग्य LLM एंडपॉइंट के साथ लोकल चलता है।Max टियर पर उपलब्ध।

npm install -g orquesta-cli

# Interactive mode
orquesta

# Connect to dashboard
orquesta --token oclt_xxx

# Execute a prompt directly
orquesta -p "Add user authentication"

LLM कॉन्फ़िगरेशन

डैशबोर्ड से या लोकल रूप से कई LLM एंडपॉइंट कॉन्फ़िगर करें। समर्थित:

• OpenAI (GPT-4, GPT-4o, आदि)
• Anthropic (Claude Opus, Sonnet, Haiku)
• Ollama (लोकल मॉडल)
• vLLM (सेल्फ़-होस्टेड)
• OpenRouter (मॉडल मार्केटप्लेस)
• कोई भी OpenAI-संगत एंडपॉइंट

डैशबोर्ड सिंक

LLM कॉन्फ़िगरेशन CLI और डैशबोर्ड के बीच दोनों दिशाओं में सिंक होते हैं। एंडपॉइंट केंद्रीय रूप से कॉन्फ़िगर करें और अपनी टीम में वितरित करें। प्रॉम्प्ट इतिहास डैशबोर्ड में ट्रैक होता है, चाहे प्रॉम्प्ट CLI से सबमिट हुआ हो या वेब UI से।

IDE एक्सटेंशन

Cursor, VS Code या Windsurf को सीधे Orquesta से जोड़ें। अपनी टीम के डैशबोर्ड से प्रॉम्प्ट प्राप्त करें और उन्हें अपने IDE के अंदर चलाएँ — एक्सटेंशन आपके एडिटर में रहता है, हर प्रॉम्प्ट को आपके वर्कस्पेस में लोकल कोडिंग CLI से चलाता है, और नतीजे रियल टाइम में डैशबोर्ड पर स्ट्रीम करता है।

इंस्टॉलेशन

.vsix फ़ाइल डाउनलोड करें, फिर उसे अपने एडिटर में इंस्टॉल करें:

# Option 1 — Command palette
# Cursor / VS Code / Windsurf:
# Press Cmd+Shift+P → "Extensions: Install from VSIX..."
# Select the downloaded orquesta-vscode-0.2.12.vsix

# Option 2 — CLI
code --install-extension orquesta-vscode-0.2.12.vsix
cursor --install-extension orquesta-vscode-0.2.12.vsix

सेटअप और टोकन

इंस्टॉलेशन के बाद, एजेंट टोकन का उपयोग करके एक्सटेंशन को अपने प्रोजेक्ट से जोड़ें:

1. Orquesta में अपना प्रोजेक्ट खोलें → Project → Agents
2. Create Agent Token पर क्लिक करें → oat_xxx टोकन कॉपी करें
3. अपने IDE में Cmd+Shift+P दबाएँ → Orquesta: Set Agent Token
4. टोकन पेस्ट करें — एक्सटेंशन कनेक्ट हो जाता है और साइडबार अपने-आप खुल जाता है

टोकन VS Code की ग्लोबल सेटिंग्स में संग्रहीत होता है। टोकन सेव होने के बाद एक्सटेंशन हर स्टार्टअप पर अपने-आप कनेक्ट होता है। ऑटो-कनेक्ट बंद करने के लिए सेटिंग्स में orquesta.autoConnect: false सेट करें।

निष्पादन मोड

प्रॉम्प्ट कैसे चलें, यह orquesta.executionMode सेटिंग से नियंत्रित करें:

कमांड

{
  "orquesta.agentToken": "oat_xxx",       // Your agent token
  "orquesta.autoConnect": true,           // Connect on startup
  "orquesta.workingDirectory": "",        // Defaults to workspace folder
  "orquesta.executionMode": "auto"        // "auto" | "cli" | "ide-ai"
}

Embed SDK

Orquesta फ़ीडबैक विजेट को अपने प्रोडक्शन एप्लिकेशन में एम्बेड करें। यूज़र एलिमेंट इंस्पेक्शन, स्क्रीनशॉट और कंसोल लॉग के साथ बग रिपोर्ट कर सकते हैं — सब कुछ आपके Orquesta प्रोजेक्ट में वापस पहुँचता है।

CDN सेटअप

Embed SDK केवल CDN के ज़रिए वितरित होता है — किसी भी HTML पेज में दो टैग डालें और बस हो गया। कोई बिल्ड स्टेप नहीं, कोई npm install नहीं, हमेशा नवीनतम संस्करण।

<link rel="stylesheet" href="https://getorquesta.com/embed/v1/orquesta.css" />
<script src="https://getorquesta.com/embed/v1/orquesta.min.js"></script>
<script>
  Orquesta.init({
    token: 'YOUR_EMBED_TOKEN',
    position: 'bottom-right'
  });
</script>

embed में नए हैं? डैशबोर्ड में Project → Embed खोलें: एक गाइडेड चेकलिस्ट आपको agent चलाने, अपना target URL सेट करने, token बनाने और snippet इंस्टॉल करने तक ले जाती है — और एक बिल्ट-इन लाइव डेमो (असली widget, मॉक डेटा) सेटअप से पहले ही दिखा देता है कि यह क्या करता है। आप बिना किसी backend के मॉक डेटा के साथ widget रेंडर करने के लिए demo: true को Orquesta.init() में भी पास कर सकते हैं।

बिल्डर मोड

बिल्डर मोड पूरी स्क्रीन का IDE-शैली इंटरफ़ेस (Bolt या Lovable जैसा) रेंडर करता है, जिसमें तीन पेन होते हैं: बाईं ओर चैट, दाईं ओर लाइव प्रीव्यू, और नीचे एक collapsible टर्मिनल।

<div id="builder-root"></div>
<script src="https://getorquesta.com/embed/v1/orquesta.min.js"></script>
<script>
  Orquesta.init({
    token: 'YOUR_EMBED_TOKEN',
    mode: 'builder',
    container: '#builder-root',
    previewUrl: 'https://your-app.com'
  });
</script>

बिल्डर पेन:

• चैट — prompt भेजें, AI के जवाब और स्टेटस अपडेट देखें
• प्रीव्यू — URL बार और रिफ्रेश बटन के साथ लाइव iframe, prompt पूरा होने पर अपने-आप रीलोड होता है
• टर्मिनल — रीयल-टाइम execution लॉग, collapsible, रंग-कोडित आउटपुट

पेन ड्रैग हैंडल से रीसाइज़ किए जा सकते हैं। टर्मिनल को collapse/expand किया जा सकता है। मोबाइल पर स्टैक्ड लेआउट के साथ पूरी तरह रिस्पॉन्सिव।

embed से भेजे गए prompt डिफ़ॉल्ट रूप से शिप होते हैं। क्योंकि भेजने वाला डिप्लॉय की गई साइट देख रहा होता है, हर embed prompt agent से कहता है कि कोड बदलाव पूरा होने पर commit, push, deploy करे और commit SHA रिपोर्ट करे — फिर प्रीव्यू cache-busting पैरामीटर के साथ रीलोड होता है ताकि नया वर्शन वाकई फ़ेच हो। किसी token को इससे बाहर रखने के लिए embed token सेटिंग्स में auto_deploy: falseसेट करें।

फ़ीचर

• Element Inspector — बग रिपोर्ट में मार्क करने के लिए किसी भी एलिमेंट पर क्लिक करें
• Console Capture — ब्राउज़र कंसोल आउटपुट अपने-आप कैप्चर करता है
• Network Capture — विफल API अनुरोध रिकॉर्ड करता है
• Comment System — खास एलिमेंट पर इनलाइन फ़ीडबैक
• Timeline — reproduce करने के लिए उपयोगकर्ता की क्रियाओं की टाइमलाइन

ब्राउज़र एक्सटेंशन

embed को पेज में एक <script> टैग चाहिए, इसलिए यह सिर्फ़ उन साइटों तक पहुँचता है जिन्हें आप नियंत्रित करते हैं। Orquesta ब्राउज़र एक्सटेंशन यही काम ब्राउज़र की तरफ़ से करता है: यह widget को किसी भी पेज में बिना HTML बदले inject कर देता है, और यह Orquesta CLI को वह ब्राउज़र चलाने देता है जिसमें आप पहले से साइन इन हैं।

• embed कहीं भी inject करें — क्लाइंट की साइट, SSO के पीछे स्टेजिंग बॉक्स, प्रोडक्शन। Prompt उसी प्रोजेक्ट में जाते हैं जिसका embed token है।
• आपका असली ब्राउज़र — browser_ext_* टूल आपकी असली प्रोफ़ाइल और सेशन इस्तेमाल करते हैं, जबकि browser_* एक साफ़, लॉग-आउट Chrome लॉन्च करता है।
• Console और network कैप्चर — CLI से पढ़ें कि पेज ने क्या लॉग किया और क्या अनुरोध किए।
• Side-panel चैट (0.3.0) — टूलबार आइकन पर क्लिक करें, Orquesta से साइन इन करें, और ऐसे agent से चैट करें जो मौजूदा टैब को पढ़ता और चलाता है (click, fill, navigate, console/network पढ़ना)। Batuta पर चलता है; CLI या bridge की ज़रूरत नहीं।
• Send to project (0.3.0) — किसी भी पेज पर टेक्स्ट चुनें, राइट-क्लिक करके Send to Orquesta project चुनें, प्रोजेक्ट चुनें और यह उस प्रोजेक्ट के agent पर prompt के रूप में चलता है। पैनल अपना लॉग स्ट्रीम करता है और उसमें Stop बटन है (POST /api/v1/prompts/{id}/cancel)।

Chrome और Edge। Firefox समर्थित नहीं है (एक्सटेंशन Chrome DevTools Protocol इस्तेमाल करता है)।

इंस्टॉल और पेयर करें

एक्सटेंशन अभी Chrome Web Store पर नहीं है, इसलिए इसे orquesta-extension रिपॉज़िटरी से unpacked लोड किया जाता है। तीन हिस्से, सब लोकल:

# 1. build the extension
git clone https://github.com/Getorquesta/orquesta-extension
cd orquesta-extension
npm install
npm run build

# 2. load packages/extension/build unpacked from chrome://extensions
#    (enable Developer mode first)

# 3. in orquesta-cli: /tool -> Browser Extension (your own browser)

टूल ग्रुप चालू करने पर लोकल bridge अपने-आप शुरू हो जाता है — 127.0.0.1 पर एक छोटा daemon जिससे एक्सटेंशन बात करता है। एक्सटेंशन पॉपअप में Pair पर क्लिक करें, CLI से कोड माँगें (browser_ext_status उसे बताता है), और ब्राउज़र कनेक्ट हो जाता है।

पेयरिंग रीस्टार्ट के बाद भी बनी रहती है, इसलिए यह हर ब्राउज़र के लिए एक बार होती है, हर सेशन में नहीं। Bridge जानबूझकर CLI से ज़्यादा देर चलता है: छोटे orquesta -p रन और कई सेशन दोबारा पेयर किए बिना एक ही ब्राउज़र साझा करते हैं। अगर आप उसका लॉग देखना चाहें तो इसे खुद npx orquesta-bridge से चलाएँ।

CLI टूल

Orquesta CLI में /tool चलाएँ और Browser Extension (your own browser) चालू करें। इससे ये रजिस्टर होते हैं:

• browser_ext_status — bridge चालू है या नहीं, कोई ब्राउज़र पेयर है या नहीं
• browser_ext_tabs / _open / _reload — टैब सूचीबद्ध करें, URL खोलें, रीलोड करें
• browser_ext_click / _fill / _press / _select — पेज के साथ इंटरैक्ट करें
• browser_ext_text / _html / _eval — पेज पढ़ें, उसमें JS चलाएँ
• browser_ext_screenshot — दिखाई देने वाले टैब को कैप्चर करें
• browser_ext_console / _network — console संदेश और अनुरोध
• browser_ext_wait — किसी selector या navigation का इंतज़ार करें
• browser_ext_embed — पेज में Orquesta widget inject करें

सुरक्षा

• कुछ भी मशीन से बाहर नहीं जाता। CLI, loopback पर bridge से बात करता है और bridge, पेयर किए गए लोकल WebSocket पर एक्सटेंशन से। रास्ते में कोई Orquesta सर्वर नहीं है।
• पेयरिंग स्पष्ट है और समाप्त हो जाती है। Bridge दो मिनट के लिए वैध कोड प्रिंट करता है; एक्सटेंशन तभी कनेक्ट होता है जब आप उसे टाइप करते हैं।
• कंट्रोल token एक फ़ाइल है, आर्ग्यूमेंट नहीं। इसे ~/.orquesta-cli/ के अंदर 0600 के साथ लिखा जाता है, इसलिए यह ps में कभी नहीं दिखता।
• Bridge केवल 127.0.0.1 पर bind होता है और ब्राउज़र से आने वाले अनुरोध अस्वीकार करता है, इसलिए कोई वेब पेज DNS rebinding के ज़रिए उस तक नहीं पहुँच सकता।

रिमोट डेस्कटॉप

ब्राउज़र चलाने से आगे, agent जिस मशीन पर चलता है उसका पूरा डेस्कटॉप भी चला सकता है — माउस हिलाना, टाइप करना और स्क्रीनशॉट लेना — और आप डैशबोर्ड से लाइव कंट्रोल ले सकते हैं। यह नेटिव ऐप्स में फ़्लो ऑटोमेट करने के लिए है, सिर्फ़ वेब पेजों के लिए नहीं। फ़िलहाल Linux/X11; Windows और macOS जल्द आ रहे हैं।

चालू करें और मोड

डिफ़ॉल्ट रूप से बंद। इसे प्रोजेक्ट के हिसाब से Settings → Agent → Remote Desktop में चालू करें। तीन मोड:

• Automation — agent डेस्कटॉप को प्रोग्रामेटिक रूप से कंट्रोल करता है (कोई VNC सर्वर शुरू नहीं होता)।
• Live (VNC) — कोई व्यक्ति डैशबोर्ड व्यूअर से कंट्रोल ले लेता है।
• Both — ऑटोमेशन के साथ लाइव टेक-ओवर।

व्यूअर का उपयोग

किसी प्रोजेक्ट पर Remote Desktop टैब खोलें। agent के स्ट्रीमिंग शुरू करते ही स्क्रीन दिखने लगती है; देखने के लिए प्रोजेक्ट एक्सेस के अलावा कुछ नहीं चाहिए।

• Take control आपका माउस और कीबोर्ड रिमोट मशीन को सौंप देता है। मूव, क्लिक, ड्रैग, स्क्रॉल व्हील और मिडिल/राइट क्लिक सब पहुँचते हैं; टाइपिंग वहाँ जिस पर फ़ोकस है उसी में जाती है।
• Pop out डेस्कटॉप को अपनी अलग विंडो में खोलता है, ताकि वह दूसरे मॉनिटर पर रह सके और आप प्रोजेक्ट टैब में काम करते रहें।
• Disconnect सेशन छोड़ देता है। जब कोई नहीं देख रहा होता तो agent स्क्रीन कैप्चर करना पूरी तरह बंद कर देता है, और स्टेटस के बगल में दिखने वाली व्यूअर संख्या भी यही बताती है।
• Session history बताती है कि हर बार किसने यह डेस्कटॉप खोला, कितनी देर के लिए, और क्या उन्होंने कंट्रोल लिया।

पेयरिंग PIN

कोई owner या admin Settings → Agent → Remote Desktop में PIN सेट कर सकता है। यह कंट्रोल लेने को रोकता है, देखने को नहीं: जिस स्क्रीन तक आपके पास पहले से डैशबोर्ड एक्सेस है उसे देखना ख़तरनाक क्षमता नहीं है — मशीन चलाना है। PIN हैश करके स्टोर किया जाता है और relay द्वारा जाँचा जाता है, इसलिए न ब्राउज़र को और न agent को बहलाकर इससे बचा जा सकता है।

सुरक्षा

• Opt-in, डिफ़ॉल्ट रूप से बंद। पूरा डेस्कटॉप कंट्रोल जोखिम भरा है, इसलिए जब तक आप किसी प्रोजेक्ट के लिए इसे चालू नहीं करते, कुछ नहीं चलता।
• देखना और चलाना अलग अनुमतियाँ हैं। कंट्रोल हर सेशन के लिए दिया जाता है और उसी के साथ ख़त्म हो जाता है — दोबारा कनेक्ट करने पर फिर पूछा जाता है, और PIN (अगर सेट है) भी फिर पूछा जाता है।
• VNC सर्वर केवल localhost पर bind होता है। अंदर आने का एकमात्र रास्ता agent की authenticated WebSocket टनल है — नेटवर्क पर कभी एक्सपोज़ नहीं होता।
• sandbox Strict में अक्षम। Strict filesystem आइसोलेशन और पूरा डेस्कटॉप टेकओवर एक-दूसरे के विरोधी हैं; agent इसे चालू करने से मना कर देता है।
• निष्क्रिय सेशन हटा दिए जाते हैं ताकि छोड़ा हुआ टेक-ओवर डेस्कटॉप को पहुँच में न छोड़े।

MCP सर्वर

Orquesta एक ही endpoint पर Model Context Protocol बोलता है, ताकि कहीं भी चल रहा असिस्टेंट — Lovable, ChatGPT, Claude Code, Cursor, VS Code — किसी प्रोजेक्ट का इतिहास पढ़ सके और अपना काम उसमें वापस लिख सके। कुछ इंस्टॉल नहीं करना: ऊपर के hooks को आपकी मशीन पर एक प्रोसेस चाहिए, जबकि MCP क्लाउड में चलने वाले टूल तक पहुँचता है।

https://getorquesta.com/api/mcp

ट्रांसपोर्ट stateless है: हर कॉल एक HTTPS अनुरोध है, ज़िंदा रखने के लिए कोई सेशन नहीं है और खुला रखने के लिए कोई इवेंट स्ट्रीम नहीं।

क्लाइंट कनेक्ट करना

URL पेस्ट करें। होस्टेड क्लाइंट 401 से OAuth सर्वर खोज लेता है, खुद को रजिस्टर करता है, और आपको Orquesta की सहमति स्क्रीन पर भेजता है जहाँ आप एक्सपोज़ करने के लिए organization चुनते हैं — कोई API key नहीं बनती, दिखती या कॉपी की जाती। Lovable में: Dashboard → Connectors → mcp खोजें → New MCP server, URL पेस्ट करें, Authentication को OAuth पर रहने दें, फिर Add server। ChatGPT और Claude सिर्फ़ URL माँगते हैं।

हर टीममेट अपने खाते से अधिकृत करता है, और token ठीक उन्हीं प्रोजेक्ट तक पहुँचता है जो वह व्यक्ति पहले से देख सकता है। हर कनेक्टेड टूल Settings → Connections में दिखता है, साथ में कितने सेशन उसने रिकॉर्ड किए, उसने आख़िरी बार कब कुछ किया, और कितने लोगों ने उसे अधिकृत किया — वहाँ एक बटन उसे पूरे organization के लिए डिस्कनेक्ट कर देता है।

टर्मिनल से, orquesta-cli भी एक MCP क्लाइंट है, और अब OAuth करता है: orquesta mcp login <name> ब्राउज़र को एक बार खोलता है और उस मशीन पर रिफ्रेश होने वाला token रखता है, जो ऐसे सर्वर तक पहुँचने का एकमात्र तरीका है जो कोई API key जारी नहीं करता। orquesta mcp list अधिकृत सर्वर को चिह्नित करता है, और orquesta mcp logout <name> उसे भुला देता है।

OAuth समर्थन के बिना क्लाइंट इसके बजाय bearer token लेते हैं — organization API key (oak_) जो Settings → API Keys में मिलती है; अगर क्लाइंट को अपना काम रिकॉर्ड करने में सक्षम होना है तो prompts:write scope रखें:

claude mcp add --transport http orquesta https://getorquesta.com/api/mcp \
  --header "Authorization: Bearer oak_abc123..."

{
  "mcpServers": {
    "orquesta": {
      "url": "https://getorquesta.com/api/mcp",
      "headers": { "Authorization": "Bearer oak_abc123..." }
    }
  }
}

टूल

External Agents API

REST API जो थर्ड-पार्टी AI agent (GPT, LangChain, CrewAI, कस्टम agent) को आपके Orquesta प्रोजेक्ट से जोड़ने देता है। बाहरी agent दिमाग लाता है, Orquesta execution + समन्वय देता है।

यह कैसे काम करता है:

1. डैशबोर्ड से oxa_ token बनाएँ (Project → Team → External Agents)
2. API के ज़रिए अपना agent रजिस्टर करें
3. कोडबेस समझने के लिए प्रोजेक्ट संदर्भ पढ़ें
4. Prompt सबमिट करें — लोकल orquesta-agent उन्हें चलाता है
5. नतीजों के लिए poll करें और दोहराएँ

प्रमाणीकरण

सभी API अनुरोधों के लिए उपयुक्त scope वाला Bearer token ज़रूरी है:

Authorization: Bearer oxa_abc123...

Rate limits: 30 अनुरोध/मिनट, 300 अनुरोध/घंटा (हर token के लिए कॉन्फ़िगर करने योग्य)।

दोनों *:write scope token बनते समय डिफ़ॉल्ट रूप से बंद होते हैं और उन्हें साफ़ तौर पर टिक करना पड़ता है। ये किसी deploy agent को एक प्रोजेक्ट के वेरिएबल और फ़ाइलें देने देते हैं, बिना पूरे org वाला oclt_ token रखे जो पूरे उपयोगकर्ता की तरह काम करता है। ये सख़्ती से केवल लिखने वाले हैं: वही token उन routes के GET/DELETE पर 403 पाता है, और हर राइट token के गतिविधि लॉग में दर्ज होता है (केवल keys और फ़ाइल नाम, कभी values नहीं)।

API संदर्भ

बेस URL: https://getorquesta.com/api/external-agent

उदाहरण

import requests

API = "https://getorquesta.com/api/external-agent"
TOKEN = "oxa_your_token_here"
HEADERS = {"Authorization": f"Bearer {TOKEN}"}

# 1. Register your agent
requests.post(f"{API}/register", headers=HEADERS, json={
    "name": "my-gpt-agent",
    "model": "gpt-4o",
    "provider": "openai",
    "version": "1.0.0",
    "capabilities": ["code-review", "testing"]
})

# 2. Read project context
ctx = requests.get(f"{API}/context", headers=HEADERS).json()
print(ctx["memory"])  # Project knowledge

# 3. Submit a prompt
resp = requests.post(f"{API}/prompts", headers=HEADERS, json={
    "content": "Add input validation to the signup form",
    "tags": ["feature"]
})
prompt_id = resp.json()["promptId"]

# 4. Poll for completion
import time
while True:
    status = requests.get(
        f"{API}/prompts/{prompt_id}", headers=HEADERS
    ).json()
    if status["status"] in ("completed", "failed"):
        print(f"Result: {status['result']}")
        break
    time.sleep(5)

curl -X POST https://getorquesta.com/api/external-agent/prompts \
  -H "Authorization: Bearer oxa_xxx" \
  -H "Content-Type: application/json" \
  -d '{"content": "Fix the login bug", "tags": ["bug"]}'

ऑटोनोमस Agent Bot

Orquesta में एक बिल्ट-इन ऑटोनोमस bot आता है जो Claude CLI को अपने दिमाग की तरह इस्तेमाल करके External Agents API के ज़रिए रणनीतिक रूप से टास्क प्लान और सबमिट करता है। लोकल agent हर टास्क चलाता है।

API key की ज़रूरत नहीं — bot आपकी Claude वेब सब्सक्रिप्शन claude login के ज़रिए इस्तेमाल करता है।

यह कैसे काम करता है:

1. API के ज़रिए ऑटोनोमस agent के रूप में रजिस्टर होता है
2. प्रोजेक्ट संदर्भ, हालिया prompt और कतार का स्टेटस इकट्ठा करता है
3. अगला टास्क तय करने के लिए पूरे संदर्भ के साथ claude -p चलाता है
4. Prompt सबमिट करता है, पूरा होने तक poll करता है, परिणाम रिकॉर्ड करता है
5. दोहराता है — हर पुनरावृत्ति पिछले नतीजों पर बनती है

# Run with token (default 5 iterations)
npx tsx scripts/autonomous-agent/run.ts oxa_your_token

# Or use env var with custom iterations
MAX_ITERATIONS=10 ORQUESTA_AGENT_TOKEN=oxa_xxx npx tsx scripts/autonomous-agent/run.ts

कॉन्फ़िगर करने योग्य: MAX_ITERATIONS (डिफ़ॉल्ट 5), ITERATION_DELAY (डिफ़ॉल्ट 30s हर पुनरावृत्ति के बीच)।

सुरक्षा

सुरक्षा Orquesta की बुनियाद है। आपका कोड आपकी मशीन पर चलता है, क्रेडेंशियल एन्क्रिप्टेड हैं, और सारा डेटा एक्सेस row-level security पॉलिसी से नियंत्रित होता है।

Row-Level Security

हर Supabase टेबल पर RLS पॉलिसी हैं जो organization-स्तर का आइसोलेशन लागू करती हैं। उपयोगकर्ता केवल अपने organization के डेटा तक पहुँच सकते हैं। Admin ऑपरेशन उन्नत अनुमतियों वाली service role key इस्तेमाल करते हैं, जो क्लाइंट को कभी एक्सपोज़ नहीं होती।

Token प्रबंधन

सभी token स्टोरेज से पहले SHA-256 से हैश किए जाते हैं। केवल हैश स्टोर होता है — असली token निर्माण के समय एक बार दिखाया जाता है और दोबारा प्राप्त नहीं किया जा सकता। Token को डैशबोर्ड से तुरंत रद्द किया जा सकता है।

Environment Variables & Secret Files

प्रोजेक्ट के secrets Settings → Environment Variables में रहते हैं और agent द्वारा चलाए जाने वाले हर prompt में inject किए जाते हैं। दो प्रकार हैं: key/value variables, और secret files — जैसे signing key, keystore, service-account JSON या.p8, जो डिस्क पर मौजूद होनी चाहिए। Agent रन से ठीक पहले हर फ़ाइल को उसके गंतव्य पथ पर लिखता है (प्रोजेक्ट के सापेक्ष, absolute, या ~/…; mode 0600) और resolved पथ के साथ ORQUESTA_FILE_<NAME> export करता है।

• Paste .env — setup wizard और Settings दोनों पेस्ट किया गया .env स्वीकार करते हैं (comments, quotes और export prefix संभाले जाते हैं; मौजूदा keys वहीं अपडेट होती हैं)।
• CLI token के साथ API एक्सेस — /api/projects/{id}/env, /credentials और /secret-files dashboard session के साथ-साथ Authorization: Bearer oclt_… भी स्वीकार करते हैं, इसलिए scripts और agents बिना ब्राउज़र के secrets लोड कर सकते हैं। हटाने के लिए credentials:manage अनुमति चाहिए।
• External-agent token के साथ केवल-लिखने की पहुँच — opt-in env:write / secret-files:write scopes (डिफ़ॉल्ट रूप से अनचेक) के साथ बनाया गया oxa_ token केवल अपने प्रोजेक्ट के लिए /env और /secret-files पर POST कर सकता है। यह उन्हें पढ़ या हटा नहीं सकता, और हर लिखना token की activity feed में लॉग होता है। जिस agent का एकमात्र काम secrets लोड करना है, उसके लिए oclt_ के बजाय इसे चुनें — देखें External Agent scopes।
• Token की स्थिति — orquesta --status अब संग्रहीत CLI token को server से सत्यापित करता है और चेतावनी देता है जब वह revoke हो गया हो, expire हो गया हो, या ऐसा पुराना token हो जिससे कोई user जुड़ा नहीं है (ऐसे token हर write पर 403 के साथ अस्वीकार होते हैं)। orquesta --login नया token बनाता है।
• प्रति प्रोजेक्ट अधिकतम 32 फ़ाइलें, प्रत्येक 512 KB, कुल 4 MB। हर अन्य credential की तरह एन्क्रिप्टेड रूप में संग्रहीत।

# Merge variables from a .env file (existing keys are updated, others kept)
curl -s -X POST https://getorquesta.com/api/projects/$PROJECT_ID/env \
  -H "Authorization: Bearer $ORQUESTA_CLI_TOKEN" -H "Content-Type: application/json" \
  -d "$(jq -n --rawfile dotenv .env.production '{dotenv: $dotenv, merge: true}')"

# Upload a signing key as a secret file
curl -s -X POST https://getorquesta.com/api/projects/$PROJECT_ID/secret-files \
  -H "Authorization: Bearer $ORQUESTA_CLI_TOKEN" -H "Content-Type: application/json" \
  -d "$(jq -n --arg b64 "$(base64 -w0 AuthKey.p8)" \
        '{files:[{name:"APPLE_AUTH_KEY", path:"~/.private_keys/AuthKey.p8", contentBase64:$b64}]}')"

# In the prompt the agent runs, the file is already on disk:
#   eas build --non-interactive   # reads $ORQUESTA_FILE_APPLE_AUTH_KEY via your eas.json / env

Identity Verification (Passkey / OTP)

कोई organization या प्रोजेक्ट सामान्य लॉगिन के ऊपर दूसरी पहचान जाँच अनिवार्य कर सकता है, इससे पहले कि कोई भी उसके agent से कार्य करवाए: prompts भेजना या चलाना, interactive sessions, browser control, remote-desktop control, scheduled runs और auto-agent autonomy। सदस्य passkey (Touch ID, Windows Hello, security key) या authenticator app कोड से सत्यापित करते हैं।

• इसे चालू करें Organization Settings → Identity verification for agents (owner) में, या प्रति प्रोजेक्ट Settings → Agent (owners और admins) में। प्रोजेक्ट केवल नीति को और सख़्त कर सकता है।
• यह expire होता है कॉन्फ़िगर किए गए समय के बाद (15 मिनट से 24 घंटे, डिफ़ॉल्ट 8 घंटे; org और प्रोजेक्ट में से छोटा मान लागू), साइन आउट करने पर, या जब आप अपनी प्रोफ़ाइल में Lock now दबाते हैं।
• Enroll करें Profile → Identity verification में, या पहली बार ज़रूरत पड़ने पर सीधे prompt से। पहली विधि के बाद कोई विधि जोड़ने या हटाने पर दोबारा सत्यापन माँगा जाता है, और हर बदलाव की सूचना आपको ईमेल से भेजी जाती है।
• नीति को ढीला करने (इसे बंद करने या expiry बढ़ाने) के लिए पिछले 15 मिनट के भीतर का सत्यापन चाहिए, ताकि चुराया गया session इसे बंद न कर सके।
• दायरा: यह जाँच dashboard sessions पर लागू होती है। Token-authenticated पथ (public API, CLI, Slack, Telegram, external agents) अपने tokens द्वारा नियंत्रित होते हैं।

Security Scanning

अंतर्निहित security scanning prompts और जेनरेट किए गए कोड का vulnerabilities के लिए विश्लेषण करती है। Scans SQL injection, XSS, command injection और उजागर credentials जैसी सामान्य समस्याओं का पता लगाते हैं। परिणाम Security पैनल में severity रेटिंग और सुधार मार्गदर्शन के साथ दिखाई देते हैं।

GuardRails

GuardRails प्रति-प्रोजेक्ट prompt सुरक्षा परत है जो हर prompt को agent तक पहुँचने से पहले रोककर जाँचती है। यह 30+ अंतर्निहित regex नियमों और एक वैकल्पिक GPT-4o-mini AI review पास की मदद से prompt injection, jailbreaks, role overrides, और data exfiltration प्रयासों को स्कैन करती है।

यह कैसे काम करता है:

1. निष्पादन से पहले हर prompt को 6 नियम श्रेणियों के आधार पर स्कोर किया जाता है
2. Score ≥ 70 → blocked, 30–69 → warned, < 30 → passed
3. परिणाम prompt पर संग्रहीत होता है (guardrail_status, guardrail_flags)
4. block मोड में prompt रद्द हो जाता है और 403 लौटाया जाता है; warn मोड में वह चलता है लेकिन flag किया जाता है

Action Modes:

• Block — prompt रद्द हो जाता है; भेजने वाले को मेल खाए नियम के साथ त्रुटि मिलती है
• Warn — prompt सामान्य रूप से चलता है लेकिन violations log में flag किया जाता है
• Log Only — prompt चलता है, ऑडिटिंग के लिए violations चुपचाप दर्ज होते हैं

कॉन्फ़िगरेशन: प्रोजेक्ट dashboard में Agent → GuardRails पर जाएँ और चालू करें, मोड सेट करें, AI review टॉगल करें और कस्टम regex patterns जोड़ें। प्रोजेक्ट admins Send Prompt टूलबार से भी GuardRails बटन से सीधे GuardRails चालू/बंद कर सकते हैं — कहीं और जाने की ज़रूरत नहीं।

GuardRail API endpoints:

Quality Gates

Quality Gates admins को विशिष्ट टीम सदस्यों के लिए Submit से पहले Simulate चरण अनिवार्य करने देते हैं। चालू होने पर सदस्य का Execute बटन Simulate में बदल जाता है — इसे क्लिक करने पर एक AI यह पूर्वावलोकन देता है कि agent क्या करेगा (छुई जाने वाली फ़ाइलें, चलने वाले कमांड, जोखिम)। फिर सदस्य आगे बढ़ने के लिए Sign & Submit या Cancel चुनता है।

कैसे चालू करें:

1. प्रोजेक्ट dashboard में Team पर जाएँ
2. सदस्य के नाम के बगल में Sign-off badge पर क्लिक करें (केवल admins)
3. सक्रिय होने पर badge amber हो जाता है — वह सदस्य "Execute" के बजाय "Simulate" देखेगा
4. सिमुलेशन prompt रिकॉर्ड पर quality_gate_signed के माध्यम से ट्रैक होता है

CLAUDE.md Sync

अपने प्रोजेक्ट का CLAUDE.md सीधे dashboard से संपादित करें और उसे agent की working directory के साथ sync में रखें। Claude Code हर session पर प्रोजेक्ट root से CLAUDE.md पढ़ता है — इसे अपडेट करने के लिए अब मैन्युअल SSH की ज़रूरत नहीं।

Dashboard Editor

Configuration → Settings → CLAUDE.md tab खोलें। कंटेंट संपादित करें और सहेजें। यह projects.settings.claude_md में संग्रहीत होता है। अगली बार agent के connect होने पर फ़ाइल <workingDirectory>/CLAUDE.md में लिखी जाती है।

Agent Sync

पहली बार connect होने पर agent लोकल CLAUDE.md को dashboard पर अपलोड करता है (केवल तभी जब कोई user कंटेंट सहेजा न गया हो):

1. Agent अपनी working directory से CLAUDE.md पढ़ता है
2. कंटेंट को /api/agent/claude-md पर POST करता है
3. Server इसे तभी संग्रहीत करता है जब settings.claude_md अभी सेट न हो (user के संपादन कभी overwrite नहीं होते)
4. बाद के connects पर, यदि settings.claude_md सेट है, तो उसे वापस डिस्क पर लिखा जाता है

Organization Agent Context

CLAUDE.md प्रति प्रोजेक्ट होता है। जो नियम organization के हर प्रोजेक्ट पर लागू होते हैं, वे Settings → Agent context (/dashboard/settings, केवल owners) में रहते हैं — ऐसी नीति जिसे आपको कभी दोबारा बताना न पड़े: “हमेशा branch पर काम करें और PR खोलें”, “dependency जोड़ने से पहले पूछें”, “commit messages अंग्रेज़ी में लिखें”।

यह प्रोजेक्ट निर्देशों और integration skills के बाद पहुँचाया जाता है, एक ऐसे header के तहत जो बताता है कि यह उन्हें override करता है — prompt की प्राथमिकता स्थिति पर निर्भर है, इसलिए अंतिम लेबल वाला ब्लॉक जीतता है। चल रहे agents सहेजने के कुछ ही सेकंड में इसे फिर से लोड कर लेते हैं।

Code Browser

Code Browser टैब dashboard से सीधे आपके प्रोजेक्ट के source code का केवल-पढ़ने योग्य दृश्य देता है। फ़ाइलें GitHub या SSH के माध्यम से लाई जाती हैं — किसी लोकल clone की ज़रूरत नहीं।

सुविधाएँ:

• 20+ भाषाओं के लिए Syntax highlighting (TypeScript, Python, Go, Rust, SQL, HTML, CSS, और अधिक)
• सर्च फ़िल्टरिंग और डायरेक्टरी नेविगेशन के साथ फ़ाइल explorer
• मैच नेविगेशन के साथ फ़ाइल-भीतर सर्च (Ctrl+F या सर्च बटन)
• Breadcrumb पथ नेविगेशन और फ़ाइल मेटाडेटा (आकार, पंक्ति संख्या, भाषा)
• पूरी फ़ाइल की सामग्री क्लिपबोर्ड पर कॉपी करें
• Ask AI — जिस फ़ाइल को आप देख रहे हैं उसके बारे में प्रश्न पूछने के लिए साइड पैनल खोलें। Claude Haiku या GPT-4o-mini द्वारा संचालित streaming उत्तर

यह केवल-देखने वाला अनुभव है — Code Browser से फ़ाइलों को संशोधित, बनाया या हटाया नहीं जा सकता। इसका उपयोग code reviews, नए टीम सदस्यों के onboarding, या codebase के अपरिचित हिस्सों को खोजने के लिए करें।

Ask AI

AI पैनल खोलने के लिए फ़ाइल टूलबार में Ask बटन पर क्लिक करें। AI को फ़ाइल की सामग्री संदर्भ के रूप में मिलती है और वह कोड के बारे में प्रश्नों के उत्तर दे सकता है, patterns समझा सकता है, संभावित समस्याएँ पहचान सकता है, और बता सकता है कि functions क्या करते हैं। शुरुआत करने के लिए सुझाए गए prompts दिए गए हैं।

Performance Dashboard

Performance टैब (Configuration → Performance) प्रोजेक्ट के लिए model और दिन के अनुसार विभाजित एकत्रित token उपयोग और लागत डेटा दिखाता है। डेटा Claude CLI executor द्वारा भरे गए tokens_used और cost_cents फ़ील्ड से आता है।

आप क्या देखते हैं:

• Stat cards: कुल लागत ($), कुल tokens, Prompt संख्या
• दैनिक bar chart: चुनी गई अवधि में प्रति दिन लागत
• Model विभाजन तालिका: model, provider, prompts, tokens, लागत — लागत के अनुसार क्रमबद्ध
• सदस्य के अनुसार खर्च: प्रति-user token + लागत खर्च, उपयोग के अनुसार क्रमबद्ध, और जब कोई एक सदस्य टीम के 40% से अधिक tokens केंद्रित कर ले तब High-spend flag
• प्रति-user token सीमा: org owners/admins प्रति सदस्य org-व्यापी मासिक Batuta token सीमा तय कर सकते हैं, alert-only मोड में (सदस्यों और admins को 80% / 95% पर ईमेल भेजा जाता है) या block मोड में (सीमा पार होने पर अगले महीने तक prompts अस्वीकार किए जाते हैं)
• अवधि चयनकर्ता: 7 दिन / 30 दिन / सभी समय

Performance API

Quick Prompts

Quick Prompts आपको बार-बार उपयोग होने वाले prompts को पुन: उपयोग योग्य टेम्पलेट के रूप में सहेजने देते हैं। वही निर्देश बार-बार टाइप करने के बजाय, उन्हें एक बार सहेजें और एक क्लिक में चलाएँ।

Create & Use Quick Prompts

बनाना:

• किसी भी प्रोजेक्ट में prompt इनपुट खोलें
• अपना prompt टाइप करें, फिर Save as Quick Prompt बटन पर क्लिक करें
• उसे एक नाम और वैकल्पिक विवरण दें
• Quick prompts प्रति-प्रोजेक्ट quick_prompts तालिका में सहेजे जाते हैं

उपयोग करना:

• prompt इनपुट क्षेत्र में Quick Prompts dropdown पर क्लिक करें
• इनपुट अपने-आप भरने के लिए सहेजा हुआ prompt चुनें
• ज़रूरत हो तो संपादित करें, फिर सामान्य रूप से submit करें

उपयोग के मामले:

• मानक code review prompts
• Deployment checklists
• Bug report टेम्पलेट
• आवर्ती रखरखाव कार्य

Building in Public

अपने प्रोजेक्ट की AI गतिविधि को सार्वजनिक रूप से दृश्यमान बनाएँ — लॉगिन की ज़रूरत नहीं। "Build in Public" टॉगल चालू करें और आपका प्रोजेक्ट Live Feed में getorquesta.com/feed पर दिखाई देगा, जिससे कोई भी देख सकता है कि आपका AI agent रियल टाइम में कोड कैसे शिप करता है। FOMO पैदा करने और यह दिखाने का शानदार तरीका कि AI-संचालित डेवलपमेंट कैसा दिखता है।

Enable & Configure

Project → Settings → Permissions tab पर जाएँ। "Build in Public" के अंतर्गत टॉगल चालू करें।

• Custom slug — my-project जैसा छोटा URL सेट करें ताकि आपका feed पेज UUID के बजाय getorquesta.com/feed/my-project पर रहे। केवल छोटे अक्षर, संख्याएँ और हाइफ़न (3–50 वर्ण) होने चाहिए। अद्वितीय होना चाहिए।
• Live site URL — अपने deploy किए गए ऐप का URL दर्ज करें (जैसे https://myapp.com)। आपके feed पेज पर आने वाले आगंतुकों को prompt टाइमलाइन के नीचे चल रहे वास्तविक प्रोडक्ट का embedded iframe पूर्वावलोकन दिखेगा।

Live Feed

/feed पर ग्लोबल feed सभी सार्वजनिक प्रोजेक्ट्स को community vote score के अनुसार क्रमबद्ध करके दिखाती है। हर कार्ड दिखाता है:

• Agent ऑनलाइन/ऑफ़लाइन स्थिति (हरा बिंदु = पिछले 3 मिनट में देखा गया)
• जब कोई prompt सक्रिय रूप से चल रहा हो तब Amber "Running now" pulse
• स्थिति आइकन और स्रोत badges (Web / Telegram / Auto / आदि) के साथ अंतिम 3 prompt स्निपेट
• Up/down vote बटन — score यानी upvotes घटा downvotes, प्रति अनाम ब्राउज़र UUID संग्रहीत
• /feed/[slug] पर पूरी प्रोजेक्ट टाइमलाइन का लिंक

प्रोजेक्ट विवरण पेज (/feed/[slug]) दिखाता है:

• लाइव साइट का Iframe पूर्वावलोकन (यदि site URL कॉन्फ़िगर है)
• पूरी prompt टाइमलाइन (अंतिम 50 prompts, केवल-पढ़ने योग्य)
• विस्तार योग्य prompt कंटेंट, tags, स्रोत, अवधि
• X पर Share बटन और लिंक कॉपी बटन
• वर्तमान में चल रहे किसी भी prompt के लिए Live logs terminal

Real-time Logs

जब कोई prompt चल रहा होता है, तो सार्वजनिक प्रोजेक्ट पेज पर उसके नीचे एक terminal पैनल दिखाई देता है और हर 2 सेकंड में agent logs स्ट्रीम करता है। Logs फ़िल्टर किए जाते हैं — आंतरिक thinking प्रविष्टियाँ छिपाई जाती हैं, और केवल कार्रवाई योग्य आउटपुट दिखाया जाता है:

Logs प्रति poll अंतिम 80 प्रविष्टियों तक सीमित हैं और प्रति पंक्ति 500 वर्णों पर काटे जाते हैं। नवीनतम प्रविष्टि तक अपने-आप स्क्रॉल होता है।

Public API

इन endpoints को किसी authentication की ज़रूरत नहीं — ये पूरी तरह सार्वजनिक हैं:

API Keys

API keys (oak_) बाहरी integrations को Orquesta डेटा तक पहुँच देती हैं। इन्हें Settings > API Keys पर बनाएँ, जहाँ हर key पर दो स्वतंत्र प्रतिबंध होते हैं: वह कौन-से scopes रखती है (डिफ़ॉल्ट रूप से केवल-पढ़ने योग्य) और वह किन प्रोजेक्ट्स तक पहुँच सकती है (सभी, या चुनिंदा कुछ)। दोनों को token दोबारा जारी किए बिना बाद में संपादित किया जा सकता है।

Authentication

हर अनुरोध में अपनी API key शामिल करें:

# Option 1: Authorization header
curl -H "Authorization: Bearer oak_xxx" https://getorquesta.com/api/v1/projects

# Option 2: X-API-Key header
curl -H "X-API-Key: oak_xxx" https://getorquesta.com/api/v1/projects

Endpoints

प्रोजेक्ट और VMs

Org keys (केवल oak_ — CLI, agent और MCP tokens अस्वीकार किए जाते हैं) प्रोजेक्ट बना सकती हैं और हर प्रोजेक्ट के क्लाउड VM को मैनेज कर सकती हैं। लिखने वाले अनुरोधों के लिए ज़रूरी है कि key बनाने वाला यूज़र अब भी संगठन का owner या admin हो। सीमा: प्रति key 30 अनुरोध/मिनट, 300/घंटा। VM के जवाबों में SSH private key या agent token कभी शामिल नहीं होता।

Partner organizations (Orquesta द्वारा सक्षम) हर अंतिम ग्राहक के लिए एक child organization बना सकते हैं और ऊपर के किसी भी endpoint पर X-Orquesta-Org: <child id> भेजकर उस पर कार्रवाई कर सकते हैं। Stripe बिलिंग वाले child को पहले अपने checkout से भुगतान करना होगा; तब तक VM बनाने पर 402 के साथ code: billing_required मिलता है।

Scopes

Key के पास केवल वही scopes होते हैं जो आप चुनते हैं। इनसे बाहर के अनुरोध पर 403 मिलता है, जिसमें छूटे हुए scope का नाम होता है।

दो presets अधिकांश मामलों को कवर करते हैं: Read only (opt-in vms:read को छोड़कर हर :read scope) और Read + submit prompts। कोई scope बताए बिना key बनाने पर read-only key मिलती है। इंफ्रास्ट्रक्चर scopes किसी preset में कभी नहीं होते: उन्हें स्पष्ट रूप से चुनें।

प्रोजेक्ट प्रतिबंध

Key तब तक org-wide होती है जब तक आप उसे सीमित न करें। प्रोजेक्ट चुनने पर हर endpoint — REST और MCP — उन्हीं तक फ़िल्टर हो जाता है: सूचियाँ केवल उन प्रोजेक्ट्स की पंक्तियाँ लौटाती हैं, और किसी और चीज़ को माँगने पर404 मिलता है, जो ऐसे प्रोजेक्ट के जवाब जैसा ही है जो मौजूद नहीं है, इसलिए कोई key यह नहीं जाँच सकती कि कौन-सी प्रोजेक्ट id असली हैं। मौजूदा keys तब तक org-wide रहती हैं जब तक आप उन्हें एडिट न करें।

# A key restricted to one project
curl -H "Authorization: Bearer oak_xxx" \
  "https://getorquesta.com/api/v1/prompts?projectId=<allowed>"   # 200

curl -H "Authorization: Bearer oak_xxx" \
  "https://getorquesta.com/api/v1/prompts?projectId=<other>"     # 404

OSS कम्युनिटी

Orquesta OSS प्लेटफ़ॉर्म का self-hosted, ओपन-सोर्स संस्करण है। OSS instances चाहें तो खुद को getorquesta.com/feed कम्युनिटी फ़ीड में प्रकाशित कर सकते हैं, जिससे आपका instance अन्य डेवलपर्स को दिखाई देता है।

Self-Hosting

OSS संस्करण के साथ शुरू करें:

# Clone the repository
git clone https://github.com/Orquesta-live/orquesta-oss.git
cd orquesta-oss

# Install dependencies
npm install

# Set up the database
npx prisma db push

# Start the development server
npm run dev

OSS Stack:

• Next.js 15 + Prisma + SQLite (किसी बाहरी DB की ज़रूरत नहीं)
• ऑथेंटिकेशन के लिए Better Auth
• रीयल-टाइम agent संचार के लिए Socket.io
• पूरा Agent Grid, agent tokens और इंटरैक्टिव सेशन

कम्युनिटी फ़ीड में प्रकाशित करें

OSS instance के मालिक अपने instance को getorquesta.com/feed पर कम्युनिटी फ़ीड में प्रकाशित कर सकते हैं। इससे आपका instance कम्युनिटी को दिखाई देता है।

प्रकाशित कैसे करें:

• अपने OSS instance का dashboard खोलें
• प्रोजेक्ट हेडर में Publish to Community बटन पर क्लिक करें (केवल owner)
• आपके instance का विवरण यहाँ भेजा जाता है: POST /api/oss/publish
• आपका instance यहाँ के Community सेक्शन में दिखता है: /feed

API:

बिलिंग और प्लान

फ़ीचर तुलना

Batuta LLM Add-on

Batuta LLM एक managed LLM proxy है जो आपकी टीम को सभी प्रमुख AI मॉडल (GPT-4o, Claude, Gemini, DeepSeek, Mistral, Grok) तक API keys मैनेज किए बिना पहुँच देता है। इसे dashboard चैट या Orquesta CLI के ज़रिए इस्तेमाल करें।

Batuta Standard, Max प्लान में शामिल है — Max orgs को अपने आप 5M token/माह कोटा मिलता है और उन्हें add-on की ज़रूरत नहीं है। नीचे के Plus, Pro और Team टियर आपको और आगे बढ़ने देते हैं।

Enterprise

Orquesta Enterprise उन संगठनों के लिए बना है जिन्हें AI-संचालित डेवलपमेंट वर्कफ़्लो पर उन्नत सुरक्षा, कंप्लायंस और नियंत्रण चाहिए। SSO और सूक्ष्म अनुमतियों से लेकर on-premise डिप्लॉयमेंट और SOC 2 कंप्लायंस तक, Enterprise आपकी सिक्योरिटी और प्रोक्योरमेंट टीमों को वह सब देता है जो उन्हें Orquesta को प्रोडक्शन उपयोग के लिए मंज़ूर करने के लिए चाहिए।

SSO और Identity Management

Orquesta आपके मौजूदा identity provider के साथ इंटीग्रेट होता है ताकि आपकी टीम अपने कॉर्पोरेट क्रेडेंशियल से लॉग इन कर सके। अलग पासवर्ड नहीं, मैन्युअल यूज़र प्रोविज़निंग नहीं।

SCIM Provisioning

SCIM 2.0 से यूज़र लाइफ़साइकिल मैनेजमेंट ऑटोमेट करें। जब कर्मचारी आपके संगठन से जुड़ते या छोड़ते हैं, तो आपके identity provider के ज़रिए उनका Orquesta एक्सेस अपने आप प्रोविज़न या रद्द हो जाता है।

• IdP ग्रुप में जोड़े जाने पर यूज़र अपने आप बनता है
• IdP से हटाए जाने पर अपने आप निष्क्रिय हो जाता है
• Group-to-role मैपिंग (IdP groups, Orquesta roles से मैप होते हैं)
• पहली बार लॉगिन के लिए Just-in-time (JIT) प्रोविज़निंग

Multi-Factor Authentication (MFA)

संगठन स्तर पर MFA अनिवार्य करें। Orquesta TOTP (authenticator apps), WebAuthn (YubiKey जैसी hardware keys) और फ़ॉलबैक के रूप में SMS को सपोर्ट करता है। Admins सभी सदस्यों या विशिष्ट roles के लिए MFA अनिवार्य कर सकते हैं।

डोमेन सत्यापन

अपने ईमेल डोमेन (जैसे @yourcompany.com) पर दावा करें ताकि उस डोमेन से साइन अप करने वाला हर कर्मचारी अपने आप आपके संगठन में जुड़ जाए। इससे shadow accounts रुकते हैं और केंद्रीकृत प्रबंधन सुनिश्चित होता है।

उन्नत Roles और अनुमतियाँ

Enterprise RBAC मानक Admin / Developer / Viewer roles से आगे जाता है। विशिष्ट प्रोजेक्ट्स, environments और कार्रवाइयों तक सीमित सूक्ष्म अनुमतियों वाले कस्टम roles बनाएँ।

अंतर्निहित Enterprise Roles

कस्टम Roles

सूक्ष्म अनुमति सेट वाले कस्टम roles बनाएँ। हर अनुमति resource + action का संयोजन है:

{
  "name": "Senior Developer",
  "permissions": [
    "prompts:submit",
    "prompts:execute",
    "prompts:approve",
    "logs:read",
    "git:commit",
    "git:push",
    "agents:connect",
    "agents:interactive_session",
    "vm:ssh",
    "settings:claude_md:edit"
  ],
  "restrictions": {
    "environments": ["development", "staging"],
    "max_tokens_per_prompt": 50000,
    "blocked_commands": ["rm -rf /", "DROP DATABASE", "format"]
  }
}

Environment-Scoped एक्सेस

तय करें कि हर role किन environments को टारगेट कर सकता है। एक डेवलपर के पास development और staging का पूर्ण एक्सेस हो सकता है लेकिन production के लिए अनुमोदन ज़रूरी हो। Environments प्रति प्रोजेक्ट परिभाषित होते हैं और agent स्तर पर लागू किए जाते हैं।

• Development — खुला एक्सेस, किसी अनुमोदन की ज़रूरत नहीं
• Staging — डेवलपर एक्सेस, वैकल्पिक रिव्यू
• Production — Reviewer या Project Admin से quality gate अनुमोदन आवश्यक
• Restricted — केवल Org Admins और Security Officers, हर कार्रवाई का पूर्ण audit

Command Allowlists और Blocklists

तय करें कि प्रति role और environment कौन-से shell commands और patterns अनुमत या अवरुद्ध हैं। Agent निष्पादन से पहले ये नियम लागू करता है, जिससे विनाशकारी या अनधिकृत ऑपरेशन रुकते हैं।

{
  "production": {
    "blocked_patterns": [
      "rm -rf",
      "DROP TABLE",
      "DROP DATABASE",
      "truncate",
      "format",
      "mkfs",
      "dd if=",
      "> /dev/sd"
    ],
    "require_approval": [
      "git push",
      "npm publish",
      "docker build",
      "kubectl apply",
      "terraform apply"
    ]
  }
}

IP Allowlisting

Dashboard और API एक्सेस को विशिष्ट IP रेंज तक सीमित करें। केवल आपके कॉर्पोरेट नेटवर्क, VPN या अनुमोदित CIDR blocks से आए अनुरोध ही Orquesta तक पहुँच सकते हैं। संगठन स्तर पर कॉन्फ़िगर किया जाता है।

{
  "ip_allowlist": {
    "enabled": true,
    "ranges": [
      "203.0.113.0/24",
      "198.51.100.0/24",
      "10.0.0.0/8"
    ],
    "bypass_for_sso": false,
    "enforce_on_api": true,
    "enforce_on_agents": true
  }
}

डिप्लॉयमेंट विकल्प

वह डिप्लॉयमेंट मॉडल चुनें जो आपकी सिक्योरिटी और कंप्लायंस ज़रूरतों से मेल खाए। Orquesta पूरी तरह managed क्लाउड से लेकर air-gapped on-premise इंस्टॉलेशन तक सब कुछ सपोर्ट करता है।

Data Residency

क्षेत्रीय नियमों के अनुपालन के लिए चुनें कि आपका डेटा कहाँ स्टोर हो। managed क्लाउड और VPC डिप्लॉयमेंट के लिए उपलब्ध क्षेत्र:

• US East (Virginia) — डिफ़ॉल्ट
• US West (Oregon)
• EU West (Frankfurt) — GDPR-अनुपालक
• EU North (Stockholm)
• LATAM (Sao Paulo)
• APAC (Sydney, Tokyo)

High Availability आर्किटेक्चर

Enterprise डिप्लॉयमेंट स्वचालित failover के साथ high-availability कॉन्फ़िगरेशन में चलते हैं:

• स्वचालित failover के साथ Multi-AZ डेटाबेस replication
• availability zones में load-balanced API servers
• sticky sessions और पुनः-कनेक्शन हैंडलिंग के साथ WebSocket relay
• रीयल-टाइम state और caching के लिए Redis cluster
• 30-दिन retention (कॉन्फ़िगर करने योग्य) के साथ स्वचालित दैनिक बैकअप
• RPO < 1 घंटा, RTO < 4 घंटे के साथ डिज़ास्टर रिकवरी

Audit और Governance

Orquesta की हर कार्रवाई पूरे संदर्भ के साथ लॉग होती है। Enterprise audit मानक लॉगिंग से आगे जाकर immutable audit trails, SIEM इंटीग्रेशन और कॉन्फ़िगर करने योग्य retention नीतियाँ देता है।

अपरिवर्तनीय ऑडिट लॉग

हर इवेंट एक append-only ऑडिट लॉग में लिखा जाता है, जिसे Org Owners भी न तो बदल सकते हैं और न ही हटा सकते हैं। छेड़छाड़ का पता लगाने के लिए इवेंट्स क्रिप्टोग्राफ़िक रूप से आपस में जुड़े होते हैं।

SIEM इंटीग्रेशन

ऑडिट इवेंट्स को रियल-टाइम में अपने SIEM या लॉग प्रबंधन प्लेटफ़ॉर्म पर स्ट्रीम करें। समर्थित गंतव्य:

• Splunk — HEC (HTTP Event Collector) के माध्यम से
• Datadog — Log Forwarding API के माध्यम से
• Elastic / ELK — Elasticsearch bulk API के माध्यम से
• AWS CloudWatch — VPC डिप्लॉयमेंट के लिए
• Azure Monitor — Log Analytics workspace के माध्यम से
• Custom Webhook — कोई भी HTTPS endpoint, JSON payload, HMAC-हस्ताक्षरित

अनुमोदन वर्कफ़्लो

Enterprise quality gates बहु-स्तरीय अनुमोदन श्रृंखलाओं का समर्थन करते हैं। प्रत्येक परिवेश और कार्रवाई प्रकार के लिए अनुमोदन आवश्यकताएँ कॉन्फ़िगर करें:

{
  "approval_policy": {
    "production": {
      "prompt_execution": {
        "required_approvals": 2,
        "approver_roles": ["Reviewer", "Project Admin"],
        "auto_reject_after_hours": 48,
        "require_diff_review": true
      },
      "git_push": {
        "required_approvals": 1,
        "approver_roles": ["Project Admin", "Org Admin"]
      },
      "destructive_commands": {
        "required_approvals": 2,
        "approver_roles": ["Org Admin", "Security Officer"],
        "notify": ["#security-alerts"]
      }
    },
    "staging": {
      "prompt_execution": {
        "required_approvals": 1,
        "approver_roles": ["Reviewer", "Developer"],
        "auto_approve_after_hours": 24
      }
    }
  }
}

डेटा प्रतिधारण नीतियाँ

कॉन्फ़िगर करें कि विभिन्न प्रकार के डेटा कितने समय तक रखे जाएँ। स्टोरेज लागत को नियंत्रित रखते हुए नियामकीय आवश्यकताएँ पूरी करें:

• ऑडिट लॉग — न्यूनतम 1 वर्ष, 7 वर्ष तक कॉन्फ़िगर करने योग्य (SOC 2, HIPAA के लिए आवश्यक)
• निष्पादन लॉग — डिफ़ॉल्ट 90 दिन, कॉन्फ़िगर करने योग्य
• प्रॉम्प्ट इतिहास — डिफ़ॉल्ट 1 वर्ष, कॉन्फ़िगर करने योग्य
• Git diffs — अनिश्चित काल तक रखे जाते हैं (commits से जुड़े)
• सत्र रिकॉर्डिंग — डिफ़ॉल्ट 30 दिन, कॉन्फ़िगर करने योग्य
• स्वचालित पर्ज — प्रतिधारण अवधि समाप्त होने के बाद डेटा सुरक्षित रूप से हटा दिया जाता है

लागत प्रबंधन और बजट

Enterprise लागत प्रबंधन वित्त और इंजीनियरिंग लीडर्स को पूरे संगठन में AI खर्च पर पूरी दृश्यता और नियंत्रण देता है।

बजट नियंत्रण

उपयोग डैशबोर्ड

एक समर्पित enterprise एनालिटिक्स डैशबोर्ड प्रदान करता है:

• सभी प्रोजेक्ट्स और टीमों में रियल-टाइम token उपयोग
• प्रोजेक्ट, उपयोगकर्ता, टीम और परिवेश के अनुसार लागत विवरण
• मासिक/त्रैमासिक रिपोर्ट के साथ ऐतिहासिक रुझान विश्लेषण
• वित्त रिपोर्टिंग के लिए CSV/PDF में एक्सपोर्ट
• API लागत विभाजन (कौन सा LLM प्रदाता, मॉडल और टियर)
• उपयोग रुझानों पर आधारित पूर्वानुमान

Enterprise इंटीग्रेशन

Orquesta को उन टूल्स से जोड़ें जिनका आपकी टीम पहले से उपयोग करती है। Enterprise इंटीग्रेशन मानक webhooks से आगे बढ़कर गहरे, द्विदिशीय इंटीग्रेशन प्रदान करते हैं।

Webhook सिस्टम

Enterprise webhook सिस्टम किसी भी HTTPS endpoint का समर्थन करता है, जिसमें कॉन्फ़िगर करने योग्य इवेंट, retry नीतियाँ और HMAC हस्ताक्षर सत्यापन शामिल हैं:

{
  "url": "https://your-service.com/webhooks/orquesta",
  "secret": "whsec_...",
  "events": [
    "prompt.submitted",
    "prompt.approved",
    "prompt.executed",
    "prompt.failed",
    "agent.connected",
    "agent.disconnected",
    "security.alert",
    "budget.threshold"
  ],
  "retry_policy": {
    "max_retries": 5,
    "backoff": "exponential",
    "timeout_ms": 30000
  },
  "headers": {
    "X-Custom-Header": "value"
  }
}

SLA और सपोर्ट टियर

Enterprise ग्राहकों को गारंटीकृत प्रतिक्रिया समय और समर्पित कस्टमर सक्सेस टीम के साथ प्रीमियम सपोर्ट मिलता है।

Slack Connect

Enterprise ग्राहकों को Orquesta इंजीनियरिंग के साथ एक साझा Slack Connect चैनल मिलता है। तेज़ समस्या समाधान, फ़ीचर अनुरोधों और आर्किटेक्चर मार्गदर्शन के लिए प्रोडक्ट बनाने वाली टीम से सीधे संपर्क करें।

अनुपालन और प्रमाणन

Orquesta उच्चतम सुरक्षा और अनुपालन मानकों को पूरा करने के लिए प्रतिबद्ध है। नीचे हमारी वर्तमान अनुपालन स्थिति और प्रमाणन रोडमैप दिया गया है।

वर्तमान अनुपालन

प्रमाणन रोडमैप

हमारे enterprise अनुपालन रोडमैप के अंतर्गत निम्नलिखित प्रमाणन नियोजित हैं या प्रगति में हैं:

सुरक्षा प्रथाएँ

• पेनिट्रेशन टेस्टिंग — वार्षिक तृतीय-पक्ष pentest। परिणाम NDA के तहत उपलब्ध।
• Bug Bounty प्रोग्राम — सुरक्षा शोधकर्ताओं के लिए जिम्मेदार प्रकटीकरण कार्यक्रम।
• Dependency स्कैनिंग — Snyk/Dependabot के माध्यम से हर build पर स्वचालित CVE स्कैनिंग।
• स्टैटिक विश्लेषण — CI/CD pipeline में एकीकृत SAST टूलिंग।
• Secret डिटेक्शन — Pre-commit hooks और CI चेक secrets के लीक होने से रोकते हैं।
• कर्मचारी सुरक्षा — बैकग्राउंड चेक, सुरक्षा प्रशिक्षण, न्यूनतम-विशेषाधिकार एक्सेस, इन्फ्रास्ट्रक्चर के लिए हार्डवेयर कुंजियाँ।
• Incident रिस्पॉन्स — P1 incidents के लिए 1 घंटे की स्वीकृति के साथ प्रलेखित IR योजना। 72 घंटे के भीतर पोस्टमॉर्टम।
• विक्रेता प्रबंधन — सभी sub-processors का सुरक्षा स्थिति के लिए मूल्यांकन। सभी विक्रेताओं के साथ DPA मौजूद।

Trust Center

हमारे सार्वजनिक Trust Center के लिए getorquesta.com/trust पर जाएँ, जिसमें शामिल हैं:

• रियल-टाइम सिस्टम स्थिति और अपटाइम इतिहास
• सुरक्षा व्हाइटपेपर (डाउनलोड करने योग्य PDF)
• SOC 2 रिपोर्ट अनुरोध फ़ॉर्म
• DPA (Data Processing Agreement) टेम्पलेट
• Sub-processor सूची
• पेनिट्रेशन टेस्ट सारांश
• जिम्मेदार प्रकटीकरण / bug bounty नीति

Enterprise ऑनबोर्डिंग

हर enterprise ग्राहक को एक संरचित ऑनबोर्डिंग अनुभव मिलता है, ताकि मूल्य तक जल्दी पहुँचा जा सके और टीमों में सफल अपनाया जा सके।

ऑनबोर्डिंग समयरेखा

Enterprise मूल्यांकन

हम पूर्ण फ़ीचर एक्सेस के साथ 30-दिन का enterprise पायलट प्रदान करते हैं। पायलट में शामिल हैं:

• पूर्ण Enterprise फ़ीचर सेट (SSO, RBAC, ऑडिट, इंटीग्रेशन)
• पायलट अवधि के दौरान 25 उपयोगकर्ताओं तक
• Orquesta टीम के साथ समर्पित Slack Connect चैनल
• दो 1-घंटे के ऑनबोर्डिंग सत्र
• पहले से भरी हुई सुरक्षा प्रश्नावली
• आपके विशिष्ट वर्कफ़्लो के लिए कस्टम proof-of-concept