Omnigent क्या है और इसे कैसे सेटअप करें

Omnigent क्या है

Omnigent एक ओपन सोर्स मेटा-हार्नेस है: यह एक ऐसा ऑर्केस्ट्रेशन लेयर है जो आपके द्वारा पहले से इंस्टॉल किए गए एजेंट कमांड लाइन टूल्स (CLIs) को संचालित करता है। यह Claude Code, Codex, Cursor, OpenCode, Hermes या Pi की जगह नहीं लेता है। यह उन्हें शुरू करता है, प्रत्येक को एक कार्य देता है, और एक ही पॉलिसी सेट के साथ एक ही सत्र (session) में परिणाम की निगरानी करता है। Databricks ने जून 2026 में Apache 2.0 लाइसेंस के तहत इस रिपॉजिटरी को प्रकाशित किया था, और मुख्य पृष्ठ पर अभी भी Status: alpha लिखा है।

इसका व्यावहारिक दावा सीमित है, और इसे स्पष्ट रूप से बताना उचित है। आप YAML में एक बार एक एजेंट का वर्णन करते हैं, और उस हार्नेस का नाम देते हैं जो इसे चलाता है। उस एक लाइन को बदलें और वही एजेंट किसी अन्य वेंडर के CLI पर चलने लगेगा। आपके सेटअप में कुछ और नहीं बदलता है, क्योंकि Omnigent एजेंटों के अंदर के लूप के बजाय उनके ऊपर के लूप को नियंत्रित करता है।

Meta-harness क्या है, और यह framework से किस प्रकार भिन्न है?

Harness वह प्रोग्राम है जो एक model को loop में लपेटता है। यह आपके prompt को पढ़ता है, tools को call करता है, files को edit करता है और परिणाम वापस देता है। Claude Code एक harness है। Codex एक harness है। आप इसे install करते हैं, login करते हैं, और यह अपने आप काम करता है।

Framework एक library है जिसके विरुद्ध आप code लिखते हैं। आप इसे import करते हैं, Python में steps परिभाषित करते हैं, और आपका प्रोग्राम agent बन जाता है। वहाँ vendor बदलने का अर्थ है अपने code को edit करना, क्योंकि vendor का client आपके प्रोग्राम के माध्यम से जुड़ा होता है।

Meta-harness इन दोनों से एक स्तर ऊपर स्थित होता है। यह एक supervisor है जो harnesses को child processes के रूप में चलाता है। Omnigent vendor CLI को start करता है, उसे काम सौंपता है, और जो परिणाम आता है उसे पढ़ता है। आप उस CLI को बनाए रखते हैं जिसे आपने पहले ही install किया है, और आप उस subscription या API (application programming interface) key को भी बनाए रखते हैं जो पहले से ही इसके लिए भुगतान कर रही है। यही पूरा अंतर है, और यह तय करता है कि यह tool किसके लिए है: उन लोगों के लिए जिनके पास पहले से ही कई agent CLIs काम कर रहे हैं, और जो उन्हें एक बार में एक terminal पर चलाने से थक चुके हैं।

एक orchestration layer कौन सी समस्या का समाधान करती है?

• Vendor बदलने की लागत एक लाइन की है। Agent definition में harness और model डेटा के रूप में होते हैं, इसलिए किसी role को एक vendor से दूसरे vendor पर ले जाने के लिए केवल YAML फाइल में बदलाव करना पड़ता है, उसे फिर से लिखने की आवश्यकता नहीं होती।
• Review अलग-अलग vendors के बीच हो सकता है। एक model द्वारा लिखे गए diff को किसी दूसरी कंपनी के model द्वारा पढ़ा जा सकता है। एक ही परिवार के दो models में अक्सर एक जैसी कमियां होती हैं, इसलिए एक ही vendor से दूसरी राय लेने का मूल्य कम होता है।
• Policy का एक ही स्थान होता है। खर्च की सीमाएं और approval prompts को agent फाइल में घोषित किया जाता है, और वे इसके अंतर्गत आने वाले प्रत्येक sub-agent पर लागू होते हैं।
• Session किसी एक tool से अधिक समय तक चलता है। एक transcript में कई CLIs द्वारा किए गए कार्य शामिल होते हैं, इसलिए आप चार अलग-अलग scrollbacks को जोड़े बिना यह पढ़ सकते हैं कि क्या हुआ था।

