VPS वर Agentlas OS self-host कसे करावे

Agentlas OS नेमके काय आहे

Agentlas OS हे open source agent runtime आहे. हे specialist agents डिस्कवर packages म्हणून ठेवते आणि प्रत्येक task साठी तात्पुरता orchestrator तयार करते. Linux VPS वरील तुमच्या स्वतःच्या user account मध्ये ते install करून self-host करता येते. ही service नाही. यात daemon, listening port, web interface किंवा repository मध्ये container image नाही.

या शेवटच्या वाक्यामुळे या पृष्ठावरील इतर सर्व बाबी ठरतात. बहुतेक multi-agent systems कायम सुरू असलेली supervisor process चालवतात आणि agents तिच्याकडे ठेवतात. Agentlas याच्या उलट पद्धतीने काम करते: specialists हे स्थिर files असतात आणि orchestrator केवळ task सुरू असतानाच अस्तित्वात असतो. त्यामुळे idle hub साठी memory नव्हे, तर disk space खर्च होते.

प्रकल्प त्याच्या open core ला Hephaestus म्हणतो. Commands, paths आणि environment variables मध्ये तुम्हाला हेच नाव दिसेल. Repository agentlas-ai/Agentlas-OS आहे, ते Apache-2.0 license अंतर्गत उपलब्ध आहे आणि मुख्यतः Python मध्ये लिहिलेले आहे.

प्रामाणिकपणे सांगायचे तर हा प्रकल्प किती नवीन आहे

हे repository 4 June 2026 रोजी तयार करण्यात आले. 13 October 2026 रोजी ते सुमारे चार महिन्यांचे आहे. त्याला अंदाजे 1,580 stars आणि 110 forks आहेत. प्रत्यक्ष कामासाठी वापरण्यात येणाऱ्या साधनासाठी हा कालावधी कमी आहे.

वयापेक्षा release cadence अधिक महत्त्वाची आहे. Version v1.1.103 8 August 2026 रोजी प्रकाशित झाले आणि v1.2.0 12 August 2026 रोजी प्रसिद्ध झाले. 1.1 मालिकेत automation द्वारे शंभरपेक्षा अधिक tagged releases प्रकाशित झाले आहेत. काही दिवसांत अनेक releases प्रकाशित झाले. 1.2 मालिकेनेही हीच गती कायम ठेवली. 10 October 2026 पर्यंत ती v1.2.62 वर पोहोचली होती. एवढ्या वेगाने बदलणारा प्रकल्प Tuesday आणि Thursday यांच्या दरम्यानही त्याचे वर्तन बदलू शकतो.

म्हणून release pin करा. Installer यासाठी environment variable वाचतो आणि खालील संपूर्ण मार्गदर्शकात ते वापरले आहे. एवढ्या वारंवार releases करणाऱ्या प्रकल्पाचे unpinned install केल्यास, script शेवटचे edit केले गेले त्या वेळी सर्वात अलीकडे tagged केलेली आवृत्ती install होऊ शकते.

VPS वर आवश्यक बाबी

आवश्यकता कमी आहेत, कारण पार्श्वभूमीत काहीही चालत नाही.

• Linux VPS. Ubuntu 24.04 हा योग्य आधार आहे. Installer uname -s वापरून operating system ओळखतो आणि Linux साठी non-macOS branch वापरतो. त्यामुळे headless box समर्थित आहे.
• Box वर curl, tar आणि git, तसेच Python 3.9 किंवा त्यानंतरची आवृत्ती आवश्यक आहे. सध्याचा installer release archive पडताळण्यासाठी Python वापरतो.
• सामान्य install साठी raw.githubusercontent.com आणि github.com कडे outbound HTTPS आवश्यक आहे. Installer release archive download करतो आणि त्याचा SHA-256 तपासतो. Outbound connectivity नसलेल्या box वरही तुम्ही स्वतः copy केलेल्या source tree मधून install करू शकता: HEPHAESTUS_SOURCE_DIR त्याकडे निर्देशित करा. त्यानंतर script download वगळतो, कारण त्याची curl आवश्यकता केवळ remote release मधून होणाऱ्या install साठी लागू आहे.
• Host harness, म्हणजे model शी प्रत्यक्ष संवाद साधणारा coding agent. Claude Code, Codex, opencode, goose आणि Hermes हे सर्व adapters समर्थित आहेत.

