June 2026
I know that the following is very unscientific and just "vibes," but in my personal experience, Anthropic's models have severely degraded since shortly before Opus 4.7 was released about six weeks ago. And my initial impression from the week or so I've spent with 4.8 is that it isn't any better.
Three months ago, Opus 4.6 was great and highly reliable. However, the performance of the recent 4.7 and 4.8 models is much less reliable for me. They often think for a long time before suddenly speeding up and answering suspiciously quickly. I now also frequently see the model correct itself in the final answer, as if it hadn't already settled on its answer during the reasoning tokens. And the models seem to lose context even in short conversations of no more than a few thousand tokens. For a while, I switched to the Opus 4.6 1M context window model instead of 4.7, but I feel that 4.6 has also degraded in recent weeks, as surprising as that may sound.
I'm reminded of the time around March/April, when Anthropic admitted that a few changes to the Claude Code harness had degraded its performance. According to their postmortem, the bugs were in the harness, not the model weights or the API. But this time, I don't think it's only the Claude Code harness, because I'm seeing the same problems in the Claude desktop app. Yesterday I asked Opus 4.8 to write some SQL queries for an investigation, a task I've done almost daily for well over a year. I usually provide the table schemas and indices, and the models normally write long, complex queries based on my instructions without trouble. This time, it just wouldn't understand what I needed, and I had to be far more explicit than ever before, even though it was a relatively simple task.
I wonder whether it's quantization or context compaction because of Anthropic's compute crunch, or whether the models have been overtrained on benchmarks with very clear task descriptions. But I need models to read between the lines and remember the context of a conversation. Otherwise, I might as well write the SQL query, code, or text myself if I have to be very explicit. I haven't tried any serious workloads on local models yet, and I'm sure I'd be even more frustrated than with the latest Opus models.
The crazy thing is that I don't want the models to be bad. I'd much rather write about the cool things I'm building with them than about how they've regressed. I genuinely want Anthropic models to be good, and the most frustrating part is knowing they were great just a few months ago, but having no way to access them now.
Anthropic announced two weeks ago that its run-rate revenue crossed $47 billion. With most of the coverage focusing on numbers like these, it’s easy to forget the companies that are sitting on the other side of this bill, actually spending all this money on tokens.
To put the number in perspective, Anthropic’s current run-rate revenue alone is roughly half the size of the entire global CRM market. Together with others like OpenAI and the AI revenue flowing through Amazon Web Services (AWS), Google Cloud, and Microsoft Azure, the total token spend is approaching the size of software categories like CRM and ERP systems that took decades to mature.
Almost every company agrees it needs some form of CRM or ERP system, and no one has to justify the existence of that line item. For AI, however, the case is much less settled, and CFOs are now demanding to see ROI on token spend, which can be genuinely hard to measure or attribute with general-purpose tools like Claude or ChatGPT.
On top of that, current changes to pricing models make budgeting and buying decisions even harder for enterprises. In a Stratechery interview last week, Satya Nadella described the future of software pricing as hybrid, combining a per-user model with a consumption model, because “there is real marginal cost to software” now, and that cost will be priced through. But enterprises are used to per-seat licenses and like them precisely because they are predictable. Ironically, many vendors are now moving toward usage-based pricing to control their own costs, just as buyers are asking for predictability.
Therefore, I doubt that frontier-lab revenue will continue to grow as steeply as it has over the past few months, and we might reach a temporary plateau due to uncertainty. I am convinced that this presents an opportunity for startups offering purpose-built AI systems focused on solving specific business problems, with a much more predictable pricing model and cost structure.
[…] if reading this wasn’t worth your time, why is it worth mine?
Therefore, I’ve adopted this principle in my work:
If you are requesting human attention, demonstrate human effort.
— Tom Bedor, On the practice of sending unsolicited AI slop to colleagues.
I have used MCP servers every now and then in the past, but they have never saved me much time. Last week, however, I got real value out of them for the first time, and I want to share what I learned.
Using an MCP integration as a “glorified form-filling tool” for a service that already offers a purpose-built UI can be useful, but in my experience, it doesn’t meaningfully increase productivity. Instead, the key insight was to use not one but two MCP servers, from entirely different systems that were never designed to communicate, and to use the LLM to connect them.
In my case, I used the Mixpanel and Notion MCP connectors, together with Claude, to build new analytics dashboards in Mixpanel, based on the extensive documentation I had previously written in Notion about our analytics and new onboarding flow. That documentation, together with the implementation tickets, gave Claude enough context to build exactly the dashboards I needed, from only a clear but high-level description of what I wanted. The resulting dashboards only required minimal manual adjustments from me.
I came to see that MCP integrations are not really about interacting with a server in natural language. They’re the piping that an LLM can use to connect or glue together deterministic systems that weren’t designed to talk to each other. And the more services you can wire together in a useful way, the more value they can provide.
For this reason, they are a great tool for prototyping and for producing any stateful output or asset that can be reviewed and refined before it is used or shared. However, I’m a lot less convinced they’ll be useful for building enterprise workflows that automate business processes and need to be robust. At least to date, MCP servers can easily have breaking changes, aren’t versioned, and so on. And the more MCP servers are involved, the more fragile any workflow becomes.
Lastly, my practical advice for the product engineers tasked with building an MCP server is not to think of it as a wrapper around your API, but to ask yourself how to build an interface for your service that is maximally useful when combined with any other existing service, to enable unique and custom use cases for the user.
So it must be that a key ingredient to blogging is simple: have a willingness to state something that seems obvious to you but nobody else is saying it.
Or if someone else is saying it, just link to them and say, “Yes!!! This!!!”
— Jim Nielsen, Jim Nielsen on the key ingredient of good blogging.