> ## Documentation Index > Fetch the complete documentation index at: https://docs.routor.io/llms.txt > Use this file to discover all available pages before exploring further. # Roadmap > What Routor is building next and the order it is being built in. This page describes what has shipped, what is being built now, and what comes after. The order reflects both technical dependencies and what delivers the most value to users first. *** ## Shipped ### Heuristic routing engine A 15-dimensional complexity scorer classifies every prompt into one of five tiers (NANO through COMPLEX) without any LLM calls in the decision path. Routing decisions complete in under 10ms at p99. Models are selected by cost within the appropriate tier pool, and reasoning-heavy prompts within COMPLEX are matched to a model built for chain-of-thought work. ### Automatic fallback and retry If the selected model fails (timeout, error, rate limit), Routor retries through remaining models in the tier pool, then escalates to the next tier. Provider failures are invisible to the application. ### Routing profiles Custom routing rules with dedicated scoped API keys. Each profile enforces a tier range, cost cap, required capabilities, and tool-calling quality floor on every request that uses it. ### Provider health monitoring Rolling 5-minute health window for all 13 providers, with p50/p95 latency, success rate, and request volume. Degraded providers are down-weighted in routing automatically. ### Dashboard Usage tracking, savings display, transaction history, provider health, model browser, API key management, and playground for testing routing decisions. ### OpenAI-compatible API Drop-in replacement. Three lines of code change. No new SDK. *** ## In Progress ### Conversation storage Every request and response will be stored in the database (with user opt-in). This is the foundation for everything below. The schema captures prompt, response, routed model, tier, confidence score, latency, and token counts. Without stored conversations, the routing engine cannot learn from real traffic. This ships first. *** ## Next ### Generation scorer The current heuristic scorer uses rules to estimate prompt complexity. It works well on common patterns but misclassifies edge cases: highly technical one-line questions that need deep reasoning, or verbose but simple prompts that inflate the complexity estimate. The improvement is a lightweight trained classifier that learns from stored routing decisions. The training signal comes from running offline quality evaluation on stored responses (using a judge model outside the request path), then labeling (prompt, tier) pairs with quality outcomes. This classifier replaces the heuristic scorer as the primary routing signal. The heuristic stays as a fallback for prompts outside the training distribution. **Dependency:** Conversation storage must ship first. *** ### Semantic routing Once a corpus of routed conversations exists, semantic similarity becomes a viable additional routing signal. The approach: embed every stored prompt using a small embedding model, store embeddings in pgvector (already in the Postgres stack), and at inference time find the nearest neighbor prompts from the corpus. The tier distribution of those neighbors becomes a prior that combines with the generation scorer output. Requests that closely resemble previously handled prompts route with higher confidence. Novel prompt types fall back to the scorer alone. **Dependency:** Generation scorer and a sufficient corpus of stored conversations. *** ### Provider-aware dynamic routing Current routing ranks candidates by value (quality + cost savings) in the appropriate tier. It does not account for real-time provider performance beyond binary up/down status. This improvement incorporates live signals into the routing weight: * If a provider's p95 latency is elevated, route away from it even if technically healthy * Track request volume per provider and predict rate limit proximity before it triggers * If a provider's outputs start scoring lower in quality evaluation, reduce its routing weight automatically The result is a routing engine that continuously adapts to provider behavior rather than reacting only after a failure. *** ### RAG chatbot for docs A question-answering interface on the Routor documentation, powered by Routor's own API. Users can ask integration questions and get answers grounded in actual docs content. Architecture: pgvector similarity search over embedded doc chunks, answered by a LIGHT-tier model routed through Routor. The system uses its own product to power its own support. *** ### Fine-tuned routing classifier Once Routor has processed sufficient real traffic with quality labels, the heuristic and generation scorer can be replaced with a model trained entirely on Routor's own routing data. This model outputs a confidence-weighted tier probability distribution rather than a hard classification. High-confidence prompts route directly. Lower-confidence prompts can be soft-routed across two adjacent tiers, with the response from the cheaper tier used if it passes a quality gate, and the more expensive tier used as fallback. **Dependency:** Significant data volume from production traffic. *** ## Not Planned **Self-hosting support.** Routor is a managed service. Self-hosted deployment is not on the roadmap. **Streaming response evaluation.** Quality scoring requires complete responses. Streaming and quality-gated routing are architecturally incompatible at this time. **Per-token billing.** Credit billing is based on model cost plus routing margin. Per-token line-item billing is not planned. *** ## Feedback If something is missing from this roadmap that matters to you, open an issue at [github.com/routor-ai/routor](https://github.com/routor-ai/routor) or email [support@routor.io](mailto:support@routor.io).