Omnigent: کئی agent CLIs کے لیے ایک meta-harness

Omnigent کیا ہے

Omnigent ایک open source meta-harness ہے: یہ ایک orchestration layer ہے جو آپ کے سسٹم پر پہلے سے نصب agent command line tools (CLIs) چلاتی ہے۔ یہ Claude Code، Codex، Cursor، OpenCode، Hermes یا Pi کی جگہ نہیں لیتی۔ یہ انہیں start کرتی ہے، ہر ایک کو کام دیتی ہے، اور ایک ہی session کے اندر ایک policy set کے تحت نتائج کی نگرانی کرتی ہے۔ Databricks نے repository کو June 2026 میں Apache 2.0 licence کے تحت شائع کیا، اور front page پر اب بھی Status: alpha درج ہے۔

اس کا عملی دعویٰ محدود ہے، اور اسے واضح طور پر بیان کرنا مفید ہے۔ آپ ایک agent کو YAML میں صرف ایک بار بیان کرتے ہیں اور وہ harness متعین کرتے ہیں جو اسے چلاتا ہے۔ اس ایک line کو تبدیل کرنے سے وہی agent کسی دوسرے vendor کے CLI پر چلتا ہے۔ آپ کے setup میں کوئی اور تبدیلی نہیں ہوتی، کیونکہ Omnigent agents کے اندر موجود loop کے بجائے ان کے اوپر موجود loop کو control کرتی ہے۔

میٹا-hارنس کیا ہے، اور یہ framework سے کیسے مختلف ہے؟

harness وہ پروگرام ہے جو model کو ایک loop میں چلاتا ہے۔ یہ آپ کا prompt پڑھتا ہے، tools کو call کرتا ہے، files میں ترمیم کرتا ہے اور نتیجہ واپس دیتا ہے۔ Claude Code ایک harness ہے۔ Codex ایک harness ہے۔ آپ اسے install کرتے ہیں، login کرتے ہیں، اور یہ خود کام کرتا ہے۔

framework ایسی library ہے جس کے خلاف آپ code لکھتے ہیں۔ آپ اسے import کرتے ہیں، Python میں steps متعین کرتے ہیں، اور آپ کا program agent بن جاتا ہے۔ اس صورت میں vendor تبدیل کرنے کے لیے code میں ترمیم کرنا پڑتی ہے، کیونکہ vendor کا client آپ کے program کے ذریعے مربوط ہوتا ہے۔

meta-harness دونوں سے ایک سطح اوپر ہوتا ہے۔ یہ ایک supervisor ہے جو harnesses کو child processes کے طور پر چلاتا ہے۔ Omnigent vendor CLI شروع کرتا ہے، اسے کام دیتا ہے، اور واپس آنے والا output پڑھتا ہے۔ آپ وہی CLI رکھتے ہیں جسے پہلے سے install کیا ہوا ہے، اور وہی subscription یا API (application programming interface) key استعمال کرتے ہیں جس سے اس کی ادائیگی پہلے ہی ہو رہی ہے۔ یہی مکمل فرق ہے، اور اسی سے طے ہوتا ہے کہ یہ tool کن لوگوں کے لیے ہے: وہ لوگ جن کے پاس کئی agent CLIs پہلے سے کام کر رہی ہیں اور جو انہیں ایک وقت میں ایک terminal کے ذریعے چلانے سے تنگ آ چکے ہیں۔

ایک orchestration layer کون سا مسئلہ حل کرتی ہے؟

• Vendor تبدیل کرنے کی لاگت ایک سطر تک محدود رہتی ہے۔ Agent definition میں harness اور model بطور data موجود ہوتے ہیں، اس لیے ایک role کو ایک vendor سے دوسرے vendor میں منتقل کرنے کے لیے YAML file میں ترمیم کافی ہوتی ہے، مکمل rewrite کی ضرورت نہیں پڑتی۔
• Review مختلف vendors کے درمیان ہو سکتا ہے۔ ایک model کا تیار کردہ diff کسی دوسری کمپنی کے model سے پڑھوایا جاتا ہے۔ ایک ہی family کے دو models عموماً ایک جیسی کمزوریاں رکھتے ہیں، اس لیے اسی vendor سے دوسری رائے کی قدر کم ہوتی ہے۔
• Policy ایک ہی جگہ موجود ہوتی ہے۔ Spend caps اور approval prompts agent file میں declare کیے جاتے ہیں، اور اس کے تحت چلنے والے ہر sub-agent پر لاگو ہوتے ہیں۔
• Session کسی ایک tool تک محدود نہیں رہتا۔ ایک transcript میں متعدد CLIs کے ذریعے کیا گیا کام شامل ہوتا ہے، اس لیے چار الگ scrollbacks کو جوڑنے کے بجائے آپ پوری کارروائی دوبارہ پڑھ سکتے ہیں۔

