Vendor-neutral per-task-type model routing: planning→Qwen, coding→Claude, exploration→GPT. Local Rust agentic coding assistant (yo CLI / MrCode). By jgarzik. GitHub · v0.6.0 (head 115f6f7, 2026-03-23)
src/model_routing.rs). The agent picks the backend by route category — planning, coding, exploration, testing, docs, fast — not by a single configured default. Selection is aware of provider health, cost budget, context-window fit, and privacy/ZDR, with fallback chains. Nobody else in this hub routes per-task-type across vendors as the core primitive.src/). File access is project-scoped via a Permission system (allow / ask / deny), not OS-enforced. "Docker" in the README is deployment packaging, not per-tenant runtime isolation.Most agents bind to one model (or one provider with manual overrides). brainpro inverts this: every request carries a route category, and src/model_routing.rs resolves that category to a concrete backend at call time. The mapping is the design point, not the model.
The router is not a static lookup. Selection folds in four awareness axes — provider health (degraded backends are skipped), cost budget, context-window fit for the request size, and privacy / ZDR (zero-data-retention) constraints — then falls through a fallback chain if the preferred backend is unavailable. The orthogonal claim holds at the code level: the unit of routing is the kind of work, resolved across vendors, not a vendor you pre-pick.
brainpro ships as a local agentic coding assistant — the yo CLI with the MrCode persona. v0.5.0 / v0.6.0 grew a gateway/channels subsystem (the MrBot face) that fronts the agent over a Unix-socket daemon, shifting it from a pure local CLI toward a remote-messaging agent.
f1411e3, Feb 2)~3785 LOC added across src/gateway/channels/{auth,config,manager,plugin,routes,session_map,telegram,discord}.rs. A plugin layer integrating Telegram + Discord as gateway clients:
ChannelSessionMap — each Telegram/Discord chat is keyed to an agent session.ChannelAuthManager — 6-character codes, persisted as AuthRecords.ChannelManager ↔ AsyncAgentConn over a Unix socket to the agent daemon.c664f25); tool_choice cleared (5e5e3f0); continuation reminders suppressed at max iter (9acb420).a703658).src/tools/edit.rs); tool descriptions overhauled (2bfab01); MrCode persona prompts rewritten (95066ac).brainpro has no runtime sandbox. There are no seccomp, namespace, Firecracker, or micro-VM primitives in src/. The security line is the in-process Permission system: file access is project-scoped with allow / ask / deny gating, enforced by the agent, not the OS. A multi-arch GHCR container build (dca91e6, linux/amd64+arm64) was added — that is CI/packaging only, not a per-tenant runtime isolation change.
On the hub's spectrum (None → Prompt-only → Container → Micro-VM → Network-cut), brainpro sits at the prompt-only end — alongside ElizaOS/Milady, and well short of Muaddib's QEMU hypervisor boundary.
The channels layer adds the only tenant boundary brainpro has. Authorization is per-channel-target pairing codes (ChannelAuthManager) mapping a Telegram/Discord chat to an agent session via ChannelSessionMap. This is lightweight gating — it answers "can this chat talk to the agent" — not isolation. All sessions live in one shared Unix-socket daemon, separated only by session-id keying. There is no per-session compute, filesystem, or credential boundary.
Concrete, source-verified signals (not production-scale claims):
f07b29c) and v0.6.0 (4f57b8e, head 115f6f7, 2026-03-23) tagged; prior research tracked the v0.1.0-era / commit 6254329.f1411e3) with persisted auth records and inline approval UI — not scaffolding.2bfab01); edit-tool fuzzy fallback for robustness on imperfect matches.What is not validated: no published throughput/efficiency benchmark, no large-scale production deployment evidence. The proof here is the codebase, not a usage metric.
115f6f7, 2026-03-23)src/model_routing.rssrc/gateway/channels/*.rs (commit f1411e3)