Live data from Hacker News

Codex pricing to align with API token usage, instead of per-message

help.openai.com

71–80 of 212 posts

Re: Codex pricing to align with API token usage, instead of per-message

#71
post #4

Earlier quoted context omitted.

Good!

It’s kind of a rug pull to effectively raise the price like 10x. I can’t afford to finish some of my projects with this change

I don't think you can call it a rug pull when everybody saw it coming from miles away

Re: Codex pricing to align with API token usage, instead of per-message

#72

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.

Pay 100 Gold or 15 Gems to generate this feature

Re: Codex pricing to align with API token usage, instead of per-message

#73

Things must be bad if they're doing this before their IPO

Billions of USD in debt, a business model bleeding cash with no profit in perspective, high-competition environnement, a sub-par product, free-to-use offline models taking off, potential regulatory issues, some investor commitments pulling out... tricky.

But let's not cry for the founders, they managed to get away with tons of money. The problem is for the fools holding the bag.

Re: Codex pricing to align with API token usage, instead of per-message

#74
post #3

The days of subsidized access is rapidly coming to an end.

subsidies always lead to waste.

This is false.

Two examples:

- https://www.msn.com/en-us/money/other/three-years-after-tria...

- https://record.umich.edu/articles/public-school-investment-r...

Re: Codex pricing to align with API token usage, instead of per-message

#75
post #73

Things must be bad if they're doing this before their IPO

Billions of USD in debt, a business model bleeding cash with no profit in perspective, high-competition environnement, a sub-par product, free-to-use offline models taking off, potential regulatory issues, some investor commitments pulling out... tricky. But let's not cry for the founders, they managed to get away with tons of money. The problem is for the fools holding the bag.

Unfortunately the fools holding the bag are going to be those who own index funds when these companies are inserted into them.

Re: Codex pricing to align with API token usage, instead of per-message

#77

Any takes on how Codex compares to Claude? I mostly use it to run ahead, document, investigate and prep the actual implementation for Claude. Gemini burned me too many times but maybe the situation has improved since.

5.4 is great. I use it for python professionally and for typescript/front-end games and educational apps recreationally. In my experience it's roughly as good as opus, just a lot cheaper. It's amazing how much usage you get for $20/mo

Re: Codex pricing to align with API token usage, instead of per-message

#78
post #40
post #18

Earlier quoted context omitted.

Is writing it by hand the old-fashioned way not on the table?

It's really not. As a one-person IT department I'm now able to build things in hours or days that it previously would have taken my weeks or even months to build (and thus they didn't get done). Things people have wanted for years that I didn't ever have the time for, I can now say "yes" to.

[flagged]

Re: Codex pricing to align with API token usage, instead of per-message

#79
post #68

Is this not just about extra credit? So what's included in the subscription doesn't change - just extra credits are now token based instead of message based? (For Plus/Pro)

God every single title I read about AI on this site ends up being a straight up lie.

I miss “BREAKING NEWS” as it is used at X /s

Re: Codex pricing to align with API token usage, instead of per-message

#80

Earlier quoted context omitted.

We are exiting a hype cycle, well into the adoption curve. Subscriptions were never going to last. My next step is going to be evaluating open and local models to see if they are sufficiently close to par with frontier models. My hope is that the end of seat based pricing comes with this tech cycle. I was looking for document signing provider that doesn't charge a monthly, I only need a few docs a year.

I'm developing software in this area right now, so I try a lot of the new models. They're not even close for coding tasks. It basically comes down to 26b parameters vs 1T parameters / quantisation / smaller context sizs, there's no comparison. However, for agentic work, tool calling, text summarisation, local LLMs can be quite capable. Workloads that run as background tasks where you're not concerned about TTFB, cold…

Kimi K2.5 (as an example) is an open model with 1T params. I don't see a reason it has to be local for most use cases- the fact that it's open is what's important.
Post reply on HN