Per-Action Model Routing: How Weave Router Replaces One-Model-Per-Workflow with Runtime Selection

Weave Router is a drop-in model-routing layer for agentic systems. Instead of sending every model call in a run to the same LLM, it evaluates each upstream action and chooses from the models you’ve enabled using an in-process ONNX embedder and cluster scorer. It speaks Anthropic, OpenAI, and Gemini APIs, can route to models from providers such as OpenRouter and other OpenAI-compatible endpoints, and works with tools like Claude Code, Codex, Cursor, and custom apps without requiring you to redesign the application around a new API. In the self-hosted setup, the router, scorer, database, and provider keys stay on your machine, while prompts go directly to the configured model provider, routing decisions can also be inspected through traces and analytics.
The core idea is simple
treat model selection as a runtime decision for every agent action, rather than hard-coding one model for the entire workflow.

Overall, the description matches how Weave Router is actually documented and reported — I didn't find factual contradictions. A few notes:

Checks out:

• Per-action routing, not one-model-per-workflow: confirmed — a cluster scorer picks the right model from your enabled providers for every upstream API request, and the router routes per action, not per turn.
• In-process ONNX embedder + cluster scorer: confirmed — each request is embedded with a small in-process ONNX model and scored against a frozen set of intent/cluster centroids.
• Speaks Anthropic/OpenAI/Gemini, routes to OpenRouter and OpenAI-compatible endpoints: confirmed — it speaks Anthropic Messages, OpenAI Chat Completions, and Gemini native APIs, and can route to OpenRouter and any OpenAI-compatible endpoint, plus OSS models like DeepSeek, Kimi, GLM, Qwen, Llama, Mistral.
• Works with Claude Code, Codex, Cursor, custom apps as a drop-in: confirmed — it's built to point Claude Code, Codex, Cursor, or your own app at localhost:8080, and reviews describe it similarly working with opencode too.
• Self-hosted: router/scorer/DB/keys stay local, prompts go direct to provider: confirmed — the router, the scorer, Postgres, and your provider keys all stay local; prompts go from the router straight to the provider you configured, never to Weave.
• Traces/analytics for inspecting routing decisions: confirmed — it exposes an OTLP tracing endpoint and a dashboard for usage/model-selection data.

Minor gaps/nuances in your description:

• You said "database" generically — it's specifically Postgres, storing installation info, API keys, encrypted BYOK keys, and usage data.
• The scorer isn't a from-scratch design — it's derived from the AvengersPro research line, retrained on production traffic, and shipped as a versioned artifact bundle.
• One detail you didn't mention: selection is explicitly multi-objective, not "always pick the smartest model" — within each surviving cluster the scorer picks the candidate that wins on a cost/latency/verbosity composite, conditional on quality being at parity with the top option.
• It's built by a company called Weave, described as the #1 engineering intelligence platform — worth knowing if you're citing provenance.
• Licensing note from a third-party review: it's described as source-available (Elastic License 2.0-style terms mentioned for a related tool, and Weave Router itself is discussed as source-available with "ELv2 licensing" in one review) — worth verifying directly if that matters for your use case, since I only have secondary-source confirmation on the license.

Nothing in your summary is factually wrong based on what I found — it's an accurate, slightly compressed description of the actual product.