اس کی لاگت خود یہ layer ہے۔ Omnigent میں موجود ہر bug اب آپ اور اس agent کے درمیان موجود bug بن جاتا ہے، جو پہلے اکیلا کام کر رہا تھا۔ Alpha مرحلے میں یہ حقیقی لاگت ہے، محض نظری مسئلہ نہیں۔

ملٹی ایجنٹ harness، single agent tools کے ساتھ کہاں موزوں ہے

اگر آپ نے ابھی تک کسی server پر ایک agent نہیں چلایا تو پہلے وہی کریں۔ ہماری VPS پر coding agent چلانے کی guide single agent کا مکمل طریقہ بیان کرتی ہے، اور Omnigent یہ فرض کرتا ہے کہ آپ کے پاس یہ setup پہلے سے موجود ہے۔ self-hosted AI agents کا وسیع میدان خود agents منتخب کرنے سے متعلق ہے، جبکہ اگر یہاں کی اصطلاحات نئی ہیں تو agents حقیقت میں کیسے کام کرتے ہیں یہ سیکھنا بہتر ابتدائی مرحلہ ہے۔

Omnigent، connector layer سے بھی مختلف دائرے میں کام کرتا ہے۔ agents کو اپنے data sources تک رسائی دینا جیسے کام اس بات سے متعلق ہیں کہ agent کن وسائل تک پہنچ سکتا ہے۔ Omnigent اس بات سے متعلق ہے کہ کون سا agent چلے گا، کس ترتیب سے چلے گا، اور کن حدود کے تحت چلے گا۔ آپ بیک وقت دونوں چاہتے ہیں، اور یہ ایک دوسرے کا متبادل نہیں ہیں۔

تنصیب سے پہلے درکار چیزیں

• Python 3.12 یا اس کے بعد کا ورژن۔ شائع کردہ package میں requires-python >= 3.12 درج ہے۔
• tmux، کیونکہ terminal harnesses اسی کے اندر چلتے ہیں۔
• کم از کم ایک vendor CLI، جو پہلے سے installed ہو اور جس میں پہلے ہی login کیا گیا ہو۔
• Node.js 22 صرف اس صورت میں درکار ہے جب آپ git checkout سے build کریں۔ PyPI پر موجود wheel میں built web assets شامل ہوتے ہیں، اس لیے معمول کی تنصیب کے لیے Node کی بالکل ضرورت نہیں ہوتی۔

مستحکم کردہ release انسٹال کریں، main نہیں

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 نظر نہیں آتا، اس لیے آپ کو اس دن دستیاب تازہ ترین ورژن ملتا ہے۔ ایسے repository میں جو ہر چند ہفتوں بعد breaking changes جاری کرتا ہو، یہی reproducible box اور غیر متوقع نتیجے کے درمیان فرق ہے۔

installer، Astral کے Python package manager، uv کا استعمال کرتا ہے اور اگر uv موجود نہ ہو تو پہلے اسے انسٹال کرنے کی پیشکش کرتا ہے۔ اگر uv پہلے سے موجود ہے تو script کو چھوڑ دیں:

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 دیتا ہے، عموماً ~/.local/bin میں، اور installer اسے آپ کے shell profile میں شامل کرنے کی پیشکش کرتا ہے۔ اگر صاف installation کے فوراً بعد command نہ ملے تو وجہ یہی ہے۔ معلوم کریں کہ آخر میں کون سا ورژن انسٹال ہوا:

omni upgrade --check

یہ installed version کا موازنہ تازہ ترین published version سے کرتا ہے اور بتاتا ہے کہ upgrade دستیاب ہے یا نہیں، مگر upgrade خود نہیں کرتا۔ omni اور omnigent ایک ہی program کے دو نام ہیں۔

ماڈل فراہم کنندہ کی طرف کنفیگر کریں

omni setup

