Omnigent क्या है? कई agent CLIs के लिए एक harness

Omnigent क्या है

Omnigent एक open source meta-harness है: यह एक orchestration layer है, जो आपके सिस्टम पर पहले से installed agent command line tools (CLIs) को चलाती है। यह Claude Code, Codex, Cursor, OpenCode, Hermes या Pi को replace नहीं करता। यह उन्हें start करता है, प्रत्येक को एक job देता है और एक ही policy set के साथ एक single session के भीतर परिणाम की निगरानी करता है। Databricks ने repository को June 2026 में Apache 2.0 licence के तहत publish किया था और front page पर अब भी Status: alpha लिखा है।

इसका practical claim सीमित है और इसे सीधे समझना उपयोगी है। आप एक agent का विवरण YAML में केवल एक बार लिखते हैं और उस harness का नाम देते हैं जो उसे चलाएगा। उस एक line को बदलने पर वही agent किसी दूसरे vendor के CLI पर चलता है। आपके setup में और कुछ नहीं बदलता, क्योंकि Omnigent agents के अंदर के loop के बजाय agents के ऊपर वाला loop नियंत्रित करता है।

meta-harness क्या है, और यह framework से कैसे अलग है?

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

framework वह library है जिसके आधार पर आप code लिखते हैं। आप इसे import करते हैं, Python में steps define करते हैं और आपका program agent बन जाता है। इसमें vendor बदलने के लिए code edit करना पड़ता है, क्योंकि vendor का client आपके program में wired होता है।

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

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

• Vendor बदलने की लागत एक line तक सीमित रहती है। Agent definition में harness और model को data के रूप में रखा जाता है। इसलिए किसी role को एक vendor से दूसरे vendor में ले जाने के लिए केवल YAML file में बदलाव करना पड़ता है, पूरा rewrite नहीं।
• Review अलग-अलग vendors के बीच हो सकता है। एक model द्वारा लिखे गए diff को किसी दूसरी company के model से पढ़वाया जाता है। एक ही family के दो models में अक्सर समान blind spots होते हैं। इसलिए उसी vendor से मिली second opinion का मूल्य कम होता है।
• Policy का एक ही स्थान होता है। Spend caps और approval prompts agent file में declare किए जाते हैं। वे उसके अंतर्गत आने वाले प्रत्येक sub-agent पर लागू होते हैं।
• Session किसी एक tool तक सीमित नहीं रहता। एक transcript में कई CLIs से किया गया काम शामिल रहता है। इसलिए चार अलग-अलग scrollbacks को जोड़ने के बजाय आप सीधे पढ़ सकते हैं कि क्या हुआ।

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

single agent tools के साथ multi-agent harness कहाँ उपयोगी है

यदि आपने अभी तक किसी server पर एक agent नहीं चलाया है, तो पहले वहीं से शुरू करें। हमारी VPS पर coding agent चलाने की guide single agent के मामले को शुरू से अंत तक कवर करती है। Omnigent मानता है कि यह setup आपके पास पहले से है। self-hosted AI agents का व्यापक क्षेत्र यह तय करने के लिए है कि कौन से agents चुनने हैं। यदि यहाँ की शब्दावली नई है, तो agents वास्तव में कैसे काम करते हैं, यह सीखना बेहतर शुरुआती स्थान है।

Omnigent connector layer से अलग प्रकार की समस्या हल करता है। agents को अपने data sources तक access देना जैसे काम यह निर्धारित करते हैं कि कोई agent किन resources तक पहुँच सकता है। Omnigent यह निर्धारित करता है कि कौन सा agent चलेगा, किस क्रम में चलेगा और किन सीमाओं के अंतर्गत चलेगा। आप दोनों एक साथ चाह सकते हैं, और इनकी भूमिकाएँ एक-दूसरे से overlap नहीं करतीं।

install करने से पहले आवश्यक चीज़ें

• Python 3.12 या नया version। प्रकाशित package में requires-python >= 3.12 घोषित है।
• tmux, क्योंकि terminal harness इसी के भीतर चलते हैं।
• कम से कम एक vendor CLI, जो पहले से installed और logged in हो।
• Node.js 22 केवल तब आवश्यक है, जब आप git checkout से build करते हैं। PyPI पर उपलब्ध wheel में built web assets शामिल होते हैं, इसलिए सामान्य install के लिए Node की बिल्कुल आवश्यकता नहीं है।

main के बजाय pinned release install करें

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

sh -s -- भाग केवल दिखावटी नहीं है। इसके बिना sh, --version को अपना option समझता है और installer को flag दिखाई नहीं देता। इसलिए आपको उस दिन उपलब्ध सबसे नया version मिलता है। जिस repository में हर कुछ सप्ताह में breaking changes जारी होते हैं, वहाँ यही reproducible box और अप्रत्याशित समस्या के बीच का अंतर है।