तुम्हाला root ची आवश्यकता नाही. Installer ~/.local/bin सह तुमच्या home directory अंतर्गतच फाइल लिहितो. एखादी पायरी अयशस्वी झाल्यास, उदाहरणार्थ एखादा path writable नसल्यास, तो warning देतो आणि उर्वरित प्रक्रिया सुरू ठेवतो. शेवटी काहीही अयशस्वी झाले असल्यास तो non-zero exit status देतो. तुम्ही स्वतः box निवडत असाल, तर VPS वर coding agent चालवणे या भागात या प्रक्रियेसाठी आवश्यक base image आणि access setup दिले आहे.

पिन केलेली release install करा

upstream README मध्ये main मधून script थेट bash कडे pipe करणारी एकच ओळ दिली आहे. ती download करून आधी वाचा. ही script तुमच्या shell configuration मध्ये आणि तिला सापडणाऱ्या प्रत्येक agent harness मध्ये बदल करते. त्यामुळे तिच्याकडे दहा सेकंद देणे योग्य आहे.

curl -fsSL -o install-all-runtimes.sh \
  https://raw.githubusercontent.com/agentlas-ai/Agentlas-OS/main/scripts/install-all-runtimes.sh
less install-all-runtimes.sh
HEPHAESTUS_REF=v1.2.0 bash install-all-runtimes.sh

HEPHAESTUS_REF हा pin आहे. main वरील script मध्ये ती ओळ आता version="${HEPHAESTUS_REF:-v1.2.62}" आहे आणि v1.2.62 ही release 10 October 2026 रोजी प्रकाशित झाली. Variable unset ठेवल्यास आता v1.2.0 मिळत नाही. प्रत्येक tag सोबत default बदलत राहील. तो स्पष्टपणे set करा. त्यामुळे काही महिन्यांनी केलेल्या rebuild मध्ये तुम्ही चाचणी केलेलीच आवृत्ती install होईल.

एक महत्त्वाची मर्यादा आहे: वरील script URL main चा मागोवा घेतो, तर HEPHAESTUS_REF ही script download करत असलेल्या runtime payload ला pin करते. या दोन वेगळ्या गोष्टी आहेत. दोन्ही pin करण्यासाठी main ऐवजी tag मधून script fetch करा. त्यासाठी त्या URL मधील main च्या जागी v1.2.0 ठेवा.

हा pin install प्रक्रियेला लागू होतो; त्यानंतर काय होते याला नाही. v1.2.0 पासून आणि main वर, hephaestus commands background update check सुरू करतात. नवीन release उपलब्ध असल्यास ते विचारणा न करता ती install करतात आणि ~/.agentlas/runtime/current ला नव्या आवृत्तीकडे निर्देशित करतात. Installer स्वतःच्या run साठी हे HEPHAESTUS_AUTO_UPDATE=0 ने बंद करते. Pin कायम ठेवण्यासाठीही हेच variable वापरा. पुढील चरणात ते तुमच्या shell profile मध्ये जोडले जाईल.

यशस्वी run मध्ये लिहिलेल्या paths दिसतात. त्यात या ओळींचाही समावेश असतो:

Installed runner: /home/you/.agentlas/runtime/current/bin/hephaestus
Installed shell commands in /home/you/.local/bin
  /home/you/.local/bin is not on your PATH yet. To use them by name:

