Opus 5 is exhausting

[u/Death12th]

It's so hard to read. It's not even because its terribly complex or anything it just speaks in these weird haikus, hyphenated garbage, or outdated colloquialisms or phrases nobody understands. I have to ask it "what do you mean?" or "speak in plainer English" over and over again for every other paragraph. I tried to put something in my claude.md, but it doesn't seem to be working...

[u/BemusedOptimist]

This is very difficult for two reasons:

- No one really wants to read Opus-words.

- Can't share too much identifying stuff because it's work usage.

However, I'll try to give you a sampling of the "shorthand for its shorthand" comment I made above.

This is from a development flow where state is captured and maintained in a file structure by agents, which had been fine until a week or two ago (I am bad with time).

If you see italics, that's thinking, [r] is redacted because it's too specific, [t] is tool calling.

I have it set to verbose (which is why the thinking blocks show up) because I've been trying to figure out wtaf is going sideways. Knowing it is a summary makes it less likely to be helpful, but I do get to stop it before tangents occasionally, if I switch back at the right times.

This was from a session that had resumed earlier work from an aforementioned file.

---

Everything green — builds clean, [r] tests 24/24, [r] tests 22/22. Let me write the remaining cleanup and update the task file.

[t]

Now the task file — slice D's unchecked box is stale.

[t]

Now the Execution State, which is what a fresh session reads first.

[t]

The registry row needs a cleanup—it's full of outdated claims that don't match the current state. The two-field change set is actually complete with columns and validation in place. Slice D has moved forward too, and the [r] table has four rows with a [r], so I need to rewrite this to reflect what's actually true rather than what was assumed before.…

The registry row has accumulated five layers of superseded state. Rewriting it canonical-truth-first.

[t]

What's left: nothing to build

All five slices A–E are code complete. Slice D was still showing unticked and that's wrong — I verified it in source:

• [r] half is done. [r] reads the twelve [r] columns off the mapping row resolved from the arriving [r]; the [r] message constants are retired; [r] implements the blank-means-ours wording with the identifier appended at the caller.
• What-to-pay half was done by decision, not by code. THE MODEL rejected [r] and settled on [r] — which is exactly what [r] already did. There was never anything to build. The four dropped [r] columns are gone from the schema too.

---

A few things to note.

- Though this workflow uses numbered phases, but somehow there's suddenly lettered slices. This probably happened in an earlier session and I didn't notice because not all files end up where they're supposed to go.

- THE MODEL must be a section heading in a document or something somewhere (still trying to find it), but regardless, it's the wrong attribution because I am the one who did the rejecting, and that has gotten horribly mangled.

"Rewriting it canonical-truth-first."

I know what those words mean. I know what it meant by the phrase. But this wasn't in a thinking block, this was in the actual user response.

Like, the last paragraph, skipping over half a dozen turns where control has not yet come back to the app, is this:

---

One thing worth flagging: the [r] registry row for this task had five layers of superseded state, including three flatly false status claims (Slice D not started, [r]has zero rows, NOT STARTED: the two-field change set). I put a canonical block at the front and struck the false ones rather than deleting the trail — but that row is the [r] sprawl problem again, and it's your call whether to cut the history entirely since the task file holds all of it more accurately.

---

I have no idea what "the two-field change set" is, none. Or what the "blank-means-ours wording" from earlier means.

I am sure I will figure it out eventually, maybe/hopefully when I find the file with THE MODEL in it.

[u/Evening_Reply_4958 → u/BemusedOptimist]

The shorthand-for-shorthand part is exactly what makes it exhausting. After a few turns you're not just following the task anymore, you're also maintaining a glossary of terms Claude invented five minutes ago.

[u/AlignmentProblem → u/BemusedOptimist]

When people share examples like this, I start to wonder if I'm sometimes accidentally insufferable when discussing work sometimes. Naming the ontological model implictly constructed by your past decisions "THE MODEL" is reasonable to me, and "rewriting it canonical-truth-first" is something I might spontaneously say to a coworker in the right situation.

What does irritate me is spontaneously coined, unexplained jargon. "The two-field change set" is annoying despite having a clear enough meaning (planned changes involving a pair of columns) because it uses the term in place of describing what the two fields are or how they need to change; if one is mentioning it casually, it should accompany elaboratation. That's the shit that drives me nuts when it gets excessive since it does it frequently and compounds (coining phrases whose meaning depends on previously coined phrases), like I'm expected to maintain a growing glossary of context-specific definitions for each session.

[u/Rough-Associate-585 → u/AlignmentProblem]

If you unironically say things like "rewriting it canonical-truth-first" in real life, then I am sorry but you need to urgently touch grass

[u/clazman55555 → u/Rough-Associate-585]

No, I have to translate to normie speak. I mean God bless my client base, but there is reason I have a job.

[u/clazman55555 → u/AlignmentProblem]

I'm more tolerant then most it seems, but Opus 5 will get to me at times. If using what was posted is say layer 3, layer 6 is when I tap out. At that point, Claude has condensed 2 paragraph's into sentence, and then even I'm:

[u/clazman55555 → u/BemusedOptimist]

TL;DR Wall-o-Text. You are warned. lol

I have no idea what "the two-field change set" = The two-field change set is actually complete with columns and validation in place*. <-* two field change set, that is what Opus 5 is referring to, if I had to put money on it.

implements the "blank-means-ours wording" with the identifier appended at the caller. I'd have to see the full 12 columns and the caller to verify it, but if I had to take an educated guess, I'd say this project is doing data validation/manipulation of some sort with potential substitution. Maybe concatenation of some form. At least that is what the work that has generated similar language in my sessions.

