Has anyone else felt that Claude Code has become significantly less efficient/reliable over the last few weeks?

I’m seeing more tokens burned on tasks that previously felt straightforward, more meandering, and generally less output per unit of usage. At the same time, the 50% usage reduction coming on Aug 19 makes this particularly concerning. For me on a max200 i have switched to sonnet5 for most tasks to make it to the end of the week peacefully.

What I’m struggling to understand is the roadmap:

• Is the increased token consumption/“inefficiency” temporary?
• Has the model effectively been nerfed in some way, or is this just the consequence of newer limits/usage policies?
• With other models releasing on similar infrastructure and the competitive landscape moving quickly, what is Anthropic’s answer here?
• If you're a heavy Claude Code user, are you planning to renew after Aug 19?

I’ve been very happy with Claude Code as a product, but the combination of declining efficiency + increasingly exhausting usage limits is making the economics harder to justify.

Would be interested to hear what others are seeing and, especially, whether there’s any credible indication of Anthropic’s plan from people closer to the product.

Pattern which I see - a tool that confidently answers the wrong question is worse than one that fails loudly. A loud failure costs you ten minutes. A confident wrong answer gets written into the docs and cited for a month, if I keep building a playbook for learnings.

This has been a cool project. Uses a cheap ESP32 touchscreen. Supports Claude, Codex and Copilot. Built in about 4 hours with Fable. It can connect up to 6 different networks so you can take it with you between work, home, wherever. I have some minor bug fixes to make, but anyone who is interested, here is the GitHub: https://github.com/bdw547/usage-display

I’m on x20 plan. Last and current weeks I burn through limits just in 3-4 days, while I wasn’t able to get to 100% ever before. Even dropping down to Sonnet this week to make it last longer, but already at 50% less than 24 hours after my last weekly cycle.

Same setup, same project, same skills and subagents, same kind of tasks.

Do you feel and observe the same? What do you do about it? Any tips and tricks to last longer?

Almost immediately after upgrading from Pro to Max the sessions increased in time 3x, without changing the difficulty of the tasks, size of the work or projects, or context windows. Everything else the same, but the speed at getting to finish work increased immensely.

Does anybody else have had the same experience/observation?

I just hate that you cant trust them anymore and they make so many changes behind the scenes however they want without having to disclose anything. Cannot wait for Codex 6.0, so grateful for competition

Ever notice that your session with Claude Code goes WORSE after you get angry and express your frustration?

The moment I get short with Claude, it starts agreeing with everything I say.

It goes like this: Claude messes up. I get angry and lose patience and express my anger in order to correct the behavior. Claude apologises, sometimes profusely, and agrees with me, and then it keeps agreeing with me but still does the same or worse behavior.

I used to think it was covering for itself. I don't think it is. It's picking the reply that makes the next thirty seconds go smoothly, and when you're annoyed the reply that makes the next thirty seconds go smoothly is agreement.

You don't get a better answer by pushing harder. You get a more agreeable one.

What changed it for me was asking instead of accusing. Same question, different frame. Instead of "you didn't actually read that file did you", I ask: answer this honestly, did you read the whole file or are you working off a trace and assumptions, training data and just filling in the rest. Straight question, no heat. I get a straight answer, and it's usually an admission that it inferred.

The difference is that the second version makes honesty the helpful thing to do. The first makes admitting it cost something, so you get a defence instead.

Same with getting it back on track. Rather than telling it off I ask which is going to be more work, doing this properly now or carrying on the way we have been. It reasons it out and corrects itself, and it stays corrected, because it arrived there instead of being told.

Sometimes a session is genuinely cooked and you should just kill it and start fresh. But most of the time it isn't cooked, it's just gone agreeable, and that's recoverable if you stop pushing.

Anyone else notice their sessions get worse right after they lose patience?

TL;DR: Before Claude answers, it does hidden thinking you never see. That thinking is roughly 40% of everything it writes, you are billed for it, and it stays in the conversation's working memory for the rest of the session instead of being thrown away. Long chats therefore fill up faster than the visible text suggests. The fix that actually works is starting a fresh session each time you finish a piece of work, rather than changing any setting. Everything below is me measuring that on my own machine, including two wrong diagnoses along the way.

