Live data from Hacker News

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

help.openai.com

61–70 of 212 posts

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

#61

For the past month, I've been claiming that $20/mo codex is the best deal in AI. Now I'm going to have to find the new best deal.

Check out z.ai coder plan. The $27/mo plan is roughly the same usage as the 20x $200 Claude plan. I have both and Claude is a little better, but GLM 5.1 is much better value.

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

#62

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 recently experimented creating a Python library from scratch with Codex. After I was done, I took the PRD and Task list that was generated and fed them to opencode with Qwen 3.5 running locally. Opencode was able to create the library as well. It just took about 2x longer.

Which version of Qwen 3.5 did you use?

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

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

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

#64

Earlier quoted context omitted.

I recently experimented creating a Python library from scratch with Codex. After I was done, I took the PRD and Task list that was generated and fed them to opencode with Qwen 3.5 running locally. Opencode was able to create the library as well. It just took about 2x longer.

Which version of Qwen 3.5 did you use?

which quant as well

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

#65
post #57

Earlier quoted context omitted.

Yes. > This format replaces average per-message estimates with a direct mapping between token usage and credits. It's to replace the opaque, per-message calculation, not the subscription plan.

It does feel like also impact the usage meter for subscription plans?

Usage meter has always been completely opaque anyway. They could (and probably did) shrink the limit whenever they like.

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

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

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

#69

For the past month, I've been claiming that $20/mo codex is the best deal in AI. Now I'm going to have to find the new best deal.

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 starts, tok/s etc., this is where local AI is useful.

If you have an M processor then I would recommend that you ditch Ollama because it performs slowly. We get double or triple tok/s using omlx or vmlx, respectively, but vmlx doesn't have extensive support for some models like gpt-oss.

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

#70
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

Sounds like saying my plan to get rich buying up $10 bills for $1 hit kind of a rug pull in that people aren't selling them for that price anymore.
Post reply on HN