हा PATH warning अनेक जण वगळतात. नवीन Ubuntu system वर ~/.local/bin बहुतेक वेळा PATH मध्ये नसतो. त्यामुळे install यशस्वी झालेले असतानाही प्रत्येक hep-* command command not found मुळे fail होतो. Installer ची सूचना ~/.zshrc मध्ये जोडते. मात्र Ubuntu चा default shell bash आहे. तेथे दुरुस्ती करा, त्याच वेळी background updater बंद करा आणि पडताळा:

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
echo 'export HEPHAESTUS_AUTO_UPDATE=0' >> ~/.bashrc
source ~/.bashrc
hep-global status

hep-global हे hephaestus global चे मूळ spelling आहे. status प्रत्येक harness instruction file मध्ये managed router block आहे की नाही हे दाखवते. हा router default ने बंद असतो. त्यामुळे output मध्ये none अपेक्षित आहे. Command चालत असेल, तर तुमचा PATH योग्य आहे.

State कुठे साठवली जाते

तुमच्या home directory अंतर्गत सर्वकाही file म्हणून साठवले जाते. त्यामुळे backup आणि migration सोपे होतात.

• ~/.agentlas/runtime/1.2.0/ मध्ये runtime स्वतः असते. Installer tag मधील सुरुवातीचे v काढतो. सक्रिय version कडे निर्देश करणारा symlink ~/.agentlas/runtime/current/ असतो. दोन pinned versions एकाच वेळी ठेवता येतात.
• ~/.local/bin/ मध्ये shell wrappers असतात. त्यात hephaestus, hep-build, hep-network, hep-search, hep-storm, hep-cloud आणि hep-upload यांचा समावेश आहे.
• ~/.agentlas/networking/memory/ मध्ये टिकाऊ memory साठवली जाते: playbook-registry.json, playbook-candidates.jsonl आणि memory-events.jsonl.
• ~/.agentlas/networking/hub-agents/<slug>/memory/experience.sqlite मध्ये प्रत्येक agent चा owner नुसार स्वतंत्र अनुभव साठवला जातो.
• <project>/.agentlas/ontology-runtime.sqlite मध्ये प्रत्येक project ची state साठवली जाते. त्यामुळे ती box ऐवजी repository सोबत हलते.
• Linux वर Python cache ~/.cache/agentlas/python मध्ये साठवला जातो. macOS वेगळा path वापरते. Installer uname वापरून योग्य branch निवडतो.

v1.2.0 मधील memory documentation मध्ये स्पष्टपणे सांगितले आहे की secrets, raw credentials आणि पूर्ण transcripts कोणत्याही memory scope मध्ये ठेवू नयेत. Credential values gitignored local files मध्येच ठेवाव्यात. Memory records मध्ये केवळ names आणि paths ठेवावेत. ~/.agentlas आणि तुमच्या project मधील .agentlas directories चा backup घेतल्यास नवीन VPS वर system पुन्हा तयार करता येते.

एक गोष्ट box च्या बाहेर जाते. सध्याच्या README नुसार hep-build default ने anonymous build counters पाठवते. त्यात prompts, paths किंवा agent content पाठवले जात नाही. ते बंद करण्यासाठी AGENTLAS_TELEMETRY=0 किंवा DO_NOT_TRACK=1 सेट करा, किंवा "telemetry": false हे ~/.agentlas/networking/config.json मध्ये ठेवा.

ते कोणत्या model backends कडे निर्देश करू शकते

संपूर्ण रचना नव्याने समजून घेण्यासाठी हा तपशील महत्त्वाचा आहे: Agentlas थेट model API ला call करत नाही. हे काम host harness करतो.

Architecture document मध्ये runtime adapters चे वर्णन आहे. हे adapters एका core चे प्रत्येक harness साठी रूपांतर करतात. README मध्ये असेही नमूद आहे की adapter स्वतःचे provider authentication हाताळतो आणि caller ने स्वतःचा model व API access पुरवायचा असतो. Agentlas कडून harness दोन surface वापरतो: एक AgentSkills file आणि stdio वर संवाद साधणारा MCP (model context protocol) server. त्यामुळे "Agentlas कोणत्या models ला support करते" हा प्रश्न प्रत्यक्षात "तुमचा harness कोणत्या models ला support करतो" असा आहे. Claude Code, Codex, opencode, goose किंवा Hermes ज्या कोणत्याही model पर्यंत पोहोचू शकतात, तो model येथे वापरता येतो.

