Hey everyone, I’d love your input on a potential change to our MAX pricing. At the moment, we charge per tool call for MAX, which supports agents with incredibly long context windows and unlimited tool usage. However, this structure has some issues:
- Short context requests end up being over-priced
- Long context requests are under-valued
- You cannot allocate your 500 free requests to MAX
We’re considering moving to API pricing for MAX. Under this model, we would pass through the actual API costs with a slight markup and convert that into equivalent requests (each request costing $0.04). What are your thoughts on this change? Do you see any benefits or alternative solutions for improving MAX pricing?
sounds like a good idea. api pricing is usually fairer for everyone. just make sure u give us some kinda cost estimator tool, ya know? don’t wanna get surprised by a huge bill at the end of the month lol. also, maybe think about some sorta package deals for heavy users? that could be pretty sweet. anyways, i’m down for it if it means i can use my free requests on MAX!
As someone who’s been using MAX extensively, I think shifting to an API-based pricing model could be a smart move. It addresses the current pricing imbalances you’ve highlighted, particularly for short vs. long context requests. This change would likely make MAX more accessible for users with varying needs and potentially encourage broader adoption.
One significant benefit I see is the ability to allocate free requests to MAX. This could be a game-changer for developers looking to test and integrate MAX into their projects without immediate cost concerns. It aligns well with how other API services structure their pricing tiers.
However, it’s crucial to ensure that the markup remains transparent and reasonable. Users should feel they’re getting fair value for the service. Additionally, consider providing detailed usage analytics so users can optimize their API calls and manage costs effectively.
Have you considered offering tiered pricing plans alongside this API-based model? This could cater to different user segments and potentially simplify budgeting for heavy users.
I’ve been using MAX for a while now, and I think moving to an API-based pricing model could be a good move. It would definitely solve the pricing issues for short and long context requests.
One thing to consider though is how this might affect heavy users. Will there be any volume discounts or caps on pricing? I’ve worked on projects where API costs can spiral quickly if you’re not careful.
Also, passing through the actual API costs plus markup sounds fair, but it might make budgeting trickier for some teams. Maybe you could offer a fixed-rate option alongside the API pricing for those who prefer predictable costs?
The ability to use free requests on MAX would be great for testing and prototyping. That alone might convince more developers to give it a try.
Overall, I think it’s a step in the right direction. Just make sure to provide clear documentation on how to estimate costs under the new model. It’ll help users adapt more easily.