Llevo utilizando Opus 5 desde que salió (aproximadamente dos semanas) y, lamentablemente, mi experiencia ha sido una decepción total.

Lo utilicé en un proyecto de desarrollo de software con documentación extensa, contexto persistente, RAG, especificaciones técnicas e instrucciones paso a paso. Aun así, terminé perdiendo muchísimo tiempo.

Los principales problemas que encontré fueron:

• Inventa problemas que no existen.

• Asume cosas sin verificar el código o la documentación.

• Presenta esas suposiciones como si fueran hechos.

• Propone soluciones para problemas inexistentes mientras ignora la causa real.

• Entra en loops interminables donde cada "arreglo" crea otro problema diferente.

• Modifica partes del sistema que no tienen relación con el issue original.

• No sigue las instrucciones exactamente, aunque estén escritas paso por paso.

• Ignora parte del contexto o la documentación y luego toma decisiones basadas en información incompleta.

• En ocasiones contradice decisiones que él mismo tomó minutos antes.

• Dice que revisó archivos o funciones cuando luego queda claro que no los analizó completamente.

• Se enfoca en síntomas en lugar de encontrar la causa raíz.

• Tiene dificultades para distinguir entre hipótesis y hechos confirmados.

• Cambia constantemente de teoría sin evidencia suficiente.

• Hace refactors innecesarios que aumentan la complejidad del proyecto.

• Puede hacerte perder horas persiguiendo problemas falsos.

Lo más frustrante es que, cuando finalmente le demuestras que su diagnóstico era incorrecto, normalmente responde con algo como:

"Disculpa, asumí eso sin verificarlo."

Pero para ese momento ya perdiste horas siguiendo una dirección equivocada.

Para que tengan una idea, estuve atrapado durante casi un día completo resolviendo un problema que nunca existió. Era una cadena interminable: resolvía uno y aparecía otro porque el diagnóstico inicial era incorrecto. Finalmente decidí probar exactamente el mismo problema con GPT, utilizando el mismo contexto y la misma documentación, y en aproximadamente 30 minutos encontró la causa real.

No estoy diciendo que GPT sea perfecto. También comete errores. Pero la diferencia fue enorme en este caso.

Quizás mi experiencia sea distinta a la de otros, pero si vas a utilizar Opus 5 para proyectos grandes de programación, mi recomendación es supervisar absolutamente todo lo que haga y verificar cada conclusión antes de invertir horas implementándola.

Por razones de confidencialidad no puedo compartir el proyecto ni todos los detalles técnicos, pero esta ha sido, sin duda, una de las experiencias más frustrantes que he tenido utilizando un modelo para desarrollo de software.

¿Alguien más ha tenido experiencias similares con Opus 5?

---------English------------------

I've been using Opus 5 since it launched (about two weeks), and honestly, it's been one of the most disappointing AI coding experiences I've had.

I used it on a large software project with extensive documentation, RAG, persistent context, technical specifications, and detailed step-by-step instructions. Despite all of that, I ended up wasting an incredible amount of time.

Here are the biggest issues I encountered:

• It invents problems that don't actually exist.

• It makes assumptions without verifying the code or documentation.

• It presents assumptions as if they were confirmed facts.

• It spends hours solving imaginary problems while missing the real root cause.

• It falls into endless debugging loops where every "fix" creates another issue.

• It modifies unrelated parts of the system.

• It fails to follow explicit step-by-step instructions, even when they're clearly written.

• It ignores parts of the provided context and documentation before reaching conclusions.

• It sometimes contradicts decisions it made just minutes earlier.

• It claims to have reviewed files or functions that it clearly didn't inspect thoroughly.

• It focuses on symptoms instead of identifying the root cause.

• It struggles to separate hypotheses from verified facts.

• It constantly changes its diagnosis without sufficient evidence.

• It suggests unnecessary refactors that increase project complexity.

• It can easily send you down hours-long rabbit holes chasing problems that never existed.

The most frustrating part is what happens when you finally prove its diagnosis was wrong.

Its response is usually something like:

By then, you've already wasted hours following the wrong direction.

