Is Consumption Pricing The Only Viable Model for AI?

Is consumption really the only viable model in the world of AI? I think it is, but there's more than one path to get to consumption. This is the key here. The oh shit moment everyone's worried about is that huge bill that they're gonna have to go up to their boss and ask for more budget or more money. It's a little nerve-wracking to go into a software or an agreement and not know how much of it you're gonna use. And real CFOs don't buy that way. They're really not gonna accept the answer of, I don't know, it depends how much I use it is what the budget would be. So really short introduction on myself. I'm Marcos Rivera. I'm the CEO of Pricing.io. I also was the head of pricing for Vista Equity Partners. Been doing pricing for about 25 years, probably if I'm counting over 500 different pricing engagements. Just seen a lot as software has evolved, and it's an exciting time in the AI space to see how pricing is evolving with all the new technology, the advancements we're making. So I like to have a little fun with my presentations, 'cause why does pricing have to be boring? You're making a lot of money, right? So from my perspective, I'm gonna add some color in terms of where I'm seeing consumption fall down. I call it clumsy consumption. I'll show you a little bit about that. I'm also gonna give you a framework for how to maybe help strike the right balance in your consumption-based models. Is the question I was given was, is consumption really the only viable model in the world of AI? I think it is, but there's more than one path to get to consumption. It doesn't mean everyone here has to go charge by tokens tomorrow. I think there's a lot of ways to manage consumption. I'm gonna show you a framework real quick around it, but also some patterns that I've been seeing in a lot of companies that we've worked with around AI from startups, that are bootstrapped to startups that are investor-backed and have a lot of money to companies that are SaaS, SaaS dominant, and that are infusing AI within their stack today. So what patterns are we seeing? I'm gonna talk a little bit about that as well. What I'm seeing here is something that as I've been in software from the on-premise days and moving things to the cloud, to mobile, to SaaS usage, and now AI, I've noticed the shift from access to action. And what I mean by that is initially the value was all in the system, right? You buy this big system, we install it, then you pay some big fee and then you just use it for a while. You capital expenditures, all those fun things. Seats and servers were the primary driver, but you weren't able to capture too much of that value. As we moved on to more cloud-based, more modern architectures, now we're able to capture more of what the software is doing, but it's still a lot of people behind that. That's what I was calling activity. And so value is in what humans were doing with the system. And now we're shifting to this, what systems are doing for humans. It's a bit of an angle shift, but what's happening is now work is not just being done by software and technology, it's being delegated to software and technology. And that shapes a little bit of how the value is exchanged. So I spend a lot of time thinking about this, and I sit and I wonder, like, what does that really mean in terms of the price point, the packaging, and the structure?. And so I want to step you through that a little bit. But first, I want to give you a sense for clumsy consumption. So let's go to the next one here. So in the middle, you already see it there. It's pretty recent, so that's why we put it up there. But Cursor made a really big blunder. And when companies make blunders in pricing and packaging, I pay attention because I think that's an opportunity for others to learn, okay, this is a mistake I don't want to make as well. But I put a few up here just to show that it's not just Cursor. Jasper. Made a big mistake with consumption-based pricing. They were charging by word count. Folks were ticked off around it, trying to find ways around it. And a quick hint here is, someone is trying to find a way around your consumption metric, it's probably not the right consumption metric. Moving on to the cursor, yep, they did make a big blunder on the unlimited. It caused a lot of users to come at them pretty angry about bills. It's something they thought was unlimited, and they had these overage fees and things like that., and when someone is judging your consumption-based model, they always judge it by the lowest exchange. And what I mean by that is the worst exchange between what they pay and what they get. It's just human behavior. It goes right down to that unit. And then around AgentForce, if everyone remembers, they made this really big, bold move to charge per conversation. A lot of pushback there. They didn't get the, uh, traction that they wanted, and so they, they fell back into this credit-based, this flex credit model, It was a lot easier, a lot more friendly for folks to consume. They still, by the way, have the per-conversation option if you look at their website, but the credit system sort of like helped ease things in. The thinking behind me and my team is like, well, why did that work better? What was it about the credits and the Flex that seemed to appease a lot of the concerns from the base, the huge base that Salesforce has? So I'll talk a little bit about that, but first a story, a personal one for me. So I've been doing pricing for a long time. I'm gonna go back about 18 years ago to 2007, where I was a bright-eyed, optimistic product manager, and I was already having a reputation for changing a lot of pricing models. So I got this new product, and it was sold to insurance companies, all right? State Farm was my customer, Progressive, and talk about companies that are trying to avoid risk and are really hard to negotiate. The pricing model that they demanded was Naturally, we want to pay a very simple flat fee and we want to use it as much as we want, right? That was, that was their opening in negotiating. And initially it was a user-based system. So think about the people who go look at the damage on your car. It was by user. So however many field adjusters you had, that was the pricing model. And so when I inherited it, I thought, well, but isn't this thing making them more efficient? Like, can't they do more with less if this optimization product works. We're gonna be rewarded with less revenue if we do a good job. And that's usually the first signal that a user-based or user seat pricing is not going to work for you. So I switched the model. I switched the model to consumption-based. This is 2007 consumption, not AI consumption, right? So just bear with me. But the idea was, I said, well, the thing that's coming through the system are claims. So every time a claim happens, right, you get into an accident, somebody hits you in the parking lot, you send someone out for the damage. So I thought, okay, what a claim would work really well. Turns out it did. It was huge. The product went from a $300,000 a year in revenue product to $30 million. It's about 100x, right? Over about 2.5 years. And it did that because the model just aligns so well. But what I don't say is that we also ran into issues with the claim as the consumption metric. And the reason why is because while claims were known, easy to count, understood, things like that, and you can predict it, they still had overage risk with hurricanes or tornadoes or catastrophes that would happen, very unpredictable, but can completely change the trajectory of how many claims they had per year. So they were always worried about these spikes that would come in, right? Everything else was fair and so on and so forth. So we ended up changing the model to have to address those moments of the oh shit moments, like I'm gonna get this huge bill as a result of this. And when it comes to consumption-based pricing, that's one of the biggest things you have to solve for. So I'm gonna give you a few different angles on how to solve for that. So this is a table that I put together. This is about 70, 75 different AI companies. And I was trying, I was looking at all their models and I was also talking to, I know some of the founders and I was thinking through, okay, so it seems like there's these components of your pricing model. There's the base, which is usually some package of features and capabilities. Sometimes they work services in there too. There's the included volume. Some call these allocations or entitlements, right? But this is more around how much volume's included or not. And then there's this sort of scalar volume or this scale that you can move up or down as usage changes over time. And this one down here in the bottom, the scale volume, is where most of the risk is when it comes to consumption-based pricing, okay? So up here on the top, I have just a series, you know, by complexity of different models, and they manage consumption in different ways, all right? So let me walk you through each one, and I'm gonna give you a bit of the levers, all right? All right, and then we're gonna step in a little bit deeper on a few of 'em. So the first one is access tier based. Now what does that mean? That means you have tiers with different levels of access. We've seen this model, we're very familiar with it. Good, better, best is a very common example of it. Not always good, better, best, sometimes there's 2 or 4 packages, but you get the point. Each tier gives you more. The way you're able to manage capabilities and performance within the tiers, so for example, the more premium tier allows you to do something more advanced, maybe access to more complex logic or more advanced models. Maybe the premium tier allows you to do certain tasks that are multi-step where the more basic tier gives you one-step tasks. So you're able to then modulate a bit of consumption just by access within the tiers. And so simple, basic versus more complex, more advanced. Allows you to manage sort of your backend consumption tokens, you need a bit more firepower to handle more complex tasks. If those are the higher tier folks, there's fewer of them paying more versus the lower tiers who can't access, and so on. So this is how— this is almost like a consumption-based model in disguise because it's sort of hidden behind a wall of these 3 capability or feature-based packages. But in essence, they're modulating consumption because they're modulating the amount of complexity behind. What you're seeing this in Granola, for example, the note-taker tool my team uses. A lot of these note-taker tools have these different, different tiers and some allow you more, more advanced capabilities. Notion, Slack, other companies like that are also increasingly adding more capabilities to the higher tiers. So Notion, for example, and Slack both had AI as an add-on. I don't know if you guys use Notion or Slack. I use it all the time. It was always getting these little pop-ups to add the little add-on for $5 or $8, whatever it is. And now they've recently switched over to, well, it's just included, right? We're just going to include it in the base. But as you move up in tiers and more premium tiers, we're going to allow you to do more, right, within there, which is modulating a bit of my consumption. That works really nicely for where people are still pretty involved in getting to the outcome, not just the product. Okay. And that's the first tier there. That's a little bit less obvious, but there's also something called fair usage policy where in the background they may say, hey, you can do these, you can do them unlimited, but try not to do like a million of them in a minute, right? They have these different windows. And so you use that to help modulate and protect yourself from consumption. This is the, you know, from a risk perspective, the customer is really not undergoing or taking on a lot of risk of overages or paying more. They just have to stay within the bounds of the plan they purchased. But as you move more to the right here, complexity and the product is doing more of the work. You'll notice flat plus unit price, something known as a two-part tariff for the— for us pricing nerds out there, right? It's just basically a two-part pricing system. So what I've been seeing here is a lot of fixed, maybe fixed per seat or fixed fee. And then as you see, there's not a lot of included volume in this model. It's just fixed plus a per unit charge, right? If you think of Intercom, it's $59 for an agent and then it's in addition $0.99 per outcome on top of that, right? So there's a fixed plus model there. This was a good model. I mean, seeing a lot of agentic AI kind of go this route where there's a base and then some unit price on top of that. And if you, you know, buy a ton of volume of it or you can, you know, you'll get some economic benefits for the commitment. But that's just a two-base model. It has a nice balancing act to it. But the more common one moves over to the next one, which is a three-part tariff. So the two-part tariff and the three-part tariff, the only difference is that there's some included volume as part of that fee. All right? So you pay a fee, there's an amount of volume included, and then you pay in addition once you exceed that volume. Seems fair, right? But that's where a lot of the risk starts to come in. Is this volume enough for me? Am I going to exceed it? What happens when I exceed it? Am I going to pay more, etc.? So this 3-part model here comes in, and I also see a lot of platform fees with some included credits as well. There's a primary volume limit, so whatever the thing is that you're purchasing, you can have a volume limit. You have what's called secondary volume limits, which are things like other elements of the software that you can add. It could be For example, Clay has like maximum number of companies in addition to credits, right? So they have these other vectors as well. So you could create other boundaries within the system that help you control consumption. And then here you pay by unit. You also have the opportunity to give them different overage options. This is the key here. The oh shit moment everyone's worried about is that huge bill that they're going to have to go up to their boss and ask for more budget or more money. How you avoid that is you give them overage options. What happens when you go over? I'm going to smack you with a bill. Not necessarily, right? There's 3 Ps that I use when it comes to overage options. The first one is protection. There's a cap protection, won't go over beyond your limit by this amount. Some of them can even set that cap in their systems, and that at least gives them a little bit of assurance that, hey, if it goes over, it'll only go over by X. The second one is performance. This is one that I think Klein does this a lot, which is they, you can go over, but your excess capacity, especially in this model with AI, gets queued. And Cursor just recently went to this as well, is we can choose which model we want based on our cost economics and you can't choose if you go over. So we're not gonna charge you, but you get throttled back, you get slowed down. And this has been around for a long time. If you remember, they still do it today, right? Companies that offer Wi-Fi or coverage, international especially, if you go over the international limits, they'll say, "Okay, you can go over, but we're gonna throttle back your access to the internet." So that throttling does help ease the pain and the fear that you're gonna hit them with a big stick. The third P is called passive. And passive, what I mean by that is you don't have to charge them right away. If they use the software and it's September 1st, and they go over on September 2nd, you don't need to smack them with a big bill, right? You can take that overage fee and there's ways to either manage it to either allow them to catch up over time. I'm gonna talk about time in a minute. You can use it as a true forward, meaning let's take this overage and adjust your next renewal depending on how close they are to renewal. And then third, you can say, look, this overage happened 2 months ago, 3 months ago. Figma was famous for this for their users. You added a user license, they wouldn't bill you for like a quarter. By then the users are already in there and getting a lot of value, so they just pay for it, right? And so deferring that bill and using it as a mechanism to negotiate another contract or to get them to upsell or allow them to catch up, those things allow you to then reduce that fear of what happens in the overage, right? So think about those, the protection, the performance throttling, and the passive., and that helps you give them overage options. From here, we've seen credit systems. You remember Kyle was just mentioning it's the hot new thing, you'll see them everywhere. Uh, I'm actually a fan in certain contexts. I talk to a lot of folks who can't stand credit systems, and I ask, well, what is it you don't like about it? They say— I get the same answer every time— I don't know what a credit means. It obfuscates it, right? It's kind of what it's supposed to do. But the idea behind credit-based systems, it could be very effective if the value of the credit and what you can do with it is super clear. And I've seen companies run into some problems where the credit is a little murky, they're not sure what it is or what it means, or they change the value midstream 'cause they're experimenting so fast that it really disrupts the credit system itself. But I think credit systems offer a fantastic way to manage that risk. You can buy a bunch of credits up front, you can burn 'em down, you can give 'em a discount per credit, for buying upfront. So there's a lot of good mechanisms, but it does make things a little bit tougher for you. You have to worry about rollovers. You have to worry about arguments that, that should not have counted as a credit. Okay. So that does increase your ability to maintain clarity with your customer. But if you can do it, a credit system can work really nicely. Then I have this one here. I call it MACs, and MACs are multi-access credit systems. And I've been seeing these spring up lately, maybe in the last 6 months or so. Let me tell you what a multi-access credit system is. A MACS is really just a credit system where you have multiple types of credits or multiple accesses that you're using the credits for. Quick example. If you look down here, I put Lovable. So you have daily credits and then you have monthly credits, but your daily credits don't impact your monthly credits. Your monthly credits are based on your fee. Your daily credits you get and they expire right away, but your monthly credits actually lasts you for the whole year. Two axes of credits, right? Base44 does this as well, where they have integration credits and then they have flow credits. And so there are two different types of credits that you can use because they have two different values. So I've been seeing these and I think you, you got to be very careful not to go down a slippery slope here, right? I think most folks can, can understand a credit, but once you start throwing in multiple types of credits and multiple types of terms, it gets really tough to maintain clarity., and you, you flow right into confusion right away. So I think with this model you wanna be really careful, limit the number of types, limit the number of types of credits. And then lastly, of course, pay as you go, pretty self-explanatory. You just pay per token and just go on your way. So that was a good deep discussion on, or the, the description of all this. And I'm gonna use this as kind of a basis for before I go to my last slide, has any questions on these different layers of base access included in Scale? Than any of these models here.

