Live data from Hacker News

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

help.openai.com

151–160 of 212 posts

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

#151
post #115

this is indicative to me that the exponential is slowing down. tool and model progress was huge in 2025 but has been pretty stale this year. the usage changes from anthropic, gemini, and openai indicate it's just a scale of economy issue now so unless there's a major breakthrough they're just going to settle down as vendors of their own particular similar flavor of apis.

What makes you think that progress has stopped? Anecdotally I personally seem to think that it's accelerated, I am having conversations with ambitious non tech people and they now seem to be excited and are staying up late learning about cli and github. They seem to have moved beyond lovable and are actually trying to embed some agents in their small businesses, etc.

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

#152

Earlier quoted context omitted.

> I would prefer if it actually explodes sooner rather than later The idea, as far as I can tell from all the pro-AI developers, was that it will never explode, and the performance will continue increasing so the slop they write today doesn't need maintenance, because when that time comes around there will be smarter models that can clean it up. If the providers are tightening the screws now (and they are all doing i…

They could also do a plan 3 where they discourage others so they can use it to, say, rapidly build many new products but competitors would have to pay a fortune for the same luxury Just spitballing.

> They could also do a plan 3 where they discourage others so they can use it to, say, rapidly build many new products but competitors would have to pay a fortune for the same luxury

Unlikely that they all decided to do this within weeks of each other. Still, like you said, you were spit-balling, not asserting :-)

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

#153

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.

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.

[flagged]

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

#154
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.

Sounds like, in the words of Douglas Adams, a SEP.

This isn't your problem; this is management's problem for cutting headcount, or not caring about the things that people wanted.

As it isn't your problem, paint it bright pink and move on.

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

#155

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.

Codex has better quality and way more usage, but Claude Code is more pleasant to interact with and use in a lot of tiny ways

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

#157
I'm confused as to how pricing works.

For home projects, I almost exclusively use the web chat interface to code. I haven't done anything large yet so I will iterate and get the web chat to update code, print out the code that I copy and paste.

How does this differ in terms of pricing than Codex?

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

#158
post #18

Earlier quoted context omitted.

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

Absolutely not. I took on some thins that would normally take 5-10 people and many months. Some people are turn out slop. I was really excited to try and make some impressive shit. My whole life has been dedicated to trying to embody what Apple preached in the early days. I knew this was coming, but I thought I had a little more time to try and get them over the finish line, ya know? Maintenance by hand might be achi…

> I’ve only got so much savings left to live on.

This confuses me - did you leave your job to cosplay as an EM, using LLMs to build your products? If not, then your savings don't matter.

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

#159

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.

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.

[flagged]

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

#160

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.

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.

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.
Post reply on HN