Any registry
Hugging Face, the Ollama library, ModelScope, or a direct URL — resumable, checksum-verified downloads, cached with LRU eviction.
OpenEng AI · features
Open-weight model execution, done right
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.
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.
These are OpenEng AI’s features. Looking for the engineering apps? Terminal, Kubernetes, Data, Git, and Chat are free: see the apps.
Pillar 1 · Open-weight model execution
Three axes. Combine models per config.
A model is three independent choices — registry, weight format, runtime — and the format determines which runtimes can run it. You combine several models in one config as a role group, so each job runs on a right-sized model. A small model answers instantly; a coding model edits files; a bigger one plans.
| Axis | The choices | What it means |
|---|---|---|
| Registry — where | Hugging Face · Ollama library · ModelScope · direct URL | The source the weights are pulled from |
| Format — what | GGUF · Safetensors · GPTQ / AWQ · EXL2 / EXL3 · MLX · ONNX · TensorRT | Determines which runtimes can run it |
| Runtime — how | llama.cpp · ONNX Runtime · vLLM · SGLang · ExLlama · MLX · TensorRT-LLM · Transformers · Ollama | On your machine: built-ins in the enclosed model daemon, Ollama via your daemon, servers once installed |
| Hosted models | Your provider account or OpenAI-compatible API | Through one gateway, via the sandbox where the host has one |
The matrix, enforced
Format determines runtime: the engine refuses an impossible format-runtime pairing instead of silently degrading.
Enclosed, local
Built-in models run only inside the engine’s enclosed model daemon — resource-capped, with a read-only root where bubblewrap works — and catalog models run in your local Ollama. Hosted models leave through one gateway.
How a role resolves — first match wins
Plan-node override
A model pinned on a specific plan node — a delegator can run its sub-plan on a different model than its parent.
Agent-level binding
The active agent's own model binding from its Console-published configuration.
Config role default
The loaded config's model for that role — any of the eleven, such as the planner, the agent, or the reviewer.
Built-in default
The default group of compact open-weight models the engine ships to map every role.
28 on-device open-weight models are available from the Ollama library, from about 1 GB up to Llama 3.3 70B, run through a local Ollama daemon you install. Before any download, the engine checks your RAM, free disk, and GPU first and refuses a model it can tell your machine can’t run — and none of them needs a provider API key. Also works with your provider accounts — Claude, ChatGPT, Gemini, DeepSeek, or OpenRouter — routed through the same gateway.
Pillar 2 · Private & local
The models run on your machine. So does the work.
With local models, inference, embeddings, planning, review, and every file tool run on-device with no network call to a model provider. The browser Web Console is a thin client that holds no model, and a vault value you type is never read back by a browser; the channel to your engine is encrypted on every hop, with the engine's streamed replies sealed end-to-end past the broker, which keeps what it routes for 7 days by default.
- No engine telemetry — no analytics SDK, no usage beacon, no crash phone-home in the engine.
- Your threads and memory live in plain files under your OpenEng home directory — read them, delete them, own them.
- Secrets are ${ENV} references in configs; the real values resolve from your local environment at run time, or from an optional write-only vault if you choose — the environment always wins.
- Every role, the planner included, falls back to a built-in local model. For the planner, the Console offers the included Cloud Planner (Gemini on Vertex AI, paid from planning credit) as its “Use default” option; it is used only when a config binds it, and then planning prompts go through our API. Any other hosted model is an explicit per-role choice.
Browser
via the broker
EngineCrosses the wire, encrypted
- Your promptsopened by the broker to route them
- Streamed repliessealed end-to-end
- Thread history, memory, configopened by the broker to deliver them
Never crosses
- Model weights
- Embeddings
- Stored provider keys
- Your OpenEng key
- Requests travel sealed to the broker, which opens them only to route them to your engine.
- Streamed replies are sealed end-to-end — the broker can’t read them.
- Engine data the console loads is sealed to the broker, which opens it to deliver it and keeps it 7 days by default.
- Every hop is encrypted; the work itself runs on your machine.
Pillar 3 · The Web Console
No modes. Just chat — with slash commands.
You work in one streaming chat in the browser. There are no 'modes' to pick: the engine scores each request’s complexity and self-routes plan-vs-execute. Slash commands run inside the chat when you want to steer it.
app.openeng.app
Migrate the users table to Postgres and update the data layer.
Planning · 4 steps
- Map the current schema
- Write the migration
- Update the data-access layer
- Update tests + docs
Ask anything…complexity 84% · planned
/templateApply a prompt template above your persona for this turn.
/agentSwitch the active agent — an orchestrator or a single-purpose worker.
/loopList, start, stop, or check a global loop — or add a loop to this message as prompt guidance.
/skillInvoke a named skill — a packaged playbook the engine runs on demand.
/roleApply a behavioral role — a rule set from the roles catalog — to this message.
Complexity-routed
Simple asks answer instantly; complex ones get a real multi-step plan. You never pick a mode.
Engine-owned threads
Threads live in your engine, not the browser, so that engine’s history follows you to any browser you sign in from.
Pillar 4 · Config-driven
Author once. The same version everywhere.
Configuration is authored in the Console and consumed read-only by the engine. A published config is a versioned artifact: models, agents, execution flow, schedulers, templates, cells, MCP servers — resolved by id@version on any engine started with your key. The engine doesn’t yet connect a config’s MCP servers (it uses your .mcp.json) or fire its schedulers.
Author
console.openeng.app
Define models, agents, execution flow, schedulers, and templates in the Console. Publish a version when it’s ready.
Publish
api.openeng.app
Only published versions are served. Per-user isolated, cached per account with revalidation. (These API routes aren’t deployed yet.)
Run
run id@version
Any engine started with your OpenEng key resolves the config by id@version and gets the same versioned config on every machine; each machine’s .mcp.json still supplies the MCP servers it connects.
- Cached per account with revalidation — offline-tolerant within the cache window, cheap to refresh past it
- Per-user isolated: a config is only visible to its owner unless explicitly shared
- Config-scoped views: agents, cells, MCP servers, and models list only what the loaded config defines
- Secrets enter as ${ENV} references; the engine resolves them from your session environment at startup
Immutable, versioned
Publish-once with strictly-higher SemVer. A published id@version always resolves to exactly the same bytes — see precisely what a config resolves to before you ship it.
Pillar 5 · Long-horizon
Runs that survive crashes, sleep, and you
Goal runs are built to span minutes to a month. Plan state and per-iteration checkpoints persist on disk, threads resume on load, and episodic memory compresses as it grows so the context never overflows.
checkpointed
Close the laptop mid-run
Every iteration writes a checkpoint. Crash, sleep, or reboot — load the thread and the run picks up from the last checkpoint, plan intact.
compressed memory
Memory that scales with time
When live history grows past a threshold it compresses into an episode block and the rolling summary regenerates — months of context in a bounded prompt.
One binary to keep current
A single Rust engine holds the agent loop, the built-in llama.cpp and ONNX runtimes, and the memory system; catalog models run in a local Ollama you install. Models update independently of the binary.
Pro & Enterprise · roadmap
Same engine, headless
Once the engine’s scheduler ships, the same engine is designed to run unattended on servers with Pro — cron-validated jobs, authenticated by an API key — so a long-horizon run doesn't need a human at the keyboard. Today openeng headless checks its key, prints the driver it would run, and exits.
Pillar 6 · Self-update
Always current, never half-updated
The engine ships a self-updater: while it runs, it checks the release service, downloads the new binary, and verifies its SHA-256 before staging it; the swap happens atomically at the next start. A failed download or a bad checksum changes nothing — the running binary is untouched until the new one checks out. The AI engine's release feed opens at launch.
Checksum-verified
A download that doesn't match its published SHA-256 is refused, so a corrupted or altered-in-transit binary never runs. The checksum comes from the same release service, so it can't catch a compromised release source.
Atomic swap at start
The staged binary replaces the old one with a single atomic rename at the next start — there is no half-updated in-between state.
One source of truth
Installers and updates fetch the same published binaries from openeng.app, each with a SHA-256 checksum beside it. The app engines’ version history is on the releases page.
Install the AI engine in one line.
Install the AI engine on Linux x86_64, start it with your Console API key on Pro (launching Q4 2026), and drive it from your browser. The models download to your machine and stay there.
AI engine · Linux x86_64 · SHA-256 checked when available · needs Pro
Questions? The FAQ answers what open-weight means, how the registry, format, and runtime axes fit together, and how OpenEng compares to cloud AI tools. Or email us.