Skip to main content
OpenEng AI · the engine

Open-weight models,
downloaded and run on your machine.

OpenEng’s engine downloads open-weight models from any registry — Hugging Face, the Ollama library, ModelScope, or a direct URL — and runs them on your own hardware, on the runtime the weight format supports: its built-in models in the engine’s enclosed model daemon, catalog models through a local Ollama daemon you install. Map a model to each role, let the engine pick the right one for every job, and ship real changes to disk through a no-bypass gate.

Open the Web Console

Install · Linux x86_64

The engine starts with an OpenEng key from the Console and needs an active Pro plan, launching in Q4 2026. On Windows, run it under WSL.

Status: OpenEng AI isn’t live yet. The Console and Web Console interfaces load, but the OpenEng AI API routes and the Broker aren’t deployed. Nothing can be saved or published, and no AI engine can register or connect. Pro, Enterprise, and pay-as-you-go launch in Q4 2026 and can’t be purchased yet. This page describes how it is built to work.

Enclosed built-in models Open-weight models No provider API keys No network port

The model team

Eleven roles, not one big model.

Most tools call one big model in the cloud for everything. OpenEng splits the work into eleven roles — each tuned for its job — and lets you point each one at any model in your catalog, whatever its registry, format, or runtime. Small models handle the easy work; bigger ones take the hard parts.

OpenEng is an agentic ecosystem for open-weight model execution: it downloads, orchestrates, and runs open-weight (open-source) AI models entirely on your machine.

Complexity analyzer

Scores each request’s complexity. Left unset, the engine’s built-in router does it with no LLM call (heuristics plus an on-device embedding); bind a model and scoring becomes one bounded model call.

Planner

Decomposes a complex goal into an ordered, multi-step plan before a single tool runs.

Plan orchestrator

Coordinates how the plan is carried out — the orchestration strategy layered on top of the planner.

Agent

Holds the conversation and does the work — it reads, writes, and edits real files. Every change that lands on disk comes from here.

Sub-agent

Specialists the agent spawns for focused sub-tasks — up to four in parallel by default.

Delegator

Hands work down a delegation tree, with a depth cap you set in the config’s execution flow.

Sub-delegator

Delegates again one level down, so a large task fans out without one model holding all of it.

Reviewer

Validates each iteration and sub-agent result, catching mistakes before they compound.

Summarizer

Compresses long context and turn history so the engine keeps a tight, relevant working memory.

Doc researcher

Grounds answers in documentation from a local research corpus the engine crawls and indexes itself.

Code researcher

Searches code to ground coding work — the code half of the engine’s research system.

always loaded

Guardrail

Not a role you pick: a guardrail model that stays loaded, and that a config’s gateway policy can use to screen model inputs for injection and outputs for groundedness. Beside it sit the embedded pair — a small classifier and an embedder.

The engine’s built-in suite is compact Q4_K_M GGUF weights from the Hugging Face Hub — Gemma 3 4B, Qwen2.5-Coder 3B, Qwen2.5 7B, Qwen2.5 1.5B, and Qwen2.5 0.5B. The installer pulls the chat model, openeng pull <role> fetches any other, and weights are shared across roles: the reviewer reuses the Gemma weights, the guardrail the classifier’s. The 28-model catalog adds larger options for every role, run through a local Ollama daemon that you install and run.

Open-weight model execution

28 on-device models. Three axes, one matrix.

A model is three independent choices: the registry the weights come from, the weight format they are in, and the runtime that executes them. The format determines which runtimes can run it — the engine enforces that compatibility matrix and refuses an impossible pairing rather than silently degrading. From about 1 GB on a thin laptop to Llama 3.3 70B on a workstation — your hardware, your choice.

Any registry, any format

Pull weights from Hugging Face, the Ollama library, ModelScope, or a direct URL — resumable, checksum-verified, and cached with LRU eviction. GGUF and ONNX run built in; Safetensors, GPTQ/AWQ, EXL2/EXL3, and TensorRT run once their runtime’s toolchain and a CUDA GPU are installed; MLX needs macOS.
  • Hugging Face · ModelScope · Ollama library
  • Direct URL supported
  • Resume + checksum + cache

The runtime that fits

Each format runs on the runtimes that support it — llama.cpp for GGUF, ONNX Runtime for ONNX, ExLlama for EXL2 and EXL3, vLLM, SGLang, TensorRT-LLM, Transformers, or MLX for Safetensors and quantized checkpoints, or Ollama. llama.cpp and ONNX Runtime are built in and run only inside the engine’s enclosed model daemon, never directly in the engine process. The runtime servers are used only when their own toolchain is installed, and the engine starts them in a resource-capped systemd scope. Ollama models run in the Ollama daemon you install and run. The published matrix lists GPU offload for llama.cpp, but GPU offload is a build option the published engine doesn’t include: it runs llama.cpp on the CPU.
  • Format ↔ runtime matrix enforced
  • Built-in runtimes in the enclosed daemon
  • Matrix published at models.openeng.app/runtimes.json

