Show HN: Smart model routing directly in Claude, Codex and Cursor

The emergence of a model router designed to plug directly into coding agents like Claude Code, Codex, and Cursor represents a practical shift in how developers interact with large language models. The tool, built by the team at Weave, intercepts requests from these coding environments and dynamically routes them to the most suitable model based on the task at hand—whether that’s a lightweight model for simple completions or a more powerful one for complex reasoning.

What Happened

The core innovation here is not a new model, but a middleware layer that sits between the developer’s coding agent and the underlying AI models. Instead of forcing a user to manually switch between, say, Claude Opus for architecture discussions and a faster model for autocomplete, the router makes that decision automatically. The demonstration shows a local setup where the router evaluates each request’s complexity, latency requirements, and context size, then dispatches it accordingly. This is a significant departure from the current norm, where developers often lock into a single model provider or manually toggle between them.

Why It Matters

The practical value is twofold: cost and performance. Coding agents are notoriously expensive to run at scale because they generate many small, frequent requests. Sending every single autocomplete suggestion to a frontier model like GPT-4 or Claude 3.5 Opus is wasteful—both in terms of latency and API cost. A router that can shunt trivial tasks (e.g., closing a bracket, completing a variable name) to a cheaper, faster model while reserving heavy lifting for high-end models directly improves the economics of AI-assisted development.

More importantly, this approach introduces model-agnosticism into the coding workflow. Developers no longer need to commit to a single provider’s ecosystem. If a new model outperforms others on code generation next week, the router can be updated to prefer it without changing the user’s interface or habits. This reduces vendor lock-in and lets the market for coding models compete on merit rather than integration convenience.

Implications for AI Practitioners

For individual developers and teams, this tool lowers the barrier to using multiple models effectively. The current state of the art often involves manual trial-and-error: “Let me try this prompt in Claude, then switch to GPT-4 if it fails.” Automating that selection means developers can focus on writing code rather than managing model orchestration. It also opens the door to more sophisticated routing logic—for example, routing security-sensitive code reviews to a model with stronger safety alignment, or routing documentation generation to a model optimized for natural language.

However, there are caveats. The router’s effectiveness depends entirely on its classification accuracy. Misrouting a complex debugging task to a weak model could produce misleading suggestions, eroding trust. Additionally, running the router locally (as shown in the demo) introduces overhead—both in terms of setup complexity and computational resources. For teams already struggling with toolchain bloat, adding another layer may feel like a burden rather than a benefit.

Key Takeaways

• Dynamic model routing can significantly reduce API costs by matching task complexity to model capability, avoiding unnecessary use of expensive frontier models for trivial operations.
• Vendor lock-in is reduced as the router abstracts away the choice of model provider, allowing teams to switch or mix models without changing their coding agent workflow.
• Practical adoption hinges on routing accuracy and local setup friction—developers will need confidence that the router won’t misclassify tasks, and the installation process must be seamless to avoid becoming another tooling headache.