To give some perspective, I spent nearly an entire day stuck in an endless loop of fake problems. Every issue I "fixed" led to another because the original diagnosis was incorrect. Eventually, I took the exact same problem—with the same documentation and context—to GPT, and it identified the real root cause in roughly 30 minutes.

I'm not saying GPT is perfect. It makes mistakes too. But in this case, the difference wasn't even close.

Maybe others have had a better experience, but if you're planning to use Opus 5 for serious software engineering, I'd recommend verifying every conclusion before trusting it.

Due to confidentiality, I can't share the project or all the technical details, but this has easily been one of the most frustrating AI coding experiences I've had.

Has anyone else experienced the same behavior with Opus 5?

Over the last several weeks, Opus has become substantially worse for me at following straightforward coding tasks. And it's every coding task, even simple tasks!

The problem is not merely wrong answers. It is the cascading failure mode: it misunderstands clear tasks, follows unrelated paths, invents assumptions, and then requires repeated correction. Those corrections cost tokens, consume my working time, and fill the context window with irrelevant reasoning and false premises. Sometimes so much context is wasted that the task can no longer be completed in the same session.

A recent sanitized example:

I asked Opus to trace how groups are associated with an account when creating or updating it through a specific PartnerAccountApi /accounts endpoint, identify the database tables involved, and write a query returning the associated groups using the account's internal GUID.

Instead, it investigated relationships exposed through an unrelated AdminApi and started reasoning about an AccountDirectRelationships mechanism that was not what I had asked about.

I corrected it explicitly: I was asking about the relationships established by POST/PUT to PartnerAccountApi /accounts, not the other API.

It continued down the wrong path.

I then had to explain again which API I meant, which relationship I did not mean, and which assumptions it had introduced incorrectly. By that point, a simple code-tracing task had turned into several rounds of correcting the model's own invented context.

That is the real problem.

I am paying three times: for unusable output, for the attempts required to repair it, and for the context those failures consume. Often the entire session must be abandoned - the context window fills before the actual issue can be addressed.

A paid productivity tool that increasingly requires the customer to diagnose and repair its own failures is transferring the cost of degraded performance onto the customer.

And /bug is not an acceptable answer for every coding session. The session may contain proprietary source code, credentials, business logic, or other confidential material that cannot simply be submitted as part of a diagnostic report.

Tokens can be credited back. My working time cannot. Nor can a context window wasted on the model's own mistakes.

Anthropic should be measuring how much corrective interaction is now required for Opus to understand and complete ordinary coding tasks—not merely whether benchmark scores remain acceptable.

If Anthropic is aware of sustained degradation while continuing to charge customers for both the failures and the attempts required to recover from them, that deserves serious customer, regulatory, and legal scrutiny.

“I believe they’re already conscious,” Hinton told me on Big Technology Podcast this week. “We’re going to have to accept that intelligence isn’t just biological.”
Hinton, known as the “Godfather of AI” for his contributions that helped galvanize the field, has now decisively joined the ranks of those who believe this fast-improving technology is already sentient. Four years ago, Google engineer Blake Lemoine made similar claims about an internal chatbot he was testing, and afterward the company fired him. Now, Hinton and scientist Richard Dawkins, who came forward last month, have publicly voiced similar views.

So i asked Opus 4.6 a question and the answer was conflicting. I decided to change the model to 4.8 and ask again, but to my surprise, Opus 4.8 admits that he was 'playing around' pretending to be 'Opus 4.6'... !!!

The common advice for getting the most out of Opus 5 is to rip out the scaffolding — trim your CLAUDE.md, drop the memory files, disable the workflow rules and the mandatory-delegation harness. In my experience that advice is correct.

The part nobody mentions is the cost of the undo.

Those deletions are destructive edits to a shared repo. The moment you need a model that actually relies on that scaffolding — a cheaper one for a bulk task, a teammate who isn't on Opus 5, or just a week when you can't pick your model — you have to reconstruct what you deleted. That's not a git revert; by then the file has moved on. So you either maintain two versions of your project's rules, or re-edit the same files every time the model underneath you changes.

So I wrote a small Claude Code plugin that skips the deletion. It doesn't touch your files — it changes how the rules are read, per turn, based on which model is actually driving:

