DevOS: An AI-Native Developer Orchestration Layer

What it is

DevOS (github.com/Shivay00001/devos) is an AI-native developer orchestration layer — and the README's first line is worth quoting because it prevents the most common misunderstanding: "DevOS is NOT a kernel." It doesn't replace your operating system. It sits on top of Windows, macOS, or Linux and turns natural-language intent into safe, validated system actions: "set up a new FastAPI project," "find what's eating my disk," "fix this failing test."

Think of it as an AI command center with a security guard at the door: an LLM translates your intent into commands, and a validation layer decides what actually executes.

The problem it solves

The terminal has a learning cliff. Every developer knows the feeling of knowing what they want ("clean up old Docker images, but not the ones my current project uses") without knowing the exact incantation. DevOS attacks this by letting you describe the outcome while the machine figures out the commands — but unlike a naive "LLM writes shell commands" demo, it wraps execution in validation, rate limiting, per-OS adapters, and an explicit permission model for plugins. The security-first posture is the differentiator: most NL-to-shell toys skip it.

How it works: architecture

The repo (~2.2 MB, the best-documented of the four in this batch) has a Python AI engine, a Go CLI core, OS adapters, tests, and serious docs:

devos/
├── run.py                     # entry → ai_engine.core.processor.main
├── ai_engine/
│   ├── core/processor.py      # NL → command translation pipeline
│   ├── adapters/llm_adapter.py# LLMAdapter ABC + Ollama/OpenAI/Anthropic/Gemini
│   ├── security/validator.py  # command validation & sandboxing
│   ├── memory/store.py        # SQLite persistent context memory
│   └── plugins/plugin_manager.py
├── windows_adapter.py / mac_adapter.py / linux_adapter.py
├── internal/                  # Go: config, executor, logger, monitoring
├── plugin.py + manifest.json # example plugin (git-helper)
├── install.sh / install.ps1 / Dockerfile / docker-compose.yml
├── tests/                     # 6 test files: processor, store, validator,
│                              #   llm_adapter, integration, benchmarks
└── ARCHITECTURE.md / SECURITY.md / docs/SECURITY_AUDIT.md /
    EXAMPLES.md / INSTALLATION_AND_TESTING.md / QUICKSTART.md

The pipeline: intent → validated action

run.py is three lines: it calls main() in ai_engine/core/processor.py. The processor (~14.3 KB) is where intent becomes action, and it reads like someone who has thought about failure modes:

• ExecutionResult is a dataclass with output, commands, needs_confirmation, and error — the pipeline returns proposed commands plus a confirmation flag, not just text.
• A rate_limit decorator (default: 100 calls per 60 seconds, per-instance tracked) guards against runaway loops.
• A validate_input decorator sanitizes input before it reaches the LLM.

The flow: your natural-language request → the LLM adapter generates a command plan → the security validator checks every proposed command against policy → safe commands execute through the OS adapter, risky ones surface with needs_confirmation=True. The LLM never touches your shell directly.

Multi-LLM adapters, local-first