Wizard آپ کے environment میں پہلے سے موجود credentials تلاش کرتا ہے اور جو credentials موجود نہ ہوں ان کے لیے آپ سے معلومات طلب کرتا ہے۔ یہ API keys، vendor subscriptions، OpenRouter یا Ollama جیسے gateways، اور Databricks workspaces کو handle کرتا ہے۔ اگر آپ اسی machine پر پہلے سے Ollama کے ساتھ local model server چلا رہے ہیں تو gateway کو اس server کی طرف configure کریں، اس طرح network traffic کبھی machine سے باہر نہیں جاتا۔

ایک کم سے کم multi-agent run

مثال کے agents repository میں موجود ہیں، اس لیے اپنے نصب کردہ tag کو clone کریں، نہ کہ main کو۔

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 کو کسی agent کے حوالے کرتا ہے، اور ہر diff کو دوسرے vendor کے reviewer تک پہنچاتا ہے۔

کسی بھی کام کو delegate کرنے سے پہلے Polly preflight check چلاتا ہے تاکہ معلوم ہو سکے کہ machine پر کون سے sub-agent CLIs واقعی موجود ہیں۔ اگر صرف ایک vendor کا CLI نصب ہو تو diff وصول کرنے والا کوئی دوسرا agent موجود نہیں ہوگا، اس لیے output کا جائزہ لینے سے پہلے کم از کم دو CLIs نصب کریں۔ Debby، فراہم کی جانے والی دوسری مثال، دو heads والا debate agent ہے؛ ایک Claude اور دوسرا GPT:

omni debby

یہ اس بات کی مختصر تصدیق کا طریقہ ہے کہ دو providers configured ہیں، کیونکہ کسی بھی output کے لیے دونوں کی ضرورت ہوتی ہے۔

سب ایجنٹس بطور tools بیان کیے جاتے ہیں

ایجنٹ فائل YAML میں ہوتی ہے۔ executor harness، model اور authentication کے نام بیان کرتا ہے۔ tools میں MCP (model context protocol) servers، Python functions اور sub-agents شامل ہوتے ہیں۔ سب ایجنٹ type: agent کے ساتھ ایک tool ہوتا ہے اور اس کا اپنا executor ہوتا ہے؛ یہی mechanism اوپر بیان کردہ تمام چیزوں کے پیچھے کام کرتا ہے۔

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 کو ان values سے بدلیں جنہیں آپ کے box پر omni setup configure کرتا ہے۔ spec میں شامل دیگر harness values میں عمومی protocol استعمال کرنے والی ہر چیز کے لیے antigravity، copilot، kimi، qwen اور acp:<slug> شامل ہیں۔ spec سب ایجنٹ پر pass_history: true کو بھی support کرتا ہے، جو اسے parent conversation فراہم کرتا ہے۔ ہر delegation پر اس کے لیے tokens خرچ ہوتے ہیں، اس لیے ایسے sub-agents کے لیے اسے بند رکھیں جنہیں صرف موجودہ task درکار ہو۔ جس coder کا prompt اسے کام کرنے والی کم سے کم تبدیلی کرنے کی ہدایت دیتا ہے، وہ اپنے reviewer کو اتنا مختصر diff فراہم کرتا ہے جسے واقعی پڑھا جا سکے؛ یہاں دونوں roles کے لیے منتخب کیے گئے model سے زیادہ یہ بات اہم ہے۔

طویل دورانیے والی orchestration کے لیے VPS کیوں موزوں ہے

Multi-agent run دو منٹ کا command نہیں ہوتا۔ منصوبہ بنائیں، کام تقسیم کریں، parallel git worktrees کے مکمل ہونے کا انتظار کریں، جائزہ لیں، اور ترمیم کریں۔ Laptop کا ڈھکن بند کرنے سے یہ تمام عمل رک جاتا ہے۔ VPS (virtual private server) چلتا رہتا ہے اور اپنا network برقرار رکھتا ہے، اس لیے جب آپ نگرانی نہیں کر رہے ہوں تو بھی session جاری رہتا ہے۔

omnigent server --background
omnigent server status

Server، port 6767 پر web user interface فراہم کرتا ہے۔ omnigent server status بتاتا ہے کہ کوئی session چل رہا ہے یا نہیں، اور omnigent stop اسے بند کر دیتا ہے۔ v0.7.0 سے پہلے کی releases میں یہ omni server start تھا، جسے ہٹا دیا گیا ہے۔ اس لیے پرانی تحریروں اور screenshots میں دکھائی دینے والا طریقہ آپ کے terminal کے موجودہ رویے سے مطابقت نہیں رکھے گا۔

