I’ve been a Claude user, switched to Codex expecting usage limits to be more loose but I can’t even get through a basic sysadmin task on the $20 plan using Sol medium before I hit the 5hr one.
I think I’m gonna move back to a Claude plan. I could barely hit the $200 limit if I went non-stop on programming tasks.
I think OpenAI essentially executed a bait-and-switch here, and they've lost a lot of goodwill with me, like Anthropic did, before them.
When they started the aggressive campaign, entire X (including myself, sadly) was full of posts about how "unlimited" codex usage is even on a $20 plan. Sam Altman was posting something in line of "we love our users, unlike Anthropic". Got my network to get codex subs because of the value compared to claude.
Then they gradually reduced the limits to the point where even $200 plan only lasts you just 1-2 days and $20 is basically unusable, then the hostage thing.
I do the bulk of work on Sol Medium/Low and don't have that experience on the $20 plan. If you said Astra I'd agree it's easy to burn through the 5 hours even on the lower reasoning levels.
I don’t think so, I’ve seen it suggest I try it. I’ll double check when I get home though.
I was considering the $100 plan, but I hit the 5hr limit in an hour. So even with the $100 plan I figured I cant go non-stop on a single agent running Sol Medium
Sorry if I am misunderstanding you, but I am pretty sure the $100 plan doesn’t have a 5hr usage limit. So, if that was what was preventing you from going non-stop, it might be worth it.
I am considering the plan myself. I just don’t know if I want to fork out $100 per month for something I will make $0 off of.
similar here: I tried Codex $20/mo on a trial and I ran out of 5hr usage mid way through a medium complexity task on a medium size model twice and gave up there. I don’t recall the equiv Claude plan being anything like that. Anecdata, but not great for OAI if they actually want to retain people on a trial.
Astra is barely usable even on the $100 plan. And that is if it doesn't just burn through 80% of your weekly quota in a couple of hours by continually expanding the scope of the task you gave it - while not noticing the failing tests that are right in front of it.
Opus is at least actually usable even on the small plan. The main downside is its insane writing style, but 5.5 seems to address that somewhat. Otherwise, you can just use your $20 OpenAI plan to have Luna de-slop Opus' prose, which seems to work fine.
I have a Claude Code hook that calls codex for a code review on commit time (Codex is set to Astra Medium) and it's been pretty good in general. It sometimes hits the 5hr limit but most of the time it provides really good feedback and because it's a completely different model it's mostly complementary to what Fable/Opus do themselves. IMHO it's been $20 well spent.
...but the few times I've tried to use codex for a moderately difficult task it burned through its limit extremely quickly.
On the $20 plan, you can't use Sol for much more than planning and review. Luna xhigh for the rest. Have Sol write the plan specifically for Luna so it adds more direction and validation to the plan.
I've run into hitting limits on the personal plan perhaps twice since the beginning of the year. But also I don't use the personal plan for coding tasks between 7am-noon M-F.
> Just tell the agent to use conventional commit messages and to keep it nice and tight.
I have this in my claude.md along with guidance on (not) writing comments but it’s still dumps multi-paragraph comments of Claude speak everywhere.
I think a lot of us are talking past eachother, but what I and I think others are complaining about is doing things well, and being minimal. LLMs don’t really do that yet, they can’t look at and simplify a codebase well, even with guidance. They always seem to add rather than subtract. And eventually it becomes an issue. I think they were actually better in this regard with like Opus 4.8, and are now getting even worse (but score better, and are more autonomous).
At home I use Codex, and it’s better as far as language goes at least.
Anyway, it’s like the logic piece necessary to do good work is still missing, and hurt by recent reinforcement fine-tuning. And it leads to massive bloat since more comments = higher scores, but walls of text and the tokens (or cognition if you’re the sad human reading them) aren’t free.
Yeah, I listen/watch some flight radar youtube and it’s insane how many issues arise from the language barrier, which could be solved by just communicating via a text channel
CPDLC exists and is used. It has its limitations though - it doesn’t provide as much flexibility for pilot replies, pilots don’t always have a free hand to text with (especially in turbulence), and is generally slower and more clumsy than voice so is only suitable for routine, non-time-sensitive messages.
That sounds like a system that was bound to fail, because it was kept limited to a certain range of capabilities.
One can easily imagine a system that broadcasts the weather and clearance, and even aircraft location data close to real-time, and provide great situational awareness to everyone involved.
I don't think it's acceptable to put tens of thousands of people within a crowded airspace and not do everything in our power to keep things organized and secure.
> That sounds like a system that was bound to fail, because it was kept limited to a certain range of capabilities.
You're always going to be limited to a limited range of capabilities. You can't run a full web browser in every cockpit - you need a standardized interface that works across different vendors, across borders, and over a low-bandwidth radio link.
And I don't think anybody considers CPDLC a failure. The goal was never to 100% replace voice communication.
> One can easily imagine a system that broadcasts the weather
That exists, it's called FIS-B. Everyone uses it.
> and clearance
Clearance isn't something that can just be broadcast. You need to have a conversation with the pilot to make sure the clearance is acceptable to them. The pilot needs the ability to reject the clearance and request amendments.
> even aircraft location data close to real-time, and provide great situational awareness to everyone involved.
Doing anything right on web is 10x harder and more complex. The problem is the browser, once you use it to deliver anything you have to buy into all of it’s bullshit. CORS, XSS, headers, caching. All that just goes away (outside your backend API, if you even need one) when you ship a native app
Maybe Dario shouldn’t have tried for regulatory capture. He was constantly on the news talking about how these models are so dangerous and that we need regulation to keep China from releasing open-source models without guardrails.
> You can't do that on larger models unless you have the hardware like this person does.
Or just rent something substantial for like $4/hr on runpod or w/e to do that.
My gripe is this persons compute is wasteful and makes it harder for me to buy something with like 64gb ram to do normal work and run containers while I keep using cloud models.
Someone else calculated the break even being 10 years, it’s just dumb. And I think it’s clear there won’t be a big rug pull anymore, there are too many open models and providers now.
I keep seeing these language specific proclamations, and they are annoying and reek of inexperience to me.
I’ve had a great time doing LLM assisted coding in Zig, and it seems comparable to the generic Typescript/React I do at work.
I don’t doubt simplicity and good PL design pay dividends, but everyone’s favorite language can’t be the silver bullet in our new LLM world. Things just don’t add up, and I keep seeing it for Erlang, Gleam, Lisp, C, Rust, Go, TypeScript, Python, etc.
And to pick on Go a little bit, I don’t think it has any unique qualities that make it better for LLMs, where I think you could make that argument for other modern languages that offer new features leveraging their compilers and enforcing more correctness guarantees.
It would be neat to see a matrix of compile times vs. language features, showing things like:
- Bounds checks
- UAF prevention
- exhaustive enums
- test speed
But I think even among those the subtleties would make a fair comparison impossible.
Anyway I think this is all very nuanced, and anyone proclaiming language X is the language to use in 2026 lacks the experience/knowledge to consider these trade-offs and can safely be ignored.
LLMs are surprisingly good with Lisp dialects. With a caveat - when you give them actual (homoiconic) REPL. It makes little sense treating a Lisp just like any other language, which is roughly the Unix/pipe model - batch-style. Agent spawns process -> reads stdout/stderr -> spawns next process. State lives in-between the calls and in files. Each tool invocation is stateless.
Things get far more interesting when you give an LLM a true Lisp REPL. LLM stops guessing and starts empirically analyzing current state of things and produces working solution faster, costing far less tokens.
Like if you ask any experienced dev to write a Clojure program giving them nothing but a notepad.exe, they'd immediately fail without structural editing and connected REPL. Why people expect that LLM somehow, magically do it better?
> leveraging their compilers and enforcing more correctness guarantees.
The counter argument here is that these checks cause slower compile times and were designed to prevent common mistakes humans make.
If models get good, they may not need the same checks human written code needs. For example, frontier models already will virtually never produce a typo.
Humans need time to think, but a model’s bottleneck is in how quickly it can verify its work. Slower compile times hurt a models ability to iterate.
I don’t think we’re there yet (and we may not get there). But there is an argument to be made that languages with faster compile times may be better for LLMs in the long run than languages with strong checks but slow compilation.
This is a rather poorly-written post that more or less boils down to "GHC isn't fast enough to let us make deep-reaching changes to our codebase all the time" (fair, but this shouldn't be necessary if your abstractions are solid? seems to telegraph very substandard engineering practices, but I guess that's what you get with vibecoding) and vague complaining about how the Haskell community isn't all-in on AI.
I was curious about this so I dug further, and by the author's own admission, they've only made the switch for basic CRUD logic without performance needs, not their core services: https://news.ycombinator.com/item?id=48865986.
It's also pretty unsurprising, given what we know about LLMs' style transfer abilities, that transferring parts of an existing Haskell codebase into Python would avoid a lot of the errors and pitfalls that codebases originating in Python are known for. From my experience writing lots of Python, this does not continue to hold true as you let the agents loose on your Python codebase.
I think this opinion is heavily shared by Swift developers now, but the messaging every WWDC is always "Swift and SwiftUI is the best way to build apps for Apple Platforms", etc.. If you have to keep telling everyone what they don't believe is true, it's a sign there's a problem.
It feels like someone with a lot of organizational power is disconnected from the pulse of the community. SwiftUI is undeniably clean in a lot of ways, it presents beautifully and fits on slides well, but that matters less and less, and this all wasn't really working out even before LLMs disrupted things.
But they do quietly drop or fix them, covertly acknowledging they were mistakes. Often with this messaging: "we have this new shiny thing that is even better than the old shiny thing (that was really a turd)".
Remember "garbage collection"? Or "modern syntax"? Or CocoaJava?
And with hardware they had their "come to Jesus" moment a while ago. And then hit it out of the ballpark with Apple Silicon.
CocoaJava was when they were not certain devs educated in C++ and Object Pascal would ever accept Objective-C.
Garbage collection is still there, regardless of the marketing message without fundamentals from CS theory of automatic memory management algorithms, because they need to blame something else other than themselves, Apple does no wrong.
> They actually went all in on CocoaJava. I was there for the WWDC.
Of course they did, until they saw the Objective-C adoption numbers were high enough.
> "Garbage collection is deprecated in OS X 10.8. Use ARC instead—see Transitioning to ARC Release Notes."
ARC is garbage collection, of course mighty Apple won't acknowledge that, because it doesn't suit their marketing, and they are to sell ARC after the Objective-C 2.0 conservative GC failure, given the underlying C semantics.
So they need to sell ARC as the great saviour, so much better than "GC".
> until they saw the Objective-C adoption numbers were high enough.
Nope. Until they saw that (a) CocoaJava was a complete dud, not just technically, but also in terms of developers buy in and (b) Cocoa/ObjC was accepted well by a large part of the dev community.
> > "Garbage collection is deprecated in OS X 10.8. Use ARC
> ARC is garbage collection,
In terms of the Apple ecosystem, "Garbage Collection" refers to the failed attempt to introduce a tracing garbage collector. Apple/OSX always had reference counting (introduced by NeXT pre-acquisition with Foundation in EOF and later in OPENSTEP 4.0), which technically is also a form of garbage collection, but again in this case the terms are distinct.
> So they need to sell ARC as the great saviour, so much better than "GC".
Again, in the Apple ecosystem, "Garbage Collection" always referred to the tracing collector, even before they had to abandon it due to it not working.
And ARC is markedly better than their GC, but only arguable and at best marginally better than the reference counting they had pre-GC, and in some significant sense worse. Which is why I generally don't use ARC. For my style of programming the benefits are minuscule and the drawbacks real.
No. Just that within the Apple ecosystem, the terms were used in a specific way.
Apple GC is a form of GC. There is no redefinition going on. It is correct.
However, it is ridiculous to say "we will replace garbage collection with garbage collection" and it is too cumbersome to say "we will replace reference counting garbage collection with tracing garbage collection".
Both "garbage collection" for the tracing garbage collection mechanism and "reference counting" for the reference-counting garbage collection mechanism are correct uses of terminology.
Using these shorthands instead of either the cumbersome complete terms or the confusing other shorthand is perfectly fine.
Although admittedly some Apple zealots started insisting that the Apple shorthands were the correct terminology. Or that programs that were broken by the broken GC had always been broken. Or that what Apple calls "MVC" is actually the correct definition of MVC when it is not.
If you want to see this behaviour dialed to 11, check how Microsoft management talks about WinUI 3.0, and the harsh reality of its sore state of development experience.
It would be great if it was half as bad as SwiftUI.
And I don’t think any pacing is/was intentional. They’de release skynet if they could and the stonks went up
reply