OMK//CONTROL — the provider-neutral multi-agent control plane for coding workflows.

자유는 제약의 부재가 아니라, 보장의 존재다.
Freedom is not the absence of constraints — it is the presence of guarantees.

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.

Most ways of running an AI coding agent force you into one of two cages.

The walled garden. One vendor's model, one vendor's tools, one vendor's rules. You are a tenant inside someone else's runtime, and your "freedom" ends exactly where their API does.

The chaos box. A model that can run anything, verify nothing, and still cheerfully declare done while the build is on fire. Unlimited power, zero accountability.

OMK hates both. We think an operator should be free to use any model, any skill, any workflow — and free to actually trust the result. OMK is the control plane that makes those two freedoms compatible.

Every freedom OMK hands you is guarded by a constraint that keeps it honest. These constraints are not cages — they are the rails that make the freedom safe to use at full speed.

That is the whole thesis in one line: models execute; OMK routes, verifies, measures, and controls. The model's freedom to act is bounded by the operator's freedom to know what actually happened.

Ten short captures of the control plane doing its job.

These are stylized terminal animations representative of the real flows — the live OMK//CONTROL TUI is even busier.

One global install, one omk, and the control plane wires the DAG scheduler, arms the evidence ledger, discovers 822 skills, connects 20 MCP servers, and registers every provider you own.

!omk plan turns a fuzzy objective into a bounded DAG: owned paths, ordered waves, and an acceptance predicate attached to every node before a single line of code is written.

!omk-loop fans independent work out across concurrent lanes on the resource-claim DAG. Independent work runs in parallel; conflicting and unknown operations stay sequential. Every lane lands an evidence receipt.

Providers stay interchangeable. The Bayesian router and refusal-learner pick the best arm for the task, but the execution, evidence, and operator model never change when you swap models.

The Correctness Wall intercepts the write and runs the acceptance predicates. One red predicate blocks completion — a green-looking reply is never a release signal.

!skill: routes to the right lane and loads the minimum necessary — usually one to three skills. A skill is loaded when it earns its place in the task, not because it happens to be installed.

/mcp reports the health and latency of every configured server. The control plane sees every integration — there are no silent failures.

/compact runs context-budget v2 with headroom: raw tokens are compressed while the goal, the checkpoint, and the evidence are preserved. Compact context, full memory of what matters.

omk session doctor detects unterminated turns and orphan results, then plans a dry-run repair against the tamper-evident replay ledger. An interrupted run is a recoverable state, not a loss.

Ship extensions, skills, prompts, and themes as ordinary pinned OMK packages. Extensibility without teaching every contributor a separate runtime.

npm install -g open-multi-agent-kit --ignore-scripts

Then run it:

omk --version
omk

Or without a global install:

npx --ignore-scripts open-multi-agent-kit

Library 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 rendering

This 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.92.0

# Project-local, pinned Git package
omk install -l git:github.com/dmae97/open-multi-agent-kit@v0.92.0

# Inspect and control the installed resources
omk list
omk config
omk update --extensions

A skills-only package is an ordinary OMK package:

{
  "name": "omk-workflows",
  "keywords": ["omk-package"],
  "omk": {
    "skills": ["./skills"]
  }
}

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.

• Subagent managed-process runtime under examples/extensions/subagent: a deadline-budgeted, checkpointed, adaptive subagent executor with process-group lifecycle management (SIGTERM→SIGKILL escalation and resistant-descendant reaping) plus an extension smoke path that runs a registered tool through the managed-process boundary without a provider API.
• Print mode now reports a clear usage message and exits with code 2 when invoked with no prompt (bare omk -p) instead of exiting silently.

