OMK

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

Models execute. OMK routes, verifies, measures, and controls.

Install · Quick start · Runtime algorithm · Docs · Visual assets

OMK (omk) turns a coding goal into a bounded, evidence-gated agent run.

Current package source version: @omk/[email protected].
Runtime contract family: v1.2.
Release channel: pre-1.0.
See versioning and provider maturity.

Why OMK

Most coding agents optimize for a single prompt/result loop. OMK wraps agent execution with a control-plane algorithm:

• compile the user goal into a DAG coordinator turn;
• inject only scoped MCP servers, skills, hooks, memory, and tools;
• classify task intent and route to compatible runtime adapters;
• execute with timeout, approval, sandbox, and fallback metadata;
• require evidence before completion claims;
• preserve run artifacts for replay, inspection, and audit.

OMK//CONTROL visual console

The GitHub visual set presents OMK as a Night City Ops Console: route status, DAG lanes, provider fallback, scoped MCP, evidence gates, and replayable run telemetry. Assets are provenance-covered in readmeasset/ASSET_PROVENANCE.md.

Operator TUI	Runtime flow

Install lane	Provider router	Evidence gate

Install

Requires Node.js >=20 and npm >=10.

npm install -g @omk/cli
omk --help

No global install:

npx -p @omk/cli omk doctor

Quick start

omk init                         # scaffold AGENTS.md, DESIGN.md, .omk/
omk doctor                       # check runtime, providers, MCP, skills, hooks
omk codex auth --choice plus-pro # prefer official Codex app/CLI OAuth for Codex lanes
omk chat --provider codex --mode agent
omk orchestrate "ship feature" --workers 4 --dry-run

Current runtime algorithm

The canonical algorithm definitions live in Native Root Runtime Algorithms. README summary:

1. Native root turn execution

Read user input
  → dispatch slash commands locally
  → build scoped MCP/skills/hooks capability injection
  → build prompt envelope
  → materialize a DAG coordinator node
  → run selected runtime with timeout/abort handling
  → stream output, sync TODOs, attach evidence

This is the interactive root loop used by omk chat. It treats shell exits, slash commands, prompt envelopes, TODO sync, and recent output as controlled runtime state instead of loose chat text.

2. Native root turn node construction

User prompt
  → infer risk: read | write | shell | merge
  → normalize scoped capabilities
  → choose provider-neutral routing policy
  → attach approval/sandbox metadata
  → produce coordinator DAG node

Read-only turns stay read-only. Write, shell, and merge turns get explicit capability metadata. DeepSeek-style advisory lanes are kept read/review when the risk is not safe for write authority.

3. Runtime-backed task runner

DAG node
  → run state
  → context capsule
  → provider-neutral AgentTask
  → RuntimeRouter.execute(task)
  → TaskResult with selected runtime + fallback chain

OMK converts DAG context into an adapter-neutral task so Codex, MiMo, Kimi API/print lanes, DeepSeek, Qwen, OpenRouter, local adapters, or future runtimes can participate through the same contract.

4. Intent-aware runtime routing and fallback

Classify intent
  → filter compatible runtimes
  → score by quality, evidence pass rate, and recent failures
  → execute best runtime
  → fallback in ranked order when a runtime fails
  → record selected runtime, intent, scores, and fallback chain

Provider routing is evidence-aware, not just provider-name matching. Failed or low-evidence lanes are penalized; compatible healthy lanes can take over.

5. Secure worker transport and scoped environment

Worker prompt
  → stdin transport where supported, not process argv
  → scoped agent file when needed
  → sanitized child environment
  → OMK_RUN_ID / OMK_NODE_ID / OMK_NODE_ROLE metadata

Kimi worker prompts use stdin with --input-format text where that adapter path applies. All worker environment claims are scoped to the exact adapter and evidence gates; private prompt envelopes and run artifacts remain trusted local data.

Core loop

Goal → DAG plan → parallel lanes → evidence bundle → verify gate → merge / replay / inspect

What OMK controls

Provider lanes

OMK is provider-neutral. The configured runtime decides which adapters are available, but the control plane is the same:

• Codex app / CLI OAuth lanes for Codex-backed coding sessions;
• MiMo as the default provider path when configured;
• Kimi API / print lanes as explicit provider adapters, not the root identity;
• DeepSeek, Qwen, OpenRouter, local adapters for advisory or execution lanes when capability contracts match;
• GPT Image 2 asset lane for visual assets when the image workflow is explicitly selected.

Codex app / OAuth first

For Codex lanes, OMK delegates auth to the official Codex app/CLI and never reads or prints ~/.codex/auth.json tokens.

codex login
omk codex auth --choice plus-pro --run
omk provider doctor codex --soft

Codex/ChatGPT OAuth is for Codex CLI sessions. omk image generate/edit --model gpt-image-2 remains an OpenAI Images API call and requires a separate OpenAI Platform project API key. See Codex OAuth setup and OpenAI image keys.

CLI and package contract

The npm package is intentionally package-safe:

Release checks:

npm run version:check
npm run proof:check
npm run pack:dry
npm run audit:package

Contract versions

Machine-readable contracts currently include:

• omk.contract.v1
• omk.evidence.v1
• omk.decision.v1
• omk.run-manifest.v1
• omk.provider.v1
• omk.version.v1
• omk.proof-bundle.v1

Schemas live in the source-tree schemas/ directory and are checked with:

npm run schema:check

Known implementation caveats

The runtime algorithms are the current contract target, with adapter-specific hardening still tracked in docs and tests:

• /provider is restart-only in the native root loop.
• /model is UX debt until live mutation or restart-only behavior is enforced consistently.
• Approval and sandbox metadata are preserved in task contracts; enforcement depends on the adapter path.
• Provider health probes do not yet uniformly separate binary/API presence, auth, model support, and quota state across every adapter.
• Safety claims are scoped to exact adapter, command, evidence, and package-audit results.

Brand system

Public copy stays OMK-owned: OMK//CONTROL, NEON GRID ONLINE, route/evidence/loop/control language, and the Night City Ops Console palette. The README/NPM hero, social preview, TUI mock, runtime-flow diagram, and derivative gallery are package-safe brand assets with provenance in readmeasset/ASSET_PROVENANCE.md.

Docs

• Getting started
• Runtime versioning
• Provider maturity
• Native root runtime algorithms
• Codex OAuth setup
• Security policy

Security

Safe by default: child env is sanitized, ambient secrets are dropped, and workspace-write routes require approval. OS-level sandboxing is planned, not claimed; see SECURITY.md.

Links

• GitHub: https://github.com/dmae97/open_multi-agent_kit
• NPM: https://www.npmjs.com/package/@omk/cli
• Releases: https://github.com/dmae97/open_multi-agent_kit/releases

License

MIT