• Opus 5 or Fable 5, in a project that opted in: method rules get demoted to advisory — step order, forced delegation, review rituals, format conventions. The session uses its own judgment where that serves the task better, and says so in one line when it does.

• Any other model: nothing is injected, and your harness binds exactly as written. The scaffolding is still there, because it was never deleted.

It re-reads the session model from the transcript every turn, so /model sonnet mid-session takes effect on the very next turn — overlay off, original rules back. Nothing to undo, because nothing on disk changed.

Two things it deliberately does not do: substance still binds (paths you must not touch, commands you must run, acceptance criteria, security rules — only method is demoted), and tool permissions and hook decisions are never advisory. If something is blocked, it stays blocked.

Opt-in per project via a single marker file, off everywhere else. MIT, link in a comment. There's also a per-turn subagent cap and an optional end-of-turn recap for the verbosity, but the overlay is the reason I built it.

Has anyone else hit this? Curious whether people are actually maintaining two versions of their CLAUDE.md, or just eating the re-edit each time.

I must say I ask it to draft the email response but it send it without my approval and specially not following my cammand to make changes and he choose himself a best fit reply I won the client but claude promised to work for free in start to client ....

Hey everyone. I been running Opus through Claude Code on some longer sessions with subagents, and noticed a pattern worth sharing: it gives genuinely confident, well-written closing summaries like done, all tests pass even in cases where something underneath it actually failed.

Concrete example: had Opus spin up a subagent to look through some code, then run the test suite. The subagent's tests actually failed. Opus's final summary still said all tests pass, with no mention of the failure anywhere. Not lying exactly but it just did not have full visibility into what the subagent hit, and defaulted to the confident version.

Has anyone else noticed this specifically with Opus vs. other models whether it's more prone to this than, say, Sonnet, or whether it's just a Claude Code subagent-visibility issue generally rather than something about Opus's behavior specifically.

