Any registry
Hugging Face, the Ollama library, ModelScope, or a direct URL — resumable, checksum-verified downloads, cached with LRU eviction.
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.
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 | Sandboxed local execution on your machine |
| Hosted models | Your provider account or OpenAI-compatible API | Through one gateway, out via the same sandbox |
The matrix, enforced
Format determines runtime: the engine refuses an impossible format-runtime pairing instead of silently degrading.
Sandboxed, local
Local models run isolated in a sandbox on your machine — never on your bare host. 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 default model for that role — planner, executor, chat, or coding.
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 ~1.3 GB to a 70B, auto-matched to your hardware — zero API keys. 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 your data.
Because the models run locally, inference, embeddings, planning, review, and every file tool run on-device with no network call. The browser Web Console is a thin client that never receives a model, a memory, or a secret; the channel to your engine is encrypted end-to-end past a blind broker.
- No 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, never centrally.
- A hosted provider is an explicit per-role choice — never a silent default.
Browser
encrypted wire
EngineCrosses the wire
- Your prompt
- Rendered output (tokens)
No field for it to travel through
- Persona
- Memory
- Embeddings
- Secrets
- API keys
- Your code
Encrypted end-to-end — the broker relays only ciphertexton 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.ai
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.
/loopPick the agent-loop strategy the engine runs.
/skillInvoke a named skill — a packaged playbook the engine runs on demand.
/roleTarget a specific model role for the next 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, shared across the Web Console and other surfaces — one account, one timeline.
Pillar 4 · Config-driven
Author once. Identical 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 machine you sign into.
Author
console.openeng.ai
Define models, agents, execution flow, schedulers, and templates in the Console. Publish a version when it’s ready.
Publish
api.openeng.ai
Only published versions are served. Per-user isolated, cached per account with revalidation.
Run
run id@version
Any machine you sign into resolves the config by id@version and runs the exact same setup — byte-identical, no drift.
- 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 your engine will run 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 model runtimes, and the memory system. Models update independently of the binary.
Same engine, headless
The same engine runs unattended on servers — cron-validated jobs, authenticated by an API key — so a long-horizon run doesn't need a human at the keyboard.
Pillar 6 · Self-update
Always current, never half-updated
At boot the engine checks the release service, verifies the new binary’s checksum, swaps it atomically, and re-execs. A failed download or a bad checksum changes nothing — the running binary is untouched until the new one is proven.
Checksum-verified
A mismatch is refused, full stop — a tampered or truncated binary never runs.
Atomic swap + re-exec
The swap is atomic and re-execs at boot — there is no half-updated in-between state.
One feed, everywhere
The same service feeds the install script and the releases page, so every machine converges to the same proven build.
Run an open-weight model in one command.
Install on Linux x86_64, sign in once, and drive it from your browser. The models download to your machine and stay there.
Linux x86_64 · checksum-verified
curl -fsSL https://openeng.ai/engine/install.sh | bashQuestions? 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.