Installer uv, यानी Astral के Python package manager, का उपयोग करता है। यदि uv मौजूद नहीं है, तो installer पहले uv install करने का विकल्प देता है। यदि uv पहले से मौजूद है, तो script को skip करें:

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

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

uv binary को उस directory में रखता है जिसे uv tool dir --bin report करता है। यह आम तौर पर ~/.local/bin होती है। Installer इसे आपके shell profile में जोड़ने का विकल्प देता है। यदि clean install के तुरंत बाद command नहीं मिलती, तो यही कारण है। देखें कि वास्तव में क्या install हुआ:

omni upgrade --check

यह installed version की तुलना latest published version से करता है और बताता है कि upgrade उपलब्ध है या नहीं, लेकिन upgrade नहीं करता। omni और omnigent एक ही program के दो नाम हैं।

इसे model provider से जोड़ें

omni setup

Wizard आपके environment में पहले से मौजूद credentials खोजता है और जो credentials उपलब्ध नहीं हैं, उनके लिए prompt दिखाता है। यह API keys, vendor subscriptions, OpenRouter या Ollama जैसे gateways और Databricks workspaces को support करता है। यदि आप उसी machine पर Ollama के साथ local model server पहले से चला रहे हैं, तो किसी gateway को उसके endpoint पर point करें। इससे network traffic उस machine से बाहर नहीं जाता।

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

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

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

Polly repository के साथ उपलब्ध multi-agent coding orchestrator है। इसकी config में claude_code, codex, opencode, cursor, hermes और pi नाम के sub-agents घोषित हैं। इसमें एक महत्वपूर्ण rule है: review हमेशा implementer से अलग vendor द्वारा किया जाता है। Polly स्वयं code नहीं लिखता। यह योजना बनाता है, लक्ष्य को work items में विभाजित करता है, प्रत्येक item को delegate करता है और हर diff को किसी दूसरे vendor के reviewer तक भेजता है।

किसी भी काम को delegate करने से पहले Polly preflight check चलाता है, ताकि यह पता लगाया जा सके कि machine पर वास्तव में कौन-से sub-agent CLIs मौजूद हैं। केवल एक vendor CLI install होने पर diff सौंपने के लिए कोई दूसरा reviewer नहीं होगा। इसलिए output का मूल्यांकन करने से पहले कम-से-कम दो install करें। Debby, दूसरा shipped example, दो heads वाला debate agent है। इनमें एक Claude और दूसरा GPT है:

omni debby

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

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

Agent file YAML में होती है। executor harness, model और authentication के नाम निर्धारित करता है। tools में MCP (model context protocol) servers, Python functions और sub-agents होते हैं। Sub-agent एक ऐसा tool है जिसमें type: agent और अपना executor होता है। यही ऊपर बताई गई पूरी व्यवस्था का आधार है।

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 को project के अपने docs/AGENT_YAML_SPEC.md example से लिया गया है और ये Databricks-hosted names हैं। harness और model को अपने system पर configured omni setup के अनुसार बदलें। Spec में generic protocol पर काम करने वाली चीजों के लिए अन्य harness values antigravity, copilot, kimi, qwen और acp:<slug> भी शामिल हैं। Spec sub-agent पर pass_history: true को भी support करता है। इससे parent conversation sub-agent को मिल जाती है। हर delegation पर इसके लिए tokens खर्च होते हैं। इसलिए ऐसे sub-agents के लिए इसे बंद रखें जिन्हें केवल सामने दिया गया task पूरा करना है।

लंबे समय तक चलने वाले orchestration को VPS पर चलाना क्यों उचित है

Multi-agent run दो मिनट का command नहीं है। इसमें plan बनाना, काम सौंपना, parallel git worktrees पर प्रतीक्षा करना, review करना और revise करना शामिल है। Laptop का lid बंद करते ही यह सब रुक जाता है। VPS (virtual private server) चालू रहता है और अपना network connection बनाए रखता है, इसलिए आपके निगरानी न करने पर भी session चलता रहता है।

omnigent server --background
omnigent server status

Server port 6767 पर web user interface host करता है। omnigent server status बताता है कि कोई session चल रहा है या नहीं, और omnigent stop उसे बंद करता है। v0.7.0 से पहले के releases में यह omni server start था। इसे हटा दिया गया है, इसलिए पुराने write-ups और screenshots आपके terminal के output से मेल नहीं खाएँगे।

6767 को public address पर publish न करें। इसके लिए दो सुरक्षित तरीके हैं। Firewall पर port बंद रखें और ssh -N -L 6767:localhost:6767 you@your-server के साथ उसे SSH के माध्यम से forward करें। इसके बाद अपने machine पर http://localhost:6767 खोलें। दूसरा तरीका है कि इसके सामने TLS (transport layer security) termination रखें और authentication चालू करें:

