vibe-orchestra

A Mistral model-and-specialist router for vibe. Describe a task; it routes to the right Mistral model, specialist, and tool — so you launch vibe and it orchestrates, instead of picking models by hand.

The idea

Inspired by Sakana AI's Fugu — you should not manage which model to call. Fugu coordinates a pool of models with learned strategies (an evolved coordinator + an RL-trained conductor). vibe-orchestra does not learn coordination; it is the practical, hand-designed slice you can run today: a cheap classifier picks the route, and a model policy maps each route to the Mistral model, specialist, and tool that fit.

task ──▶ route()  (Ministral, cheap)
            │
   surgical-edit ─▶ Codestral FIM     · tool: vibe-fim surgical_patch
   ios          ─▶ Devstral           · specialist: iOS posture + patterns
   reasoning    ─▶ Magistral
   vision       ─▶ Pixtral
   agentic-build─▶ Devstral
   quick        ─▶ Ministral
   chat         ─▶ Mistral medium

Install — then vibe, and basta

git clone https://github.com/guillaumevele/vibe-orchestra && cd vibe-orchestra
IOS_KIT=/path/to/vibe-ios-kit ./install.sh

install.sh wires everything globally and reversibly (it backs up the files it touches and edits only inside marked blocks):

• the orchestration posture → ~/.vibe/AGENTS.md (loaded by every session),
• the route + surgical_patch tools → ~/.vibe/config.toml (global MCP),
• the iOS specialist (posture + 38 patterns + a real ios vibe skill) from vibe-ios-kit.

Add --with-capabilities to also connect a curated set of real, keyless MCP plugins so the orchestrator is autonomous out of the box:

./install.sh --with-capabilities     # + apple-docs, context7, sequential-thinking

It pre-warms the npm cache and gives those servers a generous startup timeout — a cold npx download otherwise exceeds vibe's 10s limit and destabilises MCP init (learned the hard way). Plugins that need a key (github, supabase, brave) are catalogued with their command and env var for you to add yourself — this project never ships or asks for secrets.

After that, anywhere — no --agent, no per-project copy:

vibe "round the body of computeScore() to 2 decimals, leave the rest"
vibe "add a shimmer Metal loader to onboarding, gated on scenePhase"

Plain vibe calls route() to pick the model/specialist, then edits via surgical_patch (Codestral FIM, bounded). Undo with ./install.sh --uninstall.

Use the router directly

pip install vibe-orchestra
vibe-orchestra route "verify the SwiftUI glassEffect API then add a glass tab bar"
#   route      : ios
#   model      : devstral-latest
#   subjects   : apple-docs, ios
#   use        : ios, apple-docs        (already wired)
#   why        : SwiftUI work -> iOS specialist
vibe-orchestra routes          # the model policy
vibe-orchestra capabilities    # real plugins/skills: wired vs available

Connect real plugins per subject

route is capability-aware: it returns not just a model and specialist but the real plugins/skills that serve the task's subject — split into ones already wired into vibe and ones to consider adding (with the exact command and any key). The catalog is verified, public packages only:

That is the autonomy: the orchestrator reaches for the right real tool per subject instead of guessing.

from vibe_orchestra import classify
d = classify("add a SwiftUI settings screen")
d.route, d.model, d.specialist     # ('ios', 'devstral-latest', 'ios')

The classifier backend is injectable, so the routing logic is fully testable with no network:

classify("rename foo to bar", chat_fn=lambda system, user: '{"route": "surgical-edit"}')

/goal — autonomous loop

Installed as a native vibe slash-command. Give it a goal; it runs a hand-designed Thinker / Worker / Verifier loop:

/goal ship a gated Metal loader on the onboarding screen

1. decompose into 2–6 subtasks, each with an explicit acceptance check, to ./.vibe-goal/PLAN.md;
2. route each subtask (model / specialist / plugins);
3. dispatch to the smallest mechanism that works — surgical_patch for a bounded edit, reason/vision/quick for a model sub-call, the ios skill for SwiftUI/Metal, or a subagent only when a different model must be pinned;
4. verify with a tool call (never prose) and paste the evidence into REPORT.md; on failure it re-routes (retry budget 2);
5. synthesize, stating which model each step actually ran on.

A read-only goal-verifier subagent (runs the proof, cannot edit) is installed for independent verification.

Model-backed tools

The router can also hand a sub-problem to the right model directly — these make a real Mistral API call for that subtask even though your session model is fixed:

Honest limits

• Coordination is hand-designed, not learned. Fugu's edge is the trained coordinator; this is a policy + a classifier. It is transparent and cheap, not evolved.
• Within one session the driving model is fixed. You reach other Mistral models the two real ways: the model-tools (reason/vision/quick, single-shot API calls) and surgical_patch (Codestral FIM), or a subagent that pins a model. route() never silently swaps the session model.
• /goal is prompted, not enforced. A skill is instructions, not a runtime — the loop runs as faithfully as the model follows it. Fan-out is sequential, not parallel; "Thinker/Worker/Verifier" is role separation, not concurrent workers. Calling it Fugu-like refers to that shape, not learned coordination.
• Model-pinning subagents are owner-gated. Pinning an active_model alias not in your config.models crashes on first dispatch, so v1 ships none (the goal-verifier pins nothing). Adding one means co-declaring its provider/model block — left to you on purpose.

Specialties

The iOS specialist is vibe-ios-kit (build posture + 38 distilled iOS 26/27 patterns + a runnable lint). The registry is extensible: a specialist is a vibe agent plus a posture the orchestrator adopts when route selects it.

License

MIT © Guillaume Vele