מה זה Omnigent ואיך לנהל סוכני AI מרובים ב-CLI אחד

מהו Omnigent

Omnigent הוא meta-harness בקוד פתוח: שכבת תזמור אחת המפעילה את כלי שורת הפקודה (CLIs) של סוכנים שכבר מותקנים אצלכם. הוא אינו מחליף את Claude Code, Codex, Cursor, OpenCode, Hermes או Pi. הוא מפעיל אותם, מקצה לכל אחד מהם משימה, ומפקח על התוצאה בתוך סשן יחיד עם סט מדיניות אחיד. Databricks פרסמה את המאגר ביוני 2026 תחת רישיון Apache 2.0, ודף הבית עדיין מציג את Status: alpha.

הטענה המעשית היא מצומצמת, וכדאי להציג אותה בבירור. אתם מגדירים סוכן פעם אחת, בפורמט YAML, ומציינים את ה-harness שמריץ אותו. שנו שורה אחת בלבד, ואותו סוכן ירוץ על ה-CLI של ספק אחר. שום דבר אחר בהגדרות שלכם לא משתנה, כיוון ש-Omnigent שולט בלולאה שמעל הסוכנים ולא בלולאה שבתוכם.

מהו meta-harness, וכיצד הוא שונה מ-framework?

harness הוא התוכנית שעוטפת מודל בתוך לולאה. הוא קורא את ה-prompt שלכם, מפעיל כלים, עורך קבצים ומדווח על התוצאות. Claude Code הוא harness. Codex הוא harness. אתם מתקינים אותו, מתחברים, והוא עובד באופן עצמאי.

framework הוא ספרייה שאתם כותבים קוד מולה. אתם מייבאים אותה, מגדירים את השלבים ב-Python, והתוכנית שלכם הופכת לסוכן (agent). החלפת ספק (vendor) במקרה כזה דורשת עריכה של הקוד שלכם, כיוון שה-client של הספק משולב בתוך התוכנית שלכם.

meta-harness נמצא רמה אחת מעל שניהם. זהו מפקח שמריץ harnesses כתהליכי בת (child processes). Omnigent מפעיל את ה-CLI של הספק, מעביר לו עבודה, וקורא את מה שחוזר. אתם שומרים על ה-CLI שכבר התקנתם, ואתם שומרים על כל מנוי או מפתח API (application programming interface) שמשלם עליו. זה כל ההבדל, וזה מה שקובע עבור מי הכלי מיועד: אנשים שכבר עובדים עם כמה סוכני CLI, שנמאס להם להפעיל אותם טרמינל אחד בכל פעם.

איזו בעיה פותרת שכבת תזמור (orchestration)?

• עלות החלפת ספק בשורה אחת. הגדרת ה-agent מכילה את harness ו-model כנתונים, לכן העברת תפקיד מספק אחד לאחר היא עריכה של קובץ ה-YAML, ולא שכתוב מחדש.
• ביקורת יכולה לחצות ספקים. מודל אחד קורא diff שנכתב על ידי מודל של חברה אחרת. שני מודלים מאותה משפחה נוטים לחלוק את אותן נקודות תורפה, לכן דעה שנייה מאותו ספק שווה פחות.
• למדיניות יש בית אחד. תקרות הוצאה והנחיות לאישור מוצהרות בקובץ ה-agent, והן חלות על כל תת-agent שתחתיו.
• הסשן מאריך ימים יותר מכל כלי בודד. תמלול אחד מכסה עבודה שבוצעה על ידי כמה ממשקי CLI, כך שניתן לקרוא מה קרה מבלי לאחד ארבעה היסטוריות גלילה שונות.

העלות היא השכבה עצמה. כל באג ב-Omnigent הוא כעת באג שנמצא בינך לבין agent שעבד בעבר באופן עצמאי. בשלב ה-alpha זו עלות ממשית, לא תיאורטית.

היכן משתלב מנגנון רב-סוכנים (multi-agent) לצד כלים של סוכן בודד

