WorkWeave's router bets the agent cost problem is an endpoint problem

The most interesting claim in WorkWeave’s new open-source router is not the 40-70% cost cut. It is the mechanism. The tool, called router, claims to pick the right model for every request in under 50 milliseconds using a “tiny on-box embedder” and a “cluster scorer derived from Avengers-Pro 1”, a routing method from a 2025 arXiv paper by Zhang et al. That is a different design from the vibes-based prompt routing most teams hack together, and it is worth reading closely.

The pitch is deliberately frictionless. Point Claude Code, Codex, Cursor, or your own app at localhost:8080, and the router intercepts every upstream API request. It speaks Anthropic Messages, OpenAI Chat Completions, and Gemini native formats, streams responses, handles tools and vision. It also knows open-weights models: DeepSeek, Kimi, GLM, Qwen, Llama, and Mistral via OpenRouter or any OpenAI-compatible endpoint. Provider keys stay on your box, encrypted at rest. OTLP traces ship out of the box. The quickstart is a single npx @workweave/router command.

The genuinely new part is the routing unit. The README is emphatic about the terminology: the router routes per action, not per turn. An agentic session contains many actions: a tool call, a context read, a short code edit, a long reasoning chain. Each action has different model requirements. A one-line sed-style edit does not need a frontier reasoning model. A multi-step refactor might. The router tries to score each action and send it to the cheapest model that can handle it.

That is the right problem to solve. Agentic workloads are where model costs are exploding, and the naive solution, pinning an agent to one big model, is wasteful. The 40-70% savings figure is the headline, but the per-action granularity is what makes the number plausible. Routing per turn would capture some savings. Routing per action captures more, because within a single agent loop the difficulty varies wildly from step to step.

The technical design has a specific shape. The cluster scorer runs an in-process ONNX embedder, which means the embedding happens locally, on the box, not in the cloud. That is what keeps latency under 50ms. There is also an optional “frozen HMM policy” sidecar, a hidden Markov model that can run as a companion container, selected via ROUTER_DEFAULT_STRATEGY=hmm. The HMM path requires a Google API key and is opt-in. The default strategy is the cluster scorer.

There is a real architectural tension here worth naming. The cluster scorer is a static, frozen artifact derived from a research paper. The HMM policy is also frozen. Neither learns from your traffic in the default setup. The router records routing decisions and exports them as NDJSON for analytics, and the Weave dashboard shows traces, but the routing policy itself does not adapt at runtime. That is a deliberate choice for predictability, and it is also a limitation. A router that cannot learn from its own mistakes is only as good as the static scorer.

The Avengers-Pro paper, arXiv:2508.12631, is the intellectual backbone. It argues for performance-efficiency optimized routing: route each request to a model that balances quality and cost, rather than always picking the biggest model. The WorkWeave router is a productionization of that idea, wrapped in an endpoint-compatible proxy. The paper is cited in a footnote, which is a nice touch of academic hygiene for a project that is otherwise very product-forward.

The company behind it is Weave, which the README calls “the #1 engineering intelligence platform”, with Robinhood, PostHog, and Reducto named as customers. That matters for context. Weave already sells observability for AI engineering. The router is a wedge: if your prompts flow through their endpoint, the traces flow into their dashboard. The self-hosted mode keeps prompts off Weave’s servers, but the hosted router is the funnel. The business model is not the router. The business model is the platform it feeds.

The installation story is unusually polished for an open-source project. The npx @workweave/router installer asks which tool you use, walks through scope (user vs. project), grabs a router key, and wires the config file. For Codex, it patches ~/.codex/config.toml with a managed [model_providers.weave] block and preserves the existing ChatGPT OAuth login. For opencode, it merges a provider.weave entry. For pi, it installs an extension rather than forking the binary. The uninstall paths are symmetric: --uninstall rewrites only the managed block, leaving the rest of your config untouched. That is respectful engineering.

There are details that reveal how young this category is. The Codex integration ships native skills: $force-model, $unforce-model, $router-feedback. The pi extension adds a “Loom header” and “Wooly’s animated terminal mascot” and a persistent “WEAVE ROUTER route/savings line”. Cursor support is explicitly labeled “early beta, performance may not be the best”. The README is honest about rough edges, which is refreshing.

The routing decision endpoint, POST /v1/route, is the quiet killer feature. It returns the routing decision without making an upstream call. That means you can inspect what the router would do before committing. For a team that wants to audit model selection, or build its own policy on top, that endpoint is the hook. The analytics export, raw routing decisions as cursor-paginated NDJSON, is the other underrated piece. You can pull every routing decision into your own warehouse and reconstruct exactly what the router did and why.

The cost math deserves scrutiny. The 40-70% figure is a claim, not a measured result for your workload. Savings depend entirely on the mix of actions and the price spread between your cheap and expensive models. If your agent mostly does long reasoning chains, the router has less to save. If your agent does lots of short tool calls, the savings compound. The README does not publish benchmark results on real agent traces, which is a gap. The paper behind the scorer has its own numbers, but those are academic settings.

The competitive context matters. Model routing is becoming a crowded space. OpenRouter has long offered model selection, though mostly as a manual or heuristic choice. Several startups are selling router-as-a-service with claims in the same range. What WorkWeave is doing differently is the per-action granularity, the local embedder, and the endpoint compatibility with the major agentic CLIs. The npx installer that wires Claude Code and Codex in one command is a distribution advantage that pure API routers do not have.

For AI builders, the takeaway is practical. The era of pinning an agent to one model is ending. The cost structure of agentic workloads demands per-step routing, and the tooling is maturing fast. This router is a credible, open-source, self-hostable option that speaks the major APIs and installs in one command. The per-action design is the right abstraction, and the analytics hooks are the right foundation for teams that want to build their own policies later.

The open question is whether the static scorer holds up in production. A frozen cluster scorer derived from a paper is a starting point, not a destination. The teams that get the most out of this will be the ones that export the routing decisions, measure the actual quality impact, and feed that learning back into their own policy layer. The router gives them the data to do that. Whether the default scorer is good enough out of the box is something only real traffic will tell.