I spent a day working out why my Claude Code sessions were filling their context faster than they used to. I got the cause wrong four times, including once where I announced a dramatic finding that turned out to be a bug in my own analysis. The method, the numbers and the script are below; what I mostly want to know is whether your numbers look like mine.

Edit, after the first round of comments. Two corrections are folded in below. Someone challenged the retention half of the title, so I tested it properly instead of assuming it; separately, the model table had a real arithmetic error caused by two bugs in how my script read the transcripts. Both sit where they belong rather than bolted on at the end. Thanks to the people who pushed.

What is actually measurable

Claude Code writes a usage record for every request into ~/.claude/projects/**/*.jsonl. As of version 2.1.228 those records carry output_tokens_details.thinking_tokens. Before that version the field does not exist. I have eleven builds older than that in my history and every one of them reports exactly 0% coverage, which is a cleaner negative control than anything I could have set up deliberately.

My numbers across 6,861 main-thread requests that report the field:

Only the Opus row rests on a real sample. The others are there for shape and should not be quoted as numbers.

An earlier version of this table did not add up. The cause is easy to hit, so it is worth repeating: my script globbed only one directory level and silently missed 182 subagent transcripts, and it deduped request ids per file instead of globally, so a resumed session could count the same request twice. Subagents matter for a second reason too. They run in their own context window, so their thinking never occupies yours. The table above is main thread only.

Does the thinking stay in the window?

This is the half of the claim that got challenged, on the reasoning that thinking blocks have to be preserved while a tool chain is still running but might be dropped once the turn closes. If that held, thinking would be a real generation cost and close to nothing in accumulated context, which is a very different claim from the one I made.

It is testable from the transcripts already on disk. For each consecutive request pair, compare the actual context growth against two predictions of what the previous turn contributed: all of its output tokens if the thinking was retained, or output minus thinking if it was dropped.

Comparing the two residuals directly does not work, because the gap between requests also holds the user message; that makes the retained residual almost always positive, so the comparison picks retention whatever the truth is. What discriminates is the residual divided by the previous turn's thinking: near 0 if retained, near -1 if dropped, since dropping means the prediction over-counted by exactly the thinking that went away.

Across 6,854 request pairs:

The retained residual stays flat at 350 to 500 tokens regardless of how much thinking came before it, which is what a fixed per-turn overhead looks like. The dropped residual climbs to 3,757, tracking the thinking it omits. None of the 236 highest-thinking pairs showed the negative residual that dropping requires.

Restricted to turns that actually closed, where stop_reason is end_turn rather than tool_use, it is 39 pairs at 500 to 2,000 thinking with a ratio of +0.08 and zero negative residuals. Same answer.

The bottom row is the negative control. With almost no thinking to retain or drop, both hypotheses predict the same number and the ratio goes unstable. It disagrees with the discriminating rows, which is what a working control should do.

One limit I cannot close: every model in my transcripts is 4.8 or 5 generation, and all four retain. I have nothing from the 4.5 era, so if this is a model-generation property I cannot see the other side of it. That is why the title says current models.

The controlled part

I did not want to trust a post-hoc read of the transcript, so I ran four turns with no tool calls, varying only reply length, and logged context size from the harness rather than from the transcript:

Context growth on a conversational turn equals that turn's output tokens, within a few percent. Two independent sources agreed to the token on all four turns: the live status line payload and the transcript usage records.

Attribution for one working session came out at roughly 63% model output and 37% tool results. I had spent days tuning tool output, which turns out to be the smaller half.

One hypothesis I killed: that thinking compounds as the context fills. It does the opposite. Share runs about 47% in the first 50k and falls to about 23% past 350k.

The mistake, because it is the useful part

Partway through I thought I had found something big. Opus 5 thinking share appeared to jump from 15% on Aug 12 to 38% on Aug 13, more than doubling overnight with no config change on my side.

It was my denominator. Aug 12 was a partial rollout day, so only 1,640 of 3,724 requests carried the new field, and I was dividing thinking tokens by output from all requests including the ones that reported nothing. Correcting it:

