Local-first AI workflow runtime

AI workflows you can run, review, and own.

Package repeatable engineering work into versioned Chains, wire in the models and tools you choose, and run them from the CLI, your editor, or any ACP client — with every risky step gated behind an approval you control. No hosted Contenox service required.

Run a recipe Package a workflow View on GitHub

$ curl -fsSL https://contenox.com/install.sh | sh

Installs contenox. Run contenox init to scaffold a workspace.

Live from Beam, the bundled local web UI: the agent’s file edit stops at the approval gate with a diff of the exact change, gets approved on the spot, then the workspace tree flips to agent view — every file marked allowed, needs approval, blocked, or unreachable. contenox serve opens the same sessions, chains, and backends in the browser.

Read the Beam guide →

The bundled web UI

See the work. Approve the diff.

contenox serve opens the whole runtime in your browser — the same sessions, chains, and policies as the CLI, served locally and never hosted. Beam is where you watch what the agent is about to do, before it does it.

Approve the diff, not the vibe

Every gated write or command pauses at the approval gate. File edits render as a diff of the exact change — allow (Y) or reject (N). Nothing runs until you say so.

See what the agent may touch

Flip the workspace tree to agent view and every file carries its policy verdict — allowed, needs approval, blocked, or unreachable — computed from the same policy the live agent obeys.

One runtime, in the browser

Sessions started in Beam are the sessions the CLI lists. Files and a workspace terminal open as tabs; tool calls and errors persist as cards across reloads.

Bring your own agent

Register any ACP agent with contenox agent add and drive it from the same sidebar — its turns stream into Beam, gated by the same approval cards, each session labelled with the agent that ran it.

Read the Beam guide →

Core capabilities

The Chain is the contract

Prompts, model routing, tool allowlists, command policy, budgets, and approval gates are visible keys in a versioned file — reviewable, diffable, repeatable.

Runs where work happens

One runtime behind the CLI, the VS Code extension, and any ACP editor. Same chains, same sessions, same policy everywhere.

Providers are config

Route inference to local modeld, Ollama, vLLM, OpenAI, Anthropic, Mistral, Gemini, OpenRouter, Bedrock, or Vertex — without touching the workflow.

Local by default

Sessions, config, run logs, and state live in SQLite on your machine. No hosted Contenox service, no account — telemetry is opt-in and off by default.

Terminal demo: a destructive rm command stops at a human approval gate before it runs

Contenox is not just a chatbot, not just a VS Code extension, and not just an agent framework. It is a local-first workflow runtime for specific, reviewable AI work.

Nearby world	Why Contenox is different
Cursor / IDE copilots	Runtime-first, not editor-first. The same engine works from the terminal, VS Code, and ACP clients.
Aider / CLI coding agents	Broader workflow, session, tool policy, and provider scope than a single coding loop.
LangChain / agent frameworks	End-user executable product, not just a library you wire into an application.
Dify / n8n / web AI workflow tools	Local desktop/workspace-first, not web-app or SaaS-first.
Ollama wrappers	Provider-neutral and workflow/tool/HITL-oriented, with local and hosted models.

What you can author

Repeatable work, with policy in the file.

→Release evidence pack: feed in git history, PRs, ticket notes, and CI output; the chain drafts the changelog, risk notes, and deployment checklist, then stops before publishing.
→API-to-workflow wrapper: register a narrow OpenAPI subset, inject hidden workspace or environment arguments, and require approval for mutating calls.
→Repo maintenance chain: inspect an issue, plan the patch, touch only approved files, run tests, and prepare a review packet instead of silently changing the project.
→Browser QA evidence: Playwright captures the live app state, the chain writes documentation or screenshots, and the policy decides what needs human approval.

Run it where work happens

The same chain can run in your editor, terminal, or automation.

Contenox ships a native VS Code extension, and speaks the Agent Client Protocol over stdio for other editors. Use VS Code, Zed, JetBrains, or AionUi when an editor UI helps; keep the workflow itself in the chain file, with tool calls and HITL approvals routed through the client.

// ~/.config/zed/settings.json
{
  "agent_servers": {
    "Contenox": {
      "type": "custom",
      "command": "contenox",
      "args": ["acp"]
    }
  }
}

Get the VS Code extension →Read the VS Code guide →Read the Zed guide →Read the JetBrains guide →Read the AionUi guide →

Built on open standards

llama.cpp GGUF inference · CPU/CUDA/HIP/Metal OpenVINO inference runtime · CPU/iGPU OpenVINO GenAI LLM pipeline Go the pure-Go runtime SQLite local state

Local inference links these upstream projects at build time; their runtime libraries and license texts ship inside each release package. Hosted providers connect over their public APIs.

Get started

Own your AI workflows in the next five minutes.