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.

Think about what OpenRouter primarily traffics in and what you can do with that raw material.

seriously. you don’t raise $100m just to be safe unless you’re bleeding cash or you lied to the investors.

there are companies who raised xxxM$ and never had to touch the money because they were already profitable.

Yep!

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.

Great investors are helpful, not harmful :) You want accountability from smart, experienced partners!

Sure, but only to the means where they see a multiple. And sometimes that be at odds with the fundamental value prop of a business.

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 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.

i second this, And I think this will only get worse as the bigger companies seek to decommoditize their models and make moats

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!

Edit: also - THANK YOU!

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 never sold any prompt data to anyone, in any form, and have no plans to do so. Full stop.

Can you also confirm that you do not log/retain it. 100% pass through. If you are logging it, you could one day change your position on that.

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!

I’m specifically looking for it on the model page before I click into it if there’s any valid provider for it

There’s a filter on the models page for ZDR supported models

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.

how come cancelling api keys with left over prepaid credit isn't refunded?

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.

Just sent you a DM on twitter!

Thanks! We work really hard to make sure we are ready at launch :)

(openrouter co-founder here)

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?

Will think about it! Thanks for the feedback.

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.

Thanks!

Can you share more? I'm with OpenRouter and we would love to address this! We don't see this in our own testing, I don't believe -- but will share this feedback and dig in.

Just try. In a case last week it was ~3x and I tried multiple providers: deepseek, gmicloud/fp8, novita/fp8, and another one I can't remember. It was a large job where at least 2/3rds of the start of the prompts was exactly the same (literally a static string).