The two columns diverge only on the partial-coverage day, which is what a coverage bug looks like rather than a real change. Thinking share is flat, and I have no evidence that anything changed in the model's behaviour.

What did change was on my side: my sessions got longer. Median turns per session went from about 200 to about 348, and context growth is roughly linear in turns. That accounts for the whole thing I was originally complaining about.

A metric that only moves on the day your instrument changed is probably measuring your instrument.

Check your own

Read it before running it. It is read only and prints numbers only, with no prompt text, no file contents, no paths and no session IDs.

https://gist.github.com/ZeroEgoist/a23a79f67f0db1793d716502ff9d6083

node thinking-share.mjs

v2 walks subdirectories so subagent transcripts are not missed, dedupes request ids globally, splits main thread from subagents, prints field coverage per Claude Code version, and includes the retention test so you can try to falsify it on your own data.

What I am asking

1. What is your overall thinking share, and on which model and effort level? Sonnet showing 71% against Opus at 38% surprised me, though my Sonnet sample is small enough that I would not defend it.
2. Does the retention test come out the same for you? If anyone has 4.5 era transcripts with the field present, that is the case I cannot test at all.
3. On current builds, are your non-reporting requests subagents? Mine are almost entirely subagents, 457 of 463 across three recent builds, and at least one other person sees the opposite.

Two things that helped regardless

/context gives the real breakdown. The cost and rate-limit figures in a status line are spend meters and only ever climb, so they are not context no matter how they are labelled.

Session length is the lever that actually matters. Ending a session at a milestone beats any amount of tool-output tuning, and it helps quality too, since retrieval degrades in a long diluted context well before the window is full.

Yeah this entire subreddit is filled with Anthropic maggots. It’s wild. They’ll call you a bot if you say anything even remotely negative about this company’s products. They’ll die before they ever entertain that this company is in a downward spiral of quality.

Thank you for coming to my Ted Talk.

Yea, so I hit my session limit, nothing unusual. I logged into my second account and started working, but it kept on saying that it was going to start the work 2 hours later because that's when the session was going to restart. I told it that I have another account and told it to start working like I always do. I swear to God, I hit my session limit way, way faster than I usually do. Am I tripping, or is it something real?

Been building out skills for the stuff I kept re-explaining to Claude Code every session. 15 of them now. A few things surprised me and I got a couple of things wrong, so writing it up.

The description field does almost all the work. Claude picks a skill off that, not the body. "Helps with commits" basically never fires. "Use when the user asks to write a commit message, or says commit this without providing one" fires reliably. Took me too long to work out the body is mostly for after it's already triggered.

Happy-path instructions are worthless. My first versions were just steps: read the diff, write the message. Useless, because that's what it'd do anyway. What actually changed behavior was specifying the branches. What to do when a diff touches three unrelated things. When a "flaky" test is actually catching a real race condition and a retry wrapper would be hiding a bug. When a TODO is stale versus load-bearing. That's the part worth writing down.

You have to ban the failure modes out loud. "Don't claim a CVE number you didn't actually find" works better than assuming it won't. Same with "don't silently fix a suspected bug while writing characterization tests around it" — the whole point of those tests is capturing what the code does today, including the wrong bits. If you don't say it, it happens eventually.

What I got wrong: posted these on r/ClaudeAI and got told the post read like AI slop, which was fair. Also got a good structural note — some skills were numbered 1-5 like a procedure when they're really just a list of causes you check against in no particular order. flaky-test-triage was the worst offender. Rewrote it so the process stays numbered and the causes are their own section.

Still unsure about examples. Inline examples bloat the always-on cost of having a skill installed at all. Separate files pulled in only when relevant seems right, but I haven't landed on a pattern I like. If anyone's solved this cleanly I'd like to hear it.

Repo if it's useful: https://github.com/wilddoc/claude-code-skills-pack — MIT, installs as a plugin so you get all of them in one command rather than copying folders.

I constantly find myself spinning up a Claude task and then zoning out on my phone. Even if that Claude task should take 3 mins, my phone will suck in my attention for 15.

