I had access to X API's new pay-per-use model and here is my feedback

Always found X's API pricing pretty harsh and it always discouraged me from experimenting on it. The huge difference between X Basic ($200) and X Pro ($5000) says it all. If you build an app on X Pro and small unexpected traffic can make your app hit monthly limits way earlier than expected and go out of business. Of course this small hit in your traffic will not make you rich enough to upgrade to a Pro account. Glad some guys realized this in X Team and introduced top-ups which mildened the risks a bit, but still far from the ideal scenario. Therefore, when the X developer team launched the news on their X account accepting demo-builders to try out the new 'pay-per-use', I immediately requested and after a few weeks got acceptance (just right after they charged me for X Pro for the next month—coincidence? let's hope so).

Pricing

Economically speaking, I did expect higher prices per post (you know economics of scale - things are cheaper in packages), but still find it a bit too expensive (mathematically speaking something between 2-3x more expensive than X Basic charging rates per post). For instance, at the Basic tier, a third-party app could read 15,000 posts and publish 50,000 posts per month for $200. Under the pay-per-use model, a single post read costs $0.005 and a single published post costs $0.01. This means in order to read and publish the same number of posts as the previously $200 per month Basic API tier, a developer would now pay $575 per month. Oh, also, let's not forget X Team's generosity with a $500 voucher for the early-accepted users like me.

Console

The most satisfying thing so far is the new console. Actually, there's nothing fancy here, but the console for the Basic tier (called Developer Portal) was very useless without any detailed usage dashboards. The new console dashboard displays requests and posts usage instantly both in post count and pricing. I am optimistic that the dashboard will be further improved since there were enough requests in the community about that as well. Yes, the early-adopters are also invited to X Community to report bugs, provide feedback, and active members are even promised new voucher credits for the upcoming months.

Most optimal usage for me

Since 'pay-per-use' model is still expensive and current fixed tiers/packages are not efficient for scaling, I (still) see the solution in a mixed approach. Fortunately, there are businesses around which offer their own 'pay-per-use' models which are way cheaper than X's offer. They built their own business model around buying expensive packages (which small or medium companies do not need) and offering to multiple clients with small margins to make enough profit. Also, a lot of X data is stored in their own databases, which reduces actual calls to X APIs. There are certain risks associated with these businesses as well: security issues, server downs, limited response chunks (for instance while with the original X API you can receive up to 500 posts of an X user in one request, third-party API providers can limit this to a max number of 20 in one request/call), and a major emerging risk - X limiting their business via legal claims since X now is officially in the 'pay-per-use' business itself. So, what I do for optimizing X API calls for my app (supabird.io) is keeping write-posts (actual posting on X) to the official X API since they are relatively cheap calls ($0.01 for text-only posts) but also very important calls, while moving read-posts (fetching user data, followers, posts etc.) to third-party providers. However, each function that's calling a third-party provider is backed up by an official X API call in case things go wrong (probability is not low).

To sum up

While the new model didn't bring revolutionary changes to X API pricing, it definitely makes things much cheaper for early experimenting, and also helps to calculate per-user costs in a much more predictable way for scaling. I tried to write down and share my own experience, and how I try to optimize it, so do not accept what's written in this blog as the best practice. Happy hacking!