I consider fairness from the customer's perspective. Like, it seems like if you're paying for a bunch of credits and then you don't use them, I mean, the complexity points are great, but how do you think about fairness? You talked about avoiding an overcharge. Do you care about, oh, I spent $7 million with you, I only used half of my allocation? How do you address that?

The concept of fairness is an interesting one, right? Because when I ask customers what's fair, it's actually what's What's fair to me, right, at the end of the day? From a fairness perspective, I think you want to do two things. One is you wanna make sure that you don't oversell credits upfront. I think one of the big issues I've been seeing is that sales reps are still compensated in either top-line revenue or total contract values, and their incentive is to just jam in as many credits as they possibly can, which then leads to an issue even before renewal as they were like, "Well, we're halfway through the contract, and I've only used 10% of my credits. I think I've oversold," and I've seen others make adjustments, like midyear adjustments, or either give them an additional credit towards the end to say, "Okay, for next year, we're going to actually bump up your limit." The second thing I've been seeing, from a fairness perspective, is this concept of first-year forgiveness, right? First-year forgiveness is, we're going to do our best to estimate, "You can go over. I'm not going to charge you. I'm not going to touch your rate, and then we'll agree that in the next renewal," which typically is a 2-year renewal, which is another way that works really well, "we're going to go ahead and reset your credit." So the idea is upfront, good faith estimate, and then go forward. And that, from the customer's perspective, feels a little bit more fair, because you don't know what I'm going to do, and neither do they. So the idea is, Can we at least walk into this together and then play a plan forward knowing that these subscriptions are mostly relationships, not just one-time transactional events.

