Direct questions, direct answers

OpenEng is one engineering platform with two pillars: five free developer apps — Terminal, Kubernetes, Data, Git, and Chat — that run in your browser on an engine on your own machine (the Git and Chat engines are coming soon), and OpenEng AI, an agentic ecosystem for open-weight model execution.

OpenEng is a suite of five professional developer apps — Terminal, Kubernetes, Data, Git, and Chat — that run in your web browser but execute on a small native engine you run on your own machine. The browser is a thin UI — the real work happens locally on your hardware — and every app and every feature is free.

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. A local engine runs the models (the built-in ones in its enclosed model daemon, catalog models through your local Ollama) and holds the agent loop, your threads, and your provider keys; you drive it from the browser Web Console and configure it in the Console. The AI engine starts with an OpenEng key and needs a Pro plan, which launches in Q4 2026.

No, OpenEng is not open source. The engineering apps are free to use and keep your work on your machine, but the source code is not publicly available. The AI models OpenEng runs are open-weight: their weights are published for anyone to download.

OpenEng Terminal (terminal.openeng.app): The terminal that thinks in blocks.

OpenEng Kubernetes (k8s.openeng.app): A full Kubernetes console, one pane of glass.

OpenEng Data (data.openeng.app): Every database, one query workbench.

OpenEng Git (git.openeng.app): A desktop-grade Git client in your browser.

OpenEng Chat (chat.openeng.app): A coding agent that runs on your machine.

All five are free and open in your browser. The Terminal, Kubernetes, and Data engines are published today; the Git and Chat engines are coming soon.

Each app’s engine runs on your own machine and listens only on loopback, 127.0.0.1 — Terminal 50052, Kubernetes 50054, Data 50057, Git 50053, and Chat 50056. The browser reaches it at engine.openeng.app, a public name that resolves to 127.0.0.1, so the connection never leaves your computer. After the key-exchange handshake, the web app seals every frame of its session end to end (X25519 key agreement, HKDF, and ChaCha20-Poly1305). The apps use no relay: nothing between the browser tab and the engine can read your terminal, cluster, repository, or database traffic. The engine doesn’t yet reject unsealed frames, though, and any process on your machine can obtain its handshake token, so the engines can’t defend against other local programs.

Not yet. The Git and Chat web apps are live at git.openeng.app and chat.openeng.app, but their engines have not been published — the Git and Chat engines are coming soon, so there is no installer to run for them yet. The Terminal, Kubernetes, and Data engines are published now; the download page lists every engine as it ships.

Open-weight means the model’s trained weights are published for download, so you can run the model yourself — which is exactly what OpenEng does, on your own hardware. “Open source” in the strict sense (the OSI Open Source AI Definition) is a higher bar that also covers training data and process. Most downloadable models people call “open source” are, precisely, open-weight. OpenEng uses “open-weight” for accuracy and treats “open-source models” as the common synonym. Note: the models are open-weight; the OpenEng platform itself is not open source.

A model is described along three decoupled axes: the registry it comes from (Hugging Face, Ollama library, ModelScope, direct URL), the weight format it is in (GGUF, Safetensors, GPTQ / AWQ, EXL2 / EXL3, MLX, ONNX, TensorRT), and the runtime it executes on (llama.cpp, ONNX Runtime, vLLM, SGLang, ExLlama, MLX, TensorRT-LLM, Transformers, Ollama) — the format determines which runtimes can run it. You can combine several open-weight models in one config as a role group — a small model for chat, a coding model for edits, another for planning — so each job runs on the right-sized model. The on-device catalog has 28 open-weight models to pick from, from about 1 GB up to Llama 3.3 70B; they are Ollama-library models that run through a local Ollama daemon you install.

They are three independent choices. The registry (Hugging Face, Ollama library, ModelScope, direct URL) is where the weights come from. The weight format (GGUF, Safetensors, GPTQ / AWQ, EXL2 / EXL3, MLX, ONNX, TensorRT) is what the weights are. The runtime (llama.cpp, ONNX Runtime, vLLM, SGLang, ExLlama, MLX, TensorRT-LLM, Transformers, Ollama) is how they execute. The format determines which runtimes can run a model — GGUF runs on llama.cpp or Ollama, ONNX runs on ONNX Runtime, Safetensors runs on vLLM, SGLang, TensorRT-LLM, Transformers, or MLX, and so on. The engine enforces that compatibility matrix — it refuses an impossible pairing instead of silently degrading. 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).