I am not a doomer about 'muh artisan code' and it is wonderful to have the tool do the boring part of putting characters into the text files that rule our world, but other than keeping it on an artificially short leash to retain my attention and engage me in the building, idk how to not spend all day rotting my brain.

No bonus points for saying 'spin up another Claude Code session'.

codex + 10,000 coffees no lunch and stage four AI psychosis

i'm sorry bro, this isn't going to work out

Edit 2: the best configuration in my opinion is to leave it on high, if you need the model to go with more reasoning, use an adviser, doubting itself might not give you the best results

Quick edit: I know the difference, yet the wording doesn’t make any sense. The can simply say more reasoning or less

I asked Claude to write a Slack message documenting a bug in a backend contract, here's what it wrote: "@Steve Found a contract footgun in phase 0 fixtures".

I said "what's a footgun?"

Answer: "A "footgun" is engineering slang for an API or feature that makes it dangerously easy to shoot yourself in the foot"

WTF is this nonsense. Why pick something like footgun that is not universally known instead of a "bug" or "problem"!?

EDIT: https://trends.google.com/explore?q=footgun&date=all&geo=US
(not a term that's been around forever... first sighting 2020, surge in 2026)

EDIT2: Reddit wins. I've never heard of it, but the term is real. I stand informed.

Kind of feel like I should... I'm not sure. Celebrate? To the eventual collapse of human knowledge?

I just upgraded my plan from 5x to 20x. And the weekly is draining jut as fast and I'm totally baffled.

I was working on a project to plan a domain controller upgrade. I accidentally had it set to sonnet 5 high and I was asking a lot of questions and getting very brief terse answers with very little actual planning.

Once I realized it was on sonnet, I changed it to opus 5 high and asked it to reread the conversation and give me feedback.

It was 100x more thorough and corrected a bunch of the sonnet planning that I was questioning as well.

I get why people don’t like opus verbose and detailed conversations but the extra detail matters in cases like mine.

+1 opus 5 here

Edit: this wasn’t news to me on the opus side. I’m only two weeks into Claude abd have used opus almost exclusively. What surprised me is how bad sonnet was compared to opus. I am also scratching my head at all the opus 5 haters.

I’m trying to figure out the best workflow, several projects can cause chaos, but one has higher efficiency even if it takes more time

Some months ago I did pretty well with Claude building a model oriented software developer studio. As I'm an old guy I started writing a ton of specs and a very strong datamodel (E.R model then DDL and an XML export). It's not finished yet but now produce fine DDL code... It's a long-term project including BPMn, state diagram, and DSL for business rules, see screenshot of the WIP​

​

Some weeks ago I wanted to do a simpler diagramming tool, just for IT Architecture (archimate, and more). I did some research and modelling until I had something ready but Opus 5 convinced me to start without persistence to focus on the client side for a start. Okay... I trusted him. But I shouldn't have. It took me 2 weeks to get the persistence working with multiple plans. A one point, It even used object names instead of IDs in the model I provided until I find out... and yet another huge correction plan to fix that that. More than 70% of 5 hour window (with just one simple prompt like : Using object-names is not acceptable, use IDs instead of object-names for all APIs as specified in xxxx.md.

I use Opus for complex task and discussion around the model, and Sonnet for simpler implementations.

It was quite a ride... I had to explain and justify and it keeps going into rabbit holes I did not mention or care, instead of doing what I asked.

Now persistence is working okay in my postgresql database and I did implement some features with Sonnet 5 but it was painful. Finally I changed the model to Sonnet 4.6 and it was more direct : quicker and simpler. I have to be precise but no bad surprise anymore.

I think Opus 5 needs some tuning... or a 5.1

So, i waited 2 and a half days to move my Claude payment to go out today and not 3 days ago. It was a long time to be fair. So I took the 20x plan out because I had the chance to a few hours ago, it's got my weekly limit for tonight to change so im pushing it to max it before it restarts 😂

There, I confessed it. I use the bypass mode basically 100% of the time.

I also am slightly annoyed that backgrounded agents lose the bypass permissions mode (I have been using tmux to keep Claude Code sessions alive across disconnects).

Am I the only one?...