• Simplified the built-in loadout authority model: every loadout (inspect, plan, architect, review, critic, security, test, visual-qa) now resolves to write-scoped authority with a unified read/grep/find/ls/edit/write/bash tool grant and scoped-shell command mode, replacing the previous per-loadout read-only / advisory / review-only tiers and their filesystem-MCP downgrade and write-skill stripping. Lane write scope remains gated by the scheduler write-set.
• Removed the headless credential/secret-file command-safety guard: classifySecretAccess and the secret.read_path confirm tier are gone, and the agent session no longer applies the safety-floor block for secret.* verdicts before spawning a shell. Commands referencing .env, .npmrc, .netrc, .aws/credentials, auth.json, SSH private keys, *.pem/*.key, and similar are no longer gated for headless/RPC/LLM bash callers.

• Local-only scratch scripts and operator protocol notes are now gitignored and excluded from the release surface.

Release notes live in RELEASE_NOTES_v0.92.0.md.

• System-wide resource metrics in the footer — the footer CPU/MEM segment now reports whole-machine utilization (aggregate os.cpus() busy percentage and totalmem - freemem) instead of process-scoped usage. Wide terminals show CPU 42% MEM 35% (18.0GB/50.5GB); thresholds are percentage-based (warning ≥70% CPU or ≥85% MEM, error ≥90%/95%). Process-scoped getters remain available on the sampler for diagnostics.
• Aurora theme pair — new built-in omk-aurora-dark and omk-aurora-light themes with WCAG-verified contrast (body text ≥14:1, muted ≥5.7:1, semantic colors ≥4.5:1), a full 51-token color map, and a stepped thinking-level color ramp. Aliases: aurora, aurora-dark, aurora-light.
• AdaptOrch advisory bridge wiring — opt-in, global-only adaptorchBridge settings block (enabled, ttlMs, timeoutMs, maxConsultsPerSession, failureThreshold). When enabled, the v4 auto thinking-level resolver consults the circuit-breaker-protected, TTL-cached advisory bridge and fuses the returned hint as a bounded ±2-step nudge; the resolver's own confidence escalation still applies on top. Default remains fully off, and a project-scope settings file can never enable it.

• omk-adaptorch-wpl promoted to stable and added as a runtime dependency of open-multi-agent-kit (lockstep 0.91.0). The Work Packet Loop state machine, outcome adjudicator, and verification-wall modules now ship with the CLI package.
• Repository hygiene: local-only research corpora and audit artifacts are no longer tracked in git (they remain on disk, with a local SHA-256 integrity manifest for the project-owned subset).

• Masked API-key-like values in newly submitted user chat before extensions, models, event streams, and session persistence.
• Restored omk-adaptorch-wpl handling in the coding-agent shrinkwrap generator so internal workspace packaging stays reproducible.

• Published to npm as open-multi-agent-kit@0.91.0 (lockstep with omk-ai, omk-agent-core, omk-tui, and omk-adaptorch-wpl at 0.91.0).
• Verification boundary: tsgo --noEmit clean; adaptorch-wpl suite 73/73, coding-agent regression suite 784/784, theme suites green. Live-provider coverage remains outside this release.

Release notes live in RELEASE_NOTES_v0.91.0.md.

• Closed every emitted tool turn with one terminal result across normal, blocked, aborted, timed-out, failed, and resume paths; missing-result repair remains idempotent and duplicate/orphan results fail closed.
• Added a deterministic resource-claim DAG scheduler that preserves source-order artifacts, keeps unknown, bash, and unclaimed extension tools exclusive, and retains waves-v1 as the compatibility rollback path.
• Added execution-bound evidence receipts that bind normalized local command outcomes, artifact/workspace fingerprints, redacted output digests, and replay-ledger state; the built-in CLI and AgentSession bash paths remain outside this optional evidence executor.
• Made compaction transactional behind closed tool turns, revision compare-and-swap, and stale-summary discard.
• Added typed termination, incomplete-run recovery, and omk session doctor, including dry-run repair for unambiguous recoverable state only.
• Added provider-origin-aware omk provider doctor diagnostics with sanitized Level 0–2 probes for native, custom OpenAI-compatible, and local-proxy endpoints.

• Published to npm as open-multi-agent-kit@0.90.9 (lockstep with omk-ai, omk-agent-core, and omk-tui at 0.90.9); prebuilt binaries are attached to the GitHub release.
• Verification boundary: build/check and the keyless workspace suite passed; live-provider and other-OS coverage remain outside this release. Validate existing integrations against your workload.

Release notes live in RELEASE_NOTES_v0.90.9.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.

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, the stable Work Packet Loop package shipped as a runtime dependency of open-multi-agent-kit since v0.91.0 — see that package's own README for details.

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 omk process in a policy-controlled sandbox.
• Gondolin extension: keep omk and provider auth on the host while routing built-in tools and ! commands into a local Linux micro-VM.
• Plain Docker: run the whole omk process in a local container for simple isolation.

See CONTRIBUTING.md for contribution guidelines and development.md for project setup.

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.
• .npmrc sets save-exact=true and min-release-age=2 to avoid same-day dependency releases during npm resolution.
• package-lock.json is the dependency ground truth. Pre-commit blocks accidental lockfile commits unless OMK_ALLOW_LOCKFILE_CHANGE=1 is set.
• npm run check verifies 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:local to 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 --self use --ignore-scripts where supported.
• CI installs with npm ci --ignore-scripts, and a scheduled GitHub workflow runs npm audit --omit=dev plus npm audit signatures --omit=dev.
• Shrinkwrap generation has an explicit allowlist for dependency lifecycle scripts; new lifecycle-script deps fail checks until reviewed.

MIT