VNX Orchestration — Summary

VNX (vnx-orchestration) is a governance-first multi-agent orchestration runtime for AI CLI workers (Claude Code, Codex CLI, Gemini CLI, Kimi CLI, LiteLLM bridge). With 34 stars and active development, it is the most governance-focused framework in this batch: every agent action produces a structured receipt in an append-only NDJSON ledger, quality gates use deterministic file-based verdicts (not LLM judgment), and a multi-provider code review pipeline (Codex gate + Gemini review) must pass before merge is allowed. The framework ships a Python CLI (vnx), a skills directory with 21 named skills/agent roles, a dashboard web UI, a tmux 2x2 grid operator mode, a headless subprocess mode for CI, and a receipt/ledger system documenting 1,400+ entries in production use. VNX explicitly addresses Anthropic's April 2026 OAuth policy (which affected OpenClaw) by spawning claude CLI processes via subprocess rather than using OAuth tokens. Closest seed comparison: closest to claude-flow in its multi-agent coordination complexity and explicit governance, but VNX is infrastructure-first (receipts, quality gates, tmux grid, dashboard) while claude-flow is protocol-first (MCP tools, consensus algorithms).

VNX Orchestration — Overview

Origin

Created by Vinix24 (Vincent van Deth). Single contributor. Active to 2026-05-26. Release v1.0.0-rc3 milestone (multi-provider, May 2026). 34 stars.

Philosophy

"Most multi-agent frameworks solve orchestration. VNX solves governance — the audit trails, quality gates, and human checkpoints that make multi-agent workflows trustworthy."

"Governance, provenance, and operator control built in. No framework to import. No cloud dependency."

Core Design Principles

1. Receipts: every agent action writes a structured receipt to an append-only NDJSON ledger
2. Quality gates are deterministic: file size limits, test coverage thresholds, open blocker counts — not LLM judgment
3. Gate verdicts: APPROVE, HOLD, or ESCALATE — LLM never judges its own work
4. Provider-agnostic: 5 providers (Claude, Codex, Gemini, Kimi, LiteLLM bridge) in production
5. CLI subprocess only: spawns claude binary via subprocess; never touches OAuth tokens or api.anthropic.com

Compliance Positioning

The README includes a formal compliance audit table confirming VNX does not call Anthropic OAuth endpoints, does not use subscription credentials for API calls, and only launches claude CLI processes. This was written specifically in response to the April 2026 Anthropic policy that affected OpenClaw (340K stars).

Modes

• Starter Mode: single terminal, one provider, sequential dispatch
• Operator Mode: 4-terminal tmux grid (T0 orchestrator + T1/T2/T3 workers), multi-provider, parallel tracks
• Demo Mode: replay real sessions without API keys
• Headless Mode: all terminals as claude -p subprocesses (fully autonomous CI/overnight)

Key Quote

"~$200/month Max subscription versus ~$3,000/month in equivalent API tokens for the same workload. CLI subprocess trades some observability for a ~15x cost reduction."

VNX Orchestration — Architecture

Distribution

• Python package with CLI (vnx)
• Install: git clone && ./install.sh /path/to/project
• pyproject.toml-based; Python runtime

Required Runtime

• Python >= 3.x
• Claude CLI, Codex CLI, Gemini CLI (one or more)
• tmux (Operator Mode)
• Git

Directory Tree

