OpenRouter’s 10 Trillion Daily Tokens Put Inference Fraud in Focus
OpenRouter co-founder Alex Atallah and investor Anjney Midha argue that AI will remain a multi-model market: labs can build capable models but still struggle to get them into developers’ hands. They say OpenRouter grew by providing a neutral way to discover, compare and route among models. Midha argues that as agents drive more continuous use, the resulting token flows create a growing target for fraud.

Model diversity created a distribution problem
Alex Atallah traces OpenRouter’s premise to the first months of open-weight language models. At the end of 2022, he says, OpenAI was effectively the only game in town, alongside Cohere and a small number of early open models. Meta’s Llama, released in January 2023, was exciting but not yet an engaging chatbot. The turning point for him was Alpaca, a fine-tune of Llama built at Stanford with synthetic data. Atallah recalls using it on a plane and finding some outputs difficult to distinguish from ChatGPT’s. The team said the fine-tuning cost about $600.
That result suggested two things. First, data could be repackaged as a model service: a team with useful data might fine-tune a model and sell access to it. Second, once a prominent model or application demonstrated what was possible, smaller teams could create their own variations. Atallah saw an ecosystem forming around those variations, but no shared place to find them, use them, or learn why developers were choosing one over another. Hugging Face was the nearest reference point, he says, but it did not offer closed models, inference access in the way OpenRouter wanted to, or usage information that could help explain adoption.
Anjney Midha reached a similar conclusion from a different side of the system. As Discord’s head of platform, he helped deploy GPT-3.5 in the form of Clyde, a first-party assistant, and a moderation tool. The moderation plan was to give a model the rules of an individual Discord server and let it apply those community-specific norms. That was difficult with a closed model whose post-training policies could override the deployment’s instructions. A Harry Potter fan server, for example, could not get useful moderation if the model refused prompts involving trademarked material. Atallah recalled a parallel problem for writers whose models refused to help with a violent chapter in a detective story.
Midha’s point was not simply that a model might give an unsatisfactory answer. A company deploying a model to a large user base might need it to follow local instructions reliably, and have little control when the lab’s guardrails conflicted with those instructions. Discord had 250 million monthly active users and a content moderation operation of more than 5,000 people, Midha said; the goal was to apply the norms of individual communities without relying entirely on people reading every message. The moderation endpoint OpenAI provided did not solve the problem of making the model follow each server’s own rules. For Midha, this was an early practical case for open models and for a control layer that could help organizations manage them.
The case for multiple models therefore rested on more than a forecast that research would produce many checkpoints. Developers had concrete reasons to switch: a model might refuse a legitimate task, perform unevenly, cost too much, or be difficult to deploy. The need for alternatives could arise inside an application, not just from a lab’s desire to compete.
Atallah’s product idea was also shaped by a distinction between how people and software consume services. In his description, a marketplace is a kind of publish-and-subscribe system: providers publish a model or service, and consumers choose what to use. Human buying is discrete and intermittent. Inference consumers, including agents, can make requests continuously and change providers frequently. OpenRouter would therefore combine a conventional API with a marketplace: model identifiers, routing options and other “product SKUs” that let developers subscribe to a service and make choices as usage evolves.
The labs could make models, but distribution was still work
Atallah says one of the most common objections to OpenRouter was that a single model company would capture the market through scaling laws and network effects, much as Google had dominated search. He thought the comparison was incomplete. Language models were not just a user interface; they could become foundations for new businesses. And, in his view, the economics of creating capable competitors were more decentralizable than those of building a search engine.
Midha agreed that scaling mattered, but treated it as a reason to expect multiple important labs rather than a reason to bet on one. He had invested in Anthropic, Mistral, Black Forest Labs and Luma, among other model teams, and saw strong research groups arriving at new capabilities. Their common weakness, he argued, was what happened after training. A lab could complete a checkpoint, expose it through an API, and still have few developers using it. The research teams understood capability development; getting a model into practical use required a different set of skills and infrastructure.
That gap included more than an endpoint. Developers needed keys, provisioning, version control, a usable interface, model discovery and a way to understand what different models were good at. Midha recalled that Claude’s first checkpoint was ready internally long before the team released it, and that the initial public API announcement offered only a few examples of developer use. For a lab, shipping an API could feel like the end of the work. For a developer, it was the start.
Atallah adds that making the models comparable and discoverable is itself part of distribution. Models are not products whose capabilities can be completely listed on a page. Even open-weight models can behave like black boxes to a developer deciding which one to put into an application. OpenRouter’s job, in his description, was to make a difficult market more legible: provide a neutral place where developers could explore models and providers, and where model makers could reach users without having to build every part of that route themselves.
Midha contrasted that with Google’s distribution advantage. A new Google model can be pushed across existing products and devices; a smaller lab has to build its own access, developer experience and adoption. He said Anthropic took more than 12 months to reach its first $10 million in revenue. With OpenRouter, he recalled, Black Forest Labs could be offered access to a large pool of developers around launch. Atallah said the platform had more than 10 million developers, while noting that counting users involves deduplication and is not straightforward.
The practical value was also visible in the Mistral launch period. Midha recalled that Mistral initially released weights through a torrent rather than an API: the team could make a model, but users had to figure out how to run inference. OpenRouter could provide an API and a place to find the model. Atallah says the team repeatedly got newly launched models onto Hacker News and in front of users on day one. That reach depended on engineering and community work, not simply passing requests through someone else’s endpoint.
Both speakers objected to the dismissive description of OpenRouter as “just a wrapper.” Midha said some investors treated it as a thin proxy or marketplace, overlooking the work required to orchestrate several APIs reliably and create a community around them. Atallah’s earlier experience at OpenSea had taught him to look for user needs and sharing behavior inside communities; Midha said he had seen that systems thinking while working with Atallah on Discord integrations.
In one example, the team had planned to send users from Discord to OpenSea. Atallah objected that the experience was poor and proposed embedding the marketplace flow inside Discord, even though keeping users in Discord could appear to work against OpenSea’s interests. Midha saw the intervention as a sign of product judgment beyond technical implementation: the integration should serve the user’s experience, not merely satisfy the requirements of the two companies.
The same community logic shaped OpenRouter’s early work. Atallah described the bootstrap as finding places where people were already blocked, then building for them and listening closely. His OpenSea experience had involved helping communities form around early projects, because shared use and users passing links to one another were signs that something mattered. In the early LLM ecosystem, he says, the problems included refusals that prevented users from completing tasks and the lack of ways to customize models. Those communities gave the team a place to learn what a marketplace needed to solve.
The early product was not OpenRouter itself. Atallah first built Window AI, a Chrome extension that let a user choose which model a web page would call. He compared the idea to a user-controlled wallet: a way to bring a model of one’s choice into different applications. The extension also led him to meet Louis, who later co-founded OpenRouter, after Louis began contributing to the open-source project. But Atallah concluded that a browser extension was the wrong form factor. Model discovery needed more space for examples, visuals and comparisons, and developers needed an API. Window AI was a useful experiment because it clarified what the product had to become.
Community helped turn early AI experiments into a market
OpenRouter’s early distribution work grew out of a broader period in which developers were already experimenting with AI in online communities. Midha describes crypto infrastructure as a kind of dress rehearsal: Discord had built systems to support fast-growing NFT communities, and those systems became useful when generative AI applications began finding users there.
He points to Midjourney, which began as a Discord bot that turned text prompts into images. A standalone web page with an empty input field could be intimidating to someone who had never used a model. In Discord, users could watch other people prompt the system, borrow ideas and see what it could do. Midha says the server experience produced much stronger engagement than the early web app. He also recalls the product’s feedback loop: users saw several generated images and chose one, creating an interaction that was useful both for the person prompting and as feedback about preferences.
Midha said the Discord server helped Midjourney grow from launch to a $100 million revenue run rate in less than eight months. He described the community as more than a channel for support: seeing other people use the product helped new users overcome the blank-page problem and learn by example. Discord’s existing infrastructure for communities, built in part during the rise of crypto and NFT projects, provided a place for these early applications to find users.
Discord suited an end-user application like Midjourney, Midha argues, but it was not the right interface for the infrastructure developers needed. An API platform had to support codebase integrations, model comparisons, governance, data policies and control over which teams could use which models. A server could provide community and examples; it could not do all the work of a developer platform.
The difference became more consequential when open models made it possible for developers to build their own applications rather than use a single full-stack product. Midjourney trained its own models and delivered them as an application. When Stable Diffusion arrived, developers could build other image products without having to train a model themselves. Midha saw that as creating demand for an API and a distribution layer that could connect open models to developers’ own products.
The clearest early proof for Atallah came with Mistral’s Mixtral 8x7B, which drew intense attention around its December 2023 release. Developers and AI commentators described it as one of the best models available, though Midha cautioned that the excitement was partly hype. He recalled Mistral co-founder Guillaume Lample describing the model as merely “okay” and suggested that its speed helped shape users’ impressions of its intelligence. Mixtral was an efficient mixture-of-experts model, and the fast responses could make it feel smarter in ordinary use, even if a more formal evaluation might favor a slower competitor on some tasks. Midha framed that as a possibility, not a settled evaluation result.
That episode exposed the value of a provider marketplace. The inference landscape was fragmented, with developers trying to work out where to run the model and what it would cost. Atallah says OpenRouter brought the options together, allowing providers to compete on price and giving developers a way to compare them in one place. He calls Mixtral the first clear example, in his experience, of a provider marketplace adding value for developers.
The market’s growth was not a steady march from one model to another. Atallah describes a recurring pattern: a model launch creates a surge in usage; users see the resulting bills and begin looking for less expensive alternatives; open-weight models arrive a few months later with a more cost-effective option. He saw that cycle repeat as the model ecosystem expanded. OpenRouter’s role was not to declare one model the permanent winner, but to make switching practical as cost, quality and speed changed.
Evaluation and routing served different customers
OpenRouter’s rankings and LM Arena’s model comparisons can look adjacent from a distance, but Midha and Atallah described different missions. Midha had helped Arena’s founders spin the project out of Berkeley and said its original purpose was to make model evaluation more reliable for researchers. Its early work addressed the biases and uncertainty involved in comparing model outputs. The principal customer, as he understood it, was a researcher at a model lab trying to evaluate a model before release.
OpenRouter was oriented toward a different point in the chain: the developer who takes research output and turns it into an application. Its rankings and app listings could show what developers were using and how demand was changing, but they were not intended to replace research evaluation. Midha said the projects’ different goals made it natural to discuss pooling data: Arena did not have API prompts showing what developers wanted to do with models, while OpenRouter was not built as a lab evaluation service.
The distinction also affected data practices. Atallah said OpenRouter does not see prompts and completions by default, beyond the policies set by providers. An organization can opt in to make its own data visible to itself. OpenRouter also offers some free endpoints, he said, but does not collect or monetize prompts from them by default. Arena’s work, by contrast, depends on evaluation data and serves labs seeking information about model performance. For the speakers, the issue was not that one project should absorb the other; the teams had different customers, data policies and reasons for existing.
This separation is part of the case for focus. When Swyx asked why OpenRouter had not expanded into everything around model use, Atallah said the company had prototyped a fine-tuning service but did not launch it. The idea was to submit a few YouTube videos, extract their transcripts and create a model that spoke like the people in them. Atallah imagined using such a model as a “mini me” to practice a job interview, public speaking or hiring conversations. The team did not test it widely because the marketplace was growing and remained its priority.
Fine-tuning could also have been framed as an extension of routing: use a company’s inference traffic to help it train a smaller, cheaper model and reduce dependence on a frontier provider. Atallah said he had not seen that become a standard path. He instead described fine-tuning and enterprise deployment as a separate business that inference providers were building. OpenRouter’s choice was to work with those companies and preserve its position as a neutral marketplace.
Other adjacencies included memory, skills and agent sandboxes. Atallah said developers had different preferences about how to implement those features, and that they were often central to an application’s user experience. A common abstraction might not suit every developer. OpenRouter could support the surrounding ecosystem without owning each component.
Atallah described focus as important both for product quality and for how customers understand a company. If a developer has a particular problem, a clear focus helps them identify which provider is likely to address it. Midha made the same point through Anthropic’s early strategy. He said the company’s original mission centered on responsibly commercializing an AI pair programmer, even while image and video models were receiving attention elsewhere. He described coding as the company’s focus from its founding, though Atallah noted that some of Anthropic’s earlier product marketing emphasized writing and long context.
Fusion returned when the strongest models became closer
One of OpenRouter’s more ambitious experiments was MOM, short for Mixture of Models. Atallah said the team prototyped it in early 2024. A user could select several models, or let the system select them, receive their separate responses, and then send those results to another model to fuse into a final answer. The interface displayed the intermediate work in a kanban-style board. At the time, Atallah described the idea as an early form of an LLM council or multi-agent swarm.
The first version did not work well enough. Atallah said the fused answer was sometimes worse than, and sometimes no better than, the strongest individual model. The leading model was far enough ahead of the alternatives that combining outputs did not reliably improve the result. The product form also needed refinement, and developing it would have diverted attention from the marketplace. The team deleted the code rather than continue building around a technology it considered premature.
Atallah said the case for trying again changed as several frontier models became strong at once. He offered a theory for why fusion might now work better: reinforcement learning had expanded the range of approaches researchers could explore within each lab, leaving top models with more complementary ideas. That explanation was his hypothesis, not a demonstrated account of why fusion improved.
His own test was to give several models the same software architecture problem, fuse their plans, and ask each model whether the combined result was better than its original answer. He said the models judged the fused plan better in several instances. That was enough to motivate a more systematic benchmark and a revived fusion effort in early 2026. The contrast with MOM was not simply that the same product idea had become fashionable again. Atallah’s argument was that the relative quality of the models had changed: if several capable systems can contribute distinct ideas, there is more to combine.
The broader product lesson was that model diversity could mean more than choosing one provider over another. Routing allows a developer to select a model for a request; fusion tries to make multiple models contribute to one result. Atallah said the latter still required benchmarking and product work, and he presented his personal tests as an initial signal rather than proof that fusion consistently improves answers.
Agents made routing continuous and made inference a target
OpenRouter’s early users leaned heavily on writing models, Atallah says. That began to change with Claude Sonnet 3.5 in mid-2024, which he describes as a major improvement in coding. Usage surged, and developers began building more applications on top of the platform. As customers saw what they were spending, they also began looking for cheaper models that could handle parts of their workloads. The resulting demand helped open-weight models and competing inference providers.
Atallah described the pattern as a “swing” between frontier advances and more cost-effective alternatives: a new model prompts a surge in usage, users encounter the bill, and open-weight models or other providers offer lower-cost options a few months later. Different stages of that cycle helped make the marketplace useful. One model might be the best fit for a demanding task, while another could handle routine requests at lower cost.
The leaderboard began to reflect new kinds of coding applications. Atallah recalls that Cline was prominent among the early coding tools, followed by a set of IDE and terminal-based agents. Then OpenClaw appeared at the end of 2025. It brought in users beyond traditional developers, including people using AI for productivity and online creation. Its architecture also made recurring model calls to check whether the agent was alive—“heartbeats” that could make expensive inference wasteful. OpenRouter’s auto-router, Atallah says, was useful for this pattern because it could direct a broad range of requests without requiring each user to make every model choice manually.
He points to Hermes as another agent that leaned into auto-routing, alongside features such as skills and memory. OpenRouter did not try to own those features. Atallah said developers had different preferences about how to implement them, and that they were central parts of an application’s user experience rather than natural extensions of a neutral routing layer.
The shift from asking a person to select a model to routing automatically became more important as use became continuous. Atallah’s publish-and-subscribe analogy describes providers publishing models and services while users subscribe to them. Human consumption tends to be discrete. Agents can make requests continuously and change which models they use. A model slug, an auto-router and other product options give developers a way to make those changes without rebuilding their application around each provider.
The platform’s rankings became one record of those shifts. Midha called the leaderboard a kind of movie of the AI industry: model and app rankings changed as new capabilities and use cases emerged. Atallah said the lists moved from writing applications toward coding tools and then newer agent architectures. Their usefulness came partly from showing what developers were actually building and using, rather than only how labs evaluated models.
By the time of the interview, Atallah said OpenRouter was processing more than 10 trillion tokens per day. He attributed major changes in volume to model launches and shifts in what developers were building, rather than to a single product release. That scale strengthened the value of seeing multiple providers through one interface, but it also made the platform and its underlying inference flows more valuable targets.
The larger token economy brings a new fraud surface
Atallah said OpenRouter blocked ten times as much dollar volume in one recent month as in the month before. He described several kinds of abuse: stolen credit cards, hacked accounts, unauthorized resale of inference, and companies that had lost control of an account without realizing it. Some incidents were not attacks at all. An agent could run away with spending, leaving a company with a large bill it did not intend to incur. OpenRouter’s trust and safety team works to detect and contain those cases, and Atallah said the company had built models to help identify them.
The problem is not limited to gateways. Midha recalled a fraud incident from Midjourney’s early growth, when the company was giving users a free trial intended to let them generate roughly ten images—the point at which users often understood the product’s value. A sudden surge in new users initially looked positive. The team later found that someone was reselling access to the free trial. Midjourney shut the trial down, and Midha said the company had not brought it back because the abuse was difficult to manage.
For Midha, that was evidence of a broader security problem. Tokens, he argued, are becoming a unit of value transmitted across the internet. The more valuable they become, the more incentive there is to steal, resell or exploit access to them. He compared the expected growth of token flows to the development of online payments: internet commerce required new systems to handle fraud, and he expects token usage to demand similar infrastructure. Midha estimated that the token economy could reach roughly $5 trillion within five years and said he would be surprised if token flows were not around $10 trillion within ten years.
“The more valuable tokens got, the more bad actors were going to try to get their hands on those tokens.”
— Anjney Midha
Midha sees Stripe’s experience with payments fraud as relevant to that challenge. He recalled Stripe’s original pitch as making it easy for developers to accept payments, absorbing fraud costs early rather than making onboarding depend on a lengthy verification process. The data gathered over time could then support stronger fraud detection. In his account, Stripe’s lasting advantage is not simply the price of moving money but the security infrastructure built around those transactions.
That makes the OpenRouter-Stripe combination a security story as much as a distribution one, Midha argued. An inference gateway or service that resells generalized model access is exposed to fraud because the underlying resource can be diverted and sold. He expects some companies to move toward charging for discrete tasks or outcomes, with customers bringing their own inference, rather than merely marking up model calls. He pointed to infrastructure pricing based on usage events as one possible model, while expecting simpler subscriptions to remain more common in consumer products. He also said pressure from labs and inference providers to make commitments and bring inference elsewhere could encourage businesses to move beyond simple resale.
Midha’s more consequential warning is that the next wave of abuse may come from agents, not only people. Agents could attack valuable token flows at a scale that is difficult for any one model lab to see. A lab can observe failures or misbehavior in the agents it trains, but Midha argued that this gives it only a partial view of activity across other models, deployments and developers. He called for security infrastructure that can see behavior across the ecosystem and use that visibility to defend token flows.
Atallah said OpenRouter had already worked with Stripe on fraud and abuse, and described the partnership as a way to accelerate the company’s go-to-market and move upmarket. He also pointed to the practical value of helping developers accept tokens and build with inference, including letting applications bring their own inference. OpenRouter’s name, product and roadmap would remain, he said. In the near term, he expected the company to do much of what it would have done independently, but faster. The longer-term plans were not yet public.