אם טרם הרצתם סוכן אחד על שרת, התחילו מכך. המדריך שלנו בנושא הרצת סוכן תכנות על גבי VPS מכסה את המקרה של סוכן בודד מקצה לקצה, וזוהי סביבת העבודה ש-Omnigent מניחה שכבר קיימת אצלכם. התחום הרחב יותר של סוכני בינה מלאכותית באירוח עצמי הוא המקום שבו בוחרים את הסוכנים עצמם, וקריאת הבנת אופן הפעולה של סוכנים היא נקודת התחלה עדיפה אם המינוחים כאן חדשים לכם.

Omnigent פועלת במישור שונה משכבת קישור (connector layer). עבודה כגון מתן גישה לסוכנים למקורות המידע שלכם עוסקת במה שסוכן מסוגל להגיע אליו. Omnigent עוסקת בשאלה איזה סוכן ירוץ, באיזה סדר, ותחת אילו מגבלות. ניתן להזדקק לשניהם בו-זמנית, והם אינם חופפים.

דרישות קדם להתקנה

• Python 3.12 או גרסה חדשה יותר. החבילה המפורסמת מצהירה על requires-python >= 3.12.
• tmux, כיוון שהרצת הטרמינל מתבצעת בתוכו.
• לפחות כלי CLI אחד של ספק, מותקן ומוגדר עם פרטי התחברות.
• Node.js 22 נדרש רק אם אתם מבצעים build מתוך git checkout. ה-wheel ב-PyPI כולל את נכסי ה-web המוכנים, לכן התקנה רגילה אינה דורשת Node כלל.

