upvote
Every token/llm provider already has usage metering...so not sure what exactly you're imagining stripe adds here
reply
A single policy location for multiple models with usage limits/rate limits, spend limits all configurable using a common syntax + deep integration with account levels and high visibility into subscription/payments related to meter usage to help understand whether or not your pricing model is underwater as costs change is exceptionally valuable. AFAIK each product consuming model providers without an openrouter style proxy has to do that work themselves, and if you are already using stripe for subs/payments, the direct integration is a huge value add for customers, especially if you can alert on "upcoming price changes from your provider changes your unit economics for XYZ packages/sub tiers".
reply
You're just describing what OpenRouter already does?
reply
The first half yes, the second half, I don't think so, because that would require OpenRouter to know what you are charging your customers.
reply
Similar to how Stripe is a middleman for payments across (fragmented) banks, they want to be a middleman for (fragmented) AI models as tokens are the new currency.

As AI agents/harness/human are spenders of tokens, enabling them to derisk from being locked to a specific model provider & allowing to (re)route to any model at anytime for better leverage in a single API, similar to how they are doing for payments.

reply
paying for data access, for "deterministic computing", for letting the AI use online services. Maybe even micro payments for using tested and verified skills/mcps.

Example: access to real-time stock trading data, access to weather information, letting it make stock trades, etc.

At first I was confused why Stripe bought OpenRouter, but I think this makes sense.

reply
Aggregation behind one interface, just like the actual token product.
reply
That's what OpenRouter already does, so the Stripe value add here is still unclear
reply
Not OP, but I could see the vision. Right now OpenRouter is developer-paid with no way to pass costs onto the end user. Stripe could help bill and meter at the user level for per-user billing. I would also think more SDKs/easier ways to add AI features (paid for via openrouter) into apps and websites.
reply
Open router supports per-request usage metering, as well as per-key. Building user-level metering from this is trivial, and there are many implementations of this out there. Supporting per-user first-class is trivial considering Open router already has per-request and already supports per-request attribution. How important that is, is a big question, but definitely not something that requires Stripe to build.
reply
Could there be use cases where you want to run inference for users in your app, but don't want to host your own backend, user authentication, and billing?

The user could log into his personal OpenRouter account, authorize your application, and optionally set a budget, all in something like a Stripe payment screen.

reply
> The user could log into his personal OpenRouter account, authorize your application, and optionally set a budget, all in something like a Stripe payment screen.

Like standard oauth?

https://openrouter.ai/docs/guides/overview/auth/oauth

reply
Good point, just needs an user friendly flow to sign up and set the budget in a way that is more similar to Stripe checkout than regular account creation.
reply
deleted
reply
OpenRouter already supports this, requests return their exact cost.
reply
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?
reply
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.

reply
It's not just that.

As user agents become more common it's only natural that they will be used for taking the heavy lifting out of e-commerce purchases. There will be a big need for digital payments to verify and reconcile these purchases.

With LLMs that are plugged into digital payments we will essentially have buying agents in our pocket that can find us exactly what we want for the cheapest price and the quickest delivery.

reply
At some point AI will be able to deal with the repetitive and template based parts of accounting better than accounting.

Which is saying a lot.

reply
I'm not sure that's true. LLMs seem too unreliable for accounting.
reply
I'm always surprised at how many people in the tech sector don't think that things can and will change. In the next couple of years? Sure. 5+? Who knows. Necessity is the mother of invention.
reply
I'm always surprised at how many people in the tech sector assume overcoming fundamental LLM weaknesses is always “just a matter of time,” and that time will arrive quickly enough to be relevant. If you haven’t seen any of the videos of people trying to get frontier LLMs to count consistently, you might think we’re further from LLM accountant than you realize. It’s not a data problem— I’m pretty sure they’ve encountered numeric progressions between 1 ABs l and 100 before.

And there is no necessity. We have accountants.

reply
I'm not just talking about LLMs though. People thought the internet and email were just a fad that would never catch on. People thought that the idea of home computing was absurd. All because they only saw what was in front of them at the time.

Also, how many accountants do you know that are truly happy with their work? I'd like to think many of them would love to do something other than crunch numbers all day.

reply
> People thought the internet and email were just a fad that would never catch on. People thought that the idea of home computing was absurd.

We're far removed from "we've sold all the computers the world can buy" (back from when computers were the size of a building).

This is a disingenuous argument. The web and email were basically instant hits and people realized it. Similar story for home computing once the computing power caught up.

reply
> I'm always surprised at how many people in the tech sector assume overcoming fundamental LLM weaknesses is always “just a matter of time,” and that time will arrive quickly enough to be relevant.

Lots of techies are tech-optimists ("tech always improves quickly").

Lots of people also have dollar signs in their eyes (or related, such as increased visibility and scope).

Hard to tell which is which.

reply
Things can easily change for the worse, such as a stock market crash. Who knows? Will we get AGI or will we see more homeless? History says... AGI for sure!
reply
It's very difficult for this sort of thing to change for the worse. It's basically impossible on the software side. If next year's model is worse then keep using this year's model. Hardware technology can potentially go backwards, but things have to get really bad for that to happen.
reply
LLMs are inherently unreliable. We do already work with unreliable technologies for many things but there's this engineering principle called "use the right tool for the job".

And it's a lot more likely that LLMs can't be changed to become unreliable, it's just how they work. So we would need more basic research, that doesn't grow on trees and for which the timelines are basically open ended. Maybe tomorrow, maybe right after cold fusion hits mass adoption.

reply
I built modelrelay.ai that does this. Happy to give you an invite code if you want to play with it.
reply