Status: Shipped proxy/control plane, model observability, per-project model pins, review hardening, and native toolbox management for the kept serving backends (ds4/gufo/llama_cpp; v2 L1 purge — see Toolbox Backend Management); the benchmark explorer ships behind the non-default benchmarks cargo feature (v2 R2); future work is explicitly separated below Language: Rust Binary: target/release/brainrouter Implementation baseline: 3691dcc9ee7dee98f8355328d7e2e75f99faafdb (2026-09-07); extended through 32935d1 by the ai-toolbox-cockpit integration rollout, gufo overlay backend, dashboard navigation redesign, per-project pins, and review hardening — see Toolbox Backend Management and docs/design/ai-toolbox-cockpit-integration.md Config: $XDG_CONFIG_HOME/brainrouter/brainrouter.yaml or ~/.config/brainrouter/brainrouter.yaml; serve --config overrides it. Service environment files supply credentials; the daemon resolves configured environment-variable names. Repository: https://github.com/ajaxdude/brainrouter Validation: 391 Rust tests and 38 Node browser-logic tests passed at this baseline; see Validation

• Problem Statement
• Solution
• Architecture Decisions
• Component Map
• Configuration Reference
• Routing Flow
• Review Flow
• Toolbox Backend Management
• Benchmark Explorer
• Model Observability and Regression Alerts
• Bridge Architecture
• HTTP API Reference
• MCP Tools Reference
• Harness Compatibility
• Failure Modes and Mitigations
• Security Model
• What This Is Not
• Validation
• Planned and Unshipped Work

A developer running multiple LLM subscriptions (Anthropic, OpenAI/Copilot, Google, Mistral) and local models constantly hits:

1. Rate limits and quota exhaustion -- one provider fails mid-session, work stops.
2. Model selection overhead -- manually deciding cloud vs local before every query burns time.
3. Review token waste -- every code review cycle through a cloud LLM costs premium quota.
4. Harness fragmentation -- each tool (omp, vibe, claude, opencode, codex, droid) has its own provider config; keeping them aligned is manual work.
5. Role confusion -- the main author, reviewer, and local subagent pool need independent choices without silently overriding explicitly selected models.
6. Unreliable comparisons -- performance numbers lose meaning without artifact, runtime, hardware, workload, configuration, and measurement provenance.
7. Operational blind spots -- current request activity, completed-stream measurements, and historical benchmarks need a common inspection surface without treating missing data as zero or adding load to inference.

A single Rust daemon that:

1. Separates routing roles. The persisted Main choice handles auto, brainrouter/auto, and empty model selections; Reviewer has its own local/cloud/default choice; only subs or brainrouter/subs uses the separately selected local pool. Named presets configure compatible combinations without merging these roles. A per-project pin store can override Main, Reviewer, and Subagent for one canonical Git repository root while unpinned projects inherit the global profile.
2. Preserves explicit choices and fallback semantics. Bare model IDs and brainrouter/<id> select that local model with no rewrite or model substitution on failure. cloud/<id> sends the exact ID to Manifest. Explicit local/cloud aliases select backend defaults, not the Main override. Cloud requests retain the existing local fallback policy on disabled/unavailable Manifest; errors after streaming begins surface to the client rather than replaying output.
3. Reviews code with runtime policy controls, with explicit local or cloud reviewer IDs, requested-versus-actual reporting, and a reviewer snapshot retained for the lifetime of each review and its continuations. Runtime state can disable review, enable PR-generation guidance injection, and enable HankNDory design-aware review. Review prompts are token-budgeted before dispatch and escalate instead of approving when required evidence is truncated.
4. Manages system state via the dashboard: one-click upgrades of llama-swap, resets of the llama.cpp toolbox, start/stop of the Bonsai classifier, and flushing of loaded models — full VRAM control without a terminal. This extends to native, dashboard-driven management of ds4/gufo toolboxes, models, and detached servers (halogen/vllm/r9v were v1 scope, removed by the v2 L1 purge; their catalog feed ids parse as browse-only data) — brainrouter is a native Rust webui for ai-toolbox-cockpit, sharing its catalog and config.json rather than a divergent brainrouter-only store (see Toolbox Backend Management).
5. Keeps opt-ins explicit. Bonsai and Manifest are disabled by default. A role set to Auto consults the classifier only when enabled; otherwise it selects local. Applying a cloud or hybrid preset does not enable Manifest.
6. Presents a single OpenAI-compatible endpoint to all harnesses, plus an Anthropic-compatible endpoint for harnesses (Claude Code, droid) that speak Anthropic's protocol natively.
7. Bridges chat platforms -- Discord and Signal ship as the bridge sidecar plugin (v2 L2), shelling out to omp CLI, bringing LLM access to messaging apps with session management, model selection, and working directory tracking. Commands use the !br prefix.
8. Presents a simplified dashboard IA. The primary dashboard destinations are Overview, Models, Benchmarks, and Config; an always-visible command strip exposes model scope/role controls, flush/restart/sync actions, health, and quality posture.
9. Installs itself into harnesses via an idempotent install subcommand that configures 7 harnesses (omp, vibe, opencode, codex, droid, claude, pi) in a single command.
10. Tracks in-flight requests live. A registry records every request at handler entry (before routing, so the dashboard sees it during model load) and holds it until the stream ends or the user cancels it. The dashboard shows one row per active request — elapsed time, model, user agent, address, session, bytes received, PP progress, and an activity label (tool calling / reasoning / asking a multiple choice question / generating) — with a per-row Cancel button.
11. Measures completed requests by unique event ID. Actual first-output timing and provider-reported token counts support bounded recent measurements across both wire protocols. Concurrent turns in the same conversation cannot overwrite each other's samples. Missing prompt-processing speed is not inferred from TTFT.
12. Explores imported benchmarks. A normalized SQLite registry, strict Rust boundary models, immutable identities, transactional previews/imports, deterministic matrix expansion, structured inspector, telemetry plots, and bounded CSV/JSONL exports are exposed at /benchmarks.
13. Observes model activity without running benchmarks. /models combines exact local model keys, read-only backend metadata, active requests, recent completed measurements, indicative regression warnings, and explicit benchmark references.
14. Isolates optional work. Unavailable benchmark storage disables only explorer routes. Bounded blocking workers and response budgets keep benchmark work off the async routing executor. No benchmark runner, scheduler, automatic model switching, or outbound alerts are part of these additions.