इसकी लागत स्वयं यह layer है। Omnigent में मौजूद हर bug अब आपके और उस agent के बीच एक बाधा है जो पहले स्वतंत्र रूप से काम करता था। alpha चरण में यह एक वास्तविक लागत है, न कि केवल सैद्धांतिक।

मल्टी-एजेंट हार्नेस और सिंगल-एजेंट टूल्स का तालमेल

यदि आपने अभी तक सर्वर पर एक भी एजेंट रन नहीं किया है, तो पहले वहां से शुरुआत करें। VPS पर कोडिंग एजेंट चलाने के लिए हमारी गाइड सिंगल-एजेंट के मामले को पूरी तरह कवर करती है, और Omnigent इसी सेटअप को आधार मानकर चलता है। सेल्फ-होस्टेड AI एजेंट्स का व्यापक क्षेत्र वह जगह है जहां आप स्वयं एजेंट्स का चुनाव करते हैं, और यदि यहाँ इस्तेमाल की गई शब्दावली आपके लिए नई है, तो एजेंट्स कैसे काम करते हैं, यह सीखना आपके लिए बेहतर शुरुआती कदम होगा।

Omnigent एक कनेक्टर लेयर से अलग आयाम पर काम करता है। एजेंट्स को अपने डेटा स्रोतों तक पहुंच प्रदान करना जैसे कार्य इस बारे में हैं कि एक एजेंट क्या एक्सेस कर सकता है। Omnigent इस बारे में है कि कौन सा एजेंट, किस क्रम में और किन सीमाओं के भीतर रन होगा। आप एक ही समय में दोनों की आवश्यकता महसूस कर सकते हैं, और ये एक-दूसरे के कार्यक्षेत्र में हस्तक्षेप नहीं करते हैं।

इंस्टॉलेशन से पहले आपकी आवश्यकताएं

• Python 3.12 या उससे नया वर्ज़न। प्रकाशित पैकेज requires-python >= 3.12 घोषित करता है।
• tmux, क्योंकि टर्मिनल हार्नेस इसके अंदर चलते हैं।
• कम से कम एक वेंडर CLI, जो पहले से इंस्टॉल हो और जिसमें आप लॉग इन हों।
• Node.js 22 केवल तभी आवश्यक है यदि आप git checkout से बिल्ड कर रहे हों। PyPI पर मौजूद व्हील में पहले से बिल्ड की गई वेब एसेट्स शामिल होती हैं, इसलिए सामान्य इंस्टॉलेशन के लिए Node की कोई आवश्यकता नहीं है।

main के बजाय एक pinned release इंस्टॉल करें

curl -fsSL https://raw.githubusercontent.com/omnigent-ai/omnigent/main/scripts/install_oss.sh | sh -s -- --version 0.7.0

sh -s -- भाग केवल सजावट नहीं है। इसके बिना, sh इसे --version को अपना विकल्प मान लेता है और इंस्टॉलर को वह flag कभी नहीं मिलता, इसलिए आपको उस दिन का सबसे नया वर्ज़न मिल जाता है। ऐसे रिपॉजिटरी पर जो हर कुछ हफ्तों में breaking changes जारी करती है, यह एक reproducible सर्वर और अचानक आई समस्या के बीच का अंतर है।

इंस्टॉलर Astral के Python पैकेज मैनेजर, uv का उपयोग करता है, और यदि uv मौजूद न हो तो उसे पहले इंस्टॉल करने का विकल्प देता है। यदि uv पहले से मौजूद है, तो स्क्रिप्ट को छोड़ दें:

uv tool install --force --python 3.12 "omnigent==0.7.0"

Extras भी इसी पैटर्न का पालन करते हैं, और flag को दोहराया जाता है: स्क्रिप्ट पर --extra e2b --extra kubernetes, या uv के साथ "omnigent[e2b,kubernetes]"। ध्यान दें कि git tag v0.7.0 है जबकि PyPI पर पैकेज वर्ज़न 0.7.0 है।

