Weave Launches Intelligent Model Routing Tool for Claude Code, Codex, and Cursor

Weave released an open-source model router that runs locally and chooses the best large language model for each request without exposing user data.

The tool installs with a single command and acts as a proxy on localhost port 8080. It works with existing clients including Claude Code, Codex, and Cursor.

Users supply their own API keys from Anthropic, OpenAI, Gemini, or OpenRouter. The router stores those keys on the device with encryption and never sends them to external servers.

Weave built the selection engine around a cluster scorer called Avengers-Pro 1. The scorer evaluates available models on every incoming request and routes traffic to the strongest option.

The system supports native API endpoints for three major providers. For additional coverage it connects through OpenRouter to reach DeepSeek, Kimi, GLM, Qwen, Llama, and Mistral families.

Local proxy design removes cloud dependency

Weave designed the router to stay inside the user's network. Once installed, the process listens on port 8080 and accepts standard OpenAI-compatible requests from any client that supports a custom base URL.

Claude Code users can point their configuration file at the local endpoint instead of the Anthropic server. Codex and Cursor follow the same pattern, requiring only a one-line change in their settings.

Because the router never forwards full prompts to a central service, organizations that restrict data egress can still use multiple frontier models inside a single workspace.

The project also includes an OTLP tracing endpoint. Teams that already run observability stacks can collect token counts, latency, and model selection decisions without additional agents.

Model selection happens per request

Avengers-Pro 1 scores models on a combination of historical performance and current load signals. The scorer maintains a short-term memory of recent outputs so it can avoid repeating a model that produced low-quality results on similar prompts.

When a user sends a coding task through Cursor, the router reads the request metadata and runs a quick inference pass across the configured cluster. It then forwards the prompt to the single model with the highest predicted score.

This approach differs from static routing that always uses the same provider. Static setups force developers to maintain separate clients and manually switch when one model falls behind on a new benchmark.

Weave's implementation keeps all decision logic on the device. The scorer weights factors such as output length expectations, coding accuracy on internal test suites, and user-provided feedback from previous sessions.

Data handling stays on the device

Every API key entered by the user is encrypted with a device-specific key before storage. The encryption layer uses standard libraries so operators can audit the code themselves.

Prompt content and responses pass through the local proxy in memory and are not persisted unless the user enables optional logging. When logging is active, the data remains inside the same encrypted directory used for keys.

Self-hosted deployment scripts allow teams to place the router on a private server inside their firewall. In that configuration the only external calls are the model provider endpoints chosen by the router.

The repository includes instructions for running the service as a systemd unit or Docker container, which simplifies adoption inside engineering organizations that already standardize on those runtimes.

Compatibility spans three major coding clients

Claude Code, Codex, and Cursor all expose configuration options for custom base URLs. Weave supplies ready-made snippets that match the expected request and response formats for each client.

Cursor users can switch between models mid-conversation without restarting the editor. The router intercepts the conversation and applies selection logic independently for each message.

Codex integrations rely on the same OpenAI-compatible path, so existing scripts that call the Codex API continue to work after a single environment variable change.

Claude Code users gain access to non-Anthropic models without leaving the Claude interface. The router translates request fields on the fly so Claude Code receives responses that match its expected schema.

Observability features support production use

The OTLP endpoint exports standard traces that include model selection scores, token usage, and latency per request. Teams can import these traces into existing dashboards without writing custom collectors.

Trace attributes also capture which scorer version made the routing decision. This detail lets operators compare performance across different releases of Avengers-Pro 1.

Error handling inside the router returns clear status codes when a provider key is missing or when a model returns an unexpected response. These codes map directly to client error states so downstream tools continue to function.

Usage remains under user control

Weave ships the project under an open-source license that permits both personal and commercial use. The repository contains the full source for the proxy, scorer, and installation scripts.

Users who prefer not to run the service themselves can still review the code before deploying it inside their organizations. No telemetry leaves the local instance unless the operator explicitly configures an external collector.

The project documentation includes examples of combining the router with multiple front-end clients on the same machine. A developer can keep Codex open for one task while using Cursor for another, with the router handling shared model access in the background.

Next signals to watch

Teams will track whether third-party clients add native support for the router's selection metadata. If Cursor or Claude Code begin consuming those fields, the router could influence model choice at the editor level rather than only at the proxy.

Another observable development is the release of updated scorer models. Weave has indicated that Avengers-Pro 1 will receive periodic retraining on new benchmarks, and each update will be published with a changelog describing the evaluation set.

Finally, organizations running the self-hosted version will report internal benchmarks that compare router-guided model selection against fixed-provider baselines. Those numbers, once shared, will clarify whether per-request routing delivers measurable gains in output quality or cost.