The configured Bonsai model runs as an external llama-server process (PrismML fork of llama.cpp) on a dedicated port (default 9200). Brainrouter launches it at startup only when bonsai.enabled: true, waits for /health, then classifies through /v1/chat/completions. Decisions include cloud, local/light, and local/deep. Timing depends on hardware and workload; there is no guaranteed classification-latency SLA. BonsaiControl owns start/stop. An Auto role skips classification and chooses local when the classifier is disabled; enabling Bonsai does not change a Main role already pinned to local or cloud.

Bonsai was chosen specifically because it is purpose-trained to understand task complexity and model capability -- not as a general assistant. Using it only for routing preserves VRAM for llama-swap models.

Brainrouter connects to one OpenAI-compatible Manifest endpoint and one configured API-key environment variable. Default cloud selections send model: "auto"; explicit cloud role IDs and cloud/<id> pass the provider ID unchanged. Manifest selects the downstream cloud provider. The actual model is taken from reported response metadata, not assumed from the requested name. Manifest is off by default; cloud-disabled requests preserve local fallback behavior and expose that outcome.

The coupling is minimal: if Manifest is replaced with LiteLLM or OpenRouter, one URL in brainrouter.yaml changes.

• POST /v1/chat/completions -- OpenAI format. Covers vibe, opencode, codex, omp, pi (via extension).
• POST /v1/messages -- Anthropic Messages API format. Covers Claude Code (via ANTHROPIC_BASE_URL) and droid (via provider: "anthropic" in custom_models).

Internally the request is immediately translated to OpenAI format and routed through the same Bonsai / Manifest / llama-swap pipeline. Response is translated back to Anthropic SSE events at the edge. Proxy responses are streaming SSE; non-streaming provider completion APIs and OpenAI Responses endpoints are not implemented.

The brainrouter mcp process does not load Bonsai and does not run the review loop. It is a JSON-RPC stdio server that maps four tool calls to HTTP requests against the daemon's UDS. This keeps harness cold-start fast (no model load) and keeps all state -- sessions, health tracker, circuit breakers -- in one place. Both mcp and the CLI share one DaemonClient (src/daemon_client.rs) so there is exactly one HTTP client path into the daemon.

brainrouter cli uses DaemonClient over UDS by default or TCP with --url. It covers core management, routing profiles, catalogs, review configuration, and review lifecycle. It does not start a second inference service. Review requests poll every five seconds with a 30-minute cap, or return immediately with --async. Benchmark and observability workflows use the documented HTTP API or their pages; dedicated CLI subcommands for those workflows are not shipped.

When an agent requests a review, the service snapshots its Reviewer choice and iteration settings. The loop uses Router::route_with_choice, independently of the Main and subagent choices. This means:

• Explicit local/cloud reviewer IDs are honored; an Auto reviewer follows classifier behavior, not the current Main override.
• If Manifest is down, review calls fall back to llama-swap automatically.
• The same provider clients, circuit breakers, and streaming protections are reused.
• Changing global preferences affects new reviews, not the reviewer of an existing session or continuation.

src/project_pins.rs persists optional {main, reviewer, subagent} overrides keyed by the canonical absolute Git repository root of a request cwd. The store is loaded from project_pins.json beside the default config state, writes with owner-only atomic replacement, and treats missing/corrupt/unreadable files as empty so every project inherits the global profile by default. A lock-free has_pins flag keeps the proxy hot path from doing filesystem work when the store is empty or when the client sent a selector that never consults a pin.

Role precedence is deliberately role-specific: Main uses explicit request model > project pin > global profile > auto for auto/empty selectors; Reviewer injects a reviewer pin into a fresh review's config snapshot before admission; Subagent consults the pin only for subs/brainrouter/subs. GET /api/project-pin?path=... normalizes a raw path for the dashboard, while POST is a strict full replacement (path, main, reviewer, and subagent all present; null means inherit) and DELETE removes by normalized key.

Two independent circuit breakers: one for manifest, one for llama-swap. Three failures within a window open the breaker; 60-second cooldown before retry. This prevents hammering a degraded provider while allowing automatic recovery.

The adapter translates content/tool events and protocol termination, handles split lines, and reports stream failures. It drains final usage, [DONE], and clean EOF before final Anthropic terminal events so measurement capture is not abandoned at finish_reason. Tail waiting is bounded to two seconds from the first finish/DONE marker, with additional 256 KiB total, 64 KiB line, and 1,024 subsequent-chunk budgets. Content continues streaming; invalid, cancelled, errored, or incomplete tails do not produce successful performance samples.

Destructive operations (upgrade, restart) are restricted to loopback interfaces (127.0.0.1, ::1) or Unix Domain Sockets. Browser-originated requests to management endpoints are validated against Origin/Referer headers. Working directory tracking for sessions includes absolute-path enforcement, null-byte rejection, and path-traversal component blocking.

When enabled on a managed local route, the prompt rewriter replaces verbose harness instructions with a lean local system prompt and anti-loop directives. It is off at daemon startup. Direct local IDs, including explicit local role models, bypass rewriting; not every auto alias necessarily reaches a managed local route.

The rewrite is coupled to the classifier server-side, not just in the UI: turning Bonsai off via the toggle/CLI forces the rewrite flag off with it (the invariant "rewrite on ⇒ Bonsai on" holds in the daemon), and POST /api/prompt-rewrite refuses to enable while Bonsai is down. Direct model picks are never rewritten — only managed local routes.

The Discord and Signal transports ship as the bridge plugin (v2 L2): a sidecar binary (brainrouter-bridge) supervised by the daemon and spoken to over a per-plugin Unix-domain socket (newline-delimited JSON-RPC 2.0). They do not call LLMs directly. They shell out to the omp CLI as a subprocess, which connects back to brainrouter through the normal proxy path. This means bridge conversations get the same routing, fallback, and review capabilities as direct harness usage. Session state, working directories, and model aliases are persisted to disk per-transport in the plugin state dir.

The MCP server needs to know the caller's working directory. On Linux, brainrouter resolves this by mapping the peer's socket connection (TCP or UDS) back to a PID via /proc, then reading /proc/<pid>/cwd. This is a Linux-native approach that avoids requiring the caller to pass CWD explicitly, though callers may override it.

src/escalation/templates/main_dashboard.html organizes the main dashboard as four primary destinations: Overview, Models, Benchmarks, and Config. Models has internal tabs for Local models, Downloads, and Serving plus a link to /models. The command bar contains the frequent controls: project/global scope selector, Main model controls, reviewer/subagent expander, Flush Models, Restart Local Stack, Sync Models → OMP, a /api/service-health health pill, and a read-only posture line for nudge/review/HankNDory/PR state. Set-and-forget quality toggles, plugins (status, config, logs), toolbox inventory, service status/restarts, and raw config editors live in Config. The Plugins destination (v2 L2) lists installed plugins with state and set_status lines, enables/disables them, edits plugin config, and shows HTML-escaped plugin logs.