These are, feels like interesting.

Curious if I were to take up like choosing one of them, what kind of questions should I ask so that I fit in like one of them? Yeah, that's a great question. I took off a lot of those parameters, but I'll verbally layer 'em in for you. Just 'cause it got really hard to digest. Yes, so she wants to know what things should I think about to fit within one of these tiers or what elements or what factors? I paraphrase, but that's the essence of it, right? So when you think about this, if you go all the way to the right, complexity, I'm seeing a lot of, and again, from an AI perspective as well, LLMs have a subscription and a consumption-based model. If you've seen a lot of 'em, you know, there's access my API, pay these tokens. Or go ahead and pay $20 a month or $200 a month. I think Groq has like $300 a month now and just go ahead and access and then just stay within my, within my, my parameters of usage. Right. So in essence, I'm seeing LLMs mostly on the outskirts here. A lot of companies are converging here in the middle. So how much your product is doing versus people. Remember I said earlier, if people are more involved, then the usage piece is, is harder for them to consume, mainly because when the product is doing all the work, it's very simple. Yes, you pay per usage, but if the person is just using, um, say, a Canvas and using AI to generate a summary of a meeting, oftentimes you stick a little bit more on this side where simplicity— you've managed it through capabilities, performance, and you could include some volume that is very specific to what the product is doing. So say your workflow product, your productivity, a lot of people logging in, things like that. You can work more a little bit on this side with access tiers or a flat unit. And a unit, a 3-part tariff also works. But as you move more towards the product actually doing a lot of the work, think about queries, think about code, Viya coding assistance, things like that. They tend to be more on this right side, more complexity, more product doing the work. Things like that. But I'm seeing a lot of companies, as I talk to them, sort of converge in this middle area. I'm seeing a lot of the extremes change their models and evolve them forward and move a little bit more towards a 3-part tariff and the credit-based system. That's why I highlighted them there. That's where the trend seems to be pointing to.

