user43928

The more I think about it the more disappointed I am with this release.

For Anthropic's IPO, I expected a larger version of Opus 5.5 with great capabilities.

This isn't that. It's barely better at all, to the point where it's likely not even worth using with the speed and cost trade off.

I thought the Opus 5.5 improvements would scale to a larger model, clearly this hasn't happened. Scaling it up brought only marginal improvement.

It's even still making the same dumb errors as Opus 5.5, such as forgetting to pass the flag to run only the fast tests and waiting 1h, or randomly stopping to ask me if it should first implement A or B, when both are required.

Not a great story for their IPO..

I was eager to use it, but have seen no noticeable improvement over Opus 5.5, plus it's slower and drains usage approximately three times faster.

As a preliminary verdict after using 25% of the weekly limit: it's a miss.

I'm not sure "we couldn't top Opus 5.5" is the right message for the upcoming IPO. I was expecting a significant release.

I've had the same 'not looking materially different' experience with a 3D application that is not a game, that I asked Fable 5.2 to improve.

It looks like no breakthrough over Opus 5.5 and I'm somewhat disappointed.

During my use this evening, 25% of the Fable limit on the $200 plan was consumed. I'd estimate it at 3x faster consumption than Opus 5.5.

I hate that Anthropic thinks it should subvert the legal process and undermine our legal rights by arbitrating them at the tool level.

If they are already overreaching here, and needlessly, what if their AI was actually super intelligent? Where will Anthropic stop?

From the model card:

  Model                AECI   95% CI (global)
  Claude Opus 5.5    174.78   170.33-180.29
  Claude Mythos 5.2  177.12   172.42-182.94
  Internal model     178.78   173.75-185.18

Considering the IPO is planned in a week, I doubt they are holding much back.

I'm pretty convinced that those who have constantly been posting these complaints, probably for every single model release out there, are indeed wrong.

I've been working with Opus 5.5 every day, probably around 10h on average, and I feel confident in saying that they did not replace anything.

I'm a bit disappointed with how this nonsense is spread across HN today.

There's something wrong with the Fable 5.2 version, the Customizing button doesn't work for me in Chrome on Desktop.

In what sense did your test show no profitability?

I'm not sure if that is relevant here, but I've often seen people dramatically overestimate inference costs.

If we look at eg. https://inferencex.semianalysis.com/run/kimi-k31-pro-on-b300, it suggests that SOTA models are likely served in the API with profit margins in the ballpark of 98%.

I disagree. For my own enterprise job, Opus 5.5 with a $500/month API budget is the best option.

The cheaper open-weight ones, even if they were available with our enterprise contracts, would be a huge downgrade.

It is looking entirely plausible to me that Anthropic will make a profit in 2027.

Don't you think that it's less than reasonable to suggest that the technology will take on the order of 20 years to mature into widespread adoption and profitability?

Granted, maybe I extrapolated Anthropic's profitable operating result to other companies where it's not yet looking so good.

I believe your $14B OpenAI number is from 2025 though.

While it's an interesting question whether Anthropic and OpenAI can capture that value, I find the telecom comparisons not so apt.

In this comparison they are more like Apple and Google: they are ahead in research and are able to offer better technology than their competitors.

The six month gap between the open-weight models and the frontier has not closed yet.

No, they are not "losing gigantic amounts of money".

They are already profitable and are investing enormous amounts into datacenter buildout to meet demand over the next years.

People are denying it because it's simply not true and for sure has not happened consistently.

In my own work I have not once noticed a degradation where I could have said with any certainty that it's not within usual deviation or me having a bad day.

Conspicuously the model seems to be especially dumb and annoying when I did not get a lot of sleep the previous night.

When OpenAI and Anthropic engineers post here on HN that they do not quantize models and silently replace checkpoints in the API, I believe them.

I saw nothing that convinced me the people who are constantly making these complaints don't just mistake any suboptimal result for changes in the model.

First time I hear someone praise Qwen 3.8 Flash Next specifically.

Personally I was forced to use only GPT-5.6 Sol at work instead of Opus 5.5, and it was so much worse.

Benchmarks that control for benchmaxxing indicate all open-weight models behind 5.6 Sol and roughly at the level of GPT-5.5.

And that's for the latest large ones, much less local Qwen 3.8 Flash Next.

I would regret such a downgrade.

Voluntarily downgrading to Sonnet 4.5 level performance sure is one way of avoiding imagined degradation in Opus 5.5...

AI is taking just as long to mature as anything in the past, and it will take 20 years?

I don't think so.

The reality is that the adoption is incredibly fast and that revenues of the AI labs are like doubling by the quarter.

Further, there is the expectation that breakthroughs in applying AI to science, robotics, or medicine may unlock trillions in value.

That this will take 20 years, rather than happen before 2030, is just speculation. None of us can see the future.

It depends on how you define brittle.

Functional code that is perhaps overly defensive or specific in ways that will require updating it in the future? All the time.

What many do not yet understand is that the maintenance burden is a fraction of the effort that it takes you to review the code, much less iterate on it.