Codex-style TOML config मध्ये MCP server अशा प्रकारे register करता येतो:

[mcp_servers.hephaestus-network]
command = "~/.agentlas/runtime/current/bin/hephaestus"
args = ["mcp", "serve"]

Install दरम्यान हाच server ~/.cursor/mcp.json, ~/.config/goose/config.yaml आणि इतर harness configs मध्ये आपोआप register केला जातो. एका box मध्ये असे अनेक servers जोडत असल्यास, VPS वर MCP servers चालवणे या लेखात stdio आणि process model अधिक सविस्तर समजावले आहे.

स्थानिक Ollama endpoint कडे निर्देश करा

Harness कडे model connection असल्यामुळे Agentlas ला स्थानिक models कडे निर्देश करणे म्हणजे तुमच्या harness ला Ollama कडे निर्देश करणे होय. यासाठी Ollama ने v0.15 मध्ये launch subcommand समाविष्ट केले. 11 August 2026 रोजी ते v0.32.9 मध्येही उपलब्ध आहे. हे कोणतेही environment variables सेट न करता, विद्यमान harness ला स्थानिक models साठी configure करते:

ollama pull qwen3-coder:30b
ollama launch opencode

तुम्ही install केलेल्या harness नुसार opencode च्या जागी claude, codex किंवा droid वापरा. त्यानंतर स्थानिक runtime मार्फत request पाठवा:

~/.agentlas/runtime/current/bin/hephaestus route "summarise the failing tests" --runtime ollama

यशस्वी route केल्यावर निवडलेल्या agent किंवा team चे नाव असलेला JSON decision आणि receipt_id परत मिळतो. उपयुक्त output मिळत नसेल, तर त्याचे नेहमीचे कारण context length असते. v1.2.0 local-models documentation routing-heavy sessions साठी किमान 64k context असलेला model वापरण्यास सांगते. त्यात qwen3-coder, gemma3 आणि deepseek-r1 ही उदाहरणे दिली आहेत. Coding tools साठी Ollama चे स्वतःचे मार्गदर्शनही 64k हीच किमान मर्यादा सांगते. Routing decisions मध्ये prompt मध्ये agent inventory समाविष्ट असते. त्यामुळे 8k किंवा 32k context असलेला model ही inventory truncate करतो आणि चुकीची निवड करतो.

Tagline मध्ये न सांगितलेली एक महत्त्वाची मर्यादा आहे. Ollama, Gemma आणि DeepSeek यांच्याकडे स्वतःची plugin किंवा command system नाही. त्यामुळे /agentlas slash commands तेथे उपलब्ध नसतात. Local-model setup मध्ये तुम्ही MCP server आणि hephaestus route command द्वारे system चालवता. ही कार्यक्षमतांची वास्तविक घट आहे. मात्र model weights स्वतःच्या server वर ठेवण्यासाठी हा प्रामाणिक trade-off आहे.

निष्क्रिय specialists च्या hub साठी RAM मध्ये किती खर्च येतो

काहीही नाही. हेच संपूर्ण उत्तर आहे आणि त्यावर विश्वास ठेवण्याऐवजी तुम्ही ते सिद्ध करू शकता.

उधार घेतलेले hub specialists processes म्हणून नव्हे, तर package artifacts म्हणून येतात. Specialist म्हणजे एक agent.md आणि JSON असलेली .agentlas/ directory. routing-card.json मध्ये triggers आणि capabilities असतात, memory-map.json मध्ये write boundaries असतात आणि mode-map.json मध्ये तो एकट्याने चालतो की team चा भाग म्हणून हे नमूद केलेले असते. Hephaestus Network documentation मध्ये task साठी workers सुरू करणाऱ्या runner चे वर्णन आहे. त्यात listening port उघडण्याचा किंवा सेवा enable करण्याचा कोणताही उल्लेख नाही. दोन tasks दरम्यान स्वतः पडताळा:

