One endpoint, every model: the Weave Router for AI coding tools

If you use more than one AI coding tool, you already know the pain. Claude Code wants an Anthropic key. Codex wants an OpenAI key. Cursor wants both, plus maybe a Gemini key for good measure. Each tool has its own config format. Each model has its own price-performance tradeoff that shifts every few weeks as providers drop new releases. And you, the developer, are stuck making a single model choice per tool and hoping you picked right.

A new project called Weave Router tries to solve this with a different approach: one local proxy that speaks every provider's API and picks the best model for each request automatically. Not by asking you to configure routing rules. By embedding your prompt locally, clustering it against known model performance data, and routing accordingly. Every single turn.

What it actually does

The router is a Go binary that runs on your machine (or wherever you want). You point your coding tools at localhost:8080 instead of the real provider endpoints. The router intercepts every request, runs a tiny ONNX embedder on the prompt text, scores it against pre-built cluster artifacts derived from the Avengers-Pro routing research paper, and forwards the request to whichever model looks best for that specific prompt.

The cluster scorer is the interesting part. The Avengers-Pro paper trained a system that categorizes prompts by type (code generation, reasoning, creative writing, etc.) and maps those categories to measured model performance. Weave shipped pre-built cluster artifacts: centroids, rankings, a model registry, all baked into the binary. The embedder runs in-process with ONNX Runtime, so there is no network call to decide routing. The scoring takes under 200ms according to the default timeout config.

If the scorer cannot run for any reason (missing model files, timeout, corrupted artifacts), the router returns HTTP 503. It does not silently fall back to a default model. This is a deliberate design choice: a wrong routing decision that costs you real money is worse than an obvious failure.

How the wiring works

The setup story is surprisingly smooth. Run npx @workweave/router and it asks which tool you use (Claude Code, Codex, or opencode), walks you through scope (user vs project), and patches the right config file. Your existing provider keys stay on your box, encrypted at rest. The router gets its own key (rk_...) that clients send as a Bearer token.

# Self-hosted quickstart
echo "OPENROUTER_API_KEY=your-key-here" >> .env.local
make full-setup
# Router at localhost:8080, dashboard at localhost:8080/ui/

Each upstream provider only activates when its API key is present in the environment. Anthropic is special: when ANTHROPIC_API_KEY is unset, the router still registers the provider but passes through whatever Authorization headers the client sends directly to api.anthropic.com. This lets Claude Code keep using your logged-in plan without needing a separate key.

Cursor support is early beta. You set the Override OpenAI Base URL in Settings to http://localhost:8080/v1 and paste the router key as the API key. The README warns that performance "may not be the best," which is honest at least.

What it routes to

The router supports Anthropic (Claude), OpenAI (GPT family), and Gemini natively. For open weight models (DeepSeek, Kimi, GLM, Qwen, Llama, Mistral), it routes through OpenRouter or any OpenAI-compatible endpoint you configure. The cluster artifacts are trained against OpenRouter's model pool, so it is the recommended baseline.

Session pinning is on by default. Once a conversation routes to a model, it stays on that model for subsequent turns. This makes sense: switching models mid-conversation is a good way to lose context coherence. You can disable it with ROUTER_SESSION_PIN_ENABLED=false, or hard-pin a model with ROUTER_HARD_PIN_MODEL for debugging.

By the numbers

The embedder comes in two flavors: Jina v2-base-code for the default cluster artifacts, or a Qwen3-Embedding-0.6B variant with last-token pooling baked into the ONNX graph. Both run as INT8-quantized models. The runtime loads embedders lazily, so you only pay for what you use.

Observability built in

Every request emits two OTLP trace spans: router.decision (what model was picked and why) and router.upstream (how the actual provider call went). The router exports to any OpenTelemetry-compatible collector: Honeycomb, Datadog, Grafana, whatever. When OTEL_EXPORTER_OTLP_ENDPOINT is unset, telemetry is fully disabled at zero runtime cost.

There is also an opt-in content capture mode (WV_CAPTURE_CONTENT) that emits full request/response bodies as OTLP log records. "Full" means the raw bodies in the client's native wire format. There is also a "hashed" mode that only records SHA-256 hashes of content, for privacy-sensitive deployments. I like that they made this opt-in rather than on by default.

The licensing catch

The router is source-available under the Elastic License 2.0 (ELv2). Not a traditional open source license. You can read the code, run it, self-host it. But you cannot offer it as a managed service to third parties. The workweave.ai hosted version is their commercial product. This is the same license Elasticsearch used before their drawn-out trademark dispute with AWS, and it is the same one many "open source" AI companies use to stay commercially viable while sharing code. Whether this bothers you depends on your philosophy.

If you just want to run it locally for your own coding, ELv2 is functionally identical to MIT. The restriction only matters if you were planning to resell router-as-a-service.

What I actually think

The problem is real. I switch between Claude Code and Codex fairly often, and the cognitive overhead of "which model for which task" is genuine. The idea that a per-request embedder can make better model choices than my gut instinct is plausible, especially now that the model quality field is so flat at the top.

What I am less sure about is whether the routing quality is actually better than just using one good model. The Avengers-Pro benchmark numbers look solid on paper, but benchmark performance and real-world coding are different things. A model that is great on HumanEval can still produce baffling architectural suggestions. The router picks the "best" model from its cluster data, but that data comes from standardized benchmarks, not from the messy reality of debugging a 50k-line Python codebase at 2am.

The 200ms embed latency per request is also worth thinking about. On a single request it is invisible. Over a long coding session with hundreds of turns, those milliseconds compound. Not enough to notice consciously, but enough to add a slight mechanical friction. The session pinning helps (only the first turn pays the routing cost), so in practice it is probably fine.

The BYOK story is strong. Provider keys never leave your machine. They are encrypted at rest with Tink AES-256-GCM, and if you forget to set the encryption key the router warns you at startup instead of silently storing plaintext. Even the opt-in telemetry respects deployment boundaries. This is the security posture I want from a proxy that handles my API keys.

When it is worth trying

If you use multiple AI coding tools and find yourself manually switching models based on task type, the router is free to try and reasonably low-risk. The hosted version (npx @workweave/router) takes about two minutes to set up. The self-hosted version requires Docker and Postgres but gives you the dashboard and full control.

If you are happy with one model in one tool and never think about it, this adds complexity for no clear gain. The router's value scales with the number of providers and models you regularly use. Two models is marginal. Four or five makes it more compelling.

I also think this is a sign of where coding tooling is going. As model quality converges at the top end, the competitive advantage shifts from "which model is best" to "which routing strategy is smartest." Weave Router is early, but the approach of embedding prompts locally and routing against real performance data is more principled than most alternatives I have seen.