vnx-orchestration/
├── vnx_cli/              — Python CLI
│   ├── main.py           — argparse entry point
│   └── commands/         — init, doctor, status, dispatch_agent, pool, update, version
├── agents/               — agent persona SKILL.md files
│   ├── t0-orchestrator/
│   ├── planner/
│   ├── architect/
│   ├── backend-developer/
│   ├── frontend-developer/
│   ├── database-engineer/
│   ├── test-engineer/
│   ├── quality-engineer/
│   ├── security-engineer/
│   ├── reviewer/
│   ├── debugger/
│   ├── performance-profiler/
│   ├── python-optimizer/
│   ├── api-developer/
│   ├── intelligence-engineer/
│   ├── monitoring-specialist/
│   ├── data-analyst/
│   ├── supabase-expert/
│   ├── excel-reporter/
│   ├── vnx-manager/
│   └── skills.yaml       — skill manifest
├── skills/               — (same directory, 21 agent roles)
├── hooks/                — session lifecycle scripts
│   ├── sessionstart.sh
│   ├── vnx_context_monitor.sh
│   ├── vnx_handover_detector.sh
│   ├── vnx_hook_payload_logger.sh
│   └── vnx_rotate.sh
├── dashboard/            — Web dashboard (Python served)
│   ├── index.html
│   ├── serve_dashboard.py
│   └── api_*.py
├── ledger/               — Receipt storage
│   ├── engine/
│   └── t0_ledger_interface.py
├── database/             — State database
├── bin/                  — vnx binary
├── lib/                  — shared libraries
├── scripts/              — orchestration scripts
│   ├── headless_trigger.py
│   └── headless_orchestrator.py
├── schemas/              — Receipt schema definitions
├── configs/              — Provider configurations
└── claudedocs/           — Roadmap and planning docs

Target AI Tools

• Claude Code (T0 orchestrator: Claude Opus only per t0-orchestrator skill)
• Codex CLI (T1/T2/T3 workers, Sonnet-pinned)
• Gemini CLI (T1/T2/T3 workers)
• Kimi CLI
• LiteLLM bridge (DeepSeek V4 Pro/Flash, GLM-5.1)

State Storage

• .vnx-data/ — dispatch receipts, unified_reports, unified_ledger.ndjson
• .vnx/ — project state
• database/ — intelligence schema, code_snippets, project state

VNX Orchestration — Components

CLI Binary: vnx (Python)

Agent Skills (21)

Hooks (5 shell scripts)

Quality Gates

• Codex gate: OpenAI gpt-5.2-codex — bugs, data loss, security
• Gemini review: Google gemini-2.5-flash — architecture, patterns, trade-offs
• CI gate: CI green required
• Gate verdicts: pass, fail, blocked with severity-rated findings
• Triple gate policy: codex pass + gemini pass + CI green → merge allowed
• Gate locks are file-based (not LLM-based)

Dashboard (Web)

dashboard/index.html + serve_dashboard.py — served locally

• API endpoints: api_agent_stream.py, api_health.py, api_intelligence.py, api_operator.py, api_recommendations.py, api_register_stream.py, api_token_stats.py
• Token dashboard sub-module

Ledger

NDJSON append-only receipt log: .vnx-data/unified_ledger.ndjson Schema defined in schemas/ 1,400+ entries in production use

VNX Orchestration — Uniqueness

Differs From Seeds

Most complex governance infrastructure in the batch. Closest seed is claude-flow (multi-agent, multi-model, extensive tooling) but VNX differs fundamentally: VNX focuses on governance (receipts, provenance, deterministic gates) while claude-flow focuses on protocols (consensus algorithms, MCP tools). VNX's deterministic file-based quality gates (not LLM judgment) are unique in the entire corpus — no seed has a "LLM never judges its own work" gate design. The NDJSON receipt ledger with 1,400+ production entries and replay capability exceeds any seed's observability story. VNX is also unique in the corpus for explicitly addressing a specific vendor policy (Anthropic April 2026 OAuth ban) with a compliance audit.

Positioning

• Only framework with a formal compliance audit published in the README
• Strongest observability story in this batch (NDJSON ledger, token cost reports, web dashboard)
• Explicit 15x cost savings rationale (CLI subprocess vs API tokens)
• Production-proven: 1,400+ ledger entries cited
• Multi-provider in production: 5 providers simultaneously

Observable Failure Modes

• tmux complexity: 4-terminal grid requires tmux literacy
• Python runtime: non-standard for skill packs (most are Node.js/bash)
• Single contributor: 1 contributor despite active development; bus factor = 1
• Dutch README sections: some CHANGELOG entries are in Dutch, suggesting personal use pattern
• ADR-bounded: API contract stability promised but still rc3; 14 ADRs may not cover all edge cases

Notable Quotes

From README on governance:

"The same governance applies regardless of mode. Receipts, quality gates, and provenance records are generated identically whether a worker is interactive or headless. Headless does not mean ungoverned."