OpenRouter

OpenRouter operates an AI model marketplace and managed inference gateway. Its OpenAI-compatible API separates two decisions: which model answers a request and which provider serves that model. Developers can change models, route around provider failures and consolidate inference spending through one integration. Started in early 2023, the organization expanded from model access into multimodal inference, enterprise controls and quality-aware routing.[1][10][5][6]

An application can name a model while leaving provider selection automatic, or delegate model choice to OpenRouter. Serving endpoints can differ in price, availability, parameter support and output quality. Quantization, which reduces numerical precision, is one reason providers serving the same named model may produce different results. Provider failover tries another endpoint for the chosen model; a separate model fallback list lets the application move to another model when necessary.[10][7]

For standard requests without explicit sorting or ordering, provider routing prioritizes providers without significant outages in the preceding 30 seconds, selects among low-cost candidates using inverse-square price weighting, and retains the remaining providers as fallbacks. A stable endpoint priced at $1 per million tokens has nine times the selection weight of one priced at $3. Developers can instead specify provider order, sort by price, throughput or latency, and impose price or data-policy restrictions.[10][7]

Requests containing tools use Auto Exacto by default. It reorders providers for the selected model using throughput, tool-call validity and OpenRouter’s recurring benchmarks, including GPQA Diamond and Tau2-Bench Airline. Its tool-call error metric flags requests containing invalid JSON, an unknown function name or arguments that fail the supplied schema. This measures the validity of returned calls, rather than whether an external tool executes successfully.[16]

Quality-based provider reordering creates a prompt-caching tradeoff. Keeping successive agent turns on one endpoint can preserve a cached prompt prefix; moving to another endpoint can cause cache misses mid-conversation. Explicit price sorting or the :floor routing variant bypasses Auto Exacto, allowing sticky provider routing to preserve that reuse.[16]

Parameter support is a separate constraint. An application that depends on structured JSON can set require_parameters: true to exclude providers lacking support for its requested parameters. The default is false: tools, response_format and verbosity still exclude unsupported providers when at least one provider of that model supports the parameter. If none supports it, the model remains eligible and the parameter is ignored. That default preference does not remove an unsupported model from a fallback list.[7]

Auto Router handles model selection. A lightweight classifier assigns a prompt one of approximately 30 task types, such as debugging or multi-step planning. The router ranks models by their share of aggregate community spending for that task over the trailing seven days, then applies a cost band and eligibility constraints. Guardrails, zero-data-retention policies, allowed-model restrictions and output modality constrain the candidates. These rankings follow spending behavior; they do not establish a model’s correctness for a particular application.[8]

If classification or rankings are unavailable, Auto Router uses a default model set. Restrictions that leave no eligible models can still cause a request to fail. Cost tiers are bands, not price ceilings: models cheaper than the selected band are excluded too, while provider.max_price separately limits endpoint prices. For multi-turn conversations, the router prefers the remembered model only while it remains a top candidate; a change of task can change the model.[8]

These routing capabilities grew out of OpenRouter’s earlier marketplace and integration work, which began in early 2023 and expanded into infrastructure for production applications and agents.[1][5][6]

OpenRouter dates its start to early 2023. Its June 2025 founding account names Alex Atallah and Louis Vichy; CapitalG also identifies Chris Clark as cofounder and COO. By June 2025, the platform combined standardized model access and token accounting with unified billing, provider failover, spending management and enterprise data-policy controls.[1][5][4]

On June 25, 2025, OpenRouter announced that it had closed $40 million in combined Seed and Series A financing, led by Andreessen Horowitz and Menlo Ventures, with participation from Sequoia and industry angels. The company said the funding would support product development, additional model types and enterprise support.[5]

OpenRouter also reported collaborating with OpenAI on GPT-4.1’s stealth launch, providing early access and real-world developer feedback. In the financing release, OpenAI’s Tabarak Khan described the contribution: “Their diverse and active developer community has shared valuable feedback on how our models perform in practice.” Developer tools provided another route to users: Cline supports entering an OpenRouter API key and selecting a model within its coding workflow.[5][13]