I see people on here talk about a supposed eventual collapse of maintainability if they do not review or understand the code.

In reality this never happens. The latest models can salvage and refactor even the biggest mess; all you need to do is ask.

They could probably do it even if source code isn't available and you only have a binary to work with.

I've been running Codex for many weeks in the Full access mode, since their Auto mode was useless in the sense that it blocks benign commands frequently.

No data loss has occurred.

Nowadays I use Claude, where the Auto mode works.

It's not stupid if it works and the supposed insane risk never manifests.

More than 10 million developers use Claude just fine without VMs or proxies.

The approach is hardly insane, even if you personally prefer additional safeguards.

I think 2024's method of manually reviewing bash commands is unsuitable for modern agentic development. Whether that's something they want to optimize Claude Code for is their call.

That said, I've also seen problems from complicated bash calls with Opus 5.5 on xhigh. Occasionally git push hangs and it believes it's waiting for an hour for git hooks.

The actual reason apparently was that it incorrectly piped git into grep, resulting in a deadlocked command.

I switched to the GUIs half a year ago and never looked back.

From the text rendering and scrolling alone, they are much more pleasant to work with.

Conversations with activity and MR status indicators, nested sessions, images in the chat, and generally more information and functionality on the screen.

One negative is that it gives Claude, and particularly Codex, room to mess up with auto-opening artifacts.

Codex, when I was still using it, kept opening report or comparison pages in fullscreen when I did not ask for artifacts.

Claude loves to open its iOS simulator pane, but somehow never displays the one it's actually using, instead showing a simulator that is idle. It might be related to my custom tooling.

I wouldn't say so, since shooting at mini tanks and buildings that look like cardboard on a gray street map doesn't seem connected to real events.

That said, I did not find the game fun. It was laggy, UI elements seemed a bit sloppy and cut off, and the purpose of buttons wasn't very clear. Also, I saw mostly brown tiles rather than buildings, maybe it was already all destroyed.

As someone who doesn't work in ML, I can only guess what drives the recent improvements.

This kind of post-training and improvements to the training pipeline is exactly what my guess would be.

Curated tasks where the efficient approach is incentivized over getting bogged down in details. This behavior should then generalize.

It seems like a much more likely explanation than the fantasies about illegally training on user data that I often read on HN.

Sure. No, I was also running 2-5 agents typically at that time.

When working on trickier things that require me to test on device and report results, this would drop to only a single session. I can't context switch between multiple threads while focusing on an investigation where I need to steer the agent.

Yes, I'm using the $200 plan for Claude, and only $20 for Codex, where I use 6.1 Sol to review every change implemented by Opus 5.5.

In the past I paid for both $200 subscriptions, but with Claude's current usage limits, that is no longer needed.

In the last two weeks, 51 MRs, +50k -7k LOC.

I find it hard to talk about any major feature without doxxing myself, since I'm particularly proud of the features that differentiate my app from competitors.

Trying to keep it generic, 3 MRs were for optimizing the app for the iPhone Duo. My app ships 7 AI models that run on-device.

Back then with GPT-5.5, I wouldn't say that the problem was decreasing velocity because of complexity adding up.

It was more like that the open problems were difficult. Matching animations to the gesture, manually handling scroll position in a browser during rotation. When you're already 10+ rounds into instrumenting and layering fixes on top of each other, it can get frustrating.

However, things worked out eventually. I suspect with today's Opus 5.5, many of these debugging rounds wouldn't have been necessary, since it can work for 2h+ on its own with the simulator, which GPT-5.5 at the time did not.

Yes, it's an interesting topic, and at work I've often felt accomplishment from simple, efficient solutions.

Even today Opus 5.5 suggested a plan that I'd call ridiculous. Instead of using a simple package manager feature, it proposed manually handling the issue and ensuring consistency via a new check in the CI. It was idiotic, really.

At the end of the day, it probably wouldn't have made a difference if I went with it, since the proposed ridiculous solution would also have worked. If my CI would ever be bogged down by 50 jobs, I could always start a conversation and probably resolve it in half a day.

And that's with today's Opus 5.5, while the capabilities are now improving every other month.

This ended up a pretty long comment, but I guess what I want to say is that in my experience AI is working well also in large projects, and that many of the fears around maintenance and technical debt have not manifested for me in practice.

Looks good overall, but I was wondering if eg. "the timer learns nothing" and "no X, no Y, no Z" was slop rather than a deliberate choice.

I had similar concerns when I was working with GPT-5.5 earlier this year. At the time my project was perhaps ~150k LOC.

After struggling with some more complex features even after many iterations, I started to doubt, and questioned whether I'm writing myself into a dead-end.

I did not. I still made progress and things worked out just fine. Then Fable and later GPT-5.6 Sol came out, boosting productivity and complexity of features I could implement successfully.

The effort only ever went down, and my app was released in the AppStore last week, at about ~500k LOC.

I understand why people might believe that using AI and not manually cleaning up suboptimal or overly defensive implementation would eventually result in an unmaintainable mess.

Based on my personal experience and 500+ hours put into my project, I can confidently say that this is not the case. Increased effort to maintain is negligible.