התקנת גרסה מקובעת (pinned 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 כאופציה משל עצמו, והמתקין לעולם לא רואה את הדגל (flag); כתוצאה מכך, תקבלו את הגרסה העדכנית ביותר לאותו יום. במאגר שמשחרר שינויים שוברים (breaking changes) מדי כמה שבועות, זהו ההבדל בין שרת שניתן לשחזור לבין הפתעות לא רצויות.

המתקין משתמש ב-uv, מנהל החבילות של Python מבית Astral, ומציע להתקין את uv תחילה אם הוא חסר. אם uv כבר מותקן, דלגו על הסקריפט:

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

תוספים (extras) פועלים לפי אותו דפוס, והדגל חוזר על עצמו: --extra e2b --extra kubernetes בסקריפט, או "omnigent[e2b,kubernetes]" ב-uv. שימו לב שתג ה-git הוא v0.7.0, בעוד גרסת החבילה ב-PyPI היא 0.7.0.

uv מציב את הקובץ הבינארי בספרייה ש-uv tool dir --bin מדווח עליה, בדרך כלל ~/.local/bin, והמתקין מציע להוסיף אותה לפרופיל ה-shell שלכם. אם הפקודה לא נמצאת מיד לאחר התקנה נקייה, זו הסיבה. בדקו מה קיבלתם בסוף התהליך:

omni upgrade --check

פקודה זו משווה את הגרסה המותקנת מול הגרסה העדכנית ביותר שפורסמה ומציינת אם קיים שדרוג, מבלי לבצע אותו בפועל. omni ו-omnigent הם אותה תוכנה תחת שני שמות שונים.

הגדרת ספק מודלים

omni setup

אשף ההגדרה מחפש אישורי גישה הקיימים כבר בסביבת העבודה שלך ומבקש את אלו שחסרים. הוא מטפל במפתחות API, מנויים לספקים, שערים (gateways) כגון OpenRouter או Ollama, וסביבות עבודה של Databricks. אם אתה כבר מריץ שרת מודלים מקומי עם Ollama על אותה מכונה, כוון את השער אליו והתעבורה לא תצא לעולם מחוץ לשרת.

הרצה מינימלית של סוכנים מרובים

סוכני הדוגמה נמצאים במאגר, לכן בצעו clone ל־tag שבו השתמשתם בהתקנה במקום ל־main.

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

Polly הוא מתזמר הקידוד לסוכנים מרובים שמגיע עם המאגר. התצורה שלו מגדירה סוכני משנה בשם claude_code, codex, opencode, cursor, hermes ו־pi, וכלל אחד שהופך את כל התרגיל לכדאי: סקירה מתבצעת תמיד על ידי ספק שונה מזה שביצע את המימוש. Polly עצמו אינו כותב קוד. הוא מתכנן, מחלק את היעד למשימות עבודה, מאציל כל אחת מהן, ומנתב כל diff לסוקר מספק אחר.

לפני האצלת משימות, Polly מריץ בדיקת תקינות מקדימה כדי לראות אילו ממשקי CLI של סוכני משנה קיימים בפועל על המכונה. כאשר מותקן רק CLI של ספק אחד, אין למי להעביר את ה־diff, לכן התקינו לפחות שניים לפני שאתם שופטים את הפלט. Debby, דוגמה נוספת שמגיעה עם המערכת, היא סוכן דיבייט בעל שני ראשים, אחד Claude ואחד GPT:

omni debby

זו דרך קצרה לוודא ששני ספקים מוגדרים, כיוון שהוא זקוק לשניהם כדי להפיק פלט כלשהו.

סוכני משנה מוגדרים ככלים

קובץ הסוכן הוא בפורמט YAML. המשתנה executor מגדיר את ה-harness, את המודל ואת האימות. המשתנה tools מכיל שרתי MCP (פרוטוקול הקשר מודל), פונקציות Python וסוכני משנה. סוכן משנה הוא כלי בעל 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

מזהי המודלים הללו מגיעים מהדוגמה docs/AGENT_YAML_SPEC.md של הפרויקט עצמו, והם שמות המאוחסנים ב-Databricks. החליפו את harness ואת model בכל מה שהגדרתם ב-omni setup על המכונה שלכם. ערכי harness אחרים במפרט כוללים את antigravity, copilot, kimi, qwen ו-acp:<slug> עבור כל מה שתומך בפרוטוקול הגנרי. המפרט תומך גם ב-pass_history: true עבור סוכן משנה, מה שמעביר לו את שיחת האב. פעולה זו צורכת אסימונים (tokens) בכל האצלת סמכויות, לכן כדאי לוותר עליה עבור סוכני משנה שזקוקים רק למשימה שלפניהם. מתכנת שה-prompt שלו מורה לו לבצע את השינוי הקטן ביותר שעובד מגיש למבקר שלו diff קצר מספיק לקריאה, וזה חשוב כאן יותר מהמודל שתבחרו לכל אחד מהתפקידים.

מדוע תזמור ארוך-טווח שייך ל-VPS

הרצה של סוכנים מרובים אינה פקודה של שתי דקות. היא דורשת תכנון, האצלת סמכויות, המתנה לעבודת git מקבילית, סקירה ותיקון. סגירת המכסה של המחשב הנייד תסיים את כל התהליך. שרת VPS (שרת וירטואלי פרטי) נשאר פעיל ושומר על הרשת שלו, כך שהסשן שורד גם כשאינך צופה בו.

omnigent server --background
omnigent server status

השרת מארח ממשק משתמש מבוסס אינטרנט בפורט 6767. omnigent server status מדווח אם אחד כזה פועל, ו-omnigent stop מכבה אותו. בגרסאות שלפני v0.7.0 זה היה omni server start, פקודה שהוסרה, ולכן מדריכים וצילומי מסך ישנים לא יתאימו למה שקורה בטרמינל שלך.

אל תפרסם את 6767 בכתובת ציבורית. שתי תצורות הן בטוחות. השאר את הפורט סגור ב-firewall והעבר אותו דרך SSH עם ssh -N -L 6767:localhost:6767 you@your-server, לאחר מכן פתח את ממשק האינטרנט ב-http://localhost:6767 במחשב האישי שלך. לחלופין, בצע TLS termination (אבטחת שכבת תעבורה) לפניו והפעל אימות:

OMNIGENT_AUTH_ENABLED=1 omnigent server --background

חלק ה-firewall בתהליך זה הוא עבודה שגרתית, המכוסה ב-יסודות ה-firewall מסוג ufw עבור VPS, ואם השרת כבר מריץ מכולות מאחורי Traefik לפני כמה יישומי Docker Compose, אזי Omnigent הוא שירות נוסף באותה תבנית.

עבור פריסת מכולה, תיקיית ה-deploy/ במאגר מכילה הגדרת Compose: ./bootstrap.sh יוצרת סודות לתוך .env, לאחר מכן docker compose up -d מפעיל את Omnigent ו-Postgres בפורט 6767. DATABASE_URL בוחר בין Postgres ל-SQLite, ו-OMNIGENT_AUTH_ENABLED מוגדר כברירת מחדל ל-1 בתוך המכולות, שזו ברירת המחדל הנכונה לכל מה שנגיש מבחוץ.

לגבי גודל השרת, הערות הפריסה מציינות שצריכת הזיכרון של השרת היא בערך 512 MB עד 1 GB, והגדרת ה-Fly.io מקצה 1 GB. נתון זה מתייחס למפקח (supervisor) בלבד. כל סוכן משנה הוא תהליך נפרד המחזיק עותק עבודה משלו ולקוח מודל משלו, לכן יש להתאים את גודל השרת למספר הסוכנים. ברגע שהשרת פעיל, omnigent login https://your-host ולאחריו omnigent host https://your-host רושמים את המחשב הנייד שלך מולו, ו-omnigent attach <session_id> מאפשר להמשיך סשן פעיל ממכשיר אחר.

בצעו Sandbox לכל סוכן משנה לפני שתעזבו

Omnigent מספקת ארגז חול (sandbox) ברמת מערכת ההפעלה בשם Omnibox. בלינוקס הוא משתמש ב-namespaces של bubblewrap וב-seccomp, כך שהליבה (kernel) היא זו שאוכפת את הגבולות ולא ההנחיה של הסוכן. סוכן שסבל מ-prompt injection לא יכול לעקוף חוקי ליבה באמצעות שכנוע. התקינו תחילה את התלות הנדרשת:

sudo apt install bubblewrap

התצורה נמצאת תחת 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: []

תיקיית העבודה היא לקריאה בלבד עד שתגדירו אותה ב-write_paths, כך שסוכן שמשתבש אינו יכול לכתוב מחוץ לסביבת העבודה שלו. קובצי dotfiles נשארים מוסתרים אלא אם צוינו ב-cwd_allow_hidden, מה שאומר שהרשאת קריאה רחבה לא חושפת בשקט את .ssh או את .aws. הגדירו את egress_rules וכל תעבורת ה-HTTP וה-HTTPS תעבור דרך proxy עם מדיניות ברירת מחדל של חסימה, כאשר כל חוק נכתב כ-"METHODS host/path-glob". credential_proxy לוקח זאת צעד אחד קדימה: הסוכן מחזיק רק מציין מיקום (placeholder), וה-proxy מחליף אותו בסוד האמיתי ברגע שהבקשה יוצאת, כך שתמלול שהודלף לא מכיל מידע שמיש. בהתקנה מרובת סוכנים, כל סוכן משנה נושא בלוק sandbox משלו בקובץ התצורה שלו תחת agents/, כך שניתן למנוע גישה לרשת מבודק (reviewer) בעוד שהמיישם (implementer) שומר עליה.

המגבלה מצוינת בתיעוד, ויש לה חשיבות. ה-sandbox של מערכת ההפעלה חל על קריאות כלי ב-sys_os_* ועל מסופים (terminals). הוא אינו מכסה שרתי MCP, והוא אינו מכסה את תהליך ה-supervisor של Omnigent עצמו. שרת MCP שהפעלתם רץ מחוץ לארגז החול עם ההרשאות שלכם. פער זה הוא הסיבה לכך שהתבנית החזקה יותר היא עדיין מכונה חד-פעמית לכל סוכן, נושא שנדון ב-הרצת סוכני תכנות ב-VM זמני. החצי השני של המשימה הוא ניהול אישורים, ו-הרחקת סודות מהישג ידם של סוכנים הופכת לקשה יותר, לא קלה יותר, כאשר שישה סוכני משנה חולקים מארח אחד.

מגבלות תקציב הן מדיניות, המוצהרת באותו קובץ:

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]

