Routing per action, not per turn, is what makes an LLM router actually useful

The core claim here is that routing decisions should be made per action — a single upstream API call — not per conversation turn, and that the selection mechanism should be a cluster scorer derived from an embedding model running in-process, not a meta-prompt asking a large model to pick another large model. That distinction matters. Vibes-based routing ("use the cheap model for simple questions") is brittle because it requires someone to define "simple" in advance. An ONNX embedder scoring each action against learned clusters sidesteps that problem by letting the geometry of the request space do the work.

The router sits between any client — Claude Code, Codex, Cursor, opencode, or your own application — and Anthropic, OpenAI, Gemini, or any OpenAI-compatible endpoint including OpenRouter. It speaks all three native wire formats and translates between them, so a client configured for Anthropic Messages can transparently land on a Gemini or DeepSeek model if the scorer decides that's the better fit. Provider keys stay on your machine, encrypted at rest; prompts go from the router directly to the provider, never through Weave's infrastructure.

There are two routing strategies. The default is the in-process cluster scorer. The optional path is a frozen Hidden Markov Model policy running as a companion container on port 8093, which the README notes is what the hosted endpoint uses for Codex. The HMM sidecar requires a Google API key and is explicitly opt-in; the README is careful to say that enabling it does not change the default strategy unless you set ROUTER_DEFAULT_STRATEGY=hmm. That separation is sensible — it means the self-hosted stack is fully functional without the sidecar, and the sidecar's behavior is auditable through a documented artifact verification process.

The installation story is genuinely low-friction. A single npx @workweave/router command handles discovery, config patching, and key provisioning for the hosted path. The self-hosted path requires Docker and Postgres but is a two-command setup. The router exposes a /v1/route endpoint that returns the routing decision without making an upstream call, which is the right affordance for anyone who wants to audit or test the scorer's behavior before trusting it with real traffic.

The analytics export — cursor-paginated NDJSON of raw routing decisions, accessible with a read-only key — is a detail worth noting. Most proxy layers treat routing as a black box. Exporting the decisions as structured data means you can actually measure whether the router is saving money or improving quality, rather than taking the vendor's word for it.

The Elastic License v2 is the one real constraint to flag. You can self-host freely, but you cannot offer this as a managed service to others without a commercial agreement. For internal tooling that's a non-issue; for anyone building a platform on top of it, read the license carefully.