Local AI without vendor limits.
On your hardware.
Horus is a local-first AI operator for chat, coding, reasoning, automation, terminal work, and optional vision. It combines a 120-tool local operator suite, live PTY terminal, background jobs, persistent memory, Ollama model routing, and approval-aware staged edits — all running on hardware you control.
No required cloud AI APIs. No rented inference layer. No blind file edits. Your machine. Your models. Your rules.
- 120-tool local operator suite — files, code search, git, terminal, logs, SSH, PM2, process control, Ollama management, media generation, and staged edits
- Background job system — tasks survive browser disconnect
- Live PTY terminal — real interactive shell in the UI
- Conversation persistence + per-session memo scratchpad
- Optional vision analysis support
- Safe Mode by default, Root Mode opt-in
Live Terminal + Local AI Stack
A real local build running on customer-owned hardware — with interactive terminal control, model routing, live tool execution, and system-level visibility including GPU/VRAM in the UI header.
- Real command output — not mocked
- Secure remote UI + local-first defaults
- Hardware-scaled performance
- Tasks run in background — close the browser, come back later
Installation
bash horus-installer.shFollow the prompts. Everything installs automatically.
Open PowerShell as Administrator and run:
wsl --installReboot when prompted. Set a username and password when Ubuntu opens.
Open WSL (Ubuntu) and run:
bash /mnt/c/Users/YOUR-USERNAME/Downloads/horus-installer.shReplace YOUR-USERNAME with your Windows username.
When installation finishes, open your browser and go to:
http://localhost:8080120-Tool Local Operator Suite
Horus exposes 120 tools across filesystem operations, code search, terminal control, log inspection, SSH, PM2 & process management, Ollama model control, media generation, git inspection, project analysis, memoization, and staged-edit governance. The staged workflow enables a safer operating pattern: stage → review → approve → deploy.
Approval-Aware Editing Workflow
- Stage a file change without touching the live target
- Finalize the staged edit and inspect the result
- Approve only after review
- Deploy to production when ready
- Discard safely when a change is not wanted
stage_file_edit
finalize_staged_edit
approve_staged_edit
deploy_staged_edit
This is one of the biggest differences between Horus and “blind edit” local agents. It supports a disciplined human-in-the-loop workflow instead of assuming every generated change should go live.
Background Job System
Horus runs long tasks in the background, completely decoupled from the browser. Submit a job, close the tab, come back when it’s done. Every job event is buffered in a 2 MB ring buffer — reconnect anytime and replay the full run history. Configurable active job limit (default 5). Finished jobs retained for 1 hour, then garbage collected automatically.
Why local beats cloud
- Your prompts + data stay on your machine
- No rented cloud inference layer for local workflows
- You choose models, routing, and tool rules
- Core local chat, tools, files, and automation continue after installation and model download
- Data may leave your environment depending on provider and configuration
- Rate limits, usage caps, and pricing changes happen
- Model behavior changes outside your control
- Outages and downtime still happen
What “own it” actually means
Horus runs locally with a security baseline that makes sense: workspace jail by default, audited tools, staged approvals, and upgrades you control.
- Your models live on your disk — not an API
- Tool rules are explicit, jailed, and reviewable
- Switch models without changing the whole system
- Conversation history stays on your machine
- Approval-aware edits reduce accidental breakage
One System. Hardware-Scaled.
Horus is a single local AI operator. Performance scales with your hardware — not artificial software tiers.
Deployment Profiles
Starter Hardware
16–32 GB RAM • 8–12 GB VRAM optional
Ideal for smaller models and lightweight automation.
Performance Hardware
32–64 GB RAM • 24 GB VRAM recommended
Supports 32B-class reasoning + coding models comfortably.
Workstation
64 GB+ RAM • 24 GB+ VRAM (or multi-GPU)
Designed for heavy reasoning, larger models, and advanced automation.
Fully Customizable Model Stack
After installation, you control which Ollama models are installed, routed, or removed.
- Add or remove models anytime
- Switch primary reasoning engine
- Add vision models if hardware allows
- Upgrade models without reinstalling
Model availability depends on your machine’s RAM, VRAM, and storage — not artificial product limitations.
Who it’s for
Power users who want a local AI operator: developers, builders, IT / homelab folks, small teams, and creators who want an assistant that runs on their own machine — with tools, memory, terminal access, and real system visibility.
Typical uses
• Codebase audits with search, diff, and patch
• Long-running automation jobs (background, reconnect-safe)
• Interactive terminal + AI in the same UI
• UI / screenshot understanding (Vision tier)
• A private assistant that doesn’t depend on cloud AI services
What you actually get
- 120 local operator tools across files, code search, git, terminal, logs, SSH, PM2, process control, Ollama management, media generation, memo, and staged edits
- Background job system with SSE replay and cancellation
- Live PTY terminal in the browser UI
- Workspace jail, blocked extensions, auth middleware, and reviewable edit flow
Core Model Stack
Horus supports any Ollama model. Below is the reference stack used in production.
| Role | Ollama model | Size | When to use |
|---|---|---|---|
| Primary Agent | Primary Agent Model | — | Main agentic operator — chat, reasoning, tool orchestration, background jobs. |
| Vision | Vision Model | — | Image understanding, screenshots, and UI analysis. |
Chat / Code / Reason are behavior modes with automatic routing — not separate products.
Sizes vary by quantization. Table communicates role and class, not exact storage.
System requirements
Horus runs entirely on customer hardware. Choose models that match the experience you want.
Starter Hardware
Best for smaller models, fast chat, and lightweight tools.
CPU: 4–8 modern cores
RAM: 16–32 GB
GPU: optional (8–12 GB VRAM helps)
Storage: 40 GB minimum
Experience: solid on CPU, better with GPU
Performance Hardware
Best for 32B-class coding + reasoning + tools.
CPU: 8–16 modern cores
RAM: 32–64 GB
GPU: 24 GB VRAM recommended
Storage: 120 GB minimum (250 GB recommended)
Experience: fast, stable, tool-friendly
Workstation
For heavy reasoning, larger models, and advanced automation.
CPU: 16+ modern cores
RAM: 64 GB+
GPU: 24 GB+ VRAM (or multi-GPU)
Storage: 250 GB+ recommended
Experience: maximum flexibility + headroom
Universal requirements
OS: Ubuntu 24.04 LTS
Ollama endpoint: 127.0.0.1:11434
Horus UI: configurable (default 8080)
Security baseline: workspace jail, blocked script extensions, optional Basic Auth
Startup & health validation
ollama list
curl -s http://127.0.0.1:11434/api/tags | head
pm2 status
nvidia-smi # if GPU tier
Performance expectations
First response after boot: < 5–10 seconds (warmup).
Typical responses: hardware- and model-dependent for chat, code, and tool tasks.
Background jobs: run to completion independent of browser session.
Recommended baseline settings
- Keep Ollama bound to localhost; reverse proxy only if needed
- Set HORUS_WORKSPACE_DIR to your project root — jails all file tools
- Enable Basic Auth if accessing beyond localhost
- Log tool outputs for debugging and accountability
Safe Mode (default)
Horus ships with a tight security baseline: workspace jail, blocked script extensions, and no risky system access by default.
Safe Mode defaults
• All file tools restricted to HORUS_WORKSPACE_DIR
• Script uploads blocked (.sh .py .js .ts .bash etc.)
• No sudo by default
• Model routing locked to the supported set
• UUID-validated conversation IDs on all routes
Why Safe Mode matters
- Prevents commands from escaping your project directory
- Makes behavior consistent for non-technical users
- Allows remote access without giving away the keys
Root Mode (opt-in)
For power users. Root Mode unlocks full customization: models, tools, routing rules, filesystem access, and privileged commands — only when explicitly enabled.
Root Mode principles
• Human must enable it (never the AI)
• Enable locally (localhost/terminal), not from remote web sessions
• Audit log every elevated action
• One-click rollback to Safe Mode
When to use Root Mode
- Installing new Ollama models and custom routing rules
- Integrating with local services (PM2, Docker, Git, etc.)
- Advanced automation where you want maximum control
Get started
Email [email protected]
with subject Horus and include:
• Your hardware (CPU/RAM/GPU)
• What you want Horus to do (chat, coding, automation, vision)
• Whether this is local-only or you need secure remote access
If you already have hardware, include your nvidia-smi output and ollama list — it speeds up setup recommendations.
Notes
Horus is designed for local operation on customer-owned hardware. For remote access, use secure networking and restrict access appropriately.
Recommended remote access
- Use a VPN (zerotier-one) rather than exposing ports
- Enable Basic Auth for the UI if accessed beyond localhost
- Keep tool execution workspace-jailed for remote sessions
Large 70B+ reasoning models are not included by default — available as optional additions based on your hardware.