OpenRouter: Open Source Routing & LLM Inference
- OpenRouter is a dual-use concept that encompasses both open-source routing platforms with modular and community-driven designs and a unified LLM inference platform that routes AI queries.
- It emphasizes flexibility, extensibility, and cost efficiency in software routers, spanning implementations from embedded firmware like OpenWRT to modular frameworks such as Click and Quagga.
- In AI infrastructure, OpenRouter unifies access to hundreds of models through a single API, supporting privacy-preserving analytics and cost-aware, optimized inference routing.
OpenRouter denotes two distinct but related usages in recent technical literature. In networking, “Open Source Routers” are surveyed under the shorthand OpenRouter as free-software routing systems developed to overcome commercial solutions with closed platforms; they emphasize flexibility, extensibility, cost efficiency, and community support (Fatahi et al., 2022). In contemporary LLM infrastructure, OpenRouter is a unified AI inference platform that sits between developers or end-users and a diverse set of LLMs, providing a single API for routing requests across open-weight and proprietary model endpoints while collecting privacy-preserving, metadata-only analytics (Aubakirova et al., 15 Jan 2026). The shared term reflects a common systems idea: routing as a programmable coordination layer rather than a fixed appliance.
1. OpenRouter in the software-router literature
In the software-router literature, OpenRouter refers to the class of “Open Source Routers,” not to a single implementation. The motivating premise is that closed-proprietary routers from major vendors offer high performance but are expensive, inflexible, and often lack inter-vendor interoperability. The increase in bandwidth demands, new services such as multicast and IPv6, and custom routing requirements created pressure for more programmable and lower-cost platforms. General-purpose PCs had become powerful enough to handle many routing tasks, while open-source software encouraged community-driven innovation, testing, and transparent security fixes (Fatahi et al., 2022).
The key design goals in this literature are explicit. Flexibility denotes the ability to modify or extend routing functionality, including new protocols and custom policies, without vendor lock-in. Extensibility denotes a modular architecture in which new modules, such as a novel forwarding algorithm, can be plugged in at user or kernel level. Cost efficiency derives from commodity hardware, including PCs and embedded boards, combined with free software. Community support denotes a broad user and developer base contributing patches, documentation, and ports to varied hardware. These goals positioned open software routers as alternatives for research networks, campus deployments, and specialized environments where programmability outweighed appliance-style integration (Fatahi et al., 2022).
A common misconception is to treat OpenRouter in this context as a specific router distribution. The survey literature instead uses it as an umbrella term covering multiple implementation styles, from embedded firmware images to modular packet-processing frameworks and protocol daemons (Fatahi et al., 2022).
2. Architectural taxonomy and representative implementations
The survey organizes open-source router systems into four groups. Group-1 comprises embedded systems: low-power routers running firmware such as TomatoUSB or OpenWRT on MIPS or ARM SoCs, including Broadcom and Atheros chips. Group-2 comprises PC-based platforms and is divided into data-plane-centric systems, exemplified by the Click modular router in kernel or user space, and control-plane-centric systems, exemplified by daemon suites such as Quagga, XORP, and BIRD running in user space on Linux or BSD. Group-3 comprises hybrid “distributions,” such as Vyatta and DROP, that bundle control- and data-plane daemons. Group-4 comprises single-protocol implementations such as OpenOSPFD, OpenBGPD, and B.A.T.M.A.N. This taxonomy is coupled to a strict plane distinction: the control plane builds and maintains routing databases in user space, whereas the data plane forwards packets according to forwarding tables in the kernel or specialized hardware. Netlink and ForCES are cited as standard interfaces between user-space daemons and kernel forwarding, while OpenFlow is used to program forwarding tables in external ASIC-based switches (Fatahi et al., 2022).
The same literature contrasts monolithic and modular system organizations. Linux represents a monolithic kernel with an integrated forwarding path and control in user space connected through sockets or Netlink. Click represents a modular toolkit in which packet-processing pipelines are assembled from reusable elements. Quagga, XORP, and BIRD represent multi-process or protocol-separated control software, with one process per protocol or function talking to a central engine or routing core (Fatahi et al., 2022).
| System | Architecture | Notable properties |
|---|---|---|
| Quagga / GNU Zebra | Multi-process suite with zebra and per-protocol daemons |
IPv4/v6, OSPFv2/v3, RIPv1/v2/ng, BGPv4/v4+, IS-IS, MPLS |
| XORP | Multi-process stack with xorp_rmgr, xribd, xrls, fea; Click data plane |
Unicast and multicast support; XRL IPC |
| BIRD | Single-process daemon with internal protocol threads | Multiple routing tables, VRF, soft reconfiguration |
| Click Modular Router | Directed graph of packet-processing elements | “Push”/“pull” hooks; interrupt or polling-based packet I/O |
| OpenWRT / TomatoUSB | Linux-based embedded firmware on MIPS/ARM SoCs | Wireless, NAT, QoS integration |
Quagga, descended from GNU Zebra, is a multi-process suite in which the zebra daemon acts as the central FIB manager and interfaces with the kernel routing table via Netlink, while daemons such as ripd, ospfd, bgpd, and isisd implement individual protocols. Inter-process communication proceeds through the Zserv protocol. The suite supports IPv4/v6, OSPFv2/v3, RIPv1/v2/ng, BGPv4/v4+, IS-IS, and MPLS, and exposes configuration through the vtysh virtual terminal with normal and privileged modes. It was widely used as the control element in hybrid OpenFlow-plus-Quagga setups, including RouteVisor (Fatahi et al., 2022).
XORP makes plane separation especially explicit. Its components include xorp_rmgr as router manager, xribd as RIB arbiter, xrls as resource locator service, and fea as forwarding engine abstraction. It uses Click as its data-plane engine and employs XRL, the XORP Resource Locator, for IPC. Protocol support includes RIP/RIPng, OSPFv2/v3, BGPv4/v4+, IPv4/v6, PIM-SM, IGMP v1/v2, MLD v1, PPP, and MD5 authentication. Research and campus deployments valued XORP particularly where multicast support was required, and Windows and BSD ports enabled cross-platform experimentation (Fatahi et al., 2022).
BIRD adopts a different design point: a single process with multiple internal protocol threads attached to one or more routing tables. It provides export and import filters on each protocol to control route injection, a pipe protocol for inter-table exchanges, and a kernel protocol for Linux/FIB synchronization. It supports BGPv4, RIP v2/ng, OSPFv2/v3, RIPng, IPv4/v6, multiple routing tables, virtual routing, and soft reconfiguration. Its efficient single-daemon design reduces IPC overhead, and the survey identifies IX route servers and large IPv6 deployments in Europe as characteristic deployment settings (Fatahi et al., 2022).
Click is the canonical data-plane-centric platform in this ecosystem. It models the router as a directed graph of packet-processing elements implemented as C++ classes. Elements connect through “push” or “pull” hooks and support interrupt-driven or polling-based packet I/O. The platform includes a core IP forwarding chain, queueing, classification, TTL decrement, checksum handling, and user-written elements for advanced functions. In-kernel deployments can reach several Gbps on modern CPUs, while user-space deployments trade throughput for flexibility; clustered Click is reported to scale linearly with node count (Fatahi et al., 2022).
Embedded firmware such as OpenWRT and TomatoUSB occupies the low-power end of the spectrum. These Linux-based firmware images run on MIPS or ARM SoCs and integrate kernel modules for wireless, NAT, and QoS. Supported functions include basic IPv4/IPv6 routing, OSPF through a Quagga package, simple firewalling, VPN, and dynamic DNS. Their throughput is in the tens to hundreds of Mbps range and is limited by the SoC CPU and switch ASIC, which made them suitable for home and small-office deployments including WRT54-series devices and Buffalo hardware (Fatahi et al., 2022).
3. Performance modeling, limitations, and research directions in open software routing
The survey emphasizes that performance remains the critical tension in open software routing. Quagga is explicitly characterized as control-plane only and therefore dependent on Linux/FIB scale. Benchmarks cited from Bolla and Bruschi show that Linux-based control implementations can forward at several hundred Mbps to low Gbps with optimized NAPI. XORP studies report that up to 90% of packet-processing delay on PCs can arise from memory-bus and kernel-traversal overhead. These results place software routers in a regime where forwarding efficiency depends not only on protocol logic but also on bus behavior, kernel crossings, and NIC characteristics (Fatahi et al., 2022).
The performance-modeling discussion is deliberately limited. The survey references external studies but does not include explicit analytical formulas. It identifies Linux forwarding stages such as SoftNet and NAPI, notes the use of multi-stage software routers that partition the FIB across CPU clusters, and points to energy-aware routing analyses based on power-versus-throughput curves for PC-based routers. The variables commonly considered in related work are packet rate , CPU cycles per packet , memory-access latency , and bus bandwidth (Fatahi et al., 2022).
The major limitations are concrete. Data-plane bottlenecks arise on commodity buses such as PCI, and high CPU and memory latency constrain forwarding. Systems may have a limited number of high-speed NICs and lack offload support such as checksum and TSO. Linux FIB performance degrades with large routing tables above 300k routes. Security and robustness remain nontrivial because open-source protocol implementations can harbor subtle bugs, with IS-IS in Quagga cited as an example. Management interfaces vary widely in maturity, spanning CLI-oriented tools to web GUIs. Distributed architectures further introduce packet reordering, fragmentation handling, and forwarding-table synchronization problems (Fatahi et al., 2022).
The future directions listed in the survey are strongly aligned with subsequent trends in programmable networking. They include SDN integration through tight coupling of OpenFlow switches with open-source control planes such as Quagga plus OpenFlow; FPGA and NIC offload through platforms such as NetFPGA and HERO; multi-stage distributed PC clusters for higher port density and aggregate throughput; energy-efficient routing with dynamic power management; network virtualization through virtual routers in cloud environments; and redundancy frameworks that combine multiple open-source router instances for high availability. This suggests that the networking meaning of OpenRouter anticipated later interest in disaggregated control, hardware acceleration, and virtualization (Fatahi et al., 2022).
4. OpenRouter as an LLM inference and marketplace platform
In the LLM literature, OpenRouter is a unified AI inference platform positioned between developers or end-users and a heterogeneous model ecosystem. Its design goals are to provide a single API for routing requests to hundreds of open-weight and closed-source models, enable privacy-preserving metadata-only analytics on real-world usage, and support global geographies, multi-model experimentation, and seamless model switching. The platform functions as an inference “router”: users either specify a model directly or allow cost- or capability-based auto-selection, after which a routing layer chooses the appropriate endpoint according to user-selected policy and billing-region geography for latency and compliance. One empirical study describes 300+ active models from 60+ providers, including Anthropic Claude, OpenAI GPT-5, and Chinese OSS models such as Qwen and DeepSeek (Aubakirova et al., 15 Jan 2026).
Its internal architecture is described as a stack of API and routing, model connectors, metadata logging, opt-in content categorization, and analytics. On every generation, the platform logs anonymized metadata including model or provider ID, prompt and completion token counts, latency, finish reason such as tool_call, and geographic billing region, while storing no prompt or completion text. For high-level analytics, opt-in users share 0.25% of prompts for in-pipeline categorical tagging through Google Cloud Natural Language’s classifyText API, mapped into study buckets such as Programming, Roleplay, Translation, Q&A, and Productivity. Versioned SQL queries and transformations on the Hex Platform then produce weekly aggregate statistics over a 13-month rolling window (Aubakirova et al., 15 Jan 2026).
A separate economic study characterizes the same platform as a prominent LLM marketplace. In that account, OpenRouter exposes a single REST-style API for model selection, prompt submission, and response retrieval across over 249 cleaned models, from 296 initially scraped. It supports smart routing across multiple providers, such as OpenAI versus Azure, on the basis of user-specified preferences including price, latency, and uptime. It also supports fallbacks and failover through ordered “primary” and “fallback” model lists. Model pages report per-million-token input and output prices, historical uptime, and daily token-usage time series, and the study reconstructs model-day and app-by-model usage panels from those public traces (Fradkin, 21 Apr 2025).
These descriptions do not conflict; they use different observation windows and filtering procedures. One study focuses on production-scale token traffic and platform telemetry, while the other emphasizes the marketplace surface visible through model pages and public app usage (Aubakirova et al., 15 Jan 2026).
5. Usage dynamics, retention, and market structure
The largest empirical study reports more than 100 trillion tokens, defined as the sum of prompt and completion tokens, observed over a primary analysis window from November 3, 2024 to November 30, 2025. Its core metrics include total tokens in period , ; category share, ; reasoning-model share, ; tool-call share, ; and a cohort retention rate , where 0 is the number of users from a cohort active at step 1. These metrics were used to characterize task composition, regional variation, prompt-length growth, and retention patterns at platform scale (Aubakirova et al., 15 Jan 2026).
The reported usage mix is heterogeneous. By late 2025, proprietary models accounted for approximately 67% of weekly tokens and OSS models for approximately 33%. Within the OSS segment, Chinese OSS averaged 13.0% of total weekly volume by late 2025 and Rest-of-World OSS averaged 13.7%, while proprietary Rest-of-World models averaged 70%. Task composition changed sharply: Programming rose from 11% to over 50% of total tokens by late 2025, while roleplay remained the largest OSS use case at more than 50% of OSS tokens. The long tail included Productivity/Writing, Q&A, Translation, Education, and other domains. Geographic spend was also dispersed: North America remained below 50%, Europe was roughly 15% to 22%, and Asia excluding China OSS production rose from 13% to roughly 31%. Token-by-language was reported as English 82.87%, Simplified Chinese 4.95%, Russian 2.47%, Spanish 1.43%, Thai 1.03%, and Other 7.25% (Aubakirova et al., 15 Jan 2026).
The same study documents a shift toward multi-step deliberation and agentic inference. Reasoning-model token share rose from approximately 0% in Q1 2025 to more than 50% by late 2025. Average prompt length increased from 1.5K to 6K tokens, average completion length from approximately 150 to 400 tokens, and overall sequence length from less than 2,000 tokens to more than 5,400 tokens. Programming tasks generated the longest contexts, often above 20K prompt tokens. Tool invocation increased noticeably after September 2025 and was concentrated in agent-optimized models including Claude Sonnet, Gemini Flash, and Grok Code Fast. The retention analysis identifies what the paper terms the Cinderella “Glass Slipper” effect: early cohorts such as June 2025 Gemini 2.5 Pro or May 2025 Claude 4 Sonnet had roughly 40% Month 5 retention, whereas later cohorts were below 20%. The paper characterizes this as a “first-to-solve” workload-model fit that locks in a foundational user base with high switching costs (Aubakirova et al., 15 Jan 2026).
The marketplace study adds a complementary demand-side view. Platform-level daily token usage rose from roughly 50B to roughly 250B tokens over January 11 to April 11, 2025, while estimated daily revenue, using April 2025 prices, rose from \$C$2200K. Across case studies including Claude 3.7 Sonnet, Gemini 2.0 Flash, and Gemini 2.5 Pro, new models showed rapid initial adoption that stabilized within 2–3 weeks. The paper also distinguishes substitution from market expansion: Claude 3.7 exhibited strong within-brand substitution relative to Claude 3.5, with a diversion ratio of approximately 0.83, whereas Gemini 2.0 Flash and Gemini 2.5 Pro were described as expansionary releases with negligible negative usage changes elsewhere. Multihoming was pervasive: over app-week observations, the prevalence of using at least two models was approximately 0.95, and the average number of models per app was approximately 5. In the paper’s interpretation, these patterns indicate both vertical differentiation, as in premium willingness to pay for perceived coding quality, and horizontal differentiation, as apps mix models for speed, “vibes,” integration, or other niche-specific criteria (Fradkin, 21 Apr 2025).
6. Turn-level routing research and OpenRouter-style deployment
A further development in the OpenRouter orbit is cost-aware multi-turn model routing. “MTRouter” studies long-horizon tasks in which an agent makes $C$3 sequential model calls, choosing a model $C$4 at each turn under a cumulative budget $C$5 and turn limit $C$6. The objective is to maximize expected terminal score subject to cost constraints. Its central technical move is to encode the interaction history and candidate model jointly: a frozen text encoder maps serialized history to a history embedding, model attributes such as pricing and context length are combined with a learned residual embedding for the model, and a lightweight <a href="https://www.emergentmind.com/topics/multi-layer-perceptron-mlp" title="" rel="nofollow" data-turbo="false" class="assistant-link" x-data x-tooltip.raw="">MLP</a> predicts the expected terminal outcome if that model is selected at the current turn. Training uses logged trajectories from both a random router and single-model runs, with squared-error regression to a turn-conditional target that subtracts severity-weighted penalties for downstream errors (<a href="/papers/2604.23530" title="" rel="nofollow" data-turbo="false" class="assistant-link" x-data x-tooltip.raw="">Zhang et al., 26 Apr 2026</a>).</p> <p>The reported dataset comprises 1,291 tasks, 29,693 trajectories, and 515,221 turns at an approximate one-time cost of \$CC$813.9, whereas MTRouter achieved $C$9 at \$LL$161.8, whereas MTRouter achieved $L$2 at \$35.0, a cost reduction of 43.4%. Out-of-distribution results were reported as similar: ScienceWorld OOD improved by 5.0 with 65.8% cost saving, and HLE OOD improved by 3.8% with 52.3% saving (Zhang et al., 26 Apr 2026).
The analysis attributes these gains to several mechanisms. Relative to Router-R1, MTRouter makes far fewer switches, with approximately 5 successful-episode switches versus approximately 20, thereby reducing both API calls and cache warm-ups. After an error, MTRouter remains with the same model around 90% of the time and recovers more often, whereas Router-R1 frequently panic-switches. The learned model embeddings exhibit clustering by cost tier and capability, and the system shows emergent specialization: on HLE, DeepSeek is over-used for search, GPT-5 for python, and Kimi for browse; on ScienceWorld, MiniMax is over-used for observation actions, Gemini for object interactions, and GPT-OSS for query commands (Zhang et al., 26 Apr 2026).
The paper does not present MTRouter as part of OpenRouter itself. Instead, it argues that its core ideas can be adapted to an OpenRouter-style system. The proposed adaptations are model-agnostic encoding that incorporates metadata from an OpenRouter-like platform, online budget-aware scheduling that uses remaining budget as an input, real-time API routing through a scoring micro-service, and extensibility procedures for newly added models via residual-embedding initialization and limited fine-tuning. This suggests a convergence between platform-level request routing and learned turn-level routing: OpenRouter provides the heterogeneous model substrate and telemetry, while cost-aware routers aim to optimize selection across turns rather than per request (Zhang et al., 26 Apr 2026).