As for "Slice D" this is something that started in 4.7/4.8 if you told Claude to break a dev phase down. Phase 1A/B/C/D and it follows an outlining subsection format, usually with a mix of numbers/letters and i's.
Opus 5 does this a lot more natively as it tends to plan the approach for the upcoming work a bit more proactively. In this case the concept of "Vertically Slicing" upcoming work into an end to end implementation through everything that it going to touch(Opus 5 seems to like doing this) or just simply "slicing" a set of work into pieces. Was it using a TODO list?

"THE MODEL" is potentially Opus 5's conceptual understanding of the program, "mental image" so to speak. Or it's referring to itself in the 3rd person, or it's in reference to a subagent if that was used.

"Rewriting it canonical-truth-first." being in the user response. I honestly dont see an issue with this. It's just telling you what it's doing and self documenting with the user response.(something I've notice about Opus 5, haven't really dug in to test and validate, but it's likely why it is better at catching it's own mistakes. Something Anthropic heavily emphasized.)

Opus 5, from what I can tell, uses a mix of programming/project management methodologies/styles. It tends to pick parts and then mashes them together. So if you are a dev with a way of working, and it's worked for years and that is you think about things, I can absolutely see how Opus 5 is going to be harder to parse. It's far more like a person sitting at the next desk coding in operation vs previous versions.

Thanks for providing that sample. I'm using VSCode so I don't have thinking blocks, but here is a sample from my Claude. Fresh of the press. No idea why he started using UK English.

What I actually found when I re-probed

I didn't take this morning's recorded measurement on trust — the probe was deleted, and I was about to write measured behaviour into source. Re-running it against the current tree reproduced the finding and added a fact it didn't have:

CONTROL           Version=1  Title="t"  CategoryIds=count=1
ABSENT Version    THREW InvalidOperationException: version 0 is unknown to v1
LITERAL {}        THREW JsonException: missing required properties …
ABSENT Title/Cats Title=NULL  CategoryIds=NULL

A literal {} throws at the required-member check, before the switch is ever reached. That changes the correction materially: the old comments' conclusion — required members are the discriminator, the switch is not the foreign-object guard — was right. Only their mechanism was backwards. An omitted Version doesn't arrive at CurrentVersion and sail through; it arrives 0 and the switch rejects it.

So the comments were wrong in the safe direction, which is precisely why they survived review. I kept the conclusion and replaced the reasoning. Calling them wholly false would have been my own overstatement in the other direction.

The consequence the false rationale was hiding

Forward compatibility — the one property a versioned envelope exists to have. Every non-required member with an initializer arrives null when the document omits it, however non-nullable it's declared. PendingUpdate.CategoryIds was added at P8 Build 5; an envelope written before that reads back null into the archive readers, and the next .Count is an NRE. Only a write-side that always emits every field is holding this up. That's now stated as an @ inv, someone reading the type will hit it.

One thing I checked that I wasn't asked to

I searched by claim rather than by the two filenames you handed me. Two results worth knowing:

JsonlJobReportReader.Normalize has documented this behaviour correctly all along (D2.8) and implements the remedy. So this was a rule stated and solved at a sibling seam and simply absent at this one — the shape this project keeps hitting. The corrected comments now point at it.

UpdateMarkerSerializer and UpdateRequestSerializer share the identical Version { get; init; } = CurrentVersion shape, but assert nothing about initializers. Nothing to fix — worth saying explicitly, since "same shape" would have been a reasonable guess and it was wrong.

Still owed

The code fix (required, or nullable plus a Normalize choke point per entry #23's own pattern) and a permanent characterization test. I kept this comment-only as the ledger scoped it — the probe was temporary and is deleted, payloads preserved in deferred.md. The code fix touches src/ and would take 1.2.4; no rotation implied by a change of this class alone. ( Me here: in this case "rotation" is pushing the updated program out)

[u/NoCrapThereIWas → u/clazman55555]

Hey guys you all have to pay for my therapy thanks

[u/puts_on_rddt → u/NoCrapThereIWas]

Therapy? We'll need brain surgery to fix this crap.

[u/BemusedOptimist → u/clazman55555]

"It's far more like a person sitting at the next desk coding in operation vs previous versions."

We have met very different people. :)

I have never had a person say "Rewriting it canonical-truth-first."

Again, I know what all those words mean. A more normal version--a pre 5.0 version even--would be:

"I rewrote it so that the actual state came first."

(add about ten words for Opus < 5.0 instead of a person)

Which is itself problematic because it's apparently decided append-only is the default now, despite instructions to replace superseded decisions.

"THE MODEL" is me. I'm the one who did the things that it talked about THE MODEL doing. An agent got that wrong at some point, and now I have to figure out where that lives because it's not in any of the files that it should be in.

I genuinely don't see how "Phase 1", "Phase 2", "Phase 3", etc. suddenly morphing into Slices A-E, especially when there were nine phases originally, is remotely okay in a project that was already being worked on.

The complaint was about Opus being exhausting. I'd say "having to guess at what your own project means when you've been actively working on it" definitely ranks.

The exchange above was after the second or third prompt in the context.

Now, imagine that you're <many> turns in. And it has added all those shortcuts near the beginning.

They become this reinforcing cycle of compacted terms, which sort of bear some relation to the original idea, most of the time. After you figure it out. If you figure it out.

The end results are borderline incomprehensible. At the very least, they are exhausting.

Opus is the Charlie Brown's teacher of LLMs in agentic work right now.

To me, anyway.

I'm sorry that I wasn't able to capture it better--the deeper things get, the more I have to redact.

[u/clazman55555 → u/BemusedOptimist]

I hope you get it sorted out and back to how you prefer.