הרצה שתכנונה מתבצע מול ספק אחד, מימושה מול שני וסקירתה מול שלישי, מוציאה כספים בשלושה מקומות בו-זמנית. לכן, הגדירו את התקרה לפני ההרצה הלא-מפוקחת הראשונה ולא אחרי החשבונית הראשונה. המנגנונים המובנים כוללים גם את max_tool_calls_per_session ואת ask_on_os_tools, המבקשים אישור לפני פעולות קובץ ופעולות shell. ההערות שלנו בנושא שליטה בעלויות סוכני AI ב-VPS רלוונטיות ישירות לכאן, והן רלוונטיות אף יותר, כיוון שסוכני משנה מקביליים מכפילים את קצב צריכת המשאבים.

באיזו מהירות מתקדם המאגר הזה?

[
  {
    "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 באוגוסט 2026. 7 גרסאות מתויגות שוחררו בין 2026-06-19 לבין 2026-07-27, והפער הארוך ביותר בין שתי גרסאות כלשהן היה 11 ימים. גרסה v0.5.1 שוחררה באותו יום שבו שוחררה הגרסה שלפניה. הגרסה הראשונה, 0.1.1 מה-16 ביוני 2026, אינה נכללת בתרשים מכיוון שאין תג קודם למדוד לפיו.

שתיים מהגרסאות הללו שברו פקודות שכבר תועדו במדריכים. גרסה v0.7.0 הסירה את omni server start לטובת omni server --background. גרסה v0.6.0 שינתה את שם ה-extra‏ omnigent[memory] ל-omnigent[hindsight], ולכן שורת התקנה שהועתקה ממדריך של חודש יוני נכשלת בגרסת בנייה של חודש יולי. זוהי הסיבה לשימוש ב---version בפקודת ההתקנה שלכם ולציון תג (tag) ב-git clone שלכם, ולא מדובר בהעדפה סגנונית בלבד.

דברים שעדיין לא הייתי סומך עליהם

נכון לאוגוסט 2026, המאגר מחזיק בכ-8.1 אלף כוכבים, 1.2 אלף forks וכ-350 בעיות פתוחות, כאשר הגרסה הציבורית הראשונה שוחררה לפני שבעה שבועות בלבד. כוכבים מודדים עניין, ועניין אינו מעיד על בשלות. הפרויקט מגדיר את עצמו כ-alpha, והיסטוריית השחרורים לעיל מראה שזה אכן המצב.

• לא הייתי מריץ אותו על מארח שמחזיק אישורי גישה (credentials) של סביבת ייצור, כיוון שה-sandbox אינו מכסה שרתי MCP או את ה-supervisor.
• לא הייתי משאיר הרצה ללא השגחה ללא מדיניות cost_budget, כיוון ששלושה ספקים יכולים לחייב במקביל ושום דבר אחר לא עוצר אותם.
• לא הייתי חושף את השרת בכתובת IP ציבורית ללא הגדרת OMNIGENT_AUTH_ENABLED ו-TLS לפניו.
• לא הייתי מתייחס ל-YAML של הסוכן כאל יציב בין גרסאות minor בשלב זה, לכן יש לקבע (pin) את הגרסה ולקרוא את הערות השחרור לפני שדרוג.

דבר נוסף שכדאי לדעת לפני שזה יפתיע אתכם: גרסה v0.6.0 הוסיפה טלמטריית שימוש אנונימית, והפרויקט מתעד זאת בדף טלמטריה ייעודי. קראו את הדף הזה וקבלו החלטה מושכלת אם המכונה מטפלת בעבודה עבור לקוחות.

מה ש-Omnigent עושה היטב כיום הוא הדבר שלשמו היא נבנתה. יש לכם שלושה או ארבעה ממשקי CLI של סוכנים, אתם כבר משלמים עליהם, ואתם רוצים שאחד מהם יכתוב בזמן שהאחר מבצע סקירה. זה עובד כעת, על מכונה אחת, עם sandboxing אמיתי ב-Linux. התייחסו לכל מה שמעבר לכך כאל מבטיח אך לא גמור.

FAQ

האם Omnigent הוא סוכן, או כלי שמריץ סוכנים?

הוא מריץ סוכנים. Omnigent הוא מעטפת-על (meta-harness): הוא מפעיל את כלי ה-CLI של הספקים שכבר התקנת, כגון Claude Code, Codex או OpenCode, מקצה לכל אחד מהם עבודה, ומפקח על התוצאות בסשן אחד. הוא אינו כולל מודל משלו. זו הסיבה שהוא שונה מ-framework, שבו אתה כותב קוד Python מול ספרייה והתוכנית שלך הופכת לסוכן.

האם אני צריך ש-Claude Code ו-Codex יהיו מותקנים כדי ש-Omnigent יהיה שימושי?

עליך להתקין ולהתחבר לפחות ל-CLI אחד של ספק, כיוון ש-Omnigent מפעיל את התוכנות הללו במקום להחליף אותן. עבור דוגמת ה-Polly המצורפת, מומלץ להשתמש בשניים או יותר מספקים שונים. הכלל של Polly הוא שהסקירה מתבצעת תמיד על ידי ספק שונה מזה שביצע את המימוש, לכן אם קיים רק CLI אחד, אין ספק שני שאליו ניתן לשלוח את ה-diff.

כיצד ניתן להתקין גרסה ספציפית של Omnigent במקום הגרסה האחרונה?

יש להעביר את --version דרך סקריפט ההתקנה עם sh -s --, כפי שמופיע ב-sh -s -- --version 0.7.0. ללא -s --, הדגל נבלע על ידי sh עצמו והסקריפט מתקין את ה-release החדש ביותר. אם uv כבר מותקן, uv tool install --force --python 3.12 "omnigent==0.7.0" מבצע את אותה פעולה. ה-git tag הוא v0.7.0 בעוד מחרוזת הגרסה ב-PyPI היא 0.7.0.

האם ה-sandbox של Omnibox מספיק להרצת סוכנים ללא השגחה?

הוא חזק עבור מה שהוא מכסה וברור לגבי מה שהוא לא. ב-Linux הוא משתמש ב-bubblewrap יחד עם seccomp, כך שה-kernel אוכף מגבלות קבצים ורשת והסוכן אינו יכול לבטל אותן. התיעוד מציין שהוא חל על קריאות כלי sys_os_* ועל מסופים, ושהוא אינו מכסה שרתי MCP או את תהליך ה-supervisor של Omnigent. לכן, שרת MCP רץ עם ההרשאות הרגילות שלך, וזו הסיבה שמכונה וירטואלית חד-פעמית לכל סוכן נותרת פתרון הבידוד החזק יותר עבור עבודה ללא השגחה.

כמה זיכרון צריך שרת Omnigent ב-VPS?

הערות ה-deploy של הפרויקט מציינות עבור השרת נפח עבודה של כ-512 MB עד 1 GB, והגדרת ה-Fly.io שלו מקצה 1 GB. זה מכסה רק את ה-supervisor ואת ממשק ה-web בפורט 6767. כל סוכן-משנה הוא תהליך נפרד עם עותק עבודה ולקוח מודל משלו, והרצות בסגנון Polly משתמשות ב-git worktrees מקבילים; לכן, יש לתכנן את ה-RAM והדיסק לפי מספר הסוכנים שאתה מתכנן להריץ בו-זמנית, ולא לפי השרת עצמו.