uv बाइनरी को उस डायरेक्टरी में रखता है जिसे uv tool dir --bin रिपोर्ट करता है, जो आमतौर पर ~/.local/bin होती है, और इंस्टॉलर इसे आपके shell profile में जोड़ने का विकल्प देता है। यदि क्लीन इंस्टॉलेशन के तुरंत बाद कमांड नहीं मिलता है, तो यही कारण है। जाँचें कि आपके पास कौन सा वर्ज़न इंस्टॉल हुआ है:

omni upgrade --check

यह इंस्टॉल किए गए वर्ज़न की तुलना नवीनतम प्रकाशित वर्ज़न से करता है और आपको बताता है कि क्या कोई अपग्रेड उपलब्ध है, बिना उसे इंस्टॉल किए। omni और omnigent दो अलग नामों से एक ही प्रोग्राम हैं।

इसे एक मॉडल प्रदाता (model provider) पर पॉइंट करें

omni setup

विज़ार्ड आपके वातावरण में पहले से मौजूद क्रेडेंशियल्स की तलाश करता है और जो अनुपस्थित हैं उनके लिए प्रॉम्प्ट देता है। यह API keys, वेंडर सब्सक्रिप्शन, OpenRouter या Ollama जैसे गेटवे, और Databricks वर्कस्पेस को हैंडल करता है। यदि आप पहले से ही उसी मशीन पर Ollama के साथ एक लोकल मॉडल सर्वर चला रहे हैं, तो एक गेटवे को उस पर पॉइंट करें और ट्रैफिक कभी भी बॉक्स (मशीन) से बाहर नहीं जाएगा।

एक न्यूनतम multi-agent रन

उदाहरण agents रिपॉजिटरी में मौजूद हैं, इसलिए main के बजाय उसी tag को clone करें जिसे आपने install किया है।

git clone --depth 1 --branch v0.7.0 https://github.com/omnigent-ai/omnigent.git
cd omnigent
omnigent run examples/polly/

Polly एक multi-agent कोडिंग ऑर्केस्ट्रेटर है जो रिपॉजिटरी के साथ आता है। इसकी config में claude_code, codex, opencode, cursor, hermes और pi नामक sub-agents घोषित हैं, और एक नियम है जो इस पूरी प्रक्रिया को सार्थक बनाता है: समीक्षा हमेशा implementer से अलग vendor द्वारा की जाती है। Polly स्वयं कोई कोड नहीं लिखता है। यह योजना बनाता है, लक्ष्य को कार्य मदों में विभाजित करता है, प्रत्येक को सौंपता है, और प्रत्येक diff को दूसरे vendor के समीक्षक के पास भेजता है।

कुछ भी सौंपने से पहले, Polly यह देखने के लिए एक preflight check चलाता है कि मशीन पर कौन से sub-agent CLIs वास्तव में मौजूद हैं। केवल एक vendor CLI install होने पर diff देने के लिए कोई नहीं होता है, इसलिए आउटपुट का आकलन करने से पहले कम से कम दो install करें। Debby, जो दूसरा उदाहरण है, दो सिरों वाला एक debate agent है, जिसमें एक Claude और एक GPT है:

omni debby

यह पुष्टि करने का एक संक्षिप्त तरीका है कि दो providers कॉन्फ़िगर किए गए हैं, क्योंकि कुछ भी कहने के लिए इसे दोनों की आवश्यकता होती है।

Sub-agents को tools के रूप में घोषित किया जाता है

Agent फ़ाइल YAML प्रारूप में होती है। executor में harness, model और authentication का नाम दिया जाता है। tools में MCP (model context protocol) servers, Python functions और sub-agents रखे जाते हैं। एक sub-agent, type: agent और अपने स्वयं के executor के साथ एक tool होता है, जो ऊपर बताई गई हर चीज़ के पीछे का मुख्य तंत्र है।

name: orchestrator
prompt: |
  You coordinate coding and review tasks.

executor:
  harness: claude-sdk
  model: databricks-claude-sonnet-4-6

tools:
  coder:
    type: agent
    prompt: Write and test code.
    executor:
      harness: claude-sdk
      model: databricks-claude-opus-4-7
  reviewer:
    type: agent
    prompt: Review proposed changes.
    executor:
      harness: claude-sdk
      model: databricks-claude-sonnet-4-6