On May 28, 2026, OpenRouter announced a $113 million Series B led by CapitalG, with strategic investors including NVentures, ServiceNow Ventures, MongoDB Ventures, Snowflake Ventures and Databricks Ventures, alongside existing investors. The preceding year’s product work extended inference beyond text to image, audio, speech, transcription, embedding and video models. Workspaces, guardrails, zero-data-retention policies and quality-aware routing broadened the platform’s enterprise capabilities.[6]

In its June 2025 release, OpenRouter reported that annualized inference spending through the platform had risen from $10 million in October 2024 to more than $100 million as of May 2025. This was an inference-spending run rate, not company revenue or realized annual spending. It also reported that more than one million developers had used its API since launch.[5]

On May 28, 2026, OpenRouter reported weekly volume growing from 5 trillion to 25 trillion tokens over the preceding six months and said it served more than eight million developers across over 400 models. Its August 19 announcement reported more than 10 trillion tokens per day, a community of over ten million developers and companies, and a 90-person organization. The developer and community figures do not specify an active-user interval or a count of paying customers.[6][3]

OpenRouter uses dollar-denominated prepaid credits. For token-billed requests, it receives token totals from the serving provider, calculates the corresponding cost and deducts it from the credit balance. Its FAQ states that underlying inference prices pass through without markup, while credit purchases carry a separate fee. Bring-your-own-key usage above a plan-dependent allowance incurs a fee based on the model and provider’s normal OpenRouter price; the allowance is measured by list-price inference cost rather than request count.[9]ⁿ¹

Usage Accounting returns prompt and completion counts using the model’s native tokenizer, the account charge, and applicable reasoning and cached-token counts. Usage arrives in the complete non-streaming response or the final streaming message. The accounting distinguishes the total account charge from upstream inference cost.[17]

OpenRouter and a16z collaborated on State of AI: An Empirical 100 Trillion Token Study with OpenRouter, internally dated December 2025 and submitted to arXiv on January 15, 2026. Malika Aubakirova led experiment design, implementation, analysis and preparation of the paper; Alex Atallah, Chris Clark, Justin Summerville and Anjney Midha were coauthors. The study analyzed more than 100 trillion tokens to examine model adoption, tasks, geography, pricing and retention.[11][12]

The researchers reported substantial open-weight model adoption, prominent roleplay and coding workloads, and growing use of reasoning-optimized models. Most model-level and pricing analyses cover November 3, 2024–November 30, 2025; category analyses begin in May 2025. These are historical observations of OpenRouter activity, shaped by its model availability, prices and users, and do not capture locally hosted or closed internal deployments.[11][12]

Researchers analyzed anonymized request metadata without access to raw prompts or completions. Category labels came from an approximately 0.25% sample through an explicit opt-in mechanism, whose participants received discounted pricing. The classification service processed prompt content transiently; researchers used the resulting metadata. Consent-based sampling and a predefined taxonomy limit how broadly the task findings can be generalized.[11]

On August 19, 2026, Stripe announced an agreement to acquire OpenRouter, identifying Atallah as OpenRouter’s cofounder and CEO. Stripe framed the combination as linking token routing and cost optimization with its revenue infrastructure. OpenRouter explained its decision through Stripe’s developer infrastructure experience, customer network and expertise in fraud and abuse.[2][3]

In its announcement, OpenRouter promised to retain its name, product, roadmap and existing integrations, and to keep routing independent of any model, provider or parent company. Atallah summarized the rationale: “We believe intelligence will be multi-model: no single model will be optimal for every task, and developers need a neutral layer to orchestrate and manage them all.” OpenRouter stated at announcement time that the transaction was subject to customary closing conditions and expected to close in the coming weeks.[3][2]

In a Latent Space discussion, the guests recalled the launch of Mixtral 8x7B as a moment when demand for an open-weight model met a fragmented hosting market. OpenRouter brought competing inference providers into a common interface, letting developers compare prices and try the model without arranging each provider separately. The host recalled a steep price fall; the conversation does not isolate OpenRouter’s effect on that change.[18]

The discussion also describes an early Mixture of Models prototype: several models produced answers, and another model combined them while exposing the intermediate outputs. When one model was much stronger than the others, the combined result could resemble its answer. The team set the prototype aside and later revisited fusion as strong models became closer in capability. A favorable internal architecture-planning experiment led the team to benchmark it; that experiment alone does not establish an improvement for every task.[18]