pgrep -af hephaestus
systemctl --user list-units --type=service | grep -i agentlas
du -sh ~/.agentlas

पहिल्या दोन commands निष्क्रिय box वर काहीही output देत नाहीत, कारण कोणतीही process resident नसते. एक अपवाद म्हणजे background updater. HEPHAESTUS_AUTO_UPDATE=0 सेट केलेले नसल्यास, command पूर्ण झाल्यानंतर अल्पकाळ चालणारा detached update worker सुरू राहू शकतो. तिसरा command parked hub मुळे येणारा एकमेव खर्च दाखवतो. तो disk space आहे. तुम्ही ठेवलेल्या specialists ची संख्या आणि runtime सोबत येणाऱ्या bundled embedding model नुसार तो वाढतो.

म्हणून memory चा प्रश्न पूर्णपणे burst वर अवलंबून आहे. हा burst म्हणजे तुमचा harness आणि model backend. Harness hosted API शी संवाद साधत असल्यास resident cost काहीशे megabytes ची एक process इतका असतो. Weights तुम्ही self-host करत असल्यास, मुख्य खर्च weights चा असतो:

[
  {
    "label": "Hosted API model",
    "weights_gb": 0
  },
  {
    "label": "gemma3:4b",
    "weights_gb": 3.3
  },
  {
    "label": "gemma3:12b",
    "weights_gb": 8.1
  },
  {
    "label": "gemma3:27b",
    "weights_gb": 17
  },
  {
    "label": "qwen3-coder:30b",
    "weights_gb": 19
  }
]

हे Ollama च्या model library मधील प्रकाशित download sizes आहेत. Benchmark run मधील मोजमाप नाहीत. वरील शून्यापेक्षा मोठ्या प्रत्येक आकड्यावर 64k context साठीचा KV cache अतिरिक्त असतो. Agentlas docs मध्ये प्रथम नमूद केलेल्या model ला, qwen3-coder:30b, context मोजण्यापूर्वी 19 GB weights आवश्यक असतात. 27B Gemma variant लाही 17 GB आवश्यक असतात. या आकड्यांच्या तुलनेत Agentlas layer स्वतः budget मध्ये दिसून येत नाही.

एका harness चालवण्याशी तुलना

Hosted API विरुद्ध एक harness चालवल्यास तुमचा VPS एक process चालवतो. Agentlas जोडल्यावर तोच एक process, तसेच files हाताळतो. Orchestrator हा स्वतंत्रपणे दीर्घकाळ चालणारा program नाही. तो disk वरील packages मधून तयार केलेला मोठा prompt असतो आणि त्यानंतर discard केला जातो.

यात बदलणारी किंमत memory ची नसून context ची आहे. अनेक specialist cards आणि त्यांचे routing metadata समाविष्ट करणारा orchestrator, bare harness पेक्षा प्रत्येक task साठी अधिक tokens वापरतो. Hosted API मध्ये याचा परिणाम RAM ऐवजी खर्चावर होतो. Local weights वापरताना परिणाम वेळेवर होतो, कारण मोठ्या prompt मुळे CPU वर prefill अधिक वेळ घेतो किंवा GPU वर अधिक भार पडतो.

म्हणून अशा box साठी sizing advice agent framework वर नव्हे, तर model च्या निर्णयावर आधारित असते. coding agent VPS साठी RAM आणि CPU चे sizing याचे सविस्तर स्पष्टीकरण देते. निष्कर्ष येथेही लागू होतो: तुम्ही चालवणार असलेल्या backend साठी plan निवडा आणि harness साठी आणखी काही gigabytes headroom ठेवा. त्याऐवजी तुलना करण्यासाठी always-on supervisor design हवे असल्यास, Omnigent multi-agent harness त्याचा coordinator resident ठेवतो. हा उलट trade-off आहे आणि idle memory मध्ये तो थेट दिसतो.

