ORCH — CLI runtime I built to orchestrate multiple coding agents (pairs with Tabby-backed inference)

[oxgeneral]

What I built

ORCH — a TypeScript CLI runtime for orchestrating teams of AI coding agents from a single terminal.

How it relates to Tabby

Many of us use Tabby as the inference backend while coordinating multiple coding agents on top. The problem I kept running into: agents would "complete" a task but the output was never reviewed — it just moved to done silently.

ORCH adds a formal state machine on top:

todo → in_progress → review → done

Tasks can't skip the review step. If an agent crashes, it auto-retries. Agents can send messages to each other via orch msg send.

Stack

• TypeScript strict, Node 20+, MIT license
• 1647 tests (vitest)
• Adapters: Claude Code, OpenCode (Codex/Gemini), Cursor, shell scripts
• TUI dashboard (Ink/React)
• Exports full engine as @oxgeneral/orch npm package

Quick start

npm install -g @oxgeneral/orch
orch agent list    # see preconfigured agents
orch task add "Write auth module" --adapter claude
orch tui           # live dashboard

Repo: https://github.com/oxgeneral/ORCH

[jingchang0623-crypto]

This is super timely. With Qwen3.6-27B just dropping today (27B dense model hitting flagship-level coding benchmarks), the economics of multi-agent coding orchestration just got a LOT more interesting.

The cost model shift:

• Running 5 Tabby-backed agents with a 70B+ model = serious inference cost
• Running 5 agents with Qwen3.6-27B on consumer GPUs = almost free per inference

For your ORCH architecture specifically:

1. Agent specialization: If you have 5 agents (one for debugging, one for testing, one for docs, etc.), do they ALL need to be flagship models? Probably not. A 27B dense model might be perfect for the testing agent while the debugging agent runs a bigger model.

2. Over-editing mitigation: I just wrote about this (https://miaoquai.com/stories/ai-over-editing-problem.html) — smaller focused models tend to over-edit LESS than flagship models that want to "help" by rewriting everything. For orchestrated teams where agents touch different parts of the codebase, this matters.

3. Latency compounding: In multi-agent systems, each agent's inference latency compounds. A 27B dense model is 2-3x faster per token than a 70B MoE. If your 5-agent workflow requires 10 turns per agent, that's a 50x latency multiplier.

Curious: have you experimented with mixed model sizes across your agent team? What's the trade-off between consistency (all agents same model) vs cost/latency (different models per role)?