Capability-aware AI routing without model lock-in

Using one frontier model for every request is simple, but simplicity at the integration layer can become waste at the inference layer. Summarising a short note, interpreting an image, calling a tool, and reasoning through a risky change do not require the same capability. Vyom is an open research implementation of a different default: classify the work first, then use the lowest-cost model that clears an explicit capability floor.

1. The research question

Can a transparent router reduce unnecessary frontier-model use without hiding the quality trade-off? The important word is transparent. A routing system is only useful when a team can inspect why a tier was selected, reproduce the decision, and override it when the policy is wrong.

2. What the router observes

• Task difficulty and whether multi-step reasoning is required
• Tool use, coding context, and multimodal inputs
• Language and sovereignty constraints
• Action risk, including whether a request can change external state
• Confidence in the classification itself

These are routing signals, not claims about the eventual answer. The classifier does not know whether an answer is correct; it estimates which capability tier should attempt the work and whether escalation should remain available.

3. Lowest cost is not the same as cheapest model

The target is the lowest-cost capable route, not the lowest unit price. A cheap model that fails and triggers repeated attempts can cost more than a stronger first response. Vyom therefore uses quality floors: budget models for routine work, mid-tier models for harder or multimodal work, and frontier models only when the task or low confidence warrants them.

4. Context is part of the bill

Model choice is only one cost lever. Long tool output, repeated history, and untrimmed document text can dominate input tokens. Vyom compresses context by tier and preserves the final user turn, while allowing compression to be disabled when fidelity matters more than savings.

5. BYOK as a trust boundary

The public Vyom experience accepts a user-supplied OpenRouter key for the active browser session. The key is sent in a request header to the router, used for that request, and is not written to Vyom's database. Teams that need a stronger boundary can self-host the MIT-licensed code and supply provider credentials through their own environment.

6. How to evaluate it honestly

• Create a task set that represents your real workload, not a generic leaderboard
• Define pass criteria before running models
• Record selected tier, model, latency, tokens, cost, and evaluator result
• Compare routing against a fixed-model baseline
• Review failures by task class and raise capability floors where needed

This paper deliberately publishes no universal savings percentage. Savings depend on workload mix, provider pricing, retry behaviour, and the quality threshold a team sets. The repository includes an evaluation harness so those numbers can be generated for a specific workload instead of invented for a marketing page.

7. Failure modes

• A weak classifier can under-route difficult work
• Provider model aliases and prices can change
• Compression can remove context a smaller model needs
• Automatic escalation can erase savings if its threshold is poorly tuned
• High-risk decisions still require application-level approvals and human review

8. Why open research matters

Routing affects cost, latency, data movement, and answer quality. Those decisions should not disappear behind a proprietary score. Vyom exposes its policy and metadata so teams can challenge the route, run their own evaluation set, and change the rules. The useful result is not a claim that one router is always best; it is a system whose decisions can be tested.