OMNIGENT_AUTH_ENABLED=1 omnigent server --background

इसका firewall वाला भाग सामान्य configuration है। इसके बारे में VPS के लिए ufw firewall की मूल बातें में बताया गया है। यदि box पहले से कई Docker Compose apps के सामने Traefik के पीछे containers चला रहा है, तो Omnigent भी इसी pattern में एक और service है।

Container deploy के लिए repository की deploy/ directory में Compose setup है। ./bootstrap.sh secrets को .env में generate करता है। इसके बाद docker compose up -d Omnigent और Postgres को port 6767 पर start करता है। DATABASE_URL Postgres या SQLite चुनता है। OMNIGENT_AUTH_ENABLED containers के भीतर डिफ़ॉल्ट रूप से 1 पर सेट होता है। बाहर से reachable किसी भी service के लिए यही सही default है।

Sizing के संबंध में deploy notes server के working set को लगभग 512 MB से 1 GB बताते हैं, और Fly.io config 1 GB तय करता है। यह केवल supervisor के लिए है। प्रत्येक sub-agent एक अलग process होता है, जो अपना checkout और अपना model client रखता है। इसलिए server का आकार agents की संख्या और आवश्यकता के अनुसार तय करें। Server चालू होने के बाद omnigent login https://your-host और फिर omnigent host https://your-host चलाने से आपका laptop उसके साथ register हो जाता है। omnigent attach <session_id> किसी दूसरे device से चल रहे session को फिर से शुरू करता है।

दूर जाने से पहले प्रत्येक sub-agent को sandbox में चलाएँ

Omnigent, operating system स्तर का sandbox प्रदान करता है, जिसे Omnibox कहा जाता है। Linux पर यह bubblewrap namespaces और seccomp का उपयोग करता है, इसलिए सीमा agent के prompt के बजाय kernel लागू करता है। 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 को write_paths में सूचीबद्ध नहीं करते, तब तक वह read only रहती है। इसलिए गलत तरीके से चलने वाला agent workspace के बाहर write नहीं कर सकता। Dotfiles तब तक छिपी रहती हैं, जब तक उन्हें cwd_allow_hidden में नाम से शामिल न किया जाए। इसका अर्थ है कि broad read grant से .ssh या .aws अनजाने में exposed नहीं होते। egress_rules सेट करने पर सभी HTTP और HTTPS traffic default deny proxy से होकर जाता है। प्रत्येक rule को "METHODS host/path-glob" के रूप में लिखा जाता है। credential_proxy इससे भी आगे जाता है: agent के पास केवल placeholder रहता है और request बाहर जाते समय proxy वास्तविक secret डाल देता है। इसलिए transcript leak होने पर भी कोई usable secret leak नहीं होता। Multi-harness setup में प्रत्येक sub-agent अपनी configuration file में, agents/ के अंतर्गत, अपना sandbox block रखता है। इसलिए reviewer के लिए network access deny किया जा सकता है, जबकि implementer के लिए वह enabled रहता है।

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

Spend limits policies होती हैं और उसी 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 के साथ planning, दूसरे के साथ implementation और तीसरे के साथ review करता है, तो वह एक साथ तीन स्थानों पर खर्च करता है। इसलिए पहले unattended run से पहले cap सेट करें, पहली invoice आने के बाद नहीं। Built-ins में max_tool_calls_per_session और ask_on_os_tools भी शामिल हैं। ये file और shell operations से पहले approval माँगते हैं। VPS पर AI agent की लागत नियंत्रित रखना संबंधी हमारे notes यहाँ सीधे लागू होते हैं। Parallel sub-agents burn rate को कई गुना बढ़ाते हैं, इसलिए यहाँ उनका महत्व और अधिक है।

यह repository कितनी तेज़ी से आगे बढ़ रहा है?

[
  {
    "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
  }
]

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

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

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

August 2026 तक repository पर लगभग 8.1k stars, 1.2k forks और करीब 350 खुले issues हैं। इसका पहला public release सात सप्ताह पुराना है। Stars रुचि दर्शाते हैं, और रुचि maturity का प्रमाण नहीं है। Project स्वयं इसे alpha कहता है, और ऊपर दिया गया release history भी यही दिखाता है।

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

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

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

FAQ

Omnigent agent है या agents चलाने वाली कोई चीज़?

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

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

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

नवीनतम version के बजाय Omnigent का कोई specific version कैसे install करें?

Install script में sh -s -- के साथ --version pass करें, जैसा कि sh -s -- --version 0.7.0 में है। -s -- के बिना flag स्वयं sh द्वारा consume हो जाता है और script नवीनतम release install करती है। यदि 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 रूप से चलाने के लिए पर्याप्त है?

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

VPS पर Omnigent server को कितनी memory चाहिए?

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