OMK//CONTROL — provider-neutral multi-agent control plane for coding workflows.
Models execute. OMK routes, verifies, measures, and controls.
New issues and PRs from new contributors are auto-closed by default. Maintainers review auto-closed issues daily. See CONTRIBUTING.md.
npm install -g open-multi-agent-kit --ignore-scriptsThen run it:
omk --version
omkOr without a global install:
npx --ignore-scripts open-multi-agent-kitLibrary packages:
npm install omk-agent-core # Agent runtime with tool calling and state management
npm install omk-ai # Unified multi-provider LLM API
npm install omk-tui # Terminal UI library with differential renderingThis is the home of the omk agent harness project including our self extensible coding agent.
- open-multi-agent-kit: Interactive coding agent CLI
- omk-agent-core: Agent runtime with tool calling and state management
- omk-ai: Unified multi-provider LLM API (OpenAI, Anthropic, Google, …)
To learn more about omk:
- Project demos from Mario
- Browse all public Skills
- Read the documentation, but you can also ask the agent to explain itself
The OMK//CONTROL startup surface is the default operator view. The header reads omk v<package.version> · OMK//CONTROL, using the installed workspace package version as its source of truth.
The default dark TUI theme uses the omk-control-grid-dark Night City palette and keeps the control sidebar focused on route, evidence, loop, MCP, runtime, skills, and context budget state.
OMK is not another model shell. It is the control plane around the models you already use: provider routing, scoped tools and MCP, evidence gates, parallel execution, and an operator-visible terminal surface.
Official skill distribution uses OMK packages. Build a package once, install it through omk, pin it, scope it to a project when needed, and enable or disable its resources from the same control plane. This README intentionally does not send users through a separate skills launcher.
# Global, pinned OMK package
omk install npm:open-multi-agent-kit@0.90.9
# Project-local, pinned Git package
omk install -l git:github.com/dmae97/open-multi-agent-kit@v0.90.9
# Inspect and control the installed resources
omk list
omk config
omk update --extensionsA skills-only package is an ordinary OMK package:
{
"name": "omk-workflows",
"keywords": ["omk-package"],
"omk": {
"skills": ["./skills"]
}
}| Need | OMK route | Output |
|---|---|---|
| Shape a capability | !omk plan a bounded goal |
Constraints, owned paths, and acceptance predicates |
| Run a bounded workflow | !omk-loop <goal> |
Evidence-gated implementation, recovery, and a terminal status |
| Route marketing work | !skill:omk-marketing <objective> |
One primary marketing skill plus at most one prerequisite support skill |
| Extend the harness | omk install <pinned-package> |
Versioned extensions, skills, prompts, and themes under OMK control |
Use the minimum necessary skills per turn—usually one to three. A skill is loaded when it earns its place in the task, not because it happens to be installed.
- Control, not lock-in. Keep providers interchangeable while retaining one execution, evidence, and operator model.
- Evidence before completion. A green-looking response is not a release signal; declared predicates and fresh verification are.
- Parallelism with boundaries. Independent work can run concurrently while owned paths, side effects, and evidence remain explicit.
- Extensibility without a fork. Ship skills, extensions, prompts, and themes as OMK packages instead of teaching every contributor a separate runtime.
The proof standard is operational: evaluate OMK against your own task completion, verification coverage, setup time, and recovery behavior. We do not claim an unmeasured benchmark win over another harness.
This patch release closes every tool turn with exactly one terminal result, adds the deterministic dag-v2 resource-claim scheduler, execution-bound evidence receipts, transactional compaction, session recovery, and provider diagnostics.
| Area | What changed |
| Tool turns | Every emitted tool call closes with one terminal result across normal, blocked, aborted, timed-out, failed, and resume paths; missing-result repair is idempotent and duplicate/orphan results fail closed. |
| Agent loop | The deterministic resource-claim DAG scheduler (dag-v2) preserves source-order result artifacts; keep waves-v1 (or set OMK_TOOL_SCHEDULER=waves-v1) as the rollback path. |
| Evidence | Optional execution-bound evidence receipts bind normalized local command outcomes, workspace/artifact fingerprints, redacted output digests, and replay-ledger state. |
| Sessions | Transactional compaction behind closed tool turns, typed termination, incomplete-run recovery, and omk session doctor --session <path\|id> --repair --dry-run. |
| Providers | omk provider doctor <provider-id> --level 0 reports sanitized Level 0–2 diagnostics for native, custom OpenAI-compatible, and local-proxy origins. |
Release notes live in .github/RELEASE_NOTES_v0.90.9.md. The GitHub release workflow also extracts the canonical release body from packages/coding-agent/CHANGELOG.md.
This patch release adds the tool-free GPT-5.6 MoA model, ordered path-safe tool-batch waves, global context-budget controls, and evidence-gated computer-use integrations.
| Area | What changed |
|---|---|
| Models | Added openai-codex/gpt-5.6-moa: bounded concurrent Sol/Terra analysis with a single Sol synthesis, plus hardened Codex terminal and cancellation handling. |
| Agent loop | Ordered partitionToolBatchWaves preserve safe parallel reads while path conflicts and unknown calls remain sequential. |
| Context control | Added global contextBudget.enabled and compaction.model; planner cache selection stays within the remaining tier budget. |
| Evidence / verification | Correctness Wall fixtureless live OA now requires a bound MCP handler and otherwise stays preview-only; the evidence ledger is tamper-evident. |
| Computer use | Added a project-local Stagehand extension and omk-computeruse skill with explicit operator approval and redacted results. |
| Release safety | Nested extension node_modules are excluded from release staging while extension source and lockfiles remain versioned. |
GitHub-focused release notes live in .github/RELEASE_NOTES_v0.90.8.md. The GitHub release workflow also extracts the canonical release body from packages/coding-agent/CHANGELOG.md.
If you use OMK or other coding agents for open source work, publish sanitized sessions from .omk/agent/sessions.
Public OSS session data helps improve coding agents with real-world tasks, tool use, failures, and fixes instead of toy benchmarks.
| Package | Description |
|---|---|
| omk-ai | Unified multi-provider LLM API (OpenAI, Anthropic, Google, etc.) |
| omk-agent-core | Agent runtime with tool calling and state management |
| open-multi-agent-kit | Interactive coding agent CLI |
| omk-tui | Terminal UI library with differential rendering |
For Slack/chat automation and workflow integrations, use OMK extensions and MCP servers.
AdaptOrch MCP is a separate, proprietary reliability-kernel service (not part of
this monorepo) that OMK can route orchestration tasks through: topology-aware DAG routing, multi-model
synthesis, and consistency verification. It is versioned 0.1.0 — an MVP stage — with a public-ready free
Starter tier and paid Pro/Team tiers, and is backed by a published paper
(arXiv:2602.16873).
The adaptorch and adaptorch-prod MCP servers plus the adaptorch-route and adaptorch-synthesize skills
ship in OMK's default omk-core-verified execution preset, so they are available from the first prompt of a
default session without extra setup. Actually invoking AdaptOrch (e.g. adaptorch_run) still requires an
ADAPTORCH_CONTROL_PLANE_TOKEN (a dev token is auto-set for a local control plane at 127.0.0.1:8000) and
follows normal task-routing rules rather than firing on every message.
This is distinct from packages/adaptorch-wpl in this monorepo, an experimental, design-stage Work Packet
Loop package that is not yet wired into the open-multi-agent-kit CLI — see that package's own README for its
current status.
OMK does not include a built-in permission system for restricting filesystem, process, network, or credential access. By default, it runs with the permissions of the user and process that launched it.
If you need stronger boundaries, containerize or sandbox OMK. See packages/coding-agent/docs/containerization.md for three patterns:
- OpenShell: run the whole
omkprocess in a policy-controlled sandbox. - Gondolin extension: keep
omkand provider auth on the host while routing built-in tools and!commands into a local Linux micro-VM. - Plain Docker: run the whole
omkprocess in a local container for simple isolation.
See CONTRIBUTING.md for contribution guidelines and AGENTS.md for project-specific rules (for both humans and agents).
npm install --ignore-scripts # Install all dependencies without running lifecycle scripts
npm run build # Build all packages
npm run check # Lint, format, and type check
./test.sh # Run tests (skips LLM-dependent tests without API keys)
./omk-test.sh # Run OMK from sources (can be run from any directory)We treat npm dependency changes as reviewed code changes.
- Direct external dependencies are pinned to exact versions. Internal workspace packages remain version-ranged.
.npmrcsetssave-exact=trueandmin-release-age=2to avoid same-day dependency releases during npm resolution.package-lock.jsonis the dependency ground truth. Pre-commit blocks accidental lockfile commits unlessOMK_ALLOW_LOCKFILE_CHANGE=1is set.npm run checkverifies pinned direct deps, native TypeScript import compatibility, and the generated coding-agent shrinkwrap.- The published CLI package includes
packages/coding-agent/npm-shrinkwrap.json, generated from the root lockfile, to pin transitive deps for npm users. - Release smoke tests use
npm run release:localto build, pack, and create isolated npm and Bun installs outside the repo before tagging a release. - Local release installs, documented npm installs, and
omk update --selfuse--ignore-scriptswhere supported. - CI installs with
npm ci --ignore-scripts, and a scheduled GitHub workflow runsnpm audit --omit=devplusnpm audit signatures --omit=dev. - Shrinkwrap generation has an explicit allowlist for dependency lifecycle scripts; new lifecycle-script deps fail checks until reviewed.
MIT