What's the difference between cater, use, and maybe credit?

They're similar. The only difference is the unit is the actual action or event. Think of like a request. Or an API call, things like that, where a credit is an abstraction layer beyond that. A credit is a— think of it as almost like a different currency, and that credit could apply to different actions. Yeah, that would be the only difference. But they're very similar and they work and operate in the same way.

So I think this question is subjective to individual businesses. Maybe a step back when you're pricing your individual credits. As the business owner, would you recommend just pricing based off of usage costs, or would you also factor in delivery costs like implementation, customer support? How would you price your individual presence as a giver of credits?

Yeah, that's a great question because I think some, some may be tempted to, to fold all the burden within the cost structure. Where you got to be, you know, from my perspective, that can lead to a bit of a death spiral. Oftentimes, if your volume increases to a certain extent, that a lot of these costs can spread over a large number of units and therefore decrease. So I always look for the variable first. The variable cost is the one I would factor in more so than the, than any of the supporting or base costs. And the reason why I do that is mainly because I know that my economics will change with volume, number one. Number two, I do know that in this world, in AI, you can actually change your economics pretty quickly by shifting from a new model to an old one or an old one to a new one, right? Essentially, different models can incur different types of tokens and costs, and therefore you're able to change your economics overnight. If you remember what happened with DeepSeq, that could change a lot of economics quickly. You can also delegate your agent or your AI, whether it's a custom GPT or task, to a lower or an older model that can do the job at a fraction of the cost and then change it from there. So that's why the variable cost is more important a factor than total.