Then I read somewhere (I think X) that OpenRouter adds stuff and breaks caching (telemetry? headers? can't remember). So I stopped the job, switched to actual DeepSeek provider, and voilá, caching 3x more tokens per request (on average).

> switched to actual DeepSeek provider

I meant actual DeepSeek API.

Here is some data from my experience using both deepseek v4 flash directly, and deepseek v4 flash via openrouter.

Directly: 135M input tokens - $0.57 (134M cached)

Via OpenRouter 6M tokens - $0.81 (caching stats & inp/out not reported)

Caching is a huge win with using deepseek directly.

I am experiencing this using Opencode. Caching works fine via Deepseek API but not so good via Openrouter

Doesn’t it seem more plausible that the marketing shots are AI (where the “generated by AI” note appears) rather than the cover designs themselves?

Turns out it is exactly that, the OP's post has an update from them:

> Thank you for your comments. We just wanted to confirm that all Moleskine notebook covers are created by our designers, while AI was used to enhance the background of these images. We hope The Lord of the Rings inspires you!

I've seen people speculate along the lines of "all Moleskine notebook covers are created by our designers" doesn't necessarily mean "without AI".

Yeah I just really don’t see the issue in that (not saying you do or don’t either). If it were me and I were them I would have contracted with artists because it’s only a few images and it would avoid controversy. However I also use image generation tools for fun non-commercial pieces that I never would have done without the tools.

Does that make me more creative or less? I’m not sure.

That’s exactly what a clanker would say, isn’t it?

This doesn’t explain the cover (seemingly not used in the final collection) with a hallucinated map on it. Maybe they only used generative art for mockups, but they did use it on a cover design.

Shouldn't it be against some kind of law for marketing shots to not actually be of the product? I know there has to be some leeway, but a hallucinated image is clearly nothing to do with the actual product.

Does it matter? If you are opposed to buying AI art wouldn't you also be opposed to buying art from an AI ad?

Not from principle. Marketing is hateful work and almost necessarily anti-art, so I don't care. Of course you can do it badly (for example, unironically advertise to an artist audience with terrible slop illustrations).

I don't see how replacing a photographer with AI for advertising is considerably different from replacing a photographer of a nature scene with AI. Is it just "AI is okay for commercial uses"?

But it seems more extreme when the AI is recreating the art you are considering buying.

You are absolutely allowed to expose access to end users, as long as you continue to abide by terms of service. We have hundreds, if not thousands, of apps built on openrouter that in turn have end users of their own. We showcase many of them on our /apps ranking page!

TOS says: access the Site or Service for purposes of reselling API access to AI Models or otherwise developing a competing service;

So yes obviously you can do what you want as long as you abide by terms of service, but the terms of service does NOT allow you to resell the API.

> you aren't allowed to expose the access to end users, it has to be for internal usage only,

> TOS says: access the Site or Service for purposes of reselling API access to AI Models or otherwise developing a competing service;

I think what you meant is "you aren't allowed to expose the access to the API to end users", which is a fair condition IMHO.

You're still allowed to expose the functionality (ie. build a SaaS or AI assistant powered by OpenRouter API), just don't build a proxy.

To be clear, I like Openrouter and recommend it to many people (I don't aim to "shit on it").

It does talk about a competing service, if I build a service that propose all the image gen models of Openrouter, and charge the user for it per token, am I allowed?

I was actually wondering about this since I've seen like 3 comments talking about the same thing, would it happen to be related to money laundering due to the availability of the crypto payment method?

The comments are all from the same author.

OpenRouter recently started enforcing account-level regional restrictions for providers that enforce it (OpenAI, Anthropic, Google) - ie blocking accounts that look like they are being used by users in China. The regional restriction used to be based on the Cloudflare edge worker IP's geolocation and enforced upstream, so a proxy/server running inside of supported regions would get around the geoblocks, but now OpenRouter are using (unspecified) signals like your billing address to geoblock. People say "banned" because the error message says "Author <provider> is banned", which really should be read as "Unable to use models from provider due to upstream ban".

Which further strengthen the fact that you can't do anything you want with API keys, even if you pay for them.

there is a huge gap between 'doing whatever you want' and 'illegal activities' as well as upstream restrictions (out of openrouters control)

COO of OpenRouter here. Thats right — we haven’t done it to date but we can’t have unlimited liabilities stacking up forever. At some point we will start expiring credits from accounts that have seen zero activity in over a year.

Maybe a bad suggestion, but can you do an inactivity "fee" - 25% / year (min $5) or something similar. I like the pre-pay system everyone in Ai seems to have settled on, its better than the AWS bills that we all know and love.

> we can’t have unlimited liabilities stacking up forever

The liabilities are completely offset by prepayments from your customers though. Even better, you can earn interest on the deposits without paying any out.

If you just dont want the liabilities on the books, issue refunds. Expiring credits feels like a cash grab.

It's just basic bookkeeping, storing money over fiscal years is a nightmare to manage. (At least over here, dunno about whatever country Openrouter is based in)

Thank you for taking the time to explain that - makes sense. I lifted what was present in your terms of service as I'd like to understand the minimum time I have.

What if I deposited $10, and have lots of recent activity on free models and have barely touched the $10 for payg models?

In CA gift cards don’t expire and the industry does fine without having people buy expiring money.

I watched the video at the expecting one thing and finding something completely different. Remarkable — [0] watch the video in its entirety. Not what I thought when I read “staples to repair porcelain”.

[0] intentional human use of an em-dash

For others interested, perhaps a more straightforward example is here: https://www.youtube.com/watch?v=aGHkigtPcIA

The one in the article is the same essential technique (structurally speaking), but with a lot more decorative flourish.

"intentional human use of an em-dash" LOL

I still don't like them, human or pretend intelligence generated.

Please use the correct punctuation for subclauses, the comma!

However, I will give the comment author credit for _correctly_ surrounding the dash with spaces.

This is my biggest bitch about the punctuation, it's used without spaces, making it indistinguishable from hyphenation.

Written english is a space delimited language! The exception of the hyphen is to explicitly create one word by connecting several.

As per its own FAQ this plugin is out of date and doesn’t actually do anything incremental re:caching:

> "Hasn't Anthropic's new auto-caching feature solved this?"

> Largely, yes — Anthropic's automatic caching (passing "cache_control": {"type": "ephemeral"} at the top level) handles breakpoint placement automatically now. This plugin predates that feature and originally filled that gap.

I don't understand and I'm curious, why a dead on arrival open source tool needs a separate domain?

  Domain Name: prompt-caching.ai
  Updated Date: 2026-03-12T20:31:44Z
  Creation Date: 2026-03-12T20:27:35Z
  Registry Expiry Date: 2028-03-12T20:27:35Z

It's more likely the other way around, the .ai domain with a fairly generic and maybe future-proof name needed a quick vibecoded project to not be empty when it launches.

Is it perhaps because this is for claude code but there's other tools that use anthropics api like custom agents? (some i prefer to use than claude code - e.g sketch.dev what is now called shelley at exe.dev) perhaps?

No, because this doesn’t actually “fix” any existing code. It’s only useful for helping an LLM to modify your code to adjust the caching parameters in the right place, but it doesn’t have the correct API for that.

I’m pretty sure whoever made this didn’t read the website they asked their LLM to generate for them.

At the risk of totally misunderstanding this...it seems to be exfiltration by the app developer, who already has access to all of these data sources and the data that the customer is inputting into the AI KYC app (in this example)...right? I don't believe this exposes any end-user information to a third party. The AI app developer is already 'trusted' and could get access to this information regardless of the exfiltration. Maybe someone can explain this to me more clearly.

The attacker isn't the dev -- the attacker is a third party that poisoned the online data that is ingested by the AI tool.

- Dev builds secure AI app - App defends against indirect prompt injection in data from the internet - Dev reviews the flagged log - Log affected by the injection is rendered, and the attacker who wrote the injection in the web data exfiltrates the data from the AI app user

Agreed. The writeup could use a little Alice, Bob and Charlie treatment to make that more clear though.

The OSINT data seems to be the most likely source of the poisoned content. I guess you could bury that in a social media profile?

The situation this applies to is when input from the attacker is fed to a LLM, but the response from that LLM is not returned to the attacker.

If an attacker tries a prompt injection they would be unable to see the response of the LLM. In order to complete an attack they need to find an alternate way to have information sent back to them. For example if the LLM had access to a tool to send an SMS message the prompt injection could say to message the attacker, or maybe it has a tool to post on X which an attacker could then see. In this blog post the way information gets back to the attacker is by having someone load a URL by by viewing the openai log viewer.

The problem seems to be that OpenAI claims to protect against these problems. So yes, the app dev is malicious, yes, the user activated the app, but the platform (openai) also claimed to protect the user from the app dev exfiltrating data. Seems like there was a chink in the armor there.

At least that is my initial reading from this.

No, OpenAI doesn't claim to protect users from anything; this is a case of an application exfiltrating data to OpenAI, which can then end up getting leaked back out to the attacker - that's not something that is up to OpenAI to prevent, that's up to the app developer.

It's the same as if your devs accidentally sent PII to Datadog - sure, Datadog could add some kind of filter to try to block it from being recorded, but it's not their fault that your devs or application sent them data. Same situation here: bad info is being sent to OpenAI, and OpenAI's otherwise benign log viewer is rendering markdown which could load an external image that has the bad data in it's URL.

In that same situation, you'd expect Datadog to just not automatically render Markdown, but you wouldn't blame them for accepting PII that your developers willingly sent to them. Same for OpenAI, they could clean up the log console feature a bit to tighten things up but it's ultimately up to the developers to not feed secrets to a 3rd party.

it sounds like the data can be involuntarily disclosed to an external third party (the attacker’s domain) purely because someone reviewed logs that auto-load remote images

their log viewer renders the markdown and their browser will make a request containing the sensitive data to the attackers domain where it can be logged and viewed