Hacker News Reader

Comment by mrweasel | Hacker News Reader

Why not just attach a real dollar amount, rather than using "credits"?

Well, I know why. I just wanted to be snarky. It's just that trying to hide the actual price is getting a bit old. Just tell me that generating this much code will cost me $10.

View on HN

I can think of a few other reasons:

- Not everyone uses dollars.

- The price of credits in some currency could change after you bought them.

- The price of credits could be different for different customers (commercial, educational, partners, etc)

- They can ban trading of credits or let them expire

> Not everyone uses dollars.

> The price of credits in some currency could change after you bought them.

> The price of credits could be different for different customers (commercial, educational, partners, etc)

Maybe I'm missing something, but doesn't every other compute provider manage that without introducing their own token currency? Convert to the user's currency at the end of the month, when the invoice comes in. On the pricing page, have a table that lists different prices for different customers. I fail to see how tokens make it clearer. Compare:

"This action costs 1 token, and 1 token = $0.03 for educational in the US, or 0.05€ for commercial in the EU"

"This action costs $0.03 for educational in the US, or 0.05€ for commercial in the EU"

> They can ban trading of credits or let them expire

That sounds extremely user-hostile to me

otherwise you end up with "get a $20 subscription for 1000% more value -- equivalent to $200 in API usage!!![1]; [1] -- compared to API pricing for american companies on the first weekend of the month between 18:00 and 22:00 UTC+8 during full moon"

in any case, better than what anthropic does

> user-hostile

credits do expire (I thought they always do?), apparently it's not really up to them: https://news.ycombinator.com/item?id=46230848

A fundamental architectural problem is that they genuinely do not know what a query will cost ahead of time.

Even for a single standalone LLM that's the case, and the 'agentic' layers thrown on top just make that problem exponentially worse.

One'd need to entirely switch away from LLMs to fix this problem.

Isn't this an orthogonal issue that doesn't affect whether billing is done with credits or money?

If the expensive parts of the query happen to work iteratively (especially if agentic), you can act on those loops to bound the cost. Even if it's pure forward generation, you could pause an expensive inference and continue it seamlessly with a cheaper model, adding little to the cost.

Pay 100 Gold or 15 Gems to generate this feature

You joke but as a parent, I’m so sick of the gem packs, etc. they try to push on the kids to obfuscate your actual spend on games in real world money.

And now it feels like the are gamifying the compute we use for work for all the same reasons.

I refuse to play games where you pay real money for consumables.

I hate that pattern so much. It’s also not just to obfuscate the spending - it’s also to ensure you already have some amount left over in your account, so that it feels like you’re not spending as much to just “top up” and afford that one thing you want this time.

If you have some left over that you can’t spend, it feels like you’ve “wasted” them.

Board games do not have this problem.

What is snarky about that?

The answer is so that they can charge different prices per credit. If you buy low amounts, they can charge one price. If you buy in bulk, they can offer a discount. The usage is the same, but they can differentiate price per usage to give people more a favorable price if they are better customers.

Is there anything wrong with that?

Taximeter effect

Reply on news.ycombinator.com