So we've been discussing consumer or prosumer-based applications a lot here. How have you seen this play out with infra or DevTools-based applications where, you know, there are some examples here, token-based pricing for inference services, but when one thinks a little more broadly, pricing can either become very complicated or has to be really simple for infra. So how have you seen that play out with these different models?

I think infra poses a— and so the question is around how do you see this playing out for more infra DevTools, things like that, where the complexity and simplicity, you really have to hit on both, I think, in the end of the day. Simplicity for developers to pick up and use. Most infra or developer-focused tools need some level of sandbox or try it or let them test it out. Tinker, I think, is the word they like to use just to make sure they can see they can get value from it. But ultimately what ends up happening is there's the beginning middle, and then the long term. So let me explain. So when someone is picking up a tool, an infra tool or a dev-focused tool, they're learning to see if it has any value. These are problem solvers. These are folks who find ways around things, right? So you have to be able to show clear value in whatever it's saving time, whatever that might be. And then in the beginning, that you don't want them to shell out a lot of money for it. So that's why you often see focused freemium plans where it's like hobby, test or pre-production, you can do this, but you can't deploy to production, things like that. Then in the mid-tier, when they start ramping up, this is where they'll start developing more, maybe integrating you into some other source systems. They're getting more vetted, more embedded. And then so what ends up happening is now your cost is gonna climb, but typically they need to see some sort of either per user cap or some tiering that can at least share what that additional cost would be. If their volumes were to go up. So that's the visibility piece. Then long-term, this is the part that I think a lot of infra tools forget, is that developers, at least I know a lot of the smart ones, always have a backup plan and will switch you out if they don't like the cost that you're giving them, right? So, you know, we all know microservices and they can make things very tight and very componentized. So if they see the cost climb too much in the long-term and you're not able to meet their stress test, you're going to get swapped out for another tool that has better economics. And they also react very strongly if you're marking up those costs. They get it that you have costs, you need to pass them along. But if they're seeing 40, 50, 60% markups, they get ticked off. All right. 10, 20%, I've seen them be okay with. And I say okay, some developers don't want any. But the point here is you have to break down the infra. There's the beginning piece, which usually means a small allocation. And then a more of a fixed fee structure with allocations with visibility into the overage. And then third typically is some discount for higher volumes over time, so their units go down. Those are the three pieces I see for infra that fit in here, and it kind of fits in that, again, three-part tariff and credit-based system. But that's for infra because you're— you have to manage that over time with them. That may be a longer answer than you expected, but that's, that's how I look at it. So let me hold, I got one more slide to summarize a couple of things where you're trying to balance clarity and complexity. This is just what I've seen working across a lot of different companies here. And I'm a frameworky kind of guy, so I found everything falls into a T. Transparency. So the first thing around transparency is giving tools to estimate and monitor usage before you go down the consumption path. I can't stress this enough. It's a little nerve-wracking to go into, a software or an agreement and not know how much of it you're going to use. And real CFOs don't buy that way. They're really not going to say, accept the answer of, I don't know, it depends how much I use it is what the budget would be. Oftentimes they're actually stealing budget from other places or trying to manage an overall number. So you have to be able to give them at least some way to estimate and monitor that usage. So that way the visibility kind of calms down the anxiety. All right. And these tools aren't that hard to build. Clay has one right on their website, Cursor, they all have them. Really easy. Believe it or not, some companies skip this step, and I want you to do that. Have a clear fair use policy. If you do want to manage some of those high-spike unreasonable volumes, then just post it and say, "Here's our fair usage policy, here's what it means, and here's the parameters you have to stay within." You can even build it into your contracts as well. On the type side, have an indisputable definition of what a credit or what the unit is. And this is, again, one thing that I think companies should spend a little extra time on if they're going down the credit-based or the consumption path, is what does a request— what does this mean? And don't just take in the unit. Also take in the state of the unit. What I mean by that is action completed, or action processed, or something like that. Don't forget the state, because that's where a lot of arguments can come in. And then I see fewer is better, less than 3. Yes, it's okay to have 1 or 2, but I think once you start getting past 3, I asked a bunch of folks, when does it start getting complicated for you? I got a bunch of answers, but they circulated around 3. And so once you stick to 1 or 2, if you can, once you start getting to 3 or more, it gets super complex. Time. Matching your reset period to your billing period. So this is something I've also noticed where if you're gonna sign up and subscribe monthly, then your 1,000 credits or your 1,000 requests will be per month and reset per month. But if you sign up for annual, then you get the, all the $12,000 and then you sort of can burn that over time. It allows for less noise, I think overall, less billing and allows them to burn down over time. I've been seeing that trend quite a bit. And then rewarding long-term commitments. So if you guys know where, for folks that sign up for annual or multi-year, you generally see like a discount, right? Typically 2 months off, 15, 20%. But what I've been seeing lately is additional usage. Sign up for a year, get an extra 20,000 credits, or sign up for a year and you get more leniency. So think long-term, more lenient when it comes to overages, right? So those are other two benefits to rewarding long-term commitments. This is especially in AI, as you see a lot of tire kickers out there who may want to try it but never actually commit and use it. Okay? And then teeing up, teeing up the upsell or the actual move from free to paid. So small allocation to trial. I was mentioning earlier, developers love this. Give them some credits. Monday.com now has a 500 credit AI credit in each of their plans. If you exceed that 500, that's when you start to go in and pay for more credits to use AI, for example. Try to seed that, that move up and then offer options upon overage. I mentioned earlier about being passive, the protection, the performance, those things. You want to give folks a way to go and avoid that sticker shock that is gonna really give them anxiety to sign. All right, the better ways you can manage through that, the better your ability to capture those deals and grow them. Okay? All right, I think that is my last slide. What's my next one? I think it's just my QR. Yep. That's my LinkedIn profile if you wanna follow, but I post about this stuff all the time. I talk to companies all the time about this. I advise about 24, private equity firms on AI pricing, SaaS, all that fun stuff. And I just spill everything I know on there if you want to know more.