Yes — the Ollama library is one of the registries the engine pulls from, and Ollama is one of the runtimes you can select per role. Ollama models run through a local Ollama daemon that you install and run yourself (by default at 127.0.0.1:11434). Point a role at a model in your local Ollama library and OpenEng drives it through the same role system as every other model; if you author an Ollama model with a public tag, the engine pulls it into your Ollama at provisioning. The model runs inside Ollama, not in the engine’s sandbox, and Ollama manages its own GPU use. Every model in the models catalog is an Ollama-library tag, so the catalog needs Ollama installed.

Yes. The engine fetches open-weight model weights from the Hugging Face Hub — resumable, checksum-verified, and cached with LRU eviction — then runs them on your machine, on a runtime the weight format supports: GGUF on the built-in llama.cpp, inside the engine’s enclosed model daemon, and other formats on a runtime server once its toolchain is installed. Point a config at a public repo and file and the engine provisions and warms it up. ModelScope and direct URLs work the same way.

Yes. ONNX models execute on ONNX Runtime, locally on your CPU (GPU execution providers follow), inside the engine’s enclosed model daemon like the other built-in runtimes. Standard Optimum / onnx-community export layouts are supported; the engine downloads model.onnx, the tokenizer, and config from a Hub repo and decodes locally. TensorFlow models are supported via ONNX export.

