Both are great, where they differ is: Claude Code has a better instinct than Codex. Meaning it will naturally produce things like you, the developer, would have.
Codex shines really well at what I call "hard problems." You set thinking high, and you just let it throw raw power at the problem. Whereas, Claude Code is better at your average day-to-day "write me code" tasks.
So the difference is kind of nuanced. You kind of need to use both a while to get a real sense of it.
I think the way I and others use it is code with clause, review or bug hunt with codex. Then I pass the review back to Claude for implementation. Works well. Better than codex implementation and finds gaps versus using Claude to review itself in my opinion.
I'm happy I invested in setting up Codex CLI and getting it to work with ollama. For the toughest jobs I can use Github Copilot (free as an academic) or Gemini CLI. If we see the per token price increase 5x or 10x as these companies move to focusing on revenue, local models will be the way to go, so long as stuff like Gemma 4 keeps getting released.
There was a headline saying they were, and the actual article showed they were doing nothingbof the sort.
If you read HN headlines, and don't even bother to click into the comments and see everyone calling out the headline as bogus, you might think something like your statement is true.
Codex just changed the way they calculate usage with a massive negative impact.
Before a Subscription was the cheapest way to gain Codex usage, but now they've essentially having API and Subscription pricing match (e.g. $200 sub = $200 in API Codex usage).
The only value of a subscription now is that you get the web version of ChatGPT "free." In terms of raw Codex usage, you could just as easily buy API usage.
edit: This is currently rolled out for Enterprise, but is coming to Pro/Plus soon. The people below saying "I haven't had this issue" haven't yet*.
> e.g. $200 sub = $200 in API Codex usage [...] In terms of raw Codex usage, you could just as easily buy API usage.
I don't think it's made out like that, I'm on the ChatGPT Pro plan for personal usage, and for a client I'm using the OpenAI API, both almost only using GPT 5.4 xhigh, done pretty much 50/50 work on client/personal projects, and clients API usage is up to 400 USD right now after a week of work, and ChatGPT Pro limit has 61% left, resets tomorrow.
Still seems to me you'd get a heck more out of the subscription than API credits.
This. ChatGPT Pro personal at $20/month and using GPT 5.4 xhigh is the best deal currently. I don't know if they are actually losing money or betting on people staying well under limits. Clearly they charge extra to businesses on the API plans to make up for it.
In the future, open models and cheaper inference could cover the loss-leading strategies we see today.
Right, because you're on the old and not new structure.
They just rolled it out for new subscribers and existing ones will be getting it in the "coming weeks." Enterprise already got hit with this from my understanding.
That's a huge pain point, but I'm curious! What would be a good approach in your opinion? I'm not questioning the exit/print error and carry on, that's plainly wrong.
When working on private projects/libs, my functions usually return an enum error type, and do all data handling - be it arguments or returns - through pointers passed as args; I mean, I think that's the usual convention, but you clearly have way more experience, so I thought about asking! :)
On Windows, this problem is already solved well. Return 32-bit integers which conform to that spec: https://learn.microsoft.com/en-us/openspecs/windows_protocol... Possible to pack OS errors, third party library specific errors, and other classes of errors into a single value.
Technically, you can implement that spec for all OSes. I did a few times, defining vendor-specific facilities for Linux components I used, like xwindows, drm/kms, etc..
How do you return an error that communicates "missing quote on line 42 character 200"? A much better solution is to use std::expect (or something home baked if not available) and make the error type something that holds an actual context. HRESULT is a remnant of the past, not something you should replicate in your own code if you have the choice.
> How do you return an error that communicates "missing quote on line 42 character 200"?
For that use case you gonna need some other piece of data besides the error code. Maybe another type like json_error_t in Jansson library. Or maybe a special strings, like the ones returned by sqlite3_errmsg() in SQLite library.
> not something you should replicate in your own code if you have the choice
I believe HRESULT, despite rather old, is still the best error handling strategy overall.
Language-specific solutions like std::expected don’t work because all complicated software is written in multiple programing languages. For example, the entire ML ecosystem uses Python. 32-bit integers and strings are as language agnostic as you can possibly get.
Enums don’t work because most non-trivial libraries have an unbounded number of possible error conditions. You made a parser library for some format, defined an enum containing all possible failures of the parser, but then a user tried to parse a file he doesn’t have read access to. The failures need to include disk I/O errors. Another user gonna parse their source file from a mounted network share, the failures returned from your parser now need to include TCP/IP errors.
Typically, you have a parser handle and can use that to query it about various aspects of its state. Here it would include line number, character offset, and byte offset. The type of error can be encoded in the error return value.
well, i guess in C you should return a value indicating the error probably via a struct that contains the error and the success data. C programmers seem to have a terrible aversion to returning structs (possibly they don't realise that you can do it?) where in other value-based languages (e.g. c++, go) it is very common.
of course, there are reasons for mucking around with pointers. but down that route lies pointers-to-pointers, and eventually madness.
> How does Unity estimate the Runtime Fee when I have not supplied data?
> While we always recommend you supply your own data, in the absence of that, we will use our own data from Unity services that you have agreed to integrate into your project, and readily available external data.
> Does the Unity Runtime phone home by default?
> It does not, unless you have hardware stats enabled.
----
I'm not a gamedev nor have ever used Unity to develop something, but those two sections seem conflicting. Can anyone kindly explain how they have their "own data from Unity services" while the runtime does not phone home by default? Thanks!
Unity has way more services than turning on hardware stats. If you use them they can make some estimate of unique users. Unity would now prefer you give them the information yourself.
> Unity would now prefer you give them the information yourself.
I’m sure they’d prefer to capture the data themselves, but they’re now allowing you to self report in order to placate the outrage from the recent announcements.
Thank you so much for clarifying that! It makes sense now. I just wonder if folks are required to use at least one of those services in order for Unity to have at least some kind of information regarding titles sold or something like that.
The link you are trying to access has been identified by Twitter or our partners as being potentially spammy or unsafe, in accordance with Twitter’s URL Policy. This link could fall into any of the categories below:
- malicious links that could steal personal information or harm electronic devices
- spammy links that mislead people or disrupt their experience
- violent or misleading content that could lead to real-world harm
- certain categories of content that, if posted directly on Twitter, are a violation of the Twitter Rules
Same! Can't wait to just get rid of it completely. Red Hat also hosted Container Plumbing Days this week and was pretty good! Looking forward to what they will do with Podman (specially on macOS)
To be honest I'm not sure which move was worse: They announcing they would be sunsetting, or they going back on the decision after the backlash. I feel like the trust was already lost after the initial decision; there's no going back after that.
