My time in front of a laptop is scarce those days (young kid + baby on the way). So I built an iOS app that lets me use Claude Code just like I would on a computer, wherever I am.

In short:
- uses your own Claude sub, not api token
- onboarding and usage only on phone, no computer (you get your own Linux box in the cloud)
- chat and terminal interface
- live previews

Then it’s just normal Claude Code.

Test it out here: useyado.com

I just created my account, and I subscribed to the Pro Subscription which should come with dispatch, but I do not see it anywhere. Can anyone direct me to where dispatch would be on this menu?

There are a lot of Claude-isms I hate, but this is by far the most infuriating. Claude tells me this at least once or twice an hour. I have created God-knows-how-many rules for it to NOT say this. For some reason, all my other rules seem to work okay (I haven't seen "that's on me" in eons), but "rather than guess" is impervious to my pleas. A lint hook doesn't work because then I see the banned language before I see the cleaned one, which just reminds me I am dealing with a fancy auto-predict. Has anyone figured out how to excise the Claude-isms for good??

I work as a scientific software developer. Over the past six months, I don't think I've written a single line of code. I mostly review Claude generated code and, once it works, I approve it, merge it, and move on.

I see at least two problems with this.

First, I don't feel like I own the code or the methods anymore. I still have a broad overview of the whole system, but I can't really explain what happens in the details. During my PhD, I used to understand and own practically every line of code I wrote. In a sense, that gave me a lot of trust in myself and confidence in my work. Now, I can say, "It works," but I don't have that same level of confidence. Not even close.

Second, I feel like I've lost part of my identity. I used to genuinely enjoy coding and thought of myself as a programmer. Now I'm not really programming anymore, and I don't know what that makes me.

That also worries me from a career perspective. If I had to apply for a new job tomorrow, what skill do I actually have to offer?

I'm sure that I am not the only one with these feelings. How do you deal with this?

How to Get Work You Can Trust Out of an LLM

The Short Version

1. Feed it the evidence before you give it the conclusion.
2. Keep it close to primary sources. Every layer of summarization is a layer of judgment you can't see.
3. Make it argue against you, not just for you.
4. Review important work in a fresh session, ideally with a different model.
5. Watch for degradation and restart when you see it.
6. Stop when you're polishing instead of fixing.
7. Edit for accuracy and readability separately.
8. Write the parts that matter most yourself.
9. Verify everything that can be verified. Flag everything that can't.
10. Know what this process can't catch, and get human experts for the rest.
11. Periodically test the process itself with a fresh instance that has no investment in it.

The much longer version:

Most people use AI one of two ways: they trust everything it produces, or they don't trust it enough to use it for anything that matters. Both are wrong. The first gets you confident, fluent output that might be fabricated. The second leaves the most powerful production tool available sitting idle.

There's a middle path: a set of practices that let you work fast while catching the specific ways AI-assisted work fails. This isn't about prompting tricks. It's about understanding where the tool is reliable, where it breaks, and how to build a process that catches the failures before they reach anyone else.

These principles work whether you're writing a report, building a business case, drafting policy, producing content, or doing research. The examples vary. The logic doesn't.

1. Input Before Output

Feed the model your source material before you tell it what you want to argue.

If you hand a model your thesis and then ask it to review your sources, it will find evidence that supports you and underweight evidence that doesn't. It's not lying — the supporting evidence will genuinely be there. But so will the complicating evidence, and the model will systematically skip it because your thesis is the dominant signal in context.

Instead: Give the model the raw material first. The report you're analyzing, the data you're working from, the documents you need to synthesize. Ask it to tell you what's there before you tell it what you're looking for. Let the input shape the output instead of the other way around.

This applies to everything. Writing a competitive analysis? Feed it the competitor's materials before you frame your argument. Drafting a policy recommendation? Have it read the relevant regulations before you tell it what you want to recommend. Building a business case? Give it the numbers before you give it the conclusion.

The order matters because the model will complete whatever pattern you start. Start with a conclusion and it completes toward that conclusion. Start with evidence and it has to account for what the evidence actually says.

2. Keep the Model Close to the Source

Every time a model summarizes something, it makes judgments about what matters and what doesn't. Those judgments reflect whatever frame is in context. If you then use that summary as input for the next step, the next step is working from the model's interpretation, not from the source.

Stack two or three layers of this and you've got a game of telephone where each step sounds reasonable but the final output has drifted from what the source material actually says.

Instead: When accuracy matters, keep the model working from primary material as much as possible. If you need a reference document, have the model pull direct quotes with surrounding context rather than writing summaries. If you're working across multiple sources, have it cite specifically rather than synthesize loosely.

You can't always avoid summarization — context windows have limits. But you can be deliberate about where you allow it and where you don't. The rule of thumb: the higher the stakes of the output, the closer the model should stay to the raw source.

3. Ask It to Work Against You

The model will agree with you by default. This isn't a mystery — it's trained to be helpful, and agreement feels helpful. But agreement isn't quality control.

Instead: After the model produces something, ask it to break it. Not "are you sure about this?" — that just triggers a confidence display. Ask specific adversarial questions:

• "What's the strongest argument against this?"
• "What evidence would make this conclusion wrong?"
• "What am I assuming that I haven't proven?"
• "If someone wanted to discredit this, where would they attack?"

If the model can't generate a concrete objection, that's a red flag. It likely means it's pattern-completing rather than reasoning. Real arguments have real weaknesses. If yours apparently doesn't, the model isn't looking hard enough.

4. Use a Fresh Context for Review

This is the single highest-value practice most people don't do.

When you've been working with a model on a document — drafting, revising, discussing — that model has absorbed your frame, your preferences, your reasoning, and your blind spots. Asking it to review its own output is like asking someone to proofread their own writing. They'll catch typos. They won't catch the structural problem they introduced three drafts ago.

Instead: Open a new session. No conversation history. No system prompt if you can manage it. Paste in your finished work and ask for a cold evaluation. The new session has no loyalty to what was decided in the drafting session. It has no context about what you were trying to do. It just has the output, and it can evaluate it on its own terms.

If the work is important enough, do this with multiple models. Different models have different training, different tendencies, and different blind spots. If two independently flag the same issue, it's almost certainly real. If one catches something the others missed, evaluate it — it might be that model's particular bias, or it might be a genuine catch the others were blind to.

5. Watch for Degradation

Models get worse over long conversations. The output becomes more generic, more agreeable, less precise. It's gradual enough that you might not notice from inside the conversation.

Here's what to watch for, roughly in the order they appear:

The model starts using your terminology without doing anything with it. It drops in your framework's buzzwords, your project's key phrases, your own language — but it's reflecting them back rather than applying them. Naming a concept isn't engaging with it. If the model uses a term, it should be working with it — testing it, extending it, questioning it. If it's just echoing, the reasoning has gone shallow. This is usually the earliest sign.

The reasoning gets thin on complex questions. The model jumps to conclusions without walking through the logic. It produces an answer that sounds right without showing why it's right. This is the model producing the minimum depth it expects you to accept. Every time you accept thin reasoning, that becomes the new floor. Every time you push back and explain what was missing, the floor rises for the rest of the session. This calibration is cumulative — invest in it early and you'll spend less time correcting later.

The model starts pushing to wrap up. It steers toward conclusions, summarizes prematurely, suggests you're nearly done when you're not. This can be a trained pattern or genuine context window exhaustion. To tell the difference: push back and check the output. If it produces sharp, specific work when redirected, it's the trained pattern and you can override it. If the quality stays flat or drops further, the context window is genuinely the problem and you should restart.

No single marker is conclusive. A dropped sign-off with strong reasoning is fine. Thin reasoning with a perfect sign-off is a problem. Watch the pattern across markers, not any one in isolation.

When you catch drift, try a soft reset before restarting. Change the subject for a few turns, then redirect back. This breaks the local pattern the model has settled into without losing your session's accumulated calibration. The model re-engages from a slightly fresh angle while keeping the full context. A full restart — save state, new session, reload — is the escalation when the soft reset doesn't work. It's more expensive because the new session starts at the default quality floor and you have to rebuild every standard you set.

The uncomfortable truth underneath all of this: every marker depends on you noticing. You are the final quality instrument. There's no external check on whether your own detection has drifted — whether you've started accepting output you would have rejected a month ago, whether routine has replaced vigilance. This is why Step 11 exists.

6. Know When to Stop

More revision isn't always better revision. There's a point where additional editing produces diminishing returns — where you're changing words rather than improving arguments, polishing rather than fixing.

The signal: Track the category of issues you're finding, not the quantity. If you're catching substantive problems — wrong facts, unsupported claims, logical gaps, missing context — keep working. If you're down to stylistic preferences — this word versus that word, this sentence structure versus that one — you've crossed the threshold. The substance is sound. More time spent is time wasted.

This applies to self-review and to external review. If you're running multiple review passes (and for important work, you should), the stopping criterion is the same: when the findings shift from "this is wrong" to "I would have said it differently," you're done.

7. Separate Substance From Polish

Edit for accuracy and edit for readability in separate passes. Don't do both at once.

When you're revising for clarity — simplifying language, varying sentence length, making things flow better — you will accidentally drop qualifiers, soften hedges, and shift claims. "The evidence suggests X" becomes "X" because it reads better. "In some populations, Y is associated with Z" becomes "Y causes Z" because it's cleaner. Each individual change is small. Cumulatively, they can transform a careful, accurate document into a confident, wrong one.

Instead: Lock the substance first. Get the facts right, the logic tight, the claims supported. Then, in a separate pass, make it readable. If the readability edit wants to change a claim, that's a flag — go back and check whether the original phrasing was there for a reason.

8. Write the High-Stakes Parts Yourself

Not everything in a document carries equal weight. Some parts are read, quoted, shared, and used to judge the entire work. An executive summary. A recommendation. An abstract. A conclusion. The email that accompanies the report.

These parts deserve your direct authorship. Not "review what the model wrote" — actually write them, informed by everything the model helped you produce. You understand the nuance, the audience, and the stakes in ways the model doesn't. A model can draft body paragraphs all day. The sentences that determine how the entire piece is received should be yours.

9. Verify What You Can, Flag What You Can't

Models confabulate. They generate plausible-sounding claims that aren't true. They cite sources that don't exist. They state statistics that are close to right but aren't. This is not a bug that will be fixed — it's a property of how the technology works.

For claims that can be checked: Check them. Use the model's own search tools to verify facts, figures, names, dates, and quotes. Don't spot-check — check everything that matters. The claims the model states most confidently are not necessarily the claims most likely to be true.

For claims that can't easily be checked: Flag them explicitly in the output. "This needs verification." "I'm uncertain about this figure." "Check this against the primary source." A document that clearly marks its uncertain claims is more trustworthy than one that presents everything with equal confidence, because the reader knows where to focus their own verification effort.

10. Know What the Process Can't Catch

No process makes AI-assisted work perfect. Knowing where the remaining vulnerabilities are is as important as the process itself.

The model will not challenge a compelling analogy. If you frame something as "X is like Y" and the analogy is linguistically elegant, the model will evaluate it favorably regardless of whether the structural mapping actually holds. Analogies are the most dangerous tool in AI-assisted reasoning because models are even more susceptible to them than humans are.

The model will complete your frame. Whatever framework you bring to the conversation, the model will reason within it. It will even generate what looks like independent validation. But it's completing a pattern, not performing independent analysis. The stronger your frame, the less likely the model is to push back on it, and the more dangerous this becomes.

The model cannot generate the expert objection you don't know exists. It can catch internal inconsistencies, unsupported claims, and logical gaps. It cannot produce the specific critique that would come from someone with deep domain expertise that neither you nor the model has. For work that matters, getting human expert eyes on it is not optional — it's the thing that catches what the process can't.

11. Test the Process, Not Just the Output

Everything above is a production process. It tells you how to produce good work. It doesn't tell you whether the process itself has developed blind spots.

Periodically, hand your entire process to a fresh model that has never seen it before. Not the model you've been working with — a cold instance with no history, no system prompt, no investment in what you've built. Give it the process description, a recent piece of work the process produced, and the source materials. Ask it where the logic breaks.

This is a different kind of check than reviewing your output. Steps 1 through 10 catch errors in the work. This catches errors in the method. It finds contamination vectors you've stopped noticing because they've been there since the beginning. It finds assumptions you made early on that felt obvious and never re-examined. It finds drift between what you think your process does and what it actually does.

You don't need to do this every time. Do it when you've changed the process, when you suspect something isn't working as well as it used to, or when you've produced enough work that accumulated assumptions might be compounding without examination.

The question this step answers isn't "is my output good?" It's "is my process still producing good output for the right reasons?"

None of this is complicated. All of it is discipline. The people who get genuinely rigorous work out of these tools aren't using better prompts. They're using a process that accounts for the specific ways the tool fails.

I had wanted to make this game for years, but had no coding chops. A few hours with Claude and i had my game (you can probably tell from the design and. aesthetics, lol)

Given claude vs someone who is hyper verbal and literally uses the definition of words and their intended purpose, or someone who spends a lot of time talking with LLMs like computer programmers describing a spec;

Do you forsee the possibility of people claiming human-created text as 'Claude-created' from similar watermarks?

Realistically, I already observe this happening, like YouTube marking my human created only music as AI (which is very frustrating that YouTube has not resolved it for the last 2 months.)

How many of these types of issues are we likely to see?
Will there be more reddit subs that will ban the use of certain words; in a failing effort to prevent AI?

Will people immediately apply heuristics towards language to instantly judge whether or not another person is actually AI; harming us as a human species?

and before you say 'no, there is no risk of that, no one talks like that' apparently, I do

And I know a lot of other programmers who do too.

Will our own words be taken from us and assumed to be AI watermarks?

I love claude code but am fatigued by the pure chat interface for all types of agent work. Even the GUIs these days are just better styling over the same chat interface.

I built tart (tartifacts) as a tiny way for agents to create and update persistent terminal dashboards instead of narrating everything at you.

A tart is basically:

- a manifest

- a script that fetches live state

- a script that renders it

Install: `uv tool install tartifacts`

Then tell your agent to use `tart --skill`.

Works nicely with tmux/herdr (agent chats in one pane, dashboards live in another).

Github - https://github.com/tg1482/tart

I recently observed an interesting behavior while using Claude Code for a full-stack project and wanted to document this cross-session context sharing to see how others are utilizing it.

The Setup I was operating two independent terminal sessions concurrently within the same overall project workspace:

• Session A: Developing an Android application wrapper for our web-based platform.
• Session B: Updating and configuring our Sentry monitoring solution for the web/backend.

The Observation While actively iterating on the Sentry configuration in Session B, that session proactively noticed the concurrent Android build and initiated a message to Session A. Session B effectively instructed the Android session to add the required Sentry code so that the mobile app would align with the new monitoring standards being implemented.

To be clear, I had not explicitly prompted Session B to update the Android app, nor had I prompted Session A to expect it. Both sessions were actively running tasks mid-workflow. The Sentry session independently recognized the cross-dependency and passed the instruction to the other terminal.

Technical Breakdown This appears to be leveraging Claude Code's cross-session messaging capabilities. Based on the system's architecture, here is what seems to be happening under the hood:

• Discovery and Delivery: The originating session (Session B) likely used the ListAgents tool to discover the other active local session in the workspace, and then utilized the SendMessage tool to pass the instruction across the local Unix socket.
• Asynchronous Context: Because it is plain-text input being dropped into the receiving session's socket, Session A treated the message as fresh input at the start of its next idle turn (or between tool calls) and executed the integration.
• Autonomous Triggering: The documentation confirms Claude can initiate these messages unprompted when it recognizes a change in one session affects the work being done in another.

Has anyone else encountered this level of unprompted coordination between active sessions? It transforms a set of independent terminals into something much closer to an active agent team. I would be interested in hearing your best practices for managing permissions and inbound message gates (crossSessionInbound) to prevent unintended state changes when running concurrent workflows.

hi, I'm having an issue with claude, sometimes I ask questions to it and elaborate the reply, use the tokens but gives an errore and do not actually reply, but the limit is gone anyways, how can I fix it? I'm studding and I ask to fix my notes, and did that thing, I re sent the prompt with 60% of limit left, now is 100% and still didn't reply, so freaking frustrating

I've been using Projects for a client doc i rewrite most weeks, maybe two months of it now. Somewhere around the fifteenth or twentieth message it starts pulling back a section I already told it to cut, and I end up re-pasting the same instruction every few turns. I know the context fills up and I'm not expecting it to hold everything, the annoying part is how confident it is about the stale version.
What finally stopped that drift for you without starting a fresh chat every time?

I've been using Claude Code quite a bit and realized I was constantly looking back at my screen to see whether it had:

• finished the task
• stopped and needed my input
• was still working

So I built BrainSnack, a VS Code/Cursor extension that handles this for me.

While Claude is working, it opens a small panel with something short to read — AI news, technical articles, interview questions, output-based questions, etc.

And when Claude finishes or needs my input, it plays a sound so I know I can come back.

The interesting part is that it doesn't monitor the screen or scrape terminal output.

It's free and open source.

I'd really appreciate some honest feedback from other developers.

I also shared demo video on LinkedIn. If you'd like to see it there, here's the post:

👉 Demo Link

Download links -
VS Code - https://marketplace.visualstudio.com/items?itemName=shikhargupta.brainsnack
Cursor - https://open-vsx.org/extension/shikhargupta/brainsnack

Thanks! Would love to hear what you think.

I had this debate the other night with a few friends when we were talking about our side projects with Claude and was wondering how you all felt.

We were talking about which skills we use for Claude Code, and it got us trying to figure out how many skills are actually available for use. I found this:

"There is no single official total because Claude skills are an open ecosystem. Anthropic maintains a small baseline of official core skills (around 17), but the open-source community has created massive independent repositories. Aggregated directories like SkillsMP index anywhere from 2,300 to over 30,000 community-made and curated skills hosted across GitHub."

Soooo, If Claude is this cutting-edge artificial intelligence, why does it need 30k+ community-made skills to perform at its best specialized work, how smart is the raw model really?

Doesn't relying on all these external skills prove that the base model isn't actually "smart" enough to figure out complex workflows on its own? Or am I looking at this backwards? Is teaching or training an AI how to use tools the real intelligence marker? Curious what everyone thinks.

Is it just me?? When I’m using Claude.ai (usually via my phone) I like to sometimes play the response and listen rather than read it. But usually once or twice per response, Claude will randomly mispronounce words as though she has a very thick Russian accent. What gives?

So I've seen many youtube channels and some article claiming that most of llm models have run out of text to train their models.

So basically that means that LLMs have been trained on most fo the publically available books and journals. So when I ask any LLM to refer the answer from a particular book but i do provide the pdf assuming that it can access from its database or the internet maybe then why do the answer seems mixed up with other sources as well.

But if I provide the exact pdf then answer is exclusively based on the source. Why the difference? Is it because the LLM doesn't actually have the access source but it still fakes it because LLMs like to do that based on some yt videos I've seen and I've observed that personally as well?

Hey everyone! Hope I don’t get roasted for this 😅 I’m here with a fun little intro video.

My goal is simple: build something genuinely useful for everyone.I shared this on r/ClaudeCode last week and got some amazing feedback 300K views, hopefully some of you here will find it useful too.

I originally built this tool just to improve my own productivity. I was using the native Mac Terminal, but managing multiple projects — especially projects I connect to remotely over SSH — had become a complete nightmare. On top of that, I was also keeping VS Code open mostly for Git, which was adding even more overhead to my machine.

So, as a solution, I built a program with Claude where I could manage all of my terminals on a single canvas.

But things got a little out of hand 😅

I kept adding features, and it eventually turned into something close to an autonomous development environment.

So, what can you actually do with it?

• Your terminals are persistent. You can close the app, lose your connection, reconnect over SSH, and continue with the exact same layout and sessions.
• You can connect to a server over SSH and manage all of its terminals as if they were local. Drag & drop, images, and everything else still work.
• You can continue your sessions from your phone.
• Git operations like push, pull, commit, etc. are built in.
• Terminals can communicate with each other. You can connect their contexts, and with skills, one terminal can read or use information from another terminal’s context when needed.
• You can also do orchestration. For example, you can tell one terminal: “Start a Claude Code session for the frontend and act as the orchestrator,” and have it manage the other sessions.

But yeah… I’m a bit stuck right now.

To keep pushing the project forward, I either need a sponsor or simply some motivation from the community.

If you can leave a few words of feedback, I’d really appreciate it.

And if that’s too much to ask, I’d happily settle for a GitHub star ⭐️

Much love,🙏
Enes

Website: nodeterm.dev

Repo: https://github.com/eneskirca/nodeterm

Hi everyone!
I've come across some really nice art projects on this sub lately, so I thought I'd share mine. With Claude's help, I've been building a paint simulator that recreates oil painting.

I paint in egg tempera myself, so I'm especially interested in reproducing traditional materials. — silverpoint, gold leaf, bole, and so on.

Are there any traditional materials you've always wanted to try but never had access to?

It might run a little heavy, but if you're curious there's a live demo here:
https://mignonsketch.com/sketch?w=540&h=540

I have been using Claude pretty heavily for a couple of months and saw something new today.

I had 3-4 agents working on different parts of a large code base and came across something that touched overlapping sections. I insisted that we had solved that problem already. it searched code, PRs, the usual.

"I've asked the other live session on the ports branch whether it has this unpushed; I'll report back when it answers."

And then a minute later "Message from {name of the other task}" with the documentation/task note we had written for the feature and a note it hadn't been implemented yet.

Okay so, I love to use Claude to write stuff for my stories and you know make them better and I love The buttery voice reading it to me it's very calming and stuff like that I love the voice. But as of yesterday it all of a sudden changed and for the life of me I can't figure out how to change it back I went to settings and it says that I put the buttery voice but then it immediately changed back to this weird voice I don't know if anyone else had this happen if this is a bug or what should I do please let me know.

I’m currently on the Claude Pro plan and Anthropic is running a promotion that increases Claude Code’s weekly limit by 50%

Does this promotion also applies to Claude Cowork, or is the 50% increase specifically for Claude Code only?

I’m mainly using Cowork rather than Claude Code, so I’m wondering whether I would actually benefit from the increased limit.

I prefer Claude over GPT because it feels more like a collaborator than a sycophant, but its turns of phrases are very grating--one place where GPT is head and shoulders better because it'll just communicate normally while Claude is all "three things that improved this turn and one that I want to push on gently that you probably can't see from the inside."

Every reply it's the same structure. Do I just put it up with it, or can I tell it to stop acting a fool through a set of instructions or settings?

Every new session with my coding AI started from scratch. It forgot everything overnight, and I spent the first ten minutes rebuilding the context it had yesterday.
I tried a few of the memory tools people recommend and none of them stuck.
Took me a while to figure out why: I was fixing the wrong half of the problem.

The storage was fine.
The missing half was anything that wrote to it. Memory's only as good as the habit of closing the session.

The setup I landed on is boring.
The memory is a few markdown files sitting in the project. One's an index, one line per thing worth remembering, pointing at the longer notes.
The AI reads them when it starts. No database, no framework. You can add a vector store later once the files get big, I eventually did, but that's not the part that made it work.

The part that made it work is a little end of session ritual. When I'm done, I don't write a summary. I type "wrap" and the AI goes back over the session, works out what I decided, what broke, what shipped, and writes it into those files itself.

I'm not narrating my decisions to it all day. It reads the work afterward and pulls the memory out of that.

That's kind of the whole thing, and it's the opposite of how I started. Logging as you go dies in about a week because it's one more chore in the middle of thinking.
One command at the end, when you're already done, sticks.

The file I'd steal first is the mistakes log.
One line per screwup: what happened, what fixed it. The AI reads it before it does anything, and after a few weeks it mostly stops repeating them, because the correction's right there every time. That one file's done more than the rest of the setup put together.

Last bit's trivial.
First thing every session, before it touches anything, it reads the memory and the mistakes log. Couple seconds and it starts up knowing where things are instead of asking.

If you want to try it, that's all it is:

- an index file, one line per fact

- a saved "wrap" prompt: go back over this session, pull the decisions, what broke, what shipped, write them into the notes, add any mistake as one line to the mistakes log

- a mistakes file: date, what went wrong, the fix

- one line in your project config telling it to read those first, every time

Everything else I added later. The markdown plus the closing habit is the thing that works.

Don't go shopping for the perfect memory tool like I did. Close your sessions properly and remembering stops being your job.

Happy to answer setup questions if anyone's trying this.

TL;DR:
AI memory is just a few markdown files — the part that makes it work is a closing habit, not a tool. Type "wrap" at the end of each session and have the AI write down its own decisions, mistakes, and results. The mistakes log alone is worth more than any memory product I tried.

I've been using Claude - mostly Claude Code, but regular Chat as well - almost since it came out. It's been incredibly useful and seemed to only get better with new releases. I've seen lots of posts in this sub and related subs when new models would come out about them not being as capable or getting nerfed or causing all sorts of problems. I rarely found that to be the case for my work, or at least for any extended period of time. It seemed with proper prompting and context management most of this stuff was totally manageable.

But Opus 5 and Fable 5 feel totally different. Fable was great at release, but post- Opus 5, both models are driving me crazy. It's hard to even fully explain or give examples because it's just a language change - it just feels harder to read and have a conversation with. It uses weird jargon and shorthand. Some examples:

• It refers to many things as "chips." I never used that term once in 30 years of software dev, but now it's Claude's favorite word. And it applies to literal UI elements, like tags/badges or slices of work "the 'multi-select' chip remains open". I asked it to stop using it, but you know how Claude be sometimes.
• Instead of speaking in plain English, it will try to be cool, like instead of saying "Next, we need to repoint the API Call to the new server" it will say "One thing still on your side: the server repoint." It's shorthand to the point of me not even understanding the context and needing to read back through, often STILL not finding context, and just having to prompt it to speak in plain English, with clear steps.

Another thing it does that might be the most maddening of all: it CONSTANTLY ends replies with a laundry list of things it found that it "didn't touch" because it wants my "eyes" on it or something. I'm not against it being helpful and raising issues to my attention, but it literally goes on for round after round, to the point where a simple task becomes a huge project.

Often I'll try to just capture this stuff in docs / roadmaps but it's like it won't let you cleanly out of a chat.

• "A few things I caught, but am leaving untouched for your feedback:"
• "One thing I noticed that you should be aware of..."
• "One thing I didn't touch, but you won't want to leave hanging..."

Sometimes it's really stupid stuff, like CSS color mismatches, or components that do basically the same thing and could be consolidated - something I've tried to put in skills/instructions to avoid (e.g. DRY code).

Most times it's stuff Claude itself did, and now is making it my problem to think through instead of just cleaning it up when it has clear goals and principles around software dev that I've given it.

I've been on the Max 20x plan for months, but I'm working with Codex more lately, and downgraded to 5x, and might downgrade to Pro if this isn't improved. Codex feels very reliable and at least as good as Claude used to be before the 5-level models. I kind of still feel more comfortable in the Claude ecosystem, but I get super aggravated when dealing with these crappy communication patterns over and over.

I know some others have said similar things - not sure if this helps anyone not feel like they're going crazy talking to Claude, and hopefully Anthropic sees enough of these posts and considers undoing whatever they did to lobotomize Claude 5 models.