| ▲ | powvans 3 hours ago |
| 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 that sells metered AI work. I think the analogy is ADP. Payroll for all the work that's going to be done by AI agents. |
|
| ▲ | aleqs 2 hours ago | parent | next [-] |
| Every token/llm provider already has usage metering...so not sure what exactly you're imagining stripe adds here |
| |
| ▲ | ygjb 2 hours ago | parent | next [-] | | 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". | | | |
| ▲ | kridsdale1 2 hours ago | parent | prev [-] | | Aggregation behind one interface, just like the actual token product. | | |
| ▲ | aleqs 2 hours ago | parent [-] | | That's what OpenRouter already does, so the Stripe value add here is still unclear | | |
| ▲ | pests an hour ago | parent [-] | | 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. | | |
| ▲ | aleqs an hour ago | parent | next [-] | | 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. | | |
| ▲ | user43928 27 minutes ago | parent [-] | | 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. | | |
| |
| ▲ | devmor 27 minutes ago | parent | prev [-] | | OpenRouter already supports this, requests return their exact cost. |
|
|
|
|
|
| ▲ | nevi-me 2 hours ago | parent | prev | next [-] |
| 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? |
| |
| ▲ | robocat 15 minutes ago | parent [-] | | 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. |
|
|
| ▲ | j45 2 hours ago | parent | prev | next [-] |
| 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. |
| |
|
| ▲ | shanev 2 hours ago | parent | prev [-] |
| I built modelrelay.ai that does this. Happy to give you an invite code if you want to play with it. |