The registry gives the dashboard a live view of every in-flight request — the "monitor LLM activity without opening llama-swap" goal. Each request registers an entry at handler entry, before route_tagged, so the row is visible during model load (when the registry is otherwise idle). The entry's identity (InflightHandle) is an Arc carried by the spawned routing task and, once routing resolves, by a SniffStream that wraps the provider's SSE stream. The row is removed when the last handle drops — i.e. at stream end, on a routing error (no stream is created, so the task-side handle is the last one), or on an explicit dashboard Cancel (a watch channel flips a flag; the SniffStream ends the stream immediately and the handles drop). Stale entries (older than a grace window) are swept on read.

The activity label is derived by sniffing the head window of each SSE chunk for provider-specific markers (tool_calls / toolUse → tool calling, reasoning_content / thinking → reasoning, multiple choice → asking, otherwise generating). The sniff is sticky with a priority order — tool calling > reasoning > asking > generating — so a strong signal is never downgraded by a later weaker one.

model is an interior-mutable Mutex<String>: it starts as the requested model and is updated to the resolved llama-swap model key after routing.

When installed via install.sh on a shared Fedora machine:

Optional typed YAML defaults: {preset, main, reviewer, subagent_model}. Main/Reviewer are {backend: auto} or {backend: local|cloud, model: null|"<explicit-id>"}. Subagent is a local model ID or null. Presets are auto, cloud, local_main_sub, local_custom, cloud_main_local_review, local_main_cloud_review, and custom; role backends must match the preset. local_custom requires an explicit local Main model. Applying a preset preserves the independently selected subagent pool.

Without routing, Main defaults to local, Reviewer derives from review, and the pool derives from llama_swap.subs_model. Per-user $XDG_CONFIG_HOME/brainrouter/routing_state.json (otherwise under ~/.config) takes precedence over YAML role defaults. Writes validate before committing runtime state and use atomic owner-only files. review.max_iterations is YAML-owned across restarts.

When the new state file is absent, valid legacy review_state.json overrides migrate and persist once; the legacy file is not deleted. File reads alone normalize the old, ignored forced_mode: auto + forced_model combination, warning with the source path and removal guidance. New write APIs remain strict; local/cloud choices and other errors are not silently normalized. Migration errors identify their source/destination and cause. Resetting to YAML requires moving aside both new routing state and any retained legacy state while the daemon is stopped; removing only the new file can trigger legacy migration again.

database_path is optional and defaults to $XDG_DATA_HOME/brainrouter/benchmarks.sqlite3, or ~/.local/share/brainrouter/benchmarks.sqlite3. Use an explicit absolute path for an override; no shell ~ expansion is performed on a configured path. Initialization failure produces a logged explorer-only HTTP 503, not a core daemon startup failure. Repair the path/database and restart to retry; newer schemas are never downgraded.

Alert policy and explicit baseline mappings live beside the selected config: brainrouter.yaml -> brainrouter.observability.json (Path::with_extension). The page/API performs revision-checked writes; copy the latest revision and full policy from GET /api/observability/settings before changing it. Corrupt/unreadable settings expose errors and disable saves until repaired/restarted, but leave core routing and live observations available. Revision counters reset on restart; clients must reload settings before writing.

The v1 bridge.* YAML keys are gone. Discord/Signal run as the bridge plugin: install it with brainrouter plugin install plugins/bridge (from a built dist: plugin.toml + brainrouter-bridge), enable with brainrouter plugin enable bridge. The plugin reads its config — the v1 bridge.* keys minus the Discord token — via the config.get RPC (namespaced per plugin, edited with brainrouter plugin config set bridge <key>=<value> or the dashboard Plugins tab; the per-transport pause is discord.enabled / signal.enabled). The Discord token lives only in the credentials store (migrated from v1 YAML at boot; id discord_token, granted to plugin bridge) and reaches the plugin exclusively through the grant-enforced secrets.get RPC. Signal keeps its direct llama-swap listing via the live llama_swap_url config key (v1 parity). Persistence: on first start the six v1 JSON files under ~/.local/share/omp-bridge/ are copied into the plugin state dir ($XDG_STATE_HOME/brainrouter/plugins/ bridge/, 0700); v1 originals are kept for revert. Restore the v1 config state with brainrouter migration restore v2.0-p2.

Thin client for core management, roles, and reviews. --socket <path> selects the daemon UDS, --url http://… talks TCP instead. Output is JSON except raw YAML config commands. Explorer/observability workflows additionally use HTTP directly.

review get/continue/lgtm/resolve validate sessionId (alphanumeric + -/_) before URL use — path-traversal guard.

The bridge-only dependencies (serenity, async-trait, serde_yml) now live in the standalone plugins/bridge workspace, not the core.

Incoming request (OpenAI or Anthropic format)
  |
  v server.rs: deserialize, translate if Anthropic; extract_session_id()
  |           reads a client conversation header (x-omp-session / x-session-id /
  |           x-conv-id / x-conversation-id / x-client-session / x-request-conv)
  |           so the dashboard can group events per conversation
  |
  v router.rs: default/auto aliases resolve Main with explicit > project pin > global > auto
  |           review calls instead use the session's Reviewer snapshot; fresh reviews
  |           first inject a project reviewer pin when one exists
  |
  v match on the resolved selector — only managed routing tokens get
  |           Bonsai/nudge/subs treatment; every other key is a DIRECT model
  |           selection and is authoritative (bypasses Bonsai entirely)
  |
  +-- resolved Auto role --> classifier.rs (skipped if Bonsai disabled)
  |     +-- Cloud --> manifest (if enabled + healthy) --> llama-swap fallback
  |     +-- Local --> prompt_rewriter.rs (when rewrite on) --> llama-swap (Bonsai-chosen model)
  |
  +-- model="local" --> prompt_rewriter.rs only when rewriting is enabled
  |                  --> llama-swap (fallback_model)
  |
  +-- model="cloud" --> manifest (if enabled + healthy) --> llama-swap fallback
  +-- model="cloud/<id>" --> exact Manifest model --> same cloud fallback policy
  |
  +-- model="subs" / "brainrouter/subs" --> project subagent pin if present, else
  |     current local pool, bypassing Bonsai; unconfigured -> classifier/auto,
  |     NOT the Main profile override
  |
  +-- model="brainrouter/<key>" or any bare key --> llama-swap (that key), no rewrite,
  |     no classifier hop; works even when Bonsai is off
  |
  +-- nudge (if enabled): inject reasoning_budget_tokens on local routes
  |     unless the client already supplied one
  |
  v provider/openai.rs: HTTP request to chosen backend
  |
  v stream.rs: timeout/keepalive protection; event-correlated measurement wrapper
  |
  v health.rs: record success/failure for circuit breaker
  |
  v If Anthropic client: anthropic.rs SSE state machine translates back
  |
  v Response streamed to caller

