We started actually expiring the credits a ~month ago. If you make any kind of API request, it resets the clock. We try to make it a very generous policy, but we can't keep a monotonically increasing liability on the books. We end up owing (a lot) of taxes on it, but can't actually recognize revenue. We would much rather you spend the credits! Hence the reminder emails, and generous "clock reset" policy.
Hmm? You have the revenue already. I know it's awkward from an accounting point of view, but you already took my money. "Letting" me keep the balance in the account is not generous.
Edit: on re-reading this came out more combative than I intended, sorry. I think what you're doing is reasonable.
I kind a get their reasoning. They cant recognize balance topup as revenue because then they'll owe taxes on full amount.
At the same time majority of money we pay them usually just gonna be an expense paid to actual inference providers. Then they pay taxes on their fee aka actual profits.
Its understandable, but it dont make 1 year expiration any good.
Absolutely no where is that shown to customers, and OpenRouter is going to be in a world of shit when people learn this by HN post and the business asks themselves why its reputation keeps taking hits.
What a fucking ridiculous thing for me to learn by social news.
We have made MASSIVE improvements here, and network-wide caching rates have been improving relentlessly. We do publish the cache rates for each endpoint; see the "performance" area of our model pages. E.g.
https://openrouter.ai/deepseek/deepseek-v4-flash-0731#perfor...
You know how there's a router mode to use the cheapest provider? That only takes into account uncached rates, last I checked. Make another one that takes into account effective rates (the ones that include cache).
I think the future -may- be a hosted routing client. Something similar to an auth client app. Why? A few reasons:
- Customers being able to decide their own routing with true logic is a huge feature. Open router provides the seamless switching/api, route switching decisions are available in a client.
- Similarly, providing hooks at this level gives a chance for stats/other things that are hard to plug into prod code elsewhere
- a true middle man hosting for other things like MCP may also turn into a real win once it is implemented.
Just a random thought though. My point about quality/cost being clobbered by bad providers remains. The fact that cache and quality is badly handled makes me doubt that training data choices are being respected. You need a more public trust/certification process for providers with real teeth when they cheat. I'm going to wait a bit to see how things evolve and check back later.
You need to validate what providers are actually serving. Add benchmarks, properly showcase what quantization they are serving on the model and KV cache, etc.
Until that happens, your service is doomed to be shitty.
We run benchmarks against all of our endpoints, in production. That first chart that the author shows is in fact our live benchmarking data. If providers underperform, we kick them out of the routing pool. That is why we run those benchmarks. Performance
And errrr...yeah...that auto-exacto performance chart is both 100% useless, and totally unclear. We will get that fixed. But under the covers it is doing a lot of valuable work! https://openrouter.ai/docs/guides/routing/auto-exacto
Oh wow someone from the team! I'm really heartened by this response -- as you can tell, I've been something of a fan, so I felt kinda betrayed by the idea that this was a risk. Thanks for clarifying, and for taking my frustrated hyperbole in stride.
Submitting an application to your product role now. "All of the models are at least okay" is heartening, but there's a whole bunch of fun places to take this.
Thanks everyone for the feedback here. Some of this we are aware of, some of it we aren't. Some we can fix, some of it is inherent to inference (and we in fact improve the situation dramatically).
Philosophically, at OpenRouter we are trying to do two different things, that are sometimes at odds with one another:
1. Let you use a lot of capacity across a lot of providers, in a way that "just works" and you don't need to worry about it.
2. Have a huge variety of inference available so you can pick radically different price/performance tradeoffs, data policy decisions, geographic destinations, inventive hardware, etc.
These are inherently odd bedfellows, and we are still very much improving how we can make both of them true at the same time.
Some quick thoughts on the article itself:
1. Benchmarks: YES! Providers benchmark differently. We run benchmarks on the live endpoints continuously, monitor the median performance, and kick providers out of the default routing pool if they vary by more than a standard deviation. We work hard (and continue to invest) to make sure that providers serving sub-par inference can't game the system, and that our routing actively avoids them. So the chart is accurate (it's our chart) and it actively influences our routing decisions!
2. That is bad and we will fix it. Sorry.
3. When we on-board providers we run essentially the same test as the author did to verify that the param is working as expected. If it isn't, we don't launch the provider. However this is not one we are running constantly in production. We are working on making this more robust in general and I do believe is fundamentally solvable in a way where it will "just work".
4. We 100% agree that users should not filter by quantization. It's a bit of a legacy concept in general; there is a huge amount of code between "model weights" and "inference API" and in almost all cases quality degrades in that part of the stack, NOT in the model weights themselves.
5. Hmm...we will dig in here. We monitor tool calls in real time and route around providers that are regularly mis-parsing tool calls. So you should get a very low rate of these in general. Another area we have invested a lot in: https://openrouter.ai/docs/guides/routing/auto-exacto
6. We will dig in here as well. I'm surprised this is happening frequently enough to be noticeable. We eat the cost when the finish reason is an error, but not when it is "stop". Perhaps we can expand our "insurance" program: https://openrouter.ai/docs/guides/features/zero-completion-i...
7. Will investigate.
8. We attempt to heal these, but obviously missed some. Will fix.
9. We do not rate limit by IP. Would love some more information here, as that is very surprising.
10. Ugh. That sucks. I'm sorry. We are introducing QoS tiers for production apps, which will address a lot of this.
> We work hard (and continue to invest) to make sure that providers serving sub-par inference can't game the system, and that our routing actively avoids them.
I'm glad to hear that y'all are doing this, as I was unaware that this was something OpenRouter does. I was surprised and disappointed that there are so many problematic providers that it seems like community best practice [1] is to ban somewhere in the realm of 5-6 providers. Would it be possible to provide some way to express an even stronger preference for high quality providers? E.g. "only route to first party for this model" or, "cost, but don't route to providers that more than x% worse than the first party". I'm sure something like that can be done via the API but I haven't found a UI way to do it - and having it in the UI would go a long way towards feeling like OpenRouter is looking out for me/helping solve the problem as opposed to leaving it to me to have to figure out.
toven from openrouter, leading the team working with our providers - very interested in some of the things found in the report, I dug in to the image failures specifically, and in that case we have data showing deepinfra was correctly parsing images when the endpoint went live in july, but today fails those tests. we'll work on testing images and reasoning effort etc running constantly as chris mentions in point 3.
Hmm, let me check. That certainly seems wrong. Can you send me an email w/ your email so I can look into it? im cc at openrouter.ai. Or DM me on X? x.com/cclark
My ticket number is #107156 (opened 9 days ago). The point is that the Discord is full of people not getting responses, and I'm not even the one waiting the longest. The only help they get is from the AI assistant in the server saying don't bump the ticket or you'll be punished by getting moved to the back of the queue. So there's nothing anybody can do but wait who knows how long.
Yeah we are very under-staffed. We are hiring aggressively. I readily admit we have inadequate support staffing right now, but we are going as fast as we can to ramp up.
No stress! My first reaction to this was OMG THIS IS AN INCREDIBLE RESOURCE!! We are 100% grateful for this sort of feedback! Here is a direct quote of what I said at 8:17am this morning when someone sent me the article and I scanned it:
this is amazing!!
[8:19 AM]The first obvious win is routing around providers that arent handling image inputs correctly. That should be straightforward
[8:19 AM]The effort param stuff...I thought we had addressed that, but will dig in. This is incredible feedback
[8:20 AM]We should hire this guy.
One thing to note about the first graph: nobody is doing as well as the first part on tool calling, and it's not close.
This might be the fault of the other providers, but it's probably just something slightly different that the first party does with the model inference program than anybody else, and that's not sure to weights it's due to vLLM twiddling (or whatever) and probably becuase the first part actually uses their own customized inference program rather than the standard methods that all the third party providers use. This isn't nefarious, it's just the challenge of these sorts of stochastic systems.
Having been in science for decades now, and seen benchmarking across many different fields, these results are completely expected for me. LLM serving is not mechanical, it's hard to get right and has lots of unknown footguns. Even something as extreme as scrambling a matrix will still likely get results that are nearly as good as normal, and if there's a bug deep in vLLM or the tensors metadata that results in that, then it's going to be pretty hard to find unless you're an active researcher with knowledge of the particular model you're running inference on. I kind of doubt that's happening here, but maybe!
In the scientific literature, when benchmarking methods, everybody's own method performs best in their own hands. Some attribute it to researchers gaming benchmarking for publication purposes, but I think it's just what we see here: the people who made a method are just the best at using it because they know all the quirks and use it best.
Programmers are not used to thinking with that nuance, and jump to conclusions about lying about quantizations, etc., but this is really just an unavoidable part of AI/ML methods: when things aren't perfect they're still pretty good and it's going to take the model creator to truly debug it. At least until the open weights ecosystem gets a lot better at ensuring reproducibility, and model cards are nowhere detailed enough for that to happen yet.
This matches what I found experimentally with gpt-oss-20b during OpenAI's red-teaming challenge. After moving from hosted inference to running the model myself on rented H100s via vast.ai, I saw the model refuse the same kinds of prompts at noticeably different rates depending on the inference stack — differences of roughly 5–10 percentage points with otherwise identical experimental parameters and seeds.
So I very much agree that this isn't necessarily about providers secretly changing the weights. For reproducible work, the serving stack - engine, version, hardware, configuration, and probably more - really belongs in the methodology alongside the model itself.
I wrote up the results here: “In AI Sweet Harmony” (arXiv:2510.01259).
Of course, it's impossible to know for sure what was LLM processed or not, but some of your posts (like this one) have been getting classified that way. (And if this was a false positive, I apologize!)
I have attempted to report numerous errors in your Chat UI, but you seem to have decided that customer input is undesired, as you have an AI support system that ignores my problem and refuses to escalate to anyone or create a ticket.
To this day, your in-chat “Report an Issue” button still does not work consistently, and I am still billed for empty responses from many image providers.
Pulled some data - a surprisingly large number of requests to models that generate images, where the user seems to want an image, do NOT return an image. In our chatroom it's ~11%! However, in almost all of those cases, the model is instead deciding to return text, and you are being billed (correctly) for that text. We are not billing you for an image that wasn't returned.
Concretely, we pulled data on the last few days of image gen requests in our chatroom (50,893 requests). 5,846 got a text response (which is frustrating, I'm sure) and were billed for text appropriately. The model did not generate an image.
There were 16 requests where a customer was billed, but neither an image or text was returned. Those should not have been charged, and we'll see if we can either fix that issue or ensure that customers aren't charged.
I think that's only on the enterprise plans? So no real protection for those of us using open router personally? Or did I miss other protections somewhere?
Hi HN! OpenRouter co-founder and COO here. Lots of questions about why we raised!
First off: We remain founder-led and founder-controlled, and intend on being here for a long time, creating awesome products for builders all over the world. We are basically a bunch of tinkerers who like building things, and try to make stuff that we would like, when building with AI.
Since this is about the raise though, happy to share perspective on it.
We believe that strong companies should have a strong balance sheets. We touch large volumes of spend, and have large spend commits across the ecosystem; having the cash to withstand what may come is a responsible buy-down of risk, and makes the company extremely durable.
It also tells our larger customers and provider partners that we will be able to continue to serve them (and pay our bills) for a long time to come. We don't need venture dollars to continue scaling (indeed the business is healthy) but you know when you don't want to raise $100m? When you really need it!
This is also good validation to employees (current and future) that the value we are creating together is real. We also take seriously our obligation to make a return for anyone who invests; we aren't valuationmaxxing and have the privilege of getting to pick who we work with. I don't think that gets a lot of airtime in the overall start-up world, but I think it's important!
Happy to answer questions and THANK YOU to everyone here who uses OpenRouter, and to everyone who has feedback for how we can improve!
What will OpenRouter use the $100m for? You say that it "makes the company extremely durable" and is "good validation to employees", but I'd imagine that there are more interesting things to do with 100 million dollars.
Everyone wants a conspiracy, but what I originally posted is in fact the boring truth. Having a bunch of cash in the bank makes for a durable business!
> We don't need venture dollars to continue scaling (indeed the business is healthy) but you know when you don't want to raise $100m? When you really need it!
That's a nice narrative but I suspect you're not touching upon the investor pressure side of things. Your earlier investors would be upon you to show a multiple in valuation beyond what the balance sheets can show. The only way to do that is to raise more money.
The problem with this is that you're now beholden to another set of investors who will also expect a multiple on their investment which makes increasing valuation your primary objective, even to the detriment of the business. With a margin business you could sustain for a long time even when the market stagnates, but you've lost that option when you first took money from someone. It's an all or nothing play now.
By default (and in most cases) investors and operators are aligned. When we diligence our investors, we call companies they worked with where things didn’t go well, and speak to those founders. Understanding how investors operate when it’s not all up-and-to-the-right is important when picking partners!
I’m interested what you believe the intent of your message to be. You’re talking to a COO that just raised money as if you’re mentoring someone about to approach VCs for the first time. Hugely patronizing attitudes often just get a pass here on HN, but what is your purpose for using one here?
I think you misread my comment, I might've been lazy in constructing it. I don't mean to mentor anyone, rather I'm putting out my read of the situation so there's a common ground over which to discuss.
For me, raising $100m when it's not needed doesn't add up. Nobody lends money with the idea to "keep it, just in case". There are always commitments and expectations and obligations to meet those expectations. So when they said they didn't really need to raise, while also not talking about investor expectations, feels there's more to the situation than is being let on.
Would it be possible to get "raw" access to the provider APIs, but still keep the consolidated billing? The unified API is great when it works, but it often causes hassle with more exotic use cases and new API features.
+1 this. Example: Using Mistral TTS voice cloning appears to be not possible via the "providers" pass-through object in the OpenRouter API because some parameters are always forwarded which conflict with the provider's parameters.
Interesting. Will look into it! We are releasing pass through API params soon which might hit the bid, but is a bit different than what you are describing.
API param passthrough will probably help with many of the cases. Things like sampling params and constrained decoding and returning logits tend to be very finicky with the translated params. But the return value translation also makes debugging these harder.
While I'm at it, another annoyance is that OpenRouter doesn't seem to have a very good API playground. The chat does work, but the params exposed there are quite limited and it's not clear how the GUI fields map to API params. I now have resorted to exporting the chat and figure out the params from the export JSON. Just having an option to get a curl command for the chat call would help a lot, and shouldn't be hard to implement.
Edit: I think the ideal implementation for the direct API access would be that I could generate API keys for the provider at OpenRouter that I would give in the provider API calls, but that would get billed through OpenRouter. Second best would probably be a raw HTTP proxy/tunnel that injects OpenRouter's own keys (or however it is that you call the providers). I don't really know though how you call the providers and what kind of new provider integrations these would require.
Heya! First off, I love your product. consolidated billing/auth solves a big pain-point, so thank you.
Less about the funding and more about the long game: where do you see OpenRouter in 3-5 years, and which product bets are you most excited about right now? Do you guys think with this new raise you'll branch out into other adjacent verticals?
Our general theory of the case is that, in the not so distant future, inference will be the second largest opex line item for most companies (behind headcount) and that sourcing, measuring, and governing those tokens is a massive horizontal opportunity.
We will inevitably expand into adjacencies because we like building things and experimenting and we have a lot of people with great taste who are likely to ship cool things that customers want to use!
The Openrouter website says that y'all do not train on the data, but it does not make it clear that the data is not shared with any 3rd parties (other than the LLM provider) who might train on it.
There is the example of Apple and Google providing transport for push notifications, but claiming to delete the content and only preserve the metadata.
What is Openrouter's policy on this? Is the logging of user data an essential part of the business model, or is the primary business model really facilitating a proxy between multiple services and nothing beyond that? If everything is logged, do y'all store it securely so that if one database is stolen (by China for example) then it's not useful on its own?
With the race for AGI and everyone training on each other's outputs, Openrouter is clearly in a position to abuse all of that even though the major providers weaken their output to limit the value of distilling them.
We have two mechanisms whereby we retain data. Both are opt-in and off by default.
One mechanism where you get a discount and we can use the data (in theory this does mean sell it; but our intent is to use it to make efficient dynamic routing solutions. But absolutely we could one day sell it) and another where we retain it for you so you can see it in your logs. We have no rights to this data in any way. This is similar to how any tracing/logging solution works.
Both and opt-in. If you don’t opt in, we don’t retain anything and are a pass through with regards to your prompt data.
All of this is carefully documented and I encourage you to explore and chat with the docs.
Do you specify prompt data, because prompt data is subject to user copyright, but LLM outputs are not? There is the issue that LLM outputs might leak user data back through the response. Y'all don't log those either, correct?
The biggest missing feature for me is the differentiation on zero data retention providers and if a model works for the rules I defined. Right now there’s no way to hide the providers who don’t work for the zdr rules
What differentiation are looking for? We have good documentation of every provider and what their data retention stance is, and you can figure allow/blocklists for all providers.
Check out the Guardrails section under settings and tell me what’s missing!
Thank you for Openrouter, used it briefly. Tested the product a year ago or so, and wasn't able to get structured output from google's gemini model via openrouter.
Refund policies are clearly documented in our terms. We actually DO offer refunds within 24hrs of credit purchase, which is significantly more flexible than most companies that operate in a similar way. And we try to use good judgement when there are extenuating circumstances.
I understand that the refund policy is documented. But “clearly documented” and “fair to the customer” are separate questions.
If a user cancels API access while still holding prepaid credits, that unused balance represents compute they never consumed. Unlike a shipped physical product or a fixed one-time service cost, unused API credit does not seem to impose much marginal cost on OpenRouter to reallocate or refund.
So the issue isn’t whether the policy is disclosed. It’s whether keeping unused prepaid credit after cancellation is the right default, especially when the user is no longer able or willing to use the service.
Yeah we should do something to indicate cardinality. I can share that there can often (I'm talking generally; not related to this model in particular) be e.g. a very large app that can be pushing a lot of volume. But in almost all cases that app has a large number of end users. Hypothetically, for instance, would Cursor be consider one user, or millions?
I'd consider Cursor one user because it's one entity that made an editorial decision about which model to make available to their own community.
If you treated Cursor as millions of users it might look like millions of people independently chose a new model when actually it was Cursor making the choice for them - and the thing I care most about is how many choices were made that selected a model and put it above the others.
An alternative viewpoint is that the single choice made about switching the Cursor model was done after extensive testing by a competent and experienced team. Whereas my naive self choosing a model to play with this week is far less a signal to others that the model is fit for purpose.
One idea I had was to count # of distinct API keys that have spent atleast $100 (number's flexible), which would be enough to provide guidance on if the traffic is from a single power-user.
In the Cursor case which is BYOK, that would count as distinct API keys.
Hi! Big fan of OpenRouter and the data you provide. It'd be awesome if you would consider providing volume of tokens per hour, mostly for my own curiosity as to quite how peaky demand is.
reply