Live data from Hacker News

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

help.openai.com

191–200 of 212 posts

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

#191
post #178
post #121

I wish the Chinese would release a model comparable with 5.4 and free me from this pain

which ones have you tried? some are not far off, but it depends on what you do

I've tried z.ai, qwen, deepseek, minmax... they've all been barely half as capable as a middling Codex model.

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

#192

Earlier quoted context omitted.

The only catch is that you’ve spent many $1 and you don’t get any of those $10s unless you get over the finish line In that sense your analogy is kinda good. I totally agree the current situation is like getting my solo start up funded and subsidized … but with only like 4 months runway now that the prices are skyrocketing, vs ~2+ for a typical YC venture

Yeah, but... it's rocketing for everyone at the same time on all the providers at once. IOW, you are no further behind nor further ahead than your competitors compared to 1 week ago, 1 month ago, 1 year ago and 1 decade ago. Everyone has the same tools you have. The only advantage you get is if you make your own tools (I did that, and pre-AI, was able to modify my LoB WebApps at a rate of 1x new API endpoint, tested…

My comment was about the rapid and sudden cost spike of something happening unexpectedly.

They announced 2x tokens with months of notice. This announced this with no notice.

Me as an individual making a go solo is not the same as thousands of funded businesses having free credits, subsidized plans and bottomless AI budgets.

For a short period this was a massive equalizer. Now it’s a tool for those who can afford it. That’s a big shift.

Why is it that a person cannot express their own circumstances or opinions on this site without it turning into an argument? It’s so deflating.

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

#193
post #187

Earlier quoted context omitted.

I avoided Claude code and such the first few months because I thought it was all billed by the API. Which I knew was not worth it to me at all. Then I realized I was an idiot and this was magic. But it now seems more like an introductory offer to use the API, as opposed to an alternative product / way to use their API product. I thought it would get increasingly expensive, like say the $200 plan becomes $400. Switchi…

But it was well understood that the subscription was heavily subsidized. Whether or not it was a "separate product" doesn't matter as much as the fact that pricing was not sustainable.

It was not well understood that it would stop being subsidized without notice.

Does that just not matter in modern society? I’m an asshole for expecting the product I pay for on day 1 to be the same on day 8 and 29 of a 30-days subscription?

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

#194
post #116

Earlier quoted context omitted.

GH Copilot is still the best deal, while it lasts

Yeah, it's really good. Probably going to be the next best deal until they cut back. I need to try the command line version.

> I need to try the command line version.

Is there any other?

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

#195
post #178

Earlier quoted context omitted.

which ones have you tried? some are not far off, but it depends on what you do

I've tried z.ai, qwen, deepseek, minmax... they've all been barely half as capable as a middling Codex model.

i would try kimi

Qwen has also been improving recently, in fact most have, so depending on when you last tried them you can try again and see how they work for you

My local Qwen is decent for some things, Kimi is decent for most things and occasionally it has been able to do better than Opus and GPT 5.4 on particular tasks

it will soon be very costly to stay in just one provider

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

#196

The title is misleading and not in the article. This change is for business/enterprise accounts. Also, these are still credit based. The change is that credits now operate on tokens like the API rather than on messages as they used to.

Nope, they buried the lead a bit but this is coming for _all_ users, even pro/plus subscription plans. So you get chatgpt pro/plus benefits, and then effectively $20/$200 in credits for codex

> effectively $20/$200 in credits for codex

So, 1.3ish million tokens for Codex? Following the token limit from here https://openai.com/api/pricing/

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

#198

So Anthropic bundled CC with Claude.ai cuz OAI bundled chatgpt with Codex, now OAI is unbundling, IPO must be around the corner. Writing is also on the wall for CC usage based subscriptions now that main competitor effectively got rid of it. How are the Chinese models looking?

> Writing is also on the wall for CC usage based subscriptions now that main competitor effectively got rid of it. And I just subscribed for a year's worth of Claude... Terrible timing I guess. Do you know if the open models are viable?

Based on reading only I think a usable but a step below probably somewhat behind Sonnet. I also did read that some people successfully requested refunds late last year when their models shit the bed due to bugs so if they cut limits hard maybe you can try that

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

#199

Earlier quoted context omitted.

> I took on some thins that would normally take 5-10 people and many months. Based on what, exactly? It's very easy to claim some software would've taken you months to make, but this is ridiculous. Estimating project duration is well known to be impossible in this field. A few years ago you'd get laughed out the room for making such predictions. > I’ve only got so much savings left to live on. Respectfully, what are…

I’ve pivoted to writing native iOS, macOS, windows, Linux apps. Most of my career has been front end web. It would take me awhile just to learn and practice, vs having my visions working in hours or days I’m not ready to unveil the thing I alluded to, it’s important to me that it’s good and polished. But I’ve done quite well so far developing in Swift, Rust, Go, and coming up with marketing and design — things I defi…

Poolometer looks cool! I will say your smiley face icons look a lil odd and ai generated, but otherwise I love the graph tracking and suggestions

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

#200

Earlier quoted context omitted.

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.

That is just idealism. Being "open" doesnt get you any advantage in the real world. You're not going to meaningfully compete in the new economy using "lesser" models. The economy does not care about principles or ethics. No one is going to build a long term business that provides actual value on open models. They can try. They can hype. And they can swindle and grift and scalp some profit before they become irrelevant. But it will not last.

Why? Because what was built with an open model can be sneezed into existence by a frontier model ran via first party API with the best practice configurations the providers publish in usage guides that no one seems to know exist.

The difference between the best frontier model (gpt-5.4-xhigh or opus 4.6) and the best open model is vast.

But that is only obvious when your use case is actually pushing the frontier.

If you're building a crud app, or the modern equivalent of a TODO app, even a lemon can produce that nowadays so you will assume open has caught up to closed because your use case never required frontier intelligence.

Post reply on HN