6767 کو public address پر شائع نہ کریں۔ دو محفوظ طریقے ہیں۔ Port کو firewall پر بند رکھیں اور ssh -N -L 6767:localhost:6767 you@your-server کے ذریعے اسے SSH پر forward کریں، پھر اپنی machine پر http://localhost:6767 سے web interface کھولیں۔ یا اس کے سامنے TLS (transport layer security) terminate کریں اور authentication فعال کریں:

OMNIGENT_AUTH_ENABLED=1 omnigent server --background

اس کے firewall والے حصے کا طریقہ عام انتظامی کام ہے۔ اس کی وضاحت VPS کے لیے ufw firewall کی بنیادی باتیں میں ہے۔ اگر machine پر پہلے ہی متعدد Docker Compose ایپس کے سامنے Traefik کے ذریعے containers چل رہے ہوں، تو Omnigent اسی pattern میں ایک اور service ہے۔

Container deploy کے لیے repository کی deploy/ directory میں Compose setup موجود ہے۔ ./bootstrap.sh secrets کو .env میں بناتا ہے، پھر docker compose up -d Omnigent اور Postgres کو port 6767 پر start کرتا ہے۔ DATABASE_URL Postgres یا SQLite منتخب کرتا ہے، جبکہ containers کے اندر OMNIGENT_AUTH_ENABLED کی default value 1 ہے۔ باہر سے قابل رسائی کسی بھی service کے لیے یہی درست default ہے۔

Sizing کے بارے میں deploy notes server کے working set کو تقریباً 512 MB سے 1 GB بتاتے ہیں، اور Fly.io config 1 GB مقرر کرتی ہے۔ یہ مقدار صرف supervisor کے لیے ہے۔ ہر sub-agent ایک الگ process ہوتا ہے، جو اپنا checkout اور اپنا model client رکھتا ہے۔ اس لیے machine کا size agents کی تعداد اور ضرورت کے مطابق مقرر کریں۔ Server چلنے کے بعد omnigent login https://your-host کے بعد omnigent host https://your-host آپ کے laptop کو اس سے register کرتا ہے، اور omnigent attach <session_id> کسی دوسرے device سے running session دوبارہ جاری کرتا ہے۔

روانہ ہونے سے پہلے ہر ذیلی ایجنٹ کو sandbox میں محدود کریں

Omnigent ایک operating system level sandbox فراہم کرتا ہے جسے Omnibox کہتے ہیں۔ Linux پر یہ bubblewrap namespaces اور seccomp استعمال کرتا ہے، اس لیے حد بندی agent کے prompt کے بجائے kernel نافذ کرتا ہے۔ Prompt injection کا شکار agent kernel rule سے بچنے کے لیے باتوں سے راستہ نہیں بنا سکتا۔ پہلے dependency انسٹال کریں:

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 ظاہر نہیں کرتا۔ egress_rules مقرر کرنے سے تمام HTTP اور HTTPS traffic default deny proxy سے گزرتا ہے، اور ہر rule "METHODS host/path-glob" کی صورت میں لکھی جاتی ہے۔ credential_proxy اس سے بھی آگے جاتا ہے: agent کے پاس صرف ایک placeholder رہتا ہے، اور request باہر جاتے وقت proxy اس میں اصل secret شامل کر دیتا ہے۔ اس طرح leaked transcript میں استعمال کے قابل کوئی secret ظاہر نہیں ہوتا۔ 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 کے ساتھ sandbox سے باہر چلتا ہے۔ اسی خلا کی وجہ سے اب بھی زیادہ مضبوط طریقہ یہ ہے کہ ہر agent کے لیے ایک عارضی machine استعمال کی جائے۔ اس موضوع پر disposable VM میں coding agents چلانا دیکھیں۔ کام کا دوسرا حصہ credentials ہیں، اور agent کی رسائی سے secrets دور رکھنا اس وقت آسان نہیں بلکہ زیادہ مشکل ہو جاتا ہے جب چھ sub-agents ایک ہی host کا اشتراک کریں۔

Spend limits policies ہوتی ہیں، جو اسی file میں declare کی جاتی ہیں:

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 کے اخراجات قابو میں رکھنا سے متعلق ہماری ہدایات یہاں براہ راست لاگو ہوتی ہیں، بلکہ زیادہ سختی سے، کیونکہ parallel sub-agents خرچ کی رفتار کئی گنا بڑھا دیتے ہیں۔