One thing I struggle with, with metered billing and consumption-based pricing in general is it seems orthogonal to value-based pricing. And it's, it's it opens a discussion around per-unit pricing where there's a race to the bottom, a lot of pressure around per-unit pricing, and it just changes the conversation entirely about value. How do you, how do you address that?

Yeah, I'll take it a step further. Sometimes if you go pure unit-based, and my friend at Snowflake talked a lot about this, is when you're building capabilities and differentiation in your product, that's not always captured in the unit-based price, and you often— doesn't seem to be rewarded that way. And so what I look at is, you're right, pure usage can be, if there's no other differentiation, can just drive the price lower. I can do the exact same thing they can do, but for less. The way to avoid that, and the reason for the collapsing in those two models with the three-part tariff for the credit systems, is that first base access layer is actually a really key way to start driving more differentiation. And I mentioned earlier today, you can not just drive in different capabilities in terms of access to features and other resources such as data sources and things like that. You can also throw in services. I know Kyle was mentioning this with chargeback a little while ago, but you could also have differentiated services, access to information or resources that no one, no one else has. And then third, either a user experience or just a very, very clean integration or a rich, robust integration with something else that no one else has. Yes, that's not reflected in the unit price, but it's reflected in that base access piece. And so you're able to sort of help combat some of that commoditization or race to the bottom with the base access differentiation that you have. Oh, that prompted another question. I don't know, Fynn, am I allowed to? Take one more.