omnigent run path/to/my_agent.yaml

ये model ids प्रोजेक्ट के अपने docs/AGENT_YAML_SPEC.md उदाहरण से आते हैं, और ये Databricks-hosted नाम हैं। harness और model को उस मान से बदलें जिसे आपने अपने बॉक्स पर omni setup के लिए कॉन्फ़िगर किया है। स्पेक (spec) में अन्य harness मानों में antigravity, copilot, kimi, qwen और acp:<slug> शामिल हैं, जो किसी भी जेनेरिक प्रोटोकॉल पर बात करने वाली चीज़ों के लिए हैं। यह स्पेक sub-agent पर pass_history: true का भी समर्थन करता है, जो उसे पैरेंट कन्वर्सेशन (parent conversation) सौंप देता है। हर डेलिगेशन पर इसमें टोकन खर्च होते हैं, इसलिए इसे उन sub-agents के लिए बंद रखें जिन्हें केवल अपने सामने दिए गए कार्य की आवश्यकता है। एक कोडर जिसका prompt उसे सबसे छोटा बदलाव जो काम करे करने के लिए कहता है, वह अपने समीक्षक को इतना छोटा diff देता है जिसे वास्तव में पढ़ा जा सके, जो यहाँ किसी भी भूमिका के लिए आपके द्वारा चुने गए मॉडल से अधिक मायने रखता है।

लंबे समय तक चलने वाले ऑर्केस्ट्रेशन के लिए VPS का उपयोग क्यों करें

मल्टी-एजेंट रन केवल दो मिनट का कमांड नहीं है। इसमें योजना बनाना, कार्य सौंपना, समानांतर git worktrees पर प्रतीक्षा करना, समीक्षा करना और संशोधन करना शामिल है। लैपटॉप का ढक्कन बंद करने से यह सब रुक जाता है। एक VPS (virtual private server) हमेशा चालू रहता है और अपना नेटवर्क बनाए रखता है, इसलिए जब आप उसे नहीं देख रहे होते हैं तब भी सत्र (session) सक्रिय रहता है।

omnigent server --background
omnigent server status

सर्वर port 6767 पर एक वेब यूजर इंटरफेस होस्ट करता है। omnigent server status यह रिपोर्ट करता है कि क्या कोई रन चल रहा है, और omnigent stop इसे बंद कर देता है। v0.7.0 से पहले के releases में यह omni server start था, जिसे अब हटा दिया गया है, इसलिए पुराने लेख और स्क्रीनशॉट आपके टर्मिनल के व्यवहार से मेल नहीं खाएंगे।

6767 को किसी public address पर पब्लिश न करें। दो तरीके सुरक्षित हैं। firewall पर port को बंद रखें और इसे ssh -N -L 6767:localhost:6767 you@your-server के साथ SSH के माध्यम से फॉरवर्ड करें, फिर अपने कंप्यूटर पर http://localhost:6767 पर वेब इंटरफेस खोलें। या इसके सामने TLS (transport layer security) को terminate करें और authentication चालू करें:

OMNIGENT_AUTH_ENABLED=1 omnigent server --background

इसका firewall वाला हिस्सा सामान्य कार्य है, जो VPS के लिए ufw firewall की बुनियादी जानकारी में कवर किया गया है, और यदि बॉक्स पहले से ही कई Docker Compose ऐप्स के सामने Traefik के पीछे कंटेनर चला रहा है, तो Omnigent उसी पैटर्न में एक और सर्विस है।

कंटेनर डिप्लॉयमेंट के लिए, रिपॉजिटरी की deploy/ डायरेक्टरी में एक Compose सेटअप मौजूद है: ./bootstrap.sh secrets को .env में बनाता है, फिर docker compose up -d Omnigent और Postgres को port 6767 पर शुरू करता है। DATABASE_URL Postgres या SQLite का चयन करता है, और OMNIGENT_AUTH_ENABLED कंटेनरों के अंदर डिफ़ॉल्ट रूप से 1 का उपयोग करता है, जो बाहर से एक्सेस की जा सकने वाली किसी भी चीज़ के लिए सही डिफ़ॉल्ट है।

