Anthropic’s weak spots: what its own reports reveal

Quality regressions are not always detected promptly

In its September 17, 2025 report, Anthropic described three infrastructure bugs that degraded Claude’s responses. Complaints arrived in early August but initially looked like normal variation in feedback. An investigation began by late August. The company acknowledged that detection and resolution took too long and reported the fixes. [10]

This creates an awkward situation for users: the service responds, but familiar tasks get worse. They may rewrite instructions or inspect their own data when the cause lies with the provider. The issue is how quickly the company can distinguish genuine degradation from an isolated bad answer.

In 2026, the problem appeared at a different layer

On April 23, 2026, Anthropic explained three further changes: lower default reasoning effort, a reasoning-history clearing bug and a brevity instruction that hurt coding quality. Claude Code, the Agent SDK and Cowork were affected. Initial internal tests did not reproduce the problems. All were fixed by April 20; the model API was unaffected in this episode. [3]

These were separate incidents, not one continuous failure. Together, the reports expose gaps between internal quality checks and real use. My conclusion: release validation and early regression detection deserve closer scrutiny.

The model supplier can change conditions for your product

On June 3, 2025, Windsurf said Anthropic had cut nearly all its direct Claude 3.x capacity with less than a week’s notice. Windsurf said alternative capacity could not cover existing demand. Its July 16 update announced restored direct Sonnet 4 access for paying users. This is the affected party’s account; it does not establish Anthropic’s motive. [4]

The case illustrates supplier dependency: a product remains operational, but a capability promised to customers is disrupted by an external decision. It supports having a tested migration plan, not predicting that every customer will lose access.

A public safety goal is not the same as a commitment

Anthropic’s 2023 policy described conditional commitments: additional capabilities required additional safeguards, with a training pause contemplated if those safeguards were unavailable. In February 2026, the company revised its approach. The new Frontier Safety Roadmap targets were described as public goals rather than firm commitments. [7, 8]

That distinction matters. A progress report provides visibility, but does not by itself mean an unmet goal will prevent a release. It would also be wrong to say Anthropic abolished safety: its policy continues to evolve, with risk reports and external-review procedures. Versions through 3.4 followed February’s revision. [11]

Dario Amodei’s September call to slow capability growth also included a commitment to give external evaluators access to internal work. [9] My criticism concerns verifiability: which conditions are mandatory, who checks compliance, and what happens when they are not met?

Which tasks still require a computer

Starting a cloud task from a phone is already possible. Cowork supports mobile and web operation, including scheduled tasks with no device online. Developers also have Managed Agents. [1, 2]

Specific actions still depend on an open Claude Desktop app: browser control, local files, local connectors and screen interaction. A task requiring clicks in a web dashboard through Cowork’s browser therefore cannot rely on the phone alone. [2]

For someone who wants to delegate work entirely from a smartphone, this is a meaningful boundary. Before choosing Cowork, test the complete workflow: are cloud connectors sufficient, or will one step require your computer?

Run cost alone does not establish savings

Anthropic’s June 2025 research offers a useful reference: agent tasks used roughly four times as many tokens as chats; multi-agent systems roughly fifteen times as many. Suitable tasks also showed quality improvements. These ratios describe that system, not every agent or price plan. [5]

They do not establish that Anthropic is less economical than competitors. That would require equivalent tasks and a comparison of accepted-result costs. Managed Agents has session budgets. [6] Businesses still need to count retries and human review: a cheap run with unusable output is not good value.

Four statements in their original wording

Below are authentic excerpts from the pages discussed here. Labels and layout are editorial additions. The surrounding sections explain the context, fixes and subsequent changes. Original links are sources 3, 4, 8 and 9.

What to check before depending on an agent

These cases provide concrete selection criteria. Suppose an agent prepares a daily summary of customer requests. Before relying on it, I would run these checks.

• Quality after updates. Keep five anonymized customer-request samples and mark which facts each summary must include. Repeat the check after model or configuration changes.
• Phone-only operation. Test with the computer off. Verify the entire workflow: fetching requests, processing them and saving output, particularly if browser interaction is involved.
• Recovery. Interrupt a harmless test. Resuming must not lose processed requests or send a reply twice.
• Cost. Across ten runs, record total spending and correction time. Divide costs by the number of summaries actually accepted for use.
• Fallback. Give the same samples to another provider. Test quality and migration changes while the primary service is still available.

Where criticism of Anthropic is justified

The strongest criticism concerns product predictability. Anthropic documented cases where changes degraded responses and detection lagged behind user experience. Windsurf’s history adds access-dependency risk. Safety policy requires distinguishing goals, commitments and verification mechanisms.

The company’s public reports make these weaknesses visible, which is valuable. My next measure of maturity is whether such episodes become less frequent and customers spend less time diagnosing why yesterday’s working process produces a different result today.

My perspective: why we are building Teamly

I also approach these questions through our own project. We are building Teamly: a cloud multi-agent system where you can assemble AI specialists and work with them through a shared chat. A coordinator helps distribute tasks among agents with different roles.

The team appears as pixel characters in a virtual office. The screenshot below shows a content team: Kai handles short-form video, Felix content planning, Blitz trends, and Pia social-media materials. The recording shows agents being selected from a catalog and appearing in the office.

My position is that directing the work should become simpler. You set a goal, see who is responsible, refine the task and evaluate the output. We put execution in the cloud so your personal computer does not become the center of the system. This is the experience we are building in Teamly. I hold our product to the same standards: visible progress, spending control and verifiable results.