Yes, as a secondary option. Point any role at a hosted model — your own OpenAI-compatible API, or a hosted provider account. Every hosted and cloud call goes through one model gateway — routed out through the sandbox wherever the host provides one (bubblewrap or a user systemd session) — so model egress has a single auditable choke point. Every role, the planner included, falls back to a built-in open-weight model on your machine. For the planner, the Console offers the included Cloud Planner (Gemini on Vertex AI, paid from Pro’s 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 something you opt into per role.

Before a download, the engine checks the machine’s RAM, free disk, and GPU presence and refuses a model it can tell the machine can’t run. It runs under a resource budget — by default 10% of the machine’s cores and memory, shared by the whole agent tree, and tunable per config. Open ten sessions and the on-device models load once and are shared. GPU acceleration for llama.cpp models is a build option of the engine (CUDA, Metal, or Vulkan).

No. The engine needs the network to start — it registers your OpenEng key with the OpenEng API, which checks your plan — and to receive your requests, which reach it only through the OpenEng Broker (the engine opens no port). Once it is running, local inference itself makes no network call: with local models bound to each role (the planner’s default option, the included Cloud Planner, is a hosted call through our API), inference, planning, coding, review, embeddings, and memory run on your machine once the models are on disk. The network is also used for fetching your published configs (cached for short offline stretches), polling approval requests about once a second, downloading new models, and the self-update check — plus any research fetches, cells, MCP servers, or hosted models you use.

For an engineering app, install the small native engine for that app with a one-line script — for example curl -fsSL https://openeng.app/engine/terminal/install.sh | bash — then open the app in your browser and sign in once. The app shows you a one-time command to start the engine (openeng-terminal serve --oauth=<key>, carrying a one-time key tied to your sign-in); copy it, run it, and the page connects automatically. Engines are published for Terminal, Kubernetes, and Data; the Git and Chat engines are coming soon.

For OpenEng AI, install the AI engine on Linux x86_64 with curl -fsSL https://openeng.app/engine/install.sh | bash, then start it with an OpenEng key from the Console; the engine needs a Pro plan, which launches in Q4 2026. Every installer, binary, and checksum is listed at openeng.app/download.

Run: curl -fsSL https://openeng.app/engine/install.sh | bash — it downloads the prebuilt Linux x86_64 binary, checks it against its published SHA-256 when a sha256 tool is available (refusing a mismatch), and puts openeng on your PATH. It then pulls a default open-weight chat model (a few GB); set OPENENG_NO_MODELS=1 to skip that and let each config pull what it needs. Start the engine with an OpenEng key — an API key you generate in the Console — as openeng serve --key=<K> or through the OPENENG_KEY environment variable. The engine registers the key with the OpenEng API, which requires an active Pro plan (launching Q4 2026). You can also download the raw binary and checksum from openeng.app/download and verify manually. On Windows, run it under WSL.

The apps, the Web Console, and the Console open in any modern browser. The engines run natively on your own machine:

OpenEng AI engine: Linux x86_64 · Windows via WSL.

Terminal engine: Linux x86_64 · macOS (Apple silicon, Intel) · Windows via WSL.

Kubernetes engine: Linux x86_64 and ARM64 · macOS (Apple silicon, Intel) · Windows via WSL.

Data engine: Linux x86_64 · macOS (Apple silicon, Intel) · Windows via WSL.

Git engine: coming soon — not published yet.

Chat engine: coming soon — not published yet.

macOS builds are available for Terminal, Kubernetes, and Data; they are older builds pending a rebuild. There is no native Windows build of any engine yet — on Windows, run the Linux engine under WSL.

Yes — one OpenEng account, signed in with Google, works across the five apps, the Web Console, the Console, and account & billing. In an engineering app you sign in once to pair your browser with your local engine: the app mints a one-time key and shows the command that starts the engine with it. The OpenEng AI engine authenticates differently — with an OpenEng key (an API key from the Console) passed as --key=<K> or OPENENG_KEY; once the engine’s scheduler ships, headless servers will use the same kind of key. The account carries your plan and your Console-published configs. Your actual work — code, threads, memory, and the models themselves — is stored on your machine and is not synced to our servers; the Broker holds only what it routes for the Web Console, for 7 days by default.

Not in the five apps: your code, repositories, clusters, terminal output, and databases are never sent to OpenEng. Each engine runs locally, listens only on 127.0.0.1, and the web app seals every frame of its session with the engine. What you point an app at yourself — your SSH hosts, clusters, forges, MCP servers, connectors, or an external model server for Chat — receives what you send it.

In OpenEng AI, your files are read and processed on your machine, but anything that appears in a conversation — your prompts and the engine’s replies, which can quote your code — passes through the OpenEng Broker, which can read the prompts and the thread history and keeps it for 7 days by default, and a hosted model you choose receives what you send it. Local models run on your machine — the built-in models in the engine’s enclosed model daemon, catalog models in your local Ollama — and a hosted model is used only for a role you point at one (the Console’s default planner option, the included Cloud Planner, is one). 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. What you type there travels encrypted to the OpenEng Broker, which opens each request to route it to your engine. The engine’s streamed replies are sealed end to end, so the Broker cannot read them. The engine data the Web Console loads — your thread list and history (past prompts and answers, which can quote your code), learned memory, the running config, placeholder names, and loop, warm-up, and device status — is sealed to the Broker, which opens it to deliver it. The Broker keeps everything it routes for a retention window (7 days by default), then deletes it.

Not from the engines. No OpenEng engine — the five app engines or the AI engine — contains an analytics SDK, a usage beacon, or a crash phone-home. Engines do contact OpenEng to sign in or register and to check for updates, and the AI engine also fetches your configs and polls for approval requests. Server-side we hold your account and plan, what you save in the Console (configs, attachments, vault values, and API key hashes), approval requests, feedback, and what the Broker routes, kept for 7 days by default — the Privacy Policy lists it all. This website, openeng.app, uses Google Analytics for Firebase to measure page visits, as described in our Privacy Policy.

On your disk, under your OpenEng home directory (~/.openeng, or wherever OPENENG_HOME points). The AI engine keeps its threads, transcripts, memory, models, and usage ledger there, and each app engine keeps its own state in a subfolder (for example ~/.openeng/terminal). Provider API keys are encrypted at rest (AES-256-GCM) with a key file only your user can read. Delete the directory and the engine’s local copy is gone; anything the Broker routed for the Web Console is deleted when its 7-day retention window ends. What does live on our servers is listed in the Privacy Policy: your account and plan, your Console configs and attachments, any vault values you choose to save, API key hashes, approval requests, and what the Broker routes for the Web Console — your requests, the engine’s replies, and the engine data the console loads, such as thread history and memory (kept for 7 days by default, then deleted).

Configs never contain secret values — they reference ${ENV} placeholder names, and the engine resolves the real values from your local environment at run time; the Console rejects a raw secret. A breach of the configs yields names, not values. If you prefer, the Web Console can save a value to an optional per-config vault instead: it is encrypted at rest, never readable back into a browser, and released only to an engine presenting your API key, and an environment variable on the engine machine always wins. OpenEng keys (Console API keys) are shown once at creation, stored only as a hash, checked when the engine registers, fetches configs, and checks for updates, and revocable in the Console; they last a year by default, so keep yours in OPENENG_KEY rather than on the command line. Provider keys you give the engine are encrypted at rest on your machine.

The engineering apps are. Terminal, Kubernetes, Data, Git, and Chat are free to use — every app and every feature, with no tiers, subscriptions, or paywalls.

OpenEng AI is different: the AI engine starts only with an OpenEng key and an active Pro plan, and Pro — like Enterprise and pay-as-you-go credit — launches in Q4 2026, so it cannot be bought yet. The public catalogs of models, agents, skills, templates, and more are open to everyone.

Pro, Enterprise, and pay-as-you-go all launch in Q4 2026, and Pro and Enterprise prices are announced at launch. Trial terms are announced at launch. Pro is a flat monthly subscription; it unlocks the AI engine, API keys, and human-in-the-loop approval gates, plus scheduler, headless, and sandbox slots that do work once the engine’s scheduler and sandbox nodes ship. Enterprise sizes a fleet to you; for on-prem, talk to us — no on-prem edition is announced yet. Pay-as-you-go tops up the planning credit that pays for the included Cloud Planner (Gemini through our API) on a Pro or Enterprise account, from $5; credit expires, and the Console shows each grant’s expiry. A hosted model on your own provider account is billed by that provider. The engineering apps stay free.

Not yet. That is the AI engine’s headless mode (openeng headless), and once its scheduler ships it is designed to run cron-validated jobs with no terminal and no browser, authenticated by an OpenEng key, logging to an append-only file — and to refuse to start, with an explicit reason, unless the config allows headless, every model role resolves, and at least one scheduler exists. The published engine accepts the command, checks its key, prints the driver it would run, and exits: the work-pull and scheduler loops are not in the published engine yet.

One published config resolves by id@version to the same versioned config on every machine that runs it; the MCP servers an engine connects still come from that machine’s .mcp.json. Each AI engine starts with its own OpenEng key, and the API provisions one engine session per key, so you issue a key per machine in the Console, where you can also rebind or revoke it. Pro binds its one key to your active machine; Enterprise runs many keys on many machines, in a fleet you size yourself.

The AI engine ships a self-updater: it checks the release service, verifies the new binary’s SHA-256, stages it, and applies it as an atomic swap on the next launch. A download that doesn’t match its published SHA-256 is refused, so a corrupted or altered-in-transit binary never runs, and the running binary stays untouched until the new one checks out. The checksum comes from the same release service, so it does not protect against a compromised release source. The AI engine’s release feed opens at launch; the app engines already check the release service for updates when they start and every 30 minutes while they run.

Most AI tools are clients for a cloud model API: every prompt and file they read transits a provider, and you pay per token. OpenEng inverts that. It downloads open-weight models from any registry and runs them on your own machine, with no usage telemetry; a hosted provider is an explicit per-role choice routed through one gateway rather than the foundation. Pro is a flat subscription (launching Q4 2026) instead of metered tokens.

No — you work in chat, in the Web Console. Slash commands run inside the chat itself: /template applies a prompt template, /agent switches the active agent, /loop lists, starts, stops, or checks a global loop (or adds a loop to one message as prompt guidance), /skill invokes a named skill, and /role applies a behavioral role (from the roles catalog) to the message. There are no “modes” to pick; the engine scores each request’s complexity and self-routes plan-vs-execute.