साइजिंग के बारे में, डिप्लॉय नोट्स के अनुसार सर्वर का वर्किंग सेट लगभग 512 MB से 1 GB है, और Fly.io कॉन्फ़िगरेशन 1 GB निर्धारित करता है। यह आंकड़ा केवल सुपरवाइजर के लिए है। प्रत्येक सब-एजेंट एक अलग प्रोसेस है जो अपना स्वयं का चेकआउट और अपना मॉडल क्लाइंट रखता है, इसलिए एजेंटों की संख्या के अनुसार बॉक्स का आकार चुनें। एक बार सर्वर चालू हो जाने पर, omnigent login https://your-host और उसके बाद omnigent host https://your-host आपके लैपटॉप को उसके साथ रजिस्टर करता है, और omnigent attach <session_id> किसी अन्य डिवाइस से चल रहे सत्र को फिर से शुरू करता है।

किसी भी sub-agent को छोड़ने से पहले उसे sandbox में रखें

Omnigent, Omnibox नामक एक operating system level sandbox प्रदान करता है। Linux पर यह bubblewrap namespaces और seccomp का उपयोग करता है, इसलिए kernel agent के prompt के बजाय boundary को लागू करता है। एक prompt-injected agent kernel के नियमों को तोड़कर बाहर नहीं निकल सकता। सबसे पहले dependency install करें:

sudo apt install bubblewrap

Configuration agent file में os_env के अंतर्गत रहती है:

os_env:
  type: caller_process
  cwd: .
  sandbox:
    type: linux_bwrap
    write_paths: [.]
    write_files: []
    read_paths: []
    allow_network: true
    cwd_allow_hidden: [.venv]
    env_passthrough: []
    egress_rules: []
    credential_proxy: []

Working directory तब तक read-only रहती है जब तक आप उसे write_paths में सूचीबद्ध न करें, इसलिए यदि कोई agent गलत व्यवहार करता है, तो वह workspace के बाहर कुछ भी लिख नहीं सकता। Dotfiles तब तक छिपे रहते हैं जब तक कि उन्हें cwd_allow_hidden में नाम न दिया जाए, जिसका अर्थ है कि व्यापक read grant चुपचाप .ssh या .aws को expose नहीं करता है। egress_rules सेट करें और सारा HTTP तथा HTTPS traffic एक default deny proxy के माध्यम से जाएगा, जहाँ प्रत्येक नियम "METHODS host/path-glob" के रूप में लिखा जाता है। credential_proxy एक कदम और आगे जाता है: agent के पास केवल एक placeholder होता है, और जैसे ही request बाहर जाती है, proxy असली secret को swap कर देता है, ताकि leaked transcript में कोई भी उपयोगी जानकारी न मिले। Multi-harness setup में प्रत्येक sub-agent की अपनी config file में agents/ के अंतर्गत अपना sandbox block होता है, इसलिए reviewer को network access से वंचित किया जा सकता है जबकि implementer के पास वह बना रहता है।

सीमा documentation में बताई गई है, और यह महत्वपूर्ण है। OS sandbox sys_os_* tool calls और terminals पर लागू होता है। यह MCP servers को कवर नहीं करता है, और यह स्वयं Omnigent supervisor process को भी कवर नहीं करता है। आपके द्वारा शुरू किया गया MCP server आपकी permissions के साथ box के बाहर चलता है। यही कारण है कि अधिक मजबूत pattern अभी भी प्रति agent एक throwaway machine का उपयोग करना है, जो disposable VM में coding agents चलाना का विषय है। काम का दूसरा हिस्सा credentials है, और agent की पहुँच से secrets को दूर रखना तब और कठिन हो जाता है, आसान नहीं, जब छह sub-agents एक ही host साझा करते हैं।

Spend limits नीतियां हैं, जिन्हें उसी file में घोषित किया जाता है:

policies:
  budget:
    type: function
    handler: omnigent.policies.builtins.cost.cost_budget
    factory_params:
      max_cost_usd: 5.00
      ask_thresholds_usd: [1.00, 3.00]

