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".
replyYou're just describing what OpenRouter already does?
replyThe first half yes, the second half, I don't think so, because that would require OpenRouter to know what you are charging your customers.
replySimilar 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.
replyAs 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.
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.
replyExample: 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.
Aggregation behind one interface, just like the actual token product.
replyThat's what OpenRouter already does, so the Stripe value add here is still unclear
replyNot 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.
replyOpen 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.
replyCould 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?
replyThe user could log into his personal OpenRouter account, authorize your application, and optionally set a budget, all in something like a Stripe payment screen.
> 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.
replyLike standard oauth?
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.
replydeleted
replyOpenRouter already supports this, requests return their exact cost.
reply