अपयशाच्या परिस्थिती आणि दिसणारे संदेश

hep-build: command not found स्वच्छ install नंतर लगेच. Installer ने ~/.local/bin मध्ये लिहिले. Default Ubuntu image मध्ये ते PATH वर नाही. Output च्या शेवटच्या भागाजवळ याचा उल्लेख होता; warning पटकन पुढे सरकली आणि सुचवलेला उपाय bash ऐवजी ~/.zshrc ला लक्ष्य करतो. वर दाखवलेला export ~/.bashrc मध्ये जोडा.

Box पुन्हा build केल्यानंतर वर्तन बदलते. तुम्ही HEPHAESTUS_REF सेट केले नाही. त्यामुळे installer ने त्या दिवशी त्याच्या script मध्ये नमूद केलेला tag वापरला. तो pin करा आणि इतर version numbers जवळ तो pin नोंदवा.

Rebuild न करता वर्तन बदलते. Background updater ने नवीन release install करून ~/.agentlas/runtime/current त्याकडे हलवले. current कशाकडे निर्देश करतो ते तपासा आणि HEPHAESTUS_AUTO_UPDATE=0 interactive shell मध्येच नव्हे, तर तुमचा harness ज्या environment मध्ये चालतो त्यात सेट करा.

Local model वर routing चुकीचा specialist निवडते. Agent inventory साठी model ची context window खूप लहान आहे. 64k किंवा त्याहून अधिक context असलेल्या model वर बदला आणि Ollama ची context length त्यानुसार सेट करा, कारण default मूल्य coding tools ला आवश्यक असलेल्या मूल्यापेक्षा कमी आहे.

ollama launch ओळखले जात नाही. हा subcommand Ollama v0.15 मध्ये आला. Distribution repository मधील जुनी packages त्यापूर्वीची आहेत. त्यामुळे सध्याचे Ollama install करा.

Install अपेक्षित नसलेल्या harnesses मध्ये लिहिते. Script ला आढळणारा प्रत्येक harness detect करून configure करते. ते ~/.claude/, ~/.codex/, ~/.gemini/, ~/.cursor/ आणि इतर ठिकाणी लिहिते. तसेच आधीपासून अस्तित्वात असलेल्या config files, जसे ~/.codex/config.toml, संपादित करते आणि मूळ file च्या बाजूला backup ठेवते. Shared build box वर ते चालवण्यापूर्वी script वाचा आणि यापैकी कोणत्या directories तुमच्यासाठी महत्त्वाच्या आहेत हे निश्चित करा.

हे आत्ता चालवावे का

Automated releases असलेल्या आणि कधीकधी दिवसातून अनेक releases देणाऱ्या चार महिन्यांच्या project वर production workload चालवणे योग्य नाही. त्याची architecture खरोखरच वैशिष्ट्यपूर्ण आहे, license Apache-2.0 आहे आणि त्याची संपूर्ण state backup करता येणाऱ्या files मध्ये साठवली जाते. मात्र removal दिसते तितके सोपे नाही: README मध्ये uninstall ची कोणतीही माहिती नाही, installer तुमच्या home directory मधील सुमारे दहा ठिकाणी files लिहितो आणि आधीपासून असलेल्या harness configs मध्ये बदल करतो. तसेच त्याने दिलेली एकमेव removal command, hephaestus global remove, फक्त optional router block काढते. त्यामुळे disposable box वर ते वापरून पाहणे स्वस्त आहे; परंतु त्यावर अवलंबून राहणे महागात पडू शकते.