ai_engine/adapters/llm_adapter.py defines the LLMAdapter abstract base class — one method, generate(prompt, max_tokens=2048, temperature=0.7). The default is OllamaAdapter (model llama3.2, hitting http://localhost:11434/api/generate with stream=False), with a genuinely helpful error when Ollama isn't running:

Cannot connect to Ollama. Is it running? (ollama serve)

Cloud adapters for OpenAI, Anthropic, and Gemini sit behind the same interface. The local-first default is the right call for a tool that generates shell commands: your terminal history never has to leave your machine.

Security: the validator, not vibes

ai_engine/security/validator.py (~7.4 KB) is the component that makes this more than a demo. Commands proposed by the LLM pass through validation and sandboxing policy before execution. The repo backs this with SECURITY.md (~15 KB) and a full docs/SECURITY_AUDIT.md (~13.6 KB) — unusually thorough for a project this size. Read both before trusting it with anything destructive; "security-first" is a design claim you verify, not a badge.

Memory and plugins

ai_engine/memory/store.py (~10 KB) is a SQLite-backed persistent memory: context survives across sessions, so "the project we were working on yesterday" is a meaningful reference. ai_engine/plugins/plugin_manager.py (~7.7 KB) loads plugins declared via manifest.json; the included example is a git-helper plugin (v0.1.0) with an explicit permission list:

"permissions": ["execute_commands", "read_filesystem", "write_filesystem"],
"config": { "auto_stage": false, "default_branch": "main", "safe_mode": true }

Capabilities-gated plugins — the manifest declares what the plugin may do — is the correct shape for an extensible automation layer.

The Go core and OS adapters

internal/ is a Go module (config, executor, logger, monitoring, each with tests) forming the CLI/runtime core, while windows_adapter.py, mac_adapter.py, and linux_adapter.py (~5.5–8 KB each) normalize OS differences so the AI engine issues platform-agnostic intentions. CI runs through .github/workflows/ci-cd.yml, and the test suite (tests/) covers the processor, memory store, validator, LLM adapter, integration paths, and even benchmarks — pytest.ini included.

Docs

This repo documents like a product: ARCHITECTURE.md (~19 KB), EXAMPLES.md, INSTALLATION_AND_TESTING.md (~11.5 KB), QUICKSTART.md, CHANGELOG.md, CONTRIBUTING.md, plus the security docs above and an ACHIEVEMENT_REPORT.md. You can understand the whole system without reading the code — then verify the code matches, which it does.

How to run it

git clone https://github.com/Shivay00001/devos.git
cd devos
# Linux/macOS
./install.sh
# Windows (PowerShell)
.\install.ps1
python run.py

Prerequisites: Python 3.8+. Optional: Go 1.21+ for the CLI core, and Ollama (ollama serve, model llama3.2) for local LLM — without either Ollama or a cloud API key, the engine has no brain, so get one of those first. Docker deployment is also available. Note: the README's quickstart shows a devos-ai/devos clone URL; the actual repo is Shivay00001/devos — clone the latter.

The Go runtime core

internal/ is a Go module with four packages, each with its own tests: config (~3.9 KB + tests) for configuration loading, executor (~5.1 KB + tests) for command execution, logger (~3.7 KB + tests) for structured logging, and monitoring (~3 KB + tests) for runtime observability. This is the systems-programming half of the project — the part that treats DevOS as infrastructure rather than a script. The Python engine handles intelligence (NL understanding, planning); the Go core handles the parts where you want static typing, fast startup, and small binaries.

OS adapters: platform differences as data

windows_adapter.py (~5.6 KB), mac_adapter.py (~5.5 KB), and linux_adapter.py (~8.1 KB) normalize the differences between operating systems — path conventions, shell semantics, system-query commands — so the AI engine issues platform-agnostic intentions and the adapter translates. The Linux adapter is the largest because Linux exposes the most system surface to manage. This layering is what makes "cross-platform" a real claim rather than a README bullet: the platform-specific knowledge lives in three files, not scattered through the engine.

Memory: context that survives the session

ai_engine/memory/store.py (~10 KB) persists conversational and project context in SQLite. The practical effect: DevOS remembers the project you were scaffolding yesterday, the error it helped you fix, the preferences you stated. For an orchestration layer, memory is what turns a command translator into an assistant — and SQLite keeps it local, matching the local-first LLM posture.

The test suite and CI

Six test files: test_processor.py (~7 KB) for the NL-to-command pipeline, test_store.py (~4.5 KB) for memory, test_validator.py (~5.2 KB) for the security layer, test_llm_adapter.py (~6.8 KB) for the adapters, test_integration.py (~9.9 KB) for end-to-end paths, and test_benchmarks.py (~9.3 KB) for performance. pytest.ini configures the runner; .github/workflows/ci-cd.yml (~6.3 KB) wires it into CI. For a project in this category, tested security validation is the difference between a research demo and something you can evaluate seriously.

Writing a plugin in 60 seconds

The plugin contract is one manifest.json plus one entry-point module. The included git-helper example declares its name, version, permissions, and safe-mode config; plugin.py (~6.6 KB) implements the operations. plugin_manager.py (~7.7 KB) handles discovery, permission enforcement, and lifecycle. If you want DevOS to manage your Docker containers or your Terraform state, this is the seam — declare the permissions, implement the operations, drop it in the plugins directory. Capability-gated from the start, so a plugin can't silently exceed what its manifest allows.

Honest status

Status: working demo / research-grade system. The pipeline is real end to end — NL input, LLM translation, validation, OS-specific execution, persistent memory, plugins — and the test suite plus security docs show it's been thought through rather than thrown together. Caveats before you adopt it:

1. It needs a brain you provide: local Ollama or your own OpenAI/Anthropic/Gemini key. There's no hosted backend.
2. Trust but verify the validator: the security design is documented and tested, but a tool that executes shell commands on your behalf deserves your own audit of security/validator.py against your threat model before anything beyond read-only use.
3. Research-grade edges: the Go CLI core and the Python engine overlap in places; expect to pick one entry point. The plugin ecosystem is one example plugin.
4. Two stars, no releases cut, no hosted demo — evaluate from the repo.

Roadmap-shaped gaps: a plugin marketplace or at least 5–10 reference plugins, tighter Go/Python integration (one binary), signed/verified command audit logging, an eval suite measuring "intent → correct safe command" accuracy, and a proper release with installers.

Who should look at this

Developers interested in AI tooling will find the validator-first architecture and the capability-gated plugin manifest worth studying — it's the shape safe agent tooling is converging on. Tinkerers: with Ollama running locally, python run.py is a genuinely fun afternoon. And if you're evaluating "AI that runs commands" for a team, the SECURITY_AUDIT.md gives you a head start on the questions to ask.

Frequently asked questions