एक run जो एक vendor के साथ योजना बनाता है, दूसरे के साथ implement करता है और तीसरे के साथ review करता है, वह एक ही समय में तीन जगहों पर खर्च कर रहा होता है, इसलिए पहले invoice के बाद के बजाय पहले unattended run से पहले ही cap सेट कर दें। Built-ins में max_tool_calls_per_session और ask_on_os_tools भी शामिल हैं, जो file और shell operations से पहले approval मांगते हैं। VPS पर AI agent की लागत को नियंत्रित रखना पर हमारे नोट्स यहाँ सीधे लागू होते हैं, और वे और भी अधिक सख्ती से लागू होते हैं, क्योंकि parallel sub-agents burn rate को बढ़ा देते हैं।

यह रिपॉजिटरी कितनी तेजी से आगे बढ़ रही है?

[
  {
    "version": "v0.2.0",
    "released": "2026-06-19",
    "interval": 3
  },
  {
    "version": "v0.3.0",
    "released": "2026-06-27",
    "interval": 8
  },
  {
    "version": "v0.4.0",
    "released": "2026-07-03",
    "interval": 6
  },
  {
    "version": "v0.5.0",
    "released": "2026-07-10",
    "interval": 7
  },
  {
    "version": "v0.5.1",
    "released": "2026-07-10",
    "interval": 0
  },
  {
    "version": "v0.6.0",
    "released": "2026-07-21",
    "interval": 11
  },
  {
    "version": "v0.7.0",
    "released": "2026-07-27",
    "interval": 6
  }
]

ये तारीखें प्रोजेक्ट के अपने releases पेज से ली गई हैं, जिन्हें 3 August 2026 को पढ़ा गया था। 2026-06-19 और 2026-07-27 के बीच 7 tagged releases आए हैं, और किन्हीं दो releases के बीच का सबसे लंबा अंतराल 11 दिनों का रहा है। v0.5.1 को उसके पिछले release वाले दिन ही जारी किया गया था। पहला release, 0.1.1 जो 16 June 2026 को आया था, उसे चार्ट से बाहर रखा गया है क्योंकि मापने के लिए उससे पहले कोई tag मौजूद नहीं है।

उनमें से दो releases ने उन commands को तोड़ दिया जिन्हें guides में पहले ही document किया जा चुका था। v0.7.0 ने omni server start को हटाकर उसकी जगह omni server --background को शामिल किया। v0.6.0 ने omnigent[memory] extra का नाम बदलकर omnigent[hindsight] कर दिया, इसलिए June के लेख से कॉपी की गई install line July के build पर काम नहीं करती है। यही कारण है कि आपके install command में --version का उपयोग करना और आपके git clone में एक tag को पिन करना आवश्यक है, यह केवल स्टाइल की प्राथमिकता नहीं है।

जिन चीजों के लिए मैं अभी इस पर भरोसा नहीं करूँगा

अगस्त 2026 तक, रिपॉजिटरी में लगभग 8.1k stars, 1.2k forks और लगभग 350 open issues हैं, जबकि इसका पहला public release सात सप्ताह पुराना है। Stars रुचि को दर्शाते हैं, और रुचि का मतलब परिपक्वता (maturity) नहीं होता। प्रोजेक्ट खुद को alpha बताता है, और ऊपर दिया गया release history दिखाता है कि इसका मतलब वास्तव में alpha ही है।

• मैं इसे ऐसे host पर नहीं चलाऊँगा जिसमें production credentials हों, क्योंकि sandbox में MCP servers या supervisor शामिल नहीं हैं।
• मैं cost_budget policy के बिना इसे unattended नहीं छोड़ूँगा, क्योंकि तीन vendors एक साथ billing कर सकते हैं और उन्हें रोकने के लिए कोई अन्य तंत्र नहीं है।
• मैं OMNIGENT_AUTH_ENABLED सेट किए बिना और सामने TLS लगाए बिना सर्वर को public IP address पर expose नहीं करूँगा।
• मैं agent YAML को अभी minor versions के बीच स्थिर नहीं मानूँगा, इसलिए version को pin करें और upgrade करने से पहले release notes जरूर पढ़ें।

एक और बात जो आपको हैरान कर सकती है: v0.6.0 में anonymised usage telemetry जोड़ी गई है, और प्रोजेक्ट ने इसे एक समर्पित telemetry page पर document किया है। यदि मशीन client का काम संभालती है, तो उस page को पढ़ें और सोच-समझकर निर्णय लें।