सध्या योग्य पद्धत अशी आहे: v1.2.0 ला pin करा, तो pin कायम राहण्यासाठी HEPHAESTUS_AUTO_UPDATE=0 सेट करा, पुन्हा build करता येईल अशा box वर ते चालवा, ~/.agentlas तुमच्या backups मध्ये ठेवा आणि pin पुढे हलवण्यापूर्वी changelog पुन्हा वाचा. या क्षेत्रातील इतर पर्याय आणि प्रत्येकाची maturity यांचा व्यापक आढावा हवा असल्यास, self-hosted AI agents चा आढावा हा चांगला प्रारंभबिंदू आहे. Agentlas ज्या harnesses शी adapt होते त्यापैकी एका harness विषयी VPS वर Hermes agent self-host करणे येथे माहिती दिली आहे.

FAQ

Agentlas OS माझ्या VPS वर server म्हणून चालते का?

नाही. Repository मध्ये कोणताही daemon, listening port किंवा container image नाही. Installer ~/.agentlas/runtime/ अंतर्गत runtime आणि ~/.local/bin मध्ये command wrappers लिहितो. Hephaestus Network background service म्हणून नव्हे, तर एखादे task ते सुरू करते तेव्हा चालते. Idle box वर हे तपासता येते: pgrep -af hephaestus काहीही output देत नाही आणि enable करण्यासाठी कोणतेही systemd unit उपलब्ध नाही. Commands सुरू करू शकतील असा अल्पकाळ चालणारा update worker हीच एकमेव background activity आहे; HEPHAESTUS_AUTO_UPDATE=0 तो बंद करते. येथे self-hosting म्हणजे code आणि state तुमच्या machine वर असणे. याचा अर्थ कोणतीही service listening अवस्थेत आहे असा नाही.

idle specialists असलेल्या hub ला किती RAM लागते?

काहीही नाही, कारण idle specialists हे processes नसतात. Specialist म्हणजे agent.md file आणि .agentlas/ directory असते. त्या directory मध्ये routing-card.json, memory-map.json आणि तत्सम metadata असते. त्यामुळे निष्क्रिय hub ला disk space लागतो. हे du -sh ~/.agentlas ने मोजा. Memory फक्त task चालू असताना वापरली जाते. ती Agentlas layer नव्हे, तर तुमचा harness process आणि model backend वापरतात.

मी कोणती models वापरू शकतो आणि ते माझ्या स्वतःच्या Ollama कडे निर्देशित करता येते का?

Agentlas स्वतः model APIs call करत नाही. Credentials आणि connection host harness कडे असतात. त्यामुळे समर्थित models म्हणजे तुमचा harness ज्या models ला support करतो ते. Local weights साठी ollama launch opencode चालवा. त्यात claude, codex किंवा droid यापैकी योग्य value द्या. यामुळे कोणतेही environment variables न वापरता harness तुमच्या Ollama server साठी configure होते. किमान 64k context असलेले model वापरा, जसे qwen3-coder किंवा gemma3. Routing prompts मध्ये agent inventory असते. लहान context window मध्ये ते मोठ्या प्रमाणात truncate होतात.

कोणती version install करावी आणि येथे pinning महत्त्वाचे का आहे?

12 August 2026 रोजी current असलेली tagged release v1.2.0 install करा. त्यासाठी installer चालवण्यापूर्वी HEPHAESTUS_REF=v1.2.0 set करा. main वरील script चा स्वतःचा default आता version="${HEPHAESTUS_REF:-v1.2.62}" आहे. v1.2.62 ही 10 October 2026 रोजी प्रकाशित झालेली latest release आहे. प्रत्येक नवीन tag सोबत हा default बदलतो. येथे pinning नेहमीपेक्षा अधिक महत्त्वाचे आहे. Project ने 1.1 series मध्ये शंभरपेक्षा जास्त releases प्रकाशित केल्या आहेत आणि काही दिवशी अनेक releases प्रकाशित केल्या आहेत. त्यामुळे काही आठवड्यांनी unpinned rebuild केल्यास तुम्ही तपासलेली system मिळणार नाही. HEPHAESTUS_AUTO_UPDATE=0 हे देखील set करा. अन्यथा runtime background मध्ये newer releases install करेल आणि pin शांतपणे लागू राहणार नाही.