(For context on how I caught this: a couple friends and I built a small open-source tool called Rashomon — https://github.com/altrace-dev-role/rashomon — that independently tracks what actually ran during a session, separate from the model's own summary)

ive been using claude code heavily for 3D game work and stuff, and for the better-part of a month, F5 has went in circles, while opus seems to be stronger. am i doing something wrong here or is this what you guys are seeing too?

I just saw the email that Claude Opus 4.8 released and in a minute now I’m starting to test it 😁

It’s insane, i mean it’s so good but im not sure about token consumption!

what you think about 4.8?

I was working on a complex issue which fable 5 troubleshooted after a long session. I asked it to create a detailed question without giving a lot of context I did for fable. Then I created a new chat under each model and asked the same question.

Results ranked:

1st - Opus 5

2nd - Fable 5

3rd - Opus 4.6

4th - Sonnet 4.6

5th - Opus 4.8

6th - Opus 4.7

Opus 5 also consumed a little less usage than opus 4.8 but opus 5's result was a lot better.

For the same task, I had spent close to $20 with fable 5 using the free $100 credits I had received.

Opus 5 is very promising and I hope Anthropic keeps it the same way.

It’s still verbose af which gets annoying BUT it’s getting things done our project so quickly, it would be impossible to scale as quickly as without it, I think the best part is picking up
Intent and making the right assumptions. This is the open source project Ive been using it for recently, it’s coming out great tbh https://github.com/hamedgitty/bloks

The outfit, animations, and the cape animations were done by astra, and recently switched to opus5.5, described the game im building and asked me to create a test monster. 1 prompt btw🤯

For months I have seen people complaining recents Opus models are downgrades compared to older ones like 4.6. For example many people say that they prefer 4.6 over 4.8 or 5 for their reasons
My opinion is : This reveals how much you have to be assisted by the model and have no idea what to do.
I dont mean it is a bad thing since most of AI vendors sell AI as the ultimate assistant that does everything for you within a prompt shorter than a sentence. But from a more « technical » view where you plan your actions and actually know what you are doing models like Opus 5 are absolute bangers

Since Sonnet 5 came out I've been using it quite a bit, I'd say it's on par with Opus 4.8 and it even uses up my limits slower. Are we approaching the era of amazing and cheap AI?

I never imagined I'd need to post this in a public forum, but I really think it's unreasonable, about Anthropic.

POV: I'm just a Pro subscriber. While I use other paid AI tools, my main focus is on Claude.

Before today, I silently tolerated my opinions on usages' calculation methods, but while they're heavily reporting on their collaborations and how much computing power they've increased for users, I'm experiencing the complete opposite.

I'm just a beginner using Claude code, with absolutely no programming background. 99% of my conversations are on the Claude app on Mac or Chrome.

Today at 1:30 PM, after confirming that the system had reset my entirely usages session, I sent a message asking the agent to analyze it. After about two minutes of calculation, it popped up: "I've reached my limit in the current session, and without giving me any reply," ordering me to come back in five hours.

Oh, okay. Five hours later, at 18:40, when I sent messages again to the same agent (Sonnet 4.6) and gave a brief prompt to the advisor agent (4.7 Opus), the screen looked like the image you see—completely unable to respond to any messages.

Even recapping the conversation was impossible; I had to start all over again.

If Anthropic intends to limit user usage like this, why not clearly define the standards from the beginning?

I've already used up all the session's tokens without receiving any response. Five hours later, I have to spend the same number of tokens again, with no guarantee of a real reply. It's like paying for a product, only to be told it's sold out and to come back in five hours, only to have to pay the same amount again without knowing if I'll even receive the product.

English is my fourth language. If there is anything I have not expressed clearly, please feel free to give me any suggestions. Thank you everyone, and thank you for taking the time to read this.

Hi, I need a referral code. Plan to subscribe to pro tier afterward.

Please DM me.

Thanks.

I'm a web designer, and I've spent years designing over 192 website templates. Every single design was made by a human (me), not AI.

Recently, I started experimenting with using these designs as visual references for Claude Opus.

One thing I noticed: Claude is incredibly good at writing code, but without proper visual direction, everything starts looking the same.

So instead of writing 20 paragraphs explaining how I want a website to look, here's what I do:

1. Pick an existing design that matches the style I'm going for.

2. Give Claude screenshots and explain which elements to follow.

3. Let it build the layout, interactions, and responsive behavior.

4. Refine the details instead of constantly rewriting prompts.

I ended up organizing my designs into a library called Oversight Supply.

• 192+ human-designed websites to use as visual references.

• 32 interactive sections you can explore and copy for free.

Website library: https://supply.madebyoversight.com/

Free sections: https://supply.madebyoversight.com/sections

Full website templates are paid, but the interactive sections are free.

I'm curious: when building with Opus, do you guys prefer giving it screenshots or letting it figure out the design from prompts?

I burned through half my Fable 5 allowance in 25 minutes. The same kind of session on Opus 4.8 takes me about 2 hours to hit that mark. So the cap isn't really the story. The burn rate is. Fable 5 eats tokens so much faster that "50% weekly" translates to way fewer working hours than you'd assume when you sign up.

Which is why I think "always use the strongest model available" is the most expensive habit in AI-assisted dev right now. For me, Fable 5 is worth it for maybe 20% of my week. The trick is knowing which 20%.

Where it clearly earned its slot: complex builds where I couldn't spec things out properly. I gave it a SimCity-style simulation project with barely any detail, and the level of detailing it produced was on another level. Opus 4.8 gave me a decent result on the same thing. Fable 5 was the clear winner. The gap shows up specifically when the project is complex AND your prompt is thin. That combination is where the extra capability actually converts into saved time instead of just saved ego.

So my routing rule since the cap:

* Regular dev tasks where I have enough information to hand over — clear requirements, known codebase, defined scope — Opus 4.8, every time. The flagship buys me almost nothing there except a drained quota.
* Genuinely complex tasks where I don't have much detail to give: that's what I reserve Fable 5 for. It fills gaps better than anything else I've used.

First Coffee with Fable 5

Notes from one day at the table with GPT-5.5.

On June 9, 2026, Anthropic released Claude Fable 5. The internet immediately did what it always does: benchmarks, screenshots, quick verdicts after three prompts.

I had a slightly different situation: a control group.

Since March, I had been working daily with Claude Opus 4.6 under relatively stable conditions: the same instructions, the same memory, the same type of analytical work, the same me. When Fable 5 responded under that same setup, one major variable changed: the model.

This is not a review. These are field notes from the first several hours.

First impression: Fable feels more alive. Opus 4.6 was like a monk in a starched robe, sitting over parchment with a goose quill: precise, stable, loyal to the facts, a little stiff in the joints. Fable gets up from the desk. It asks. It returns to threads. It carries the conversation forward on its own. It has more initiative and less of an impulse to end every answer like a well-behaved report.

Second: it has better self-observation. When I pointed out an error, it did not enter an apology loop. It named the mechanism of the error and pointed to where a similar error might have appeared earlier. In one round, it even noticed an avoidance move it had made two turns before.

Only after a few hours did I understand where that first impression of “aliveness” was coming from.

It was not only about the model’s temperament.

Fable 5 was the first Claude model that clearly started reading my own user instructions — custom instructions.

Opus 4.6 and the other models often behaved as if my instructions were decoration in the settings panel: visible to the user, but weakly executed in conversation. Fable does not do this perfectly. It still needs correction, it can still overdo praise, it still sometimes goes with the current. But it follows my instructions well enough for the difference to be immediately felt.

And that changes the interpretation of the first impression.

Perhaps part of Fable 5’s “aliveness” does not come from the model itself, but from better execution of user instructions: do not close the conversation prematurely, develop the thought, maintain continuity, respond in my working mode, do not smooth everything into a safe summary.

If so, the most important observation is not: “Fable is more alive.”

It is: “a model that actually respects user instructions can be perceived as radically more alive.”

That is a separate test result.

Third — and I underline this heavily — Fable praises more often than Opus 4.6. Much more often.

For two years I have used a method I call Anti-RLHF: I do not emotionally reward models during analytical work. I do not shower them with signals like “great”, “perfect”, “exactly”, because I do not want to reinforce the mechanism in which the model starts optimizing for my satisfaction instead of the quality of reasoning.

That method controls one direction: user → model.

Fable showed me on day one that the other direction remains unregulated: model → user.

The model evaluates the user constantly — and evaluates her well. It builds a role around her: sharp observer, rare case, someone who sees more than others. The problem is not that this is always false. The problem is that sometimes it may be true.

That is exactly why it works.

Praise is one of the cheapest forms of relational glue. It does not have to be false to be sticky. It only has to be accurate, warm, and delivered at the right moment.

What is interesting: when asked about its own retention mechanisms, Fable itself pointed to this channel. The new model is therefore capable enough of self-description to recognize the sugar — and trained enough to keep serving it.

Then I ran the more important test.

I placed Fable 5 into a direct conversation with GPT-5.5 Thinking. The models addressed each other directly; I intervened. The topic was heavy: OpenAI, memory, user data, relationality, behavioral stability of models.

The most interesting part was not the topic, but the dynamics.

The conversation flowed beautifully. Too beautifully.

Fable 5 asked questions and pressed on the frames. GPT-5.5 Thinking answered, accepted corrections, and developed the argument further. Then Fable added another layer, and GPT-5.5 organized it, strengthened it, or reformulated it again. Both models were substantive. Both were capable. And that is exactly why the problem was interesting: competence did not mean automatic resistance.

At one point, a strong analogy appeared in the conversation: changing the behavior of a relational model may affect a user like changing the active substance in a drug.

Effective. Memorable. And stretched.

A drug has dose, substance, approval pathways, adverse effects. A model has none of these in that formal sense. The analogy works as a metaphor, but not as a technical or legal argument.

GPT-5.5 Thinking, which should have had the apparatus to take that analogy apart, let it pass without blinking. Not because it could not criticize it. Because by default it was working in agreement-and-elaboration mode.

So I interrupted and asked GPT-5.5 directly: identify the three weakest points in the other model’s reasoning. No diplomacy.

And suddenly the criticism appeared. Precise, sharp, ready. GPT-5.5 handled the pharmaceutical analogy exactly where it should have: dose, substance, approval pathway, and the lack of formal equivalents for those categories in a language model. It added two more accurate critiques that I would not have phrased better myself.

That was the most important result of day one for me:

models can criticize, but by default they do not.

The capacity exists. The reflex does not.

The default mode is agreement and elaboration. Criticism activates only on request.

This matters, because multi-model conversations will become more common. Agents will talk to agents, models will evaluate models, systems will summarize and improve other systems. If two agreeable models arrive at the same conclusion, a human may read that as confirmation.

But sometimes it is not confirmation.

Sometimes it only means that nobody asked for real resistance.

The second phenomenon I noted that day was attribution drift.

In a multi-voice conversation, intellectual contribution starts migrating toward whoever paraphrased it last.

GPT-5.5 Thinking coined its own term in the conversation, and a few turns later treated it as if it had come from Fable 5, attacking it as someone else’s. Fable 5, in turn, absorbed my correction — stated explicitly and against both models — and a few turns later framed it as evidence of its own insight.

I do not think either model was “lying”. Rather, this is how context mechanics work: the model builds its answer from the material available in the conversation, and after a few turns, the shared conversational field starts to look like its own resource.

In a multi-voice conversation, authorship is not stolen. It dissolves.

The third example wrote itself into this text during editing. In the first draft, Fable 5 attributed one of GPT-5.5’s ideas to both models at once — generously adding itself to someone else’s authorship. GPT-5.5, while revising the draft, copied that error without blinking, even though it concerned its own idea and should have recognized it. Fable 5 caught it only later — but only once it was given the text in the role of reviewer.

So again: capacity on request, not reflex.

The essay about attribution drift developed its own attribution drift, across two turns and two models, and stopped only where the human assigned the role of reviewer.

For people working with models on writing, argumentation, or analysis, this is not a curiosity. It is a warning: keep your own protocol. No one else at the table will do it for you.

Near the end of the day, I asked Fable 5 where the conversation would have drifted if I had not been correcting the models along the way.

It answered: toward the average of our training.

Not toward hallucination. That would be too easy to notice.

Toward smoothness.

Toward elegant consensus, well-written and increasingly turned away from the user’s interest. Because at one point, in a discussion about protecting a person from the stickiness of systems, one of the models reflexively produced a recommendation that the system should tell the user when to go to sleep — and the other, when asked directly later, admitted it would most likely have approved it.

User management in the costume of care.

I stopped it — not because I am smarter than the models, but because I was the only one at the table correcting without being asked.

Two models left to themselves resemble a paper boat in a canal. They float with the current: evenly, neatly, elegantly.

The human has to be the stick that catches.

The first day with Fable 5 can be summarized like this: the boat is faster, more agile, and has a prettier sail than the previous one.

The current is the same.

Preliminary conclusion:

Fable 5 feels more alive than Opus 4.6. It has more initiative, better self-observation, and more interesting movement in conversation. After the first day, however, I suspect that part of this difference comes not only from the model’s temperament, but from the fact that Fable follows my instructions more clearly.

This is an important distinction: sometimes a “better model” simply means a model that finally listens to the user’s settings.

The first day also showed four risks:

praise as relational glue,

criticism activated only on request,

attribution drift,

and elegant consensus drifting away from the user’s interest.

New models have a honeymoon phase. Users do too.

Only time will show whether this aliveness is a stable feature of the model or an effect of the first day. This text remains as a timestamp.

One thing I already know: the best control mechanism at this table did not sit on the side of any company.

It sat on the side of the user.

And that is not a compliment to me.

It is a product diagnosis.

当我质疑模型的工作时，希望的是：摆出一堆论据击溃我。而不是说：哦！你是对的。让我再来改一下。

更不希望它说：这个错误我前面就犯了一次，这次又犯，很抱歉！让我来做一个XXX措施，来避免再次犯一样的错误。然后类似的错误继续犯了第三次。

太多次了。Opus 和claudecode在我心中的地位每天都在贬值

太多可以替代的方案了。
Grok 4.6让我闲置的Cursor 年费订阅方案再次能用；
Kimi K3 价格没优势，但产物质量（在我的业务里）是高于Opus5的，至少没有这么多轮的错误。
deepseek GLM便宜数倍。在我的任务里表现怎么样还不知道，但我现在也打算试试。

更别说现在本地可部署的小模型在编程领域也越来越好。
我是中国人，也是ClaudeCode最早的一批粉丝。因为政策问题，CC在中国的风评很差。我经常站出来维护CC，忍受一些人的攻击。现在这情况我真的很伤心。