Omnigent आज जिस चीज में वास्तव में अच्छा है, वह वही है जिसके लिए इसे बनाया गया था। आपके पास तीन या चार agent CLIs हैं, आप उनके लिए पहले से भुगतान कर रहे हैं, और आप चाहते हैं कि उनमें से एक लिखे जबकि दूसरा समीक्षा करे। यह अभी एक मशीन पर, Linux पर वास्तविक sandboxing के साथ काम करता है। इसके अलावा बाकी सब कुछ को अभी आशाजनक लेकिन अधूरा मानें।

FAQ

क्या Omnigent एक agent है, या यह agents को चलाने वाला माध्यम है?

यह agents को चलाता है। Omnigent एक meta-harness है: यह आपके द्वारा पहले से इंस्टॉल किए गए vendor CLIs (जैसे Claude Code, Codex या OpenCode) को शुरू करता है, प्रत्येक को कार्य सौंपता है, और एक ही session में परिणामों की निगरानी करता है। इसका अपना कोई model नहीं है। यही कारण है कि यह एक framework से अलग है, जहाँ आप एक library के लिए Python code लिखते हैं और आपका अपना program ही agent बन जाता है।

क्या Omnigent का उपयोग करने से पहले Claude Code और Codex का इंस्टॉल होना आवश्यक है?

आपके पास कम से कम एक vendor CLI का इंस्टॉल और logged-in होना आवश्यक है, क्योंकि Omnigent उन programs को replace करने के बजाय उन्हें संचालित (drive) करता है। साथ में दिए गए Polly उदाहरण के लिए आपको अलग-अलग vendors के दो या अधिक CLIs की आवश्यकता होगी। Polly का नियम यह है कि review हमेशा implementer से अलग vendor द्वारा किया जाना चाहिए, इसलिए यदि केवल एक ही CLI मौजूद है, तो diff भेजने के लिए कोई दूसरा vendor उपलब्ध नहीं होगा।

मैं नवीनतम version के बजाय Omnigent का कोई विशिष्ट version कैसे इंस्टॉल करूँ?

Install script के माध्यम से --version को sh -s -- के साथ पास करें, जैसा कि sh -s -- --version 0.7.0 में दिखाया गया है। -s -- के बिना, यह flag स्वयं sh द्वारा consume कर लिया जाता है और script नवीनतम release इंस्टॉल कर देती है। यदि uv पहले से मौजूद है, तो uv tool install --force --python 3.12 "omnigent==0.7.0" भी वही काम करता है। Git tag v0.7.0 है, जबकि PyPI version string 0.7.0 है।

क्या Omnibox sandbox agents को unattended चलाने के लिए पर्याप्त है?

यह जिन चीजों को कवर करता है उनके लिए मजबूत है और जो नहीं करता उनके बारे में स्पष्ट है। Linux पर यह bubblewrap और seccomp का उपयोग करता है, इसलिए kernel फाइल और network की सीमाएं लागू करता है और agent इनसे बाहर नहीं निकल सकता। documentation में उल्लेख है कि यह sys_os_* tool calls और terminals पर लागू होता है, और यह MCP servers या Omnigent supervisor process को कवर नहीं करता है। इसलिए, एक MCP server आपके सामान्य permissions के साथ चलता है, यही कारण है कि unattended कार्यों के लिए प्रति agent एक disposable virtual machine अधिक सुरक्षित isolation प्रदान करती है।

VPS पर Omnigent server को कितनी memory की आवश्यकता होती है?

Project के deploy notes के अनुसार server को लगभग 512 MB से 1 GB RAM की आवश्यकता होती है, और इसका Fly.io configuration 1 GB पर निर्धारित है। यह केवल supervisor और port 6767 पर चलने वाले web interface के लिए है। प्रत्येक sub-agent अपनी working copy और model client के साथ एक अलग process है, और Polly-style runs में समानांतर git worktrees का उपयोग होता है, इसलिए RAM और disk का आकार server के लिए नहीं, बल्कि उन agents की संख्या के आधार पर तय करें जिन्हें आप एक साथ चलाना चाहते हैं।