یہ 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 کو پڑھا گیا تھا۔ 7 tagged releases، 2026-06-19 اور 2026-07-27 کے درمیان جاری ہوئیں، اور کسی بھی دو 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 کی کسی تحریر سے copy کی گئی install line July build پر ناکام ہو جاتی ہے۔ یہی وجہ ہے کہ اپنی install command میں --version اور اپنے git clone میں کوئی tag استعمال کریں؛ یہ صرف style preference نہیں ہے۔

جس کام کے لیے میں ابھی اس پر اعتماد نہیں کروں گا

August 2026 تک repository کو تقریباً 8.1k stars، 1.2k forks اور تقریباً 350 open issues حاصل ہیں، جبکہ اس کی پہلی public release کو سات ہفتے ہوئے ہیں۔ Stars دلچسپی کو ظاہر کرتے ہیں، اور دلچسپی maturity کے برابر نہیں ہوتی۔ Project خود اسے alpha کہتا ہے، اور اوپر دی گئی release history سے بھی واضح ہے کہ اس سے مراد واقعی alpha ہے۔

• میں اسے ایسے host پر نہیں چلاؤں گا جس میں production credentials موجود ہوں، کیونکہ sandbox، MCP servers یا supervisor کا احاطہ نہیں کرتا۔
• میں cost_budget policy کے بغیر کوئی run unattended نہیں چھوڑوں گا، کیونکہ تین vendors بیک وقت bill کر سکتے ہیں اور انہیں روکنے والی کوئی دوسری پابندی موجود نہیں۔
• میں OMNIGENT_AUTH_ENABLED set کیے بغیر اور اس کے آگے 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 مگر unfinished سمجھیں۔

FAQ

کیا Omnigent ایک agent ہے، یا agents چلانے والی چیز ہے؟

یہ agents چلاتا ہے۔ Omnigent ایک meta-harness ہے: یہ آپ کے پہلے سے نصب vendor CLIs، مثلاً Claude Code، Codex یا OpenCode، شروع کرتا ہے، ہر ایک کو کام دیتا ہے، اور ایک ہی session میں نتائج کی نگرانی کرتا ہے۔ یہ اپنا کوئی model فراہم نہیں کرتا۔ اسی لیے یہ framework سے مختلف ہے، جہاں آپ library کے خلاف Python لکھتے ہیں اور آپ کا اپنا program agent بن جاتا ہے۔

کیا Omnigent کے مفید ہونے سے پہلے Claude Code اور Codex نصب ہونا ضروری ہیں؟

آپ کے پاس کم از کم ایک vendor CLI نصب اور logged in ہونا چاہیے، کیونکہ Omnigent ان programs کو چلاتا ہے، ان کی جگہ نہیں لیتا۔ فراہم کردہ Polly example کے لیے مختلف vendors کے دو یا اس سے زیادہ CLIs درکار ہیں۔ Polly کا اصول ہے کہ review ہمیشہ implementer سے مختلف vendor کرتا ہے۔ اس لیے صرف ایک CLI موجود ہو تو diff بھیجنے کے لیے دوسرا vendor نہیں ہوتا۔

تازہ ترین کے بجائے Omnigent کا مخصوص version کیسے نصب کروں؟

Install script کے ذریعے --version کو sh -s -- کے ساتھ pass کریں، جیسا کہ sh -s -- --version 0.7.0 میں دکھایا گیا ہے۔ -s -- کے بغیر یہ flag خود sh استعمال کر لیتا ہے، اور 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 طور پر چلانے کے لیے کافی ہے؟

یہ ان حدود کے اندر مضبوط ہے جنہیں یہ نافذ کرتا ہے، اور ان چیزوں کے بارے میں واضح ہے جنہیں یہ cover نہیں کرتا۔ Linux پر یہ bubblewrap اور seccomp استعمال کرتا ہے، اس لیے kernel file اور network limits نافذ کرتا ہے اور 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 کا working set تقریباً 512 MB سے 1 GB ہے، اور اس کی Fly.io configuration 1 GB مقرر کرتی ہے۔ اس میں صرف supervisor اور port 6767 پر چلنے والا web interface شامل ہے۔ ہر sub-agent الگ process ہوتا ہے، جس کے پاس اپنی working copy اور model client ہوتا ہے۔ Polly طرز کے runs متوازی git worktrees بھی استعمال کرتے ہیں۔ اس لیے RAM اور disk کا حجم server کے بجائے ان agents کی تعداد کے مطابق مقرر کریں جنہیں آپ بیک وقت چلانے کا ارادہ رکھتے ہیں۔