Unfortunately, I'm finding that in long-form agentic use, when I'm trying to use Sol, I keep tripping guardrails – moreso than even Fable, somehow.
I don't know exactly what part of my codebase is triggering it, so I'm going to have to keep poking, but apparently the guardrails are not that gentle despite the phrasing. :(
Anthropic just changed their web interface yesterday to have Chat versus Cowork as well, and every time I look at it, I'm so confused. I'm still so unclear when I'm supposed to use one or the other or the other.
Now the 'ChatGPT desktop app' (the Codex app, renamed) also has the split between work and code, and as far as I can tell, all it does is change which plugins are loaded by default to include Office ones when you put it in work mode. Perhaps it also changes the system prompt slightly?
I feel like a core difference is that the AI implementor can get cheaper/faster (and indeed _uniformly_ better), whereas it would be very difficult for the same humans to do so.
Even if this is not the right answer today, it can at the very least serve as a herald of a possible future, no?
I believe you're right and I'm familiar with the actual distinction – the confusion is mostly about how they _feel_ about it, and what'll change from here.
> GPT-5.5 Pro does not offer a cached input discount.
I think this tells you in one line. It's basically set up for one-shot inference right now, by the looks of things. If you use this in a harness, it would almost immediately fall apart on cost. Not to say that they couldn't make it work, just saying that at least as it's delivered currently, they haven't done so. On the web, there might be doing something to get the equivalent of that behavior internally, such as keeping the session truly alive on GPUs rather than using their external-facing cache-style approach.
I definitely use GPT-5.5 as a counterpart to validate these exact sorts of things in Anthropic models' implementations, in the (now-rarer) cases where I allow Anthropic's models _to_ implement.
And yeah, it's a bit depressing to think that 5.6 might be similarly nerfed. Less secure software for us all, I guess... except BigCorps. :(
Frankly, it feels like we should just sidestep arguments entirely and just all contribute our messy data/reports, and then see how we can meld all of it together, to find the best answers for our individual situations.
Probably a good use of frontier AI, melding all of that!
It's all closed code, so I don't have a great way of showing you, but this is all pretty easy to test for yourself, and a good chunk of it is fairly objective:
On performance: just grab CC + Codex and try Opus 4.8 xhigh and GPT 5.5 xhigh side by side. Ask them a trivial question about something that's already in their context. Opus will churn for 30 seconds, and GPT 5.5 will respond in about three seconds. If you try the same with Fable 5 you'll notice way better adaptive thinking than Opus (it'll quicker than Opus, even on xhigh – although often still slower than 5.5).
I have many, many times done 'Opus xhigh, Opus max and GPT xhigh all tried to implement something' – Opus max is... hours and hours. Opus xhigh is usually ~1.5-2x GPT 5.5 xhigh. This feels like a pretty straightforward generalization of the first point. Again, just try racing three agents and see what you get.
As far as 'right on the edge of what they're able to do', my specific tasks don't matter. Just find something that no matter how hard you try, with however many agents or combinations thereof, with arbitrarily detailed plans, agents can't seem to implement without massively mistakes or a hollowing-out of 'the point' of the implementation... and then try it on the 'following generation' of models. I've been doing this repeatedly with coding agents since I turned aider into a CC-like coding agent in early 2025 (this was my second one, my first modern-style coding agent was in Jan 2025): https://github.com/Aider-AI/aider/pull/3781
A couple of examples of the latter thing that I tend to work on are database internals (indexes, query planner stuff, etc.; I built the DB in full before agents, it just works on it with me), very advanced UIs (try making a beautiful Rolex-like interactive visualization of the internals of a mechanical watch with Opus and see how far it gets – not very), and 'hardcore product questions' (all agents kinda suck at schema – Fable far less than prior ones).
I have dozens and dozens of these that they can't do, though.
> I think for programming the strength of GPT over Opus is winning here over the context window.
On this, absolutely!
I more often use Opus for planning than for implementation. In those cases I really do need the very large context window, because the agent has to read in a bunch of my code base and a bunch of previous plan files and product context and such, to understand what we're talking about.
And then I need to go back and forth with it over a really extended period: getting into a bunch of details, asking it to load how things already work so that we can discuss options for evolution of those, etc.
For that kind of thing, compaction completely destroys its effectiveness because even if you try to serialize out all the decisions made in the conversation into a plan file, the agent still loses e.g. the plan files and code files that it's read in that are adding sharp edges to its understanding of the scope of what's being planned.
For implementation or something like what you're describing in the vein of benchmarking, often I can get away with compaction. Although even then, if the agent needs to have a lot "loaded" into its head, to implement something very, very subtle, complex or far-reaching, in those cases it can be really detrimental if it compacts.
I'm pretty baffled by their choice of axes. I would have thought that the left was the cheapest, not the most expensive. I appreciate that this layout means that top right can be best, but it's still unintuitive to have this backwards cost axis IMO.
Putting that aside, I spend all day every day implementing very, very hard things right on the edge of what agents are (barely, sometimes) capable of, and I have had to keep Opus on max for things that need 'real validation' for a while now. And that has felt like 'the only way' to get Opus to perform even close to 5.5 xhigh. I'm only using Opus at all because GPT-5.5 in the subscriptions only has a small (400k, but 258k effective) context window.
The difference is that 5.5 xhigh is extremely fast in most practical cases, both efficiently implementing _overall_, and responding very quickly with great adaptive thinking if you ask it something that it doesn't have to think about. Opus 4.8 Max will needlessly chew on everything and can take hours to implement even simple things, so I can mostly only use it for planning/review.
Fable is much much better at adaptive thinking / responding quickly (although probably still worse than 5.5 xhigh), and... I think folks have said enough elsewhere about its strengths and weaknesses. Sadly still not a reliable implementor for my hard tasks though (that's still GPT's domain) – it tends to leave big, dangerous holes hiding inside implementations unless babied.
This seems absolutely lovely. In my codebase, going back a long way, I built a simple project/company-specific Rust crate called `devops`, which I use to manage all IaC infrastructure building and everything else. And it's been by far and away the best way to manage everything.
I would love to see more frameworks for things like this that are just libraries or similar, so that you can just use normal programs for these sorts of tasks.
I don't really disagree with you, but one thing I will give Fable credit for is that it's much better at adaptive thinking. In general, it's much better at quickly thinking and responding. It generally has—for me at least—none of the slowness properties of Opus, even when on extra high.
It makes for a particularly awkward time because the claim to fame is that it's good at long horizon and tenacity and autonomously driving big things. But you can't very well rely on that when it may fall back to Opus 4.8 or cut out at any time in that process.
Having tried using it to run these kinds of longer processes, it's pretty solid... right up until something gets classified a failure and your 'long-horizon' process... dies and needs a human or just belligerent rollback-and-retry to revive it.
It's interesting that they will only have it on the surface through July 7, especially since GPT-5.6 will presumably come out soon as well.
Of course, it's possible that Fable remains drastically better than 5.6, but to whatever extent Fable is the true frontier (if temporarily)... it makes me wonder if external commitments on compute put a hard deadline on how long they could run Fable on the subscriptions.
Building pervasive.app
hn @ <username> . com
On GitHub, Twitter, etc. as tekacs.
If you've replied to me and I've not got back to you... I'm probably busy. I'm trying to change that.
ac5ecc4e73f4852ebd856bd3959cc2b611802b6330356a61088dabc826d60c86
meet.hn/city/us-New York