CPU today, GPU as a build option

The published Linux x86_64 build runs llama.cpp on the CPU. GPU offload to CUDA, Vulkan, or Metal is a build option of the engine that the published binary does not include. vLLM, SGLang, ExLlama, and TensorRT-LLM need a CUDA-capable GPU and their own toolchain; MLX needs macOS on Apple silicon, where there is no AI engine build yet. A local Ollama daemon manages its own GPU use.
  • llama.cpp on the CPU in the published build
  • CUDA · Vulkan · Metal as build options

Want a hosted model instead? Point any role at one — your own OpenAI-compatible API or a provider account — and the engine reaches it through one gateway, routed out through the sandbox wherever the host provides one. Open-weight, on your machine, is the default.

No mode-picking

It picks the right brain. You just type.

There is no mode switch to get wrong. By default a two-stage built-in router scores every request with no LLM call (heuristics plus an on-device embedding), then routes it to plan, execute, or answer outright. Bind a Complexity Analyzer model and it scores instead, in one bounded model call.

stage 1 · heuristics

Cheap signals first

Fast, deterministic heuristics catch the obvious cases — length, structure, and intent markers decide most requests instantly, before any model spins up.

stage 2 · semantic gap

Then a semantic check

When heuristics are unsure, an on-device embedding measures the semantic gap between a quick answer and the real task. Past the threshold, the engine commits to a full multi-step plan.

The routing decision

  • Below threshold

    Answered directly by the agent — no plan, no overhead.

  • Above threshold

    Promoted to the planner: a real, ordered, multi-step plan with a specialist model per task.

  • Every request

    Scored once — by the built-in router with no LLM call (heuristics plus an on-device embedding), or by the Complexity Analyzer model you bind.

Agents that ship

It doesn't just plan. It puts files on disk.

A complex goal runs as an agent loop — up to 28 iterations with as many as 4 sub-agents working in parallel — and every change reaches your filesystem through the Worker Execution System’s no-bypass gateway. The shell commands the agent runs go through it too, in a kernel sandbox where the host provides one.

A real agent loop

Plan, act, observe, review, repeat. The reviewer validates each iteration, so mistakes are caught before they compound across a long run.
  • Up to 28 iterations
  • 4 parallel sub-agents
  • Reviewed every iteration

The Worker Execution System

Every action — read, write, edit, run — executes through workers behind a gateway. The shell tool goes through it too: its commands run in a kernel sandbox where bubblewrap works on the host, and unconfined where it doesn’t.
  • No-bypass gateway
  • Shell sandboxed where the host allows
  • Resource-capped workers

Changes you can review

Work lands as concrete file edits on disk that you can review and diff — not a transcript that claims it did something. Revert them with your own tools, for example git; the Web Console has no undo. Agents that actually ship.
  • Concrete file edits
  • Review and diff them
  • Revert with your own tools, such as git

Safe to leave running

Autonomy with a hard floor under it.

An agent with file access only earns trust if it's contained. Every tool call passes the engine’s compiled security floor, the shell commands it runs execute in a kernel sandbox where the host provides one, and destructive actions need your approval by default.

A floor under every tool call

By default, every tool call passes the compiled floor (authorization, secret-egress blocking and redaction), a heuristic injection screen flags what tools return, and destructive actions and downloads need your explicit approval and are denied if nobody answers in time. A guardrail model stays loaded, and a config’s gateway policy can use it to screen model inputs for injection and outputs for groundedness. Operators can relax this: OPENENG_MCP_AUTO_ALLOW pre-approves the MCP tools it names, and OPENENG_FLOOR_MODE=off or observe turns the approval floor off.
  • Every tool call passes the floor
  • Destructive actions → ask
  • Downloads → ask

Kernel sandboxing where the host has it

Where bubblewrap works on the host, shell commands the agent runs execute inside it, with a read-only root filesystem, writes only in the workspace, and the network off where the host can isolate it. Without it, they run unconfined — set OPENENG_SANDBOX=workspace-write to refuse them instead, or OPENENG_SANDBOX=off to opt out. The model daemon runs in an enclosure: a systemd resource cap where a user systemd session works, and a read-only root where bubblewrap works. Confinement is enforced by the operating system, not by a prompt; per-worker isolation is the next hardening milestone.
  • Kernel-enforced where bubblewrap works
  • Read-only root · network off where isolatable
  • OPENENG_SANDBOX to require or opt out