Yeah, I was wondering, do you talk about what would you see people looking at Shuro Wallet in their pricing strategy? Because I feel like credit-based pricing leads itself down this like, oh, well, I'll use somebody's personal credits and then I'll go to Claude and I'll use my $20 subscription there instead. I mean, obviously more important than your credit, I will let an individual, I will pitch, people thought about it.

Yeah, I think I think the share of wallet discussions are actually getting more active with the 3 layers I just walked out, laid out for you. Walking through the base access tier gets, sometimes comes from one wallet versus some of the overage pieces. I'll talk about, I didn't talk about this today 'cause I'm running out of time, but there's this distance to the pricing and purchasing decision that I took off of the chart 'cause it was just getting too messy. If you're enterprise and you're, your, this purchasing decision is far away from the actual usage and overage, then you're actually making the most money from that base layer and the includes because they don't wanna think about it again. Versus if you're a little bit, if that purchase decision is a little closer to the, the scaler, which is typically when a developer is startup founder, et cetera, you're making actually more money on the volatile or the usage layer. And so when going after a share of wallet, You're actually laying out, okay, so we can get budget from, you know, IT, budget from labor, but we could also get budget from other departments as well through the different layers that you laid out, usage included or base. So I think, yes, the answers are there, but it comes from different layers within my system.