Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenRouter is joining Stripe

openrouter.ai

Post reply on HN
Print view View original

271–280 of 532 posts

Re: OpenRouter is joining Stripe

#271

Post by robocat »

nevi-me wrote: post #182
powvans wrote: post #109

AI products are going to have to deal with accounting. An agent performs some work. It uses some models and perhaps some other metered services. Someone has to meter that activity. They have to attribute costs, apply the product's pricing rules, bill the customer, collect, reconcile with vendors, and maintain the ledger. Stripe can use OpenRouter to build the financial and accounting infrastructure for every product…

IDK, that sounds like a solution in search of a problem. What would be different about this than what OpenRouter is currently doing with pricing?

Metering as a service?

Perhaps stripe thinks metering is a lovely big market? A nice complement to their existing service. Plus a little AI buzz likely helps their valuation. OpenRouter could be a step rather than a goal.

Re: OpenRouter is joining Stripe

#273

Post by tomnipotent »

cute_boi wrote: post #200
asadm wrote: post #165

Earlier quoted context omitted.

OR I can keep paying 15% markup till next month and then jump to newest / cheapest model with one-liner change instead of being locked to a model/provider.

Which model/provider locks like this, most of them use chatgpt style apis anyway.

That requires that you create accounts and separately manage each provider you want to use. OpenRouter removes that - if a new provider gets added, you can start using them immediately.

Re: OpenRouter is joining Stripe

#274

Post by macNchz »

BeetleB wrote: post #223
rkangel wrote: post #71

Earlier quoted context omitted.

Yeah, and Stripe is "just" a payments platform. Openrouter is easy, reliable and performant (like Stripe).

Payments is quite hard, actually. Payment platforms existed for years before Stripe came along. They solved the problems the others couldn't.

Having worked on web apps that processed online payments before and after Stripe I totally agree, this was an area of real pain that became suddenly extremely simple because of Stripe. The alternatives were terrible–100 page Word docs of SOAP API docs for Authorize.net, massive PCI compliance requirement specifications, horrible legacy merchant services businesses.

On the other hand, I operate an app that talks to (and logs prompts/meters costs) to many different LLM API providers, and I do not consider it painful at all. I have an AI agent to deal with any integration quirks, if needed. Mostly they provide OpenAI-compatible APIs anyhow. It's basically a no-brainer to go direct with the providers and save 5%, the great majority of the cost of an AI-powered app is no longer dev time implementing the integration, it's the tokens themselves.

Re: OpenRouter is joining Stripe

#275

Post by hmokiguess »

thatjoeoverthr wrote: post #268
hmokiguess wrote: post #218

I rather have protocols be built and less middlemen PaaS. One great example is Open Banking. I would support an Open Router that mirrors Open Banking, unfortunately the Open here doesn’t carry the same connotation. Kudos to the team for succeeding in executing around a clear DX issue during the chaos of providers, though long term I am not really a fan of it staying as is even if Stripe gets to be the one carrying it…

One problem here with the protocols is the field isn't yet so stable. Most people are copying OpenAI's endpoint, and so you have "OpenAI compatible", but there are always little hairs on it. Case in point, OpenAI itself no longer offers multiple basic inference options on their new models. Can't pass temp, get back logits, etc. on anything after GPT 4.1. It's not a total zoo and Open Router is pretty easy but everyth…

Agreed, though that's not a reason to discourage building it or putting it forward. That's more the reason why a protocol would be beneficial, we are ending up with price wars and middlemens everywhere because we're racing.

Re: OpenRouter is joining Stripe

#276

Post by dzikimarian »

hmokiguess wrote: post #239
Muromec wrote: post #233

Earlier quoted context omitted.

What open banking? I can't even get a read-only token for my personal use to see the balance on my account and I sit two team calls away from people who cooked the API

Where it is already operational and available elsewhere worldwide. Unfortunately complex lobbying and Wall Street not being a fan of it as they’re the biggest loser makes it slow to get it done in the US.

In the EU you also cannot just get a token to open banking.