Private by construction

No network port. Sealed replies.

The engine opens no network port — it dials out to the OpenEng Broker, so there's nothing on your network to connect to. Every hop is encrypted: your requests travel sealed to the broker, which opens them only to route them to your engine, and the engine's streamed replies are sealed end-to-end to your browser. The engine data the Web Console loads, such as thread history and memory, is sealed to the broker, which opens it to deliver it.

  • No network port

    The engine opens no network port — it dials out to the OpenEng Broker, so nothing on your network or a web page can connect to it. Its model daemon uses a local Unix socket, and runtime servers and Ollama, if you use them, listen on 127.0.0.1.

  • Sealed replies

    The engine’s streamed replies are sealed end-to-end to your browser — the broker that relays them cannot read them. Requests, and the engine data the Web Console loads, travel sealed to the broker, which opens them to route them.

  • What never crosses

    Model weights, embeddings, the engine’s stored provider keys, and your OpenEng key never cross the wire. What crosses is what you exchange in the Web Console — your requests, the engine’s replies, and the data it shows you — encrypted on every hop.

  • No engine telemetry

    The engine sends no analytics about your prompts, code, or files, and nothing is kept for training. Its per-turn metrics are local trace events on your machine.

Get the engine

Install once. Start it with your key.

One line installs the engine on Linux x86_64. It starts with your OpenEng key, registers with the OpenEng API — which requires an active Pro plan — and dials the Broker, and the Web Console finds it from there.

step 1 · install

Install

Downloads the openeng binary, checks its SHA-256 when a sha256 tool is available, puts it on your PATH, and pulls the default chat model (skip that with OPENENG_NO_MODELS=1).

step 2 · start

Start with your key

Create an OpenEng key — an API key — in the Console, then run openeng serve --key=<your-key>, or put the key in OPENENG_KEY instead of the flag. With no key, the engine refuses to start.

step 3 · connect

Connect

Sign in to the Web Console, pick your engine and a published config, and it warms up the models. It reaches your engine through the OpenEng Broker — no host or port to paste.

Linux x86_64 · Windows via WSL

There is no native Windows or macOS build of the AI engine yet; on Windows, run the Linux engine under WSL. Pro, Enterprise, and pay-as-you-go are launching Q4 2026 and can’t be purchased yet.

The openeng commands

openeng [serve]
Boot the engine and dial the Broker (the default).
openeng pull <role>
Fetch an embedded model weight (chat, coding, planner, …).
openeng headless
Check your key and print the headless driver it would run; the work-pull and scheduler loops ship later.
openeng daemon
Run the enclosed model daemon (spawned by the engine).
serve --config=a,b,c
Preload these configs and download their models.
serve --default=<config-id>
The default config (by id) for requests that omit one.
serve --key=<K>
Your OpenEng key, or set OPENENG_KEY. Required — the key is registered with the OpenEng API (Pro required) and never sent to the broker.
See the full security model Every engine and platform

Questions

The engine, answered.

Models are described along three decoupled axes: a registry (Hugging Face, Ollama library, ModelScope, direct URL) says where the weights come from, a weight format (GGUF, Safetensors, GPTQ / AWQ, EXL2 / EXL3, MLX, ONNX, TensorRT) says what they are, and a runtime (llama.cpp, ONNX Runtime, vLLM, SGLang, ExLlama, MLX, TensorRT-LLM, Transformers, Ollama) says how they execute — the format determines which runtimes can run it. The built-in models run in-process on llama.cpp inside the engine’s enclosed model daemon, never directly in the engine process: it is resource-capped with a systemd scope where a user systemd session works, and given a read-only root where bubblewrap works. Release builds refuse local inference on a host that has neither. The models catalog’s open-weight models are Ollama-library tags: the engine pulls and runs them through a local Ollama daemon that you install and run, so they run inside Ollama rather than in the engine’s sandbox. vLLM, SGLang, ExLlama, TensorRT-LLM, and Transformers are used only when their own toolchain is installed on the machine, and the engine starts them in a resource-capped systemd scope; MLX needs macOS, and there is no macOS build of the AI engine yet. Hosted and cloud models are reached through one gateway, routed out through the sandbox wherever the host provides one (bubblewrap or a user systemd session). You combine several models as a role group so each job runs on a right-sized model.

Your AI team, running on your own machine.

Install the engine, start it with your OpenEng key, and drive it from your browser. Your models and provider keys stay on your machine, and your files are read there.

Install the engine · Linux x86_64

Open the Web Console Read the docs