route_local takes an allow_fallback gate:

• Managed routing (auto/local tokens) passes allow_fallback: true — if the chosen local model fails, the router retries once with fallback_model.
• Direct model picks (any named/bare key, subs, specific-key routes) pass allow_fallback: false — a failed explicit selection surfaces the error to the client instead of silently switching models. This is the "memory compaction" fix: a failing ds4-* pick used to jump to the subs pool behind the agent's back; direct picks are authoritative.

Every failed hop is recorded in RouteInfo.failed_attempts (stage, provider, model_key, error) and the router emits one RouteEvent per failed hop plus one for the winner. The dashboard therefore renders multi-hop routes as a hop chain (e.g. manifest ✗ → local ✓) inside the card body; the Sankey ROUTING column embeds the chain in the routing node key itself.

Both Bonsai and Manifest disabled (the default): auto → local, cloud → local — every request is a single hop to llama-swap.

Agent calls mcp_brainrouter_request_review (or: brainrouter cli review request <taskId> <summary>)
  |
  v mcp_server.rs / cli.rs: POST /review/api/request-async over UDS
  |
  v escalation/mod.rs: parse request (invalid cwd → HTTP 400, no silent fallback),
    call ReviewService::start_review_async
  |
  v review/context.rs: gather context
  |   - Auto-detect PRD in project
  |   - git diff HEAD
  |   - Read AGENTS.md if present
  |   - Safe UTF-8 truncation
  |
  v review/review_loop.rs:
      for i in 1..max_iterations (default 5):
        review/prompt.rs + review/tokens.rs: build a token-budgeted prompt
        if protected content overflows or required evidence is truncated, escalate safely
        router.route_with_choice(snapshot) --> selected local/cloud/default reviewer
        parse JSON response (STATUS: approved | needs_revision)
        update session + llm_turns in the in-memory session store
        if approved --> return success
      if max_iterations reached --> escalate to human UI
  |
  v response: {sessionId} (async) — CLI/MCP poll GET /review/api/sessions/{id} every 5s
  |
  v Dashboard: GET /review/ redirects to /dashboard; JSON/session detail APIs remain available
  |
  v Human resolve: POST /review/api/resolve (or cli review resolve / lgtm)
  |
  v Continue: POST /review/api/continue — registers a notifier and waits for
    human resolution if the continuation escalates; seeds from llm_turns

Runtime switches are GET/POST /api/review/enabled, /api/review/pr-guidelines, and /api/review/hankndory; GET /api/review/status exposes the HankNDory/review ledger. /review/api/* POST routes pass the same is_destructive gate as the other management endpoints (loopback-only + Origin check), closing the browser-CSRF hole. The legacy blocking POST /review/api/request endpoint is still routed but no client uses it; CLI/MCP use request-async + polling.

brainrouter is a native Rust webui for kyuz0's ai-toolbox-cockpit — a Python Textual TUI with no CLI or API mode that otherwise is the only way to manage podman toolbox containers for these backends. brainrouter reads cockpit's own catalog/config formats and reimplements its Toolboxes/Server Mode/Models tabs natively, so managing these backends never requires cockpit to be installed or running. Design rationale, alternatives, and the full phased rollout are recorded in docs/design/ai-toolbox-cockpit-integration.md.

Backends covered: llama_cpp (Vulkan/ROCm), ds4 (DeepSeek4 GGUF), and gufo (Strix Halo ROCm/OpenAI-compatible GGUF serving). v2 L1 purge: halogen, vllm, and r9v were v1-scope serving backends; their code (builders, routes, downloads, panels) is removed and their catalog feed ids now parse as browse-only data (no actionable payload) so the vendored cockpit feed keeps loading unchanged. comfyui is explicitly excluded from every user-facing surface (image-gen, not coding-relevant) — the catalog parser still tolerates it structurally so a shared upstream catalog file never fails to load.

toolboxes.json/models.json are vendored, not fetched at runtime: a pinned copy lives in the repo (assets/cockpit-catalog/SOURCE records the upstream commit), refreshed by a weekly sync-toolbox-catalog CI workflow (.github/workflows/sync-toolbox-catalog.yml + scripts/sync-toolbox-catalog.sh) that opens a PR rather than mutating main directly, so drift from upstream is visible and reviewed, not silent. src/toolbox_catalog/schema_validate.rs structurally validates candidate catalog files before vendoring; unlike upstream's own catalog/schema.py, it is permissive on unrecognized backend ids (warnings, not hard failures), so brainrouter keeps loading the catalog if cockpit adds a new backend before brainrouter has code for it.

Two backend-identity types exist deliberately (src/toolbox_catalog/types.rs): CatalogBackendId is open and lossless (parses every id the catalog can ever contain, including comfyui and the brainrouter-owned gufo overlay); SupportedServingBackend is the closed enum (ds4/gufo/llama_cpp after the v2 L1 purge) that every user-facing surface actually switches on. CatalogBackendId deliberately keeps parsing the removed backends' feed strings (halogen/vllm/r9v) — feed vocabulary, not actionable backends. ModelPayload is a per-backend enum, not one generic struct, because the feed's backends' model entries are structurally incompatible with each other.

gufo is not in the vendored upstream cockpit catalog. src/toolbox_catalog/gufo_overlay.rs embeds assets/gufo-catalog/{toolboxes,models}.json, merges it into clones of the vendored JSON, validates the merged whole with the normal structural validator plus gufo-specific checks, and fails closed if the overlay is malformed or conflicts with upstream IDs. GUFO_BACKEND_ID is "gufo"; the runtime image is ghcr.io/gufo-org/toolboxes/gufo-runtime:latest, and the injected runtime is a Strix Halo ROCm engine.

GET /api/toolbox-catalog and /api/toolbox-models expose the effective typed catalog; GET /api/toolbox-containers lists podman containers across all six backends (generalizing the old llama-only /api/toolboxes, which remains for compatibility). POST /api/toolbox-containers creates a new toolbox container from a catalog entry; /{name}/update, /{name}/delete, and /{name}/adopt cover the rest of the lifecycle, each serialized by a per-container operation lock so concurrent create/update/delete against the same container can't race.

Fedora Toolbx has no toolbox create --label, so brainrouter now tracks ownership in managed_toolboxes.json: a local sidecar mapping container name to the exact live podman container ID, image, catalog ID/revision and timestamp. A container is managed only if it has the legacy label or its sidecar ID matches the live inspect ID. Create pulls the image first and writes the sidecar after inspect; adopt records the current ID without recreating; delete/update/legacy toolbox upgrade are ownership-gated and remove by ID, not by name. The sidecar is atomic-written with mode 0600; corrupt/unreadable state fails safe toward "unmanaged."

src/model_downloads.rs implements native download orchestration for ds4/gufo/llama_cpp (mirroring each backend's own upstream mechanism; the v2 L1 purge removed the halogen/r9v payload assembly and the R9V Prepare-PLE job kind) via a job-registry pattern (queued/downloading/verifying/complete/ failed/cancelled), with OS-level cancel and a global download concurrency limit of 1. vllm is deliberately excluded — its server pulls from Hugging Face on demand at container start, so there is no separate download step to orchestrate, matching upstream's own design. Progress is raw-log-tail only (no byte-level progress bar) because the underlying hf CLI has no machine-readable progress output to consume. GET/POST /api/model-downloads* exposes this. (v1 also carried POST /api/model-downloads/r9v/prepare-ple + ModelPresence.ple_ready as R9V's second readiness gate; removed with the backend by the v2 L1 purge.)

GET /api/model-downloads/status response schema. Returns { "models": [ModelPresence…], "hf": { "found_on_path": bool, "binary": string, "message": string|null, "install_command": string|null } }. The hf object is an advisory preflight: the ds4/halogen/r9v/gufo/llama_cpp download path runs the hf (Hugging Face) CLI on the host, so found_on_path reports whether an executable hf is visible on the brainrouter service's PATH (a best-effort scan; the authoritative check is still the per-job download spawn). When found_on_path is false, message/install_command are populated (python3 -m pip install --user -U "huggingface_hub[cli]") and the dashboard shows a warning banner on the Models/Downloads and Server Mode panels; when true they are null. Install hf on the service PATH as a prerequisite for model downloads (vllm pulls at server start and needs no host hf).

src/server_mode.rs starts/stops/checks-status of headless, detached podman run servers for ds4 and gufo — distinct from the Toolboxes tab's interactive dev-shell containers. GET/POST /api/server-mode/{ds4,gufo}/{status,start,stop} cover the lifecycle. v1 also shipped halogen, vllm (with a cache-paths action), and r9v (with a paths action); the v2 L1 purge removed those builders, their routes, and their panels — requests to the removed paths answer 404. R9V server mode is native Rust but shipped with an explicit "unverified" badge: no 2×AMD R9700 hardware was reachable from this environment to functionally validate ROCm/HSA device passthrough end-to-end (see Open Questions).

Gufo is a Strix Halo OpenAI-compatible ROCm engine. Its server command is podman run ... ghcr.io/gufo-org/toolboxes/gufo-runtime:latest gufo serve --host 0.0.0.0 --port <port> --sessions <n> llm --model /models/<main>.gguf --served-model-name <model_id> --context <ctx>, with optional DFlash2 speculative decoding appended as --speculative dflash2 --dflash-model /models/<draft>.gguf. src/serving_identity.rs reports openai_compatible=true for gufo and derives compute_api="rocm", but this remains bookkeeping only — the request router still does not dispatch to gufo.

src/cockpit_config.rs reads cockpit's own JSON config file directly, so both tools share one source of truth for active_platform and per-backend default toolboxes — instead of a second, divergent brainrouter-only config. This is Phase 1 only: brainrouter never performs continuous, automatic read-modify-write against this file; the only write path is an explicit, user-triggered "apply" action scoped to the specific keys cockpit itself owns (GET /api/cockpit-config, POST /api/cockpit-config/default-toolbox, POST /api/cockpit-config/active-platform). A continuously-synced bidirectional merge protocol is explicitly out of scope for this rollout (user-confirmed — see the design doc's Decision log), since no brainrouter/cockpit locking protocol exists upstream to make concurrent writes safe. If the config directory doesn't exist on a host, brainrouter surfaces that rather than silently auto-creating it.

src/serving_identity.rs records a {toolbox_backend, compute_api, runtime_profile_id, endpoint} fact per currently-running, brainrouter-managed Server Mode container (GET /api/serving-identities). This is read-only bookkeeping, not a routing mechanism — it does not make any backend reachable from brainrouter's actual /v1/chat/completions request router. Only llama_cpp (via Manifest/llama-swap) is genuinely routable traffic today; every other backend renders as an explicit status_only entry in the Sankey/benchmark dashboards below, never faked as routed traffic. Making status_only backends actually dispatchable is unshipped future work — see Planned and Unshipped Work.

The dashboard's routing Sankey (GET /dashboard, described under Dashboard above) gains two additional columns: toolbox backend (which of the six families served the request) and compute API (vulkan/rocm/etc.). Both are nullable/additive on RouteEvent; the existing 4-column behavior is a strict subset of the extended layout, and click-to-filter works identically on the new columns. Traffic from backends that aren't yet wired into the router (everything except llama_cpp today) renders in an explicit status_only bucket rather than being omitted or faked as routed.

• Not a CLI-parity surface. brainrouter cli toolboxes/upgrade toolbox remain llama.cpp-only; the new backends are dashboard/API-only today (see Planned and Unshipped Work).
• Not a router-integration. No Server Mode container is dispatchable as real LLM traffic yet — see Serving-identity registry above.
• Not a TUI-fidelity clone. Feature parity is scoped to capabilities (create/update/delete/list/launch/configure), not cockpit's exact widgets, keybindings, or ASCII banner.

v2 R2 feature gate: the explorer (/benchmarks, /api/benchmarks/*, the native lab) compiles only with --features benchmarks; default builds answer the documented 503 degradation envelope ("Benchmark explorer unavailable: … Core routing is still available.") from the same routes, and the dashboard hides the explorer nav link via a server-injected flag. The registry core (store schema, ingestion types, degradation contract) is always compiled.

This is an import/planning/inspection subsystem inside the existing Rust/Hyper daemon, with embedded HTML/JavaScript and SVG charts. It is not a Python/FastAPI sidecar, a model runner, or a benchmark scheduler. Opening pages, discovering metadata, planning matrices, and previewing imports must not start inference.

The initial migration creates normalized SQLite STRICT tables and initializes WAL. Each connection enables foreign keys and a five-second busy timeout. Startup checks the migration identity/version and required tables. A future, corrupt, or unusable database disables only the explorer; it is not reset or downgraded. This is a new dedicated database, not a conversion of ephemeral review sessions or the live routing buffer.

Rust boundary models reject unknown structural fields and invalid enums, negative/out-of-range metrics, malformed lowercase SHA-256 values, invalid timestamp order, invalid parameter/test/proposal relationships, and integers too large for normalized SQLite integer columns. Backend-specific metadata remains JSON. Feature states distinguish unsupported, disabled, enabled, and requested_unavailable; speculation kinds are recorded, not executed.

An experiment hash covers the canonical serialized registry IDs and complete experiment settings but excludes its application ID. Registry fingerprints protect those referenced identities from later mutation. Artifact, executable, manifest, and build metadata are declarations supplied by the importer; the daemon does not hash/download files or attest what a runtime actually loaded. Declared draft-artifact references must exist.

Runs are uniquely identified by ID and (experiment_id, repetition). Those dimensions cannot move. A succeeded run is immutable; a correction requires a new repetition or experiment. Other statuses (planned, running, failed, oom, timeout, cancelled, skipped) may receive a replacement full bundle under the same attempt identity. This is not an append-only live telemetry feed.

1. A complete bundle includes model, artifact, runtime, hardware, workload, experiment, and run, with optional performance, speculation, quality, and telemetry sections. Cross-references must agree.
2. Validation/prepare endpoints exercise transactional ingestion checks and roll back. Only explicit ingestion commits; previews neither reserve IDs nor guarantee a later concurrent import will succeed.
3. Reusable templates contain registry definitions plus an experiment, not a run payload. /prepare combines a template, explicit repetition/status/command, optional timestamps/llama-bench output, and optional selected plan candidate. Existing matching custom IDs are reused.
4. The llama-bench adapter accepts one object, an array, or a results array. It rejects ambiguous/repeated/contradictory phases, invalid metric types, conflicting bundle metrics, and incompatible reported token counts. Generic avg_ts/tokens_per_second/tps must resolve to one phase; combined tests require separate prompt and generation rates. Raw uploaded output is retained under run.raw_result.llama_bench.
5. JSON/YAML matrices deterministically expand registry IDs, contexts, token counts, and optimization combinations. Duplicate dimensions/configurations are invalid; prompts exceeding context are returned as exclusions. Planning does not validate artifact existence on disk, runtime feasibility, or actual capability support. Repetition/randomization/telemetry fields are execution hints for external tooling, not actions performed by this daemon.
6. The UI supports file upload, validation preview, explicit confirmation, success links, opt-in browser-local template reuse, and plan-candidate selection. Supplied examples are clearly labelled synthetic, with matching IDs and 8K/32K/128K contexts; examples never auto-populate the database.

GET /api/benchmarks/runs returns {items,page,per_page,total,total_pages}. Defaults are page 1, 25 rows, and sort=started_at&order=desc. page must be positive; per_page is 1..100. Exact filters are status, family, backend, workload, quant_name, and speculator_type. q is literal substring search across model/runtime/workload/run labels with SQLite's ASCII case-insensitive LIKE behavior; %/_ are escaped. Blank filters are omitted. Repeated parameters take their last value; unknown parameters, sort fields, and orders are rejected. Unknown exact filter values simply match no rows.

Sort fields are started_at, family, workload, context_tokens, prompt_tps, generation_tps, and ttft_ms, with asc/desc. Timestamp sorting uses creation time when start time is absent. Missing numeric metrics sort last; ties use ascending run ID. A page beyond the result count is empty.

The inspector presents all configuration/provenance, performance/latency, speculation and task-quality data, with ordered host/per-GPU sparklines that keep null gaps and never sum duplicated host readings. Commands, URLs, and paths are inert text. Raw JSON view/download preserves original response text; the browser warns on unsafe JavaScript numeric precision and rejects unsafe import rewrites. quality_score in summaries is the mean of pass@1 results only, not an average of heterogeneous metrics.

The page's scatter/Pareto, context, runtime, quantization, and pass@1-per-GiB views use the current page only (at most 25 runs). The total matching count is separate. Changing page, order, or status selection changes the displayed sample; these views are not controlled cross-workload experiments.

CSV/JSONL export ignores UI pagination and uses one consistent SQLite snapshot. It returns all matching summaries within the documented budgets or an explicit limit error, not partial data. CSV escapes delimiters/newlines and neutralizes spreadsheet formula prefixes. It is not a full database backup, bundle archive, telemetry export, or Parquet implementation.

HTTP parsing/validation/planning/SQLite/serialization executes on bounded blocking workers. Admission survives cancellation until actual blocking work exits, and survives Hyper body drop while response Bytes remain queued; output frames are capped at 16 KiB. A disconnected ingestion may already have committed: inspect its run ID before retrying. Larger records remain in SQLite for offline or synchronous consumers; HTTP does not silently sample/truncate them. Async internal consumers must reuse BenchmarkStore::run_blocking.

runtimes.backend (CHECK(backend IN ('cpu','cuda','rocm','vulkan','metal','sycl','rpc','other'))) already existed and is the "engine" axis surfaced as Engine everywhere in the UI. Migration 0003_toolbox_serving_dimension.sql adds the genuinely new dimension: which toolbox family (ds4/halogen/vllm/r9v/llama_cpp in the frozen migration vocabulary) served a run, via a new serving_runtimes table plus a toolbox_catalog_snapshot table (both nullable/additive; existing llama.cpp-only rows are unaffected). GET /api/benchmarks/filters and GET /api/benchmarks/runs gained toolbox_backend/compute_api as queryable/filterable fields alongside the existing family/workload/etc.

Spider/radar chart (GET /api/benchmarks/spider, rendered on /benchmarks): compares runs across a user-picked pair of axes drawn from models, harnesses, engine, backend, toolbox, speed, and TEPR ("token efficiency to positive result" — see below), with a "compare by" family/workload/family×workload picker, an entity picker capped at 5 series, and an SVG radar renderer with min-max normalization and greyed-out vertices for insufficient data.

TEPR is the confirmed metric definition (signed off by the user). As implemented: SUM(quality_results.generated_tokens) across every attempt in the cohort, divided by the count of positive runs (status='succeeded' and no associated quality_results row with passed=0); runs with zero quality_results rows are excluded entirely. Comparing by model requires a single pinned workload (token cost is workload-dependent); comparing by harness, or by model×harness pairs, needs no pin.

/models (including ?model=<encoded-key>) combines exact local model keys from backend status and observed routes with active requests, reported metadata, completed measurements, and explicit historical references. Read-only polls use /running, /v1/models, and /props for at most four already-ready proxies. No poll loads a model. Backend requests have two-second deadlines, 1 MiB bodies, and a 256-model catalog limit; there is a five-second pause between poll cycles. Unavailable metadata is represented explicitly. Runtime/build/quantization values are shown only when reported; disk size is never used as resident memory. Unattributed/cloud activity is not silently attached to a local model.

The global in-memory limits are 500 route events and 500 completed samples; per-model detail exposes up to 25 recent samples. Restart clears history and alert latches. High traffic can evict a comparison window early.

Alerts compare two disjoint windows from the same local provider/model and measurement source. They are indicative live trends, not statistically controlled benchmark regressions or causal thermal-throttling diagnoses.

Performance comparisons use medians; route-error/fallback warnings use rates and minimum occurrence counts. OOM/timeout labels require corresponding recorded error text. New evidence is required to advance warning/recovery debounce; repeated polls and insufficient data are not recovery. Late/out-of-order completed event IDs remain deduplicated. Router errors are not an exhaustive count of stream failures. Policy/mapping changes reset latches.

Operators preview a succeeded run with a completion timestamp and positive generation/TTFT measurement, then select it for a known exact local model key with the expected experiment hash and a nonempty rationale. Family names are not matched automatically. Configuration/artifact/runtime/hardware/workload provenance is retained independently of live observations.

Reference status is not_selected, unavailable, stale, mismatched, or not_comparable. Even a valid reference remains not comparable until per-sample artifact/build/hardware/context/workload/concurrency identity and metric equivalence can be established. Benchmark failure affects reference lookup, not the live page or core routing; mappings can be cleared while that database is down.

At most 32 baseline mappings are stored, alongside policy, in the config-adjacent observability JSON file. Writes require the latest revision, 128 KiB maximum body/settings size, and a five-second body deadline. Stale revision/hash confirmation returns 409; validation, read, and write errors are visible. Unreadable settings disable saving until repair/restart, not daemon startup. No request history, automated remediation, scheduling, or outbound notifications are persisted or performed by this subsystem.

The Bridge Architecture below ships as the bridge sidecar plugin (v2 L2): the daemon supervises the brainrouter-bridge binary and serves it a grant-gated JSON-RPC surface over a per-plugin Unix socket. Discord and Signal transports bring LLM access to messaging apps. They do not call LLMs directly -- they shell out to the omp CLI as a subprocess, which connects back to brainrouter through the normal proxy path. This means bridge conversations get the same routing, fallback, and review capabilities as direct harness usage.

Each user message triggers an omp subprocess invocation:

1. Transport receives a message (Discord event / Signal CLI poll)
2. Bridge core resolves the session context: working directory, active model, conversation history
3. omp CLI is spawned with the resolved context, pointed at brainrouter as its backend
4. Response is chunked to fit platform limits (Discord: 1500 chars, Signal: 4000 chars)
5. Session state is updated and persisted

Runtime persistence moved to the plugin state dir $XDG_STATE_HOME/brainrouter/plugins/bridge/ (0700). On the plugin's first start, the six v1 files are copied from ~/.local/share/omp-bridge/ if absent; v1 originals are left in place for revert:

Each transport maintains per-channel (Discord) or per-user/group (Signal) state:

• Model selection: Users can set a specific llama-swap model with !br <model-name> (Discord) or !br model <name> (Signal), or switch routing modes with !br auto, !br local, !br cloud. The selection persists across messages until explicitly changed.
• Working directories: Tracked per-channel/user. Commands like !br cd, !br .., and !br mkdir manipulate the working directory, which is passed to omp as the CWD for file-aware operations.
• Sessions: Conversation context is maintained per-channel/user and can be reset with !br reset. Bare text (without any prefix) is treated as a query.

Most POST routes require the loopback/CSRF gate (see Security Model). Covers ds4/gufo/llama_cpp after the v2 L1 purge — never comfyui, and never the browse-only feed ids (halogen/vllm/r9v).

All POST routes require the loopback/CSRF gate. Bodies and result limits apply to previews as well as writes. Responses are JSON unless downloading examples, CSV/JSONL, or HTML.

The MCP server exposes 4 tools via JSON-RPC stdio, forwarded to the daemon over UDS.

Start a new code review session.

List all review sessions. No parameters.

Get details for a specific review session.

Resolve a review session with feedback.

Main, Reviewer and Subagent are model-selection roles, not authorization roles.

Brainrouter binds to 127.0.0.1:9099 by default. Its Unix socket defaults to $XDG_RUNTIME_DIR/brainrouter.sock, falling back to /run/brainrouter.sock. There is no general proxy/read-API authentication layer. Do not expose a non-loopback listener without a separate trusted access-control layer. Protected mutations include routing profiles, /review/api/*, benchmark and observability POSTs, and the listed management operations. They require a loopback peer or the local Unix socket.

The protected gate checks Origin first, otherwise Referer. HTTP localhost, IPv4 loopback, and IPv6 loopback hosts are accepted on any port to support local tunnel/container port remapping. null, non-loopback, malformed, and credential-bearing origins are rejected. Headerless local CLI clients are allowed. The peer restriction still applies; a public HTTPS/Tailscale hostname is not implicitly trusted by this loopback policy. This is not a configurable general reverse-proxy origin allowlist.

The legacy /review/session/:id/resolve form route is not in the /review/api/* prefix gate. Keep the listener local and use the protected JSON review APIs for automation; this gate is not general authentication for every route.

Imported commands/paths/URLs are never executed or fetched. Browser rendering uses inert text, CSV exports neutralize spreadsheet formula prefixes, and benchmark/observability bodies and workloads are explicitly bounded. Raw imported environment/result metadata can still be sensitive; operators must redact it before importing or sharing exports.

Working directory tracking (for bridge sessions and review context gathering) enforces:

• Absolute path requirement
• Null-byte rejection
• Path-traversal component blocking (no .. escapes in session-tracked paths)

Required configuration is validated at daemon startup:

• manifest.base_url must start with http:// or https://
• bonsai.model_path must exist on disk — only when bonsai.enabled: true; a missing file with Bonsai off does not crash startup (Bonsai can be enabled later at runtime once the model is in place)
• llama_swap.fallback_model is required

The Manifest API key (mnfst_*) is never committed: it lives in /etc/brainrouter/env (shared) or each user's ~/.config/brainrouter/.env, and configs reference it by variable name via manifest.api_key_env. Per-user repair scripts in deploy/*.sh are machine-local and gitignored — they never embed the key; they source it from an existing .env on the machine or prompt the admin for it at deploy time.

/etc/brainrouter/env is owned root:aistack with mode 640. Only the root user and members of the aistack group can read it. install.sh adds every human system user to aistack automatically. Individual users never have write access to this file -- only root can update the API key. The file is not world-readable; a user not in aistack cannot extract the Manifest API key.

Required core configuration/routing-state failures remain explicit startup errors. Optional benchmark storage and observability-settings failures are isolated as described above; legacy auto-mode compatibility is a read-only normalization, not weakened validation for new writes.

• Not a multi-provider cloud backend. Brainrouter implements OpenAI-compatible proxying and an Anthropic wire shim; Manifest handles downstream cloud providers and pricing.
• Not a general request-time model runner. brainrouter proxies chat traffic to Manifest/llama-swap and manages detached Server Mode containers for status/operations; the request router does not dispatch to Server Mode containers. It only spawns the single classifier llama-server for Bonsai.
• Not an auth layer. Loopback is the default trust boundary, not user authentication. Credentials live in provider configuration/environment.
• Not a conversation store. Chat history is managed by the harness. brainrouter is stateless for proxy calls; review sessions are in-memory and lost on daemon restart.
• Not a chat application. The Discord/Signal bridges are thin wrappers around the omp CLI, not standalone chat bots with their own reasoning.
• Not a benchmark executor or runtime attestation service. Registered capabilities/hashes and imported metrics do not prove artifact integrity, runtime feature support, or controlled comparability.
• Not a persistent live-traffic monitor. Samples and alert latches reset on restart; role preferences, project pins, benchmark records, toolbox ownership sidecars and explicit observation settings persist.

The implementation baseline was verified with 192 Rust tests and 31 Node browser-logic tests using fixtures/stub providers, without real inference. Coverage includes both wire protocols, event-ID/terminal-frame measurements, hybrid roles and continuation snapshots, legacy migrations/strict write APIs, actual daemon availability with invalid benchmark storage, bounded database/ response backpressure, synthetic import-to-reference flows, and alert threshold/dedup/recovery behavior. HTML script syntax and scoped Rust formatting were checked; a debug binary built successfully. This is not a performance benchmark, a real-browser/accessibility certification, or proof of deployment on a particular host.

The ai-toolbox-cockpit integration rollout (docs/design/ai-toolbox-cockpit-integration.md) extended this to 391 Rust tests and 38 Node browser-logic tests, covering catalog structural validation (including deliberately-permissive handling of unrecognized/comfyui backend ids), the toolbox-container lifecycle, cockpit-config read/apply, model-download job state machines, Server Mode command construction for ds4/gufo, the migration-runner's version-3 gate (serving_runtimes/toolbox_catalog_snapshot), and the spider chart's TEPR formula/cohort-pinning/insufficient-data behavior (v2 L1 purge: the halogen/vllm/r9v Server Mode suites were deleted with their backends; the explorer suites additionally run under --features benchmarks). None of ds4/ gufo's command builders have been run against real target hardware from this environment — they are verified against upstream documentation/catalog data and unit-tested in isolation, not integration-tested end-to-end on a real podman/GPU host. Ship behind an explicit "unverified" badge until a real host confirms them.

cargo test --locked
cargo clippy --locked --all-targets
node --test scripts/test-benchmark-ui.cjs
bash scripts/check-html-js.sh
cargo build --locked --bin brainrouter

Existing unrelated Clippy warnings remain; strict CI must distinguish baseline warnings from new diagnostics. Transferring source/Git commits does not rebuild, install, or restart a running binary. Plan any runtime rollout separately.

These are ideas requiring separate approval, not acceptance claims for this release.

• Bonsai as a Strategic Context Expert -- real-time synthesis of cloud agent output
• Interrupt-and-redirect: user types a correction mid-stream; brainrouter cancels and re-prompts
• Persistent review sessions (SQLite) so they survive daemon restarts
• Persistent request history, per-request token costs and budget enforcement
• Non-model per-project settings, optional strict cloud fallback consent, reviewer diversity rules, and escalation ladders
• Quant Lab: actual llama-perplexity/PPL/KLD execution, compatible same-family reference checking, queued/sequential runs with cancellation/progress, per-token distributions and GGUF parsing
• Model Compare: complete common-suite execution across unrelated families, token-space compatibility checks, and blind human evaluation
• Automated benchmark scheduling, controlled regression campaigns, outbound notifications, or automatic model switching
• Parquet export and an integrated analytical warehouse
• Runtime-loaded component attestation (PLE/n-gram tables, adapters, caches, retrieval assets), beyond declared registry provenance
• Runtime context-selection controls: the retained cli context command has no implemented /api/context server route
• brainrouter cli parity for ds4/gufo. The toolbox backends are dashboard/API-only; cli toolboxes/cli upgrade toolbox remain llama.cpp-only. (v1's halogen/vllm/r9v scope in this item was removed by the v2 L1 purge.)
• Register downloaded GGUFs into llama-swap. Designed in docs/design/llama-swap-register-downloaded-gguf.md, not implemented.
• Router integration for Server Mode backends ("PR 11b" / Feature B). Server Mode containers are not dispatchable as real request traffic; Router/route() still only knows Manifest + llama-swap. This is the prerequisite for status_only Sankey/benchmark entries to ever become real routed traffic, and needs its own pre-implementation design note plus a live deployment to validate against before it touches request dispatch.
• R9V functional validation on real 2×AMD R9700 hardware. v1 scope; the r9v backend was removed by the v2 L1 purge (see docs/design/v2-streamlining.md L1) — re-validating this hardware path requires a new backend per the v2 engine-adapters plan (R6), not a revival of v1 code.
• Bidirectional/continuous config.json sync with ai-toolbox-cockpit. Only an explicit, user-triggered single-write "apply" path exists; no locking/conflict protocol is defined for concurrent brainrouter+cockpit writes.
• ROCm/AMD-GPU auto-detection. brainrouter has no rocminfo/sysfs-based hardware detection; R9V is offered as a selectable option and fails loudly on unsupported hardware rather than being auto-hidden.

The notes motivating Quant Lab/Model Compare are not fully implemented by the current explorer. Ember/Flash environment, cache-building, or provisioning work is not a shipped Brainrouter feature. Existing tables, chart labels, and imported measurements must not be presented as an execution pipeline or attestation.