Re: OpenRouter is joining Stripe

#277

Post by lxgr »

michaelbuckbee wrote: post #259
apexalpha wrote: post #194

Great product, been using it for a while. Turns out even a proxy can be worth $8bn with the right business model behind it. Users get an array of providers competing behind a single API, meaning they have to compete on price and quality not vendor lock-in. This encourages users to join OpenRouter over specific model vendors. Providers get easy access to revenue (and data) and new customers with little to no ad spendi…

I've been using OpenRouter since relatively early (I build evvl.ai - an eval platform on top of it) and think that they're selling at a good time. An underpinning of their model is that API calls / inference are similar across providers allowing for commodity tokenization cost comparisons, but the providers are beginning to shift to non commodity features that don't easily shift. For instance, calling Gemini with "se…

> For instance, calling Gemini with "search grounding" isn't something that OpenRouter can do (they sub their own web search in)

It can: https://openrouter.ai/docs/guides/features/server-tools/web-...

It's apparently even the default these days (which makes sense, as it's usually better in my experience).

Re: OpenRouter is joining Stripe

#278

Post by lxgr »

hmokiguess wrote: post #230
flexagoon wrote: post #225

Earlier quoted context omitted.

Every single Open Banking implementation I know also requires everyone to go through a useless certified middleman (eg. Plaid, GoCardless, ...) instead of letting people use the APIs directly

Brazil did PIX which in that case the middleman is the government and everyone got to benefit from

Isn't PIX a payment scheme?

Open banking is slightly different, as it's more about account access (although with read+write access, you can kind of build it into a payment scheme as well, although it's usually clunky).

Re: OpenRouter is joining Stripe

#279

Post by ppalata »

theplatman wrote: post #265
flexagoon wrote: post #225

Earlier quoted context omitted.

Every single Open Banking implementation I know also requires everyone to go through a useless certified middleman (eg. Plaid, GoCardless, ...) instead of letting people use the APIs directly

would encourage you to read up about how the rest of the world has solved this

When you say rest of the world, what countries exactly do you mean? I'm from the Czech Republic and the process is also insurmountable for a regular company. You either go through a middleman or you can apply for a license (only 4 companies in the entire country ever got it and it costs upwards of $50k in legal fees just to file the application).

Re: OpenRouter is joining Stripe

#280

Post by TZubiri »

Taikhoom10 wrote: post #176
TZubiri wrote: post #34

Earlier quoted context omitted.

Is that 100M of openrouter revenue? Or money that flows through openrouter? If the latter, 100M$ annualized looks like very little. It's as if a bank said that it has 100M$ of annual transfers, instead of 100M in revenue from bank fees and such. Hard to think of any type of company that can do the topline meme as effectively as a compute aggregator proxy. Almost like a bitcoin pool mining company counting their share…

We are in a bubble, but you are looking at this in the wrong way. OpenRouter basically creates lock-in through Stripe's distribution and family of products; it is much stronger within Stripe than alone. I agree valuations are absurd, but it is what it is. But if we have to go through a bubble for a16z to crash and burn, I am all for it.

So customers use OpenRouter to avoid lock-in to specific model providers, and in doing so they lock-in into openrouter's aggregation API?

Lock-in to what exactly? A string(string) function without any further restrictions? Note that aggregator users will not use more specific parameter features (because those vary by vendor), or they escape the aggregator and lock-in directly string(string, vendorOptions={"openAI.logprobs":true})

Selling vendor lock-in to vendor lock-in avoidant customers sounds like a losing proposition, like trying to beat competition on price and undercutting, which is a thing openrouter does too btw, the main reason people use these products is to get cheaper prices. I don't think 2$/M tokens is expensive, and I don't think those that try to cut costs are going to win, whether devs cutting token costs, or small business owners with 5 employees who look at AI as a way to fire 2 of them. I get that the other end of the spectrum is overspending and tokenmaxxing, but the conclusion is that extremes are bad? Nothing new here.

Post reply on HN