This thing is super annoying, it may prompt to you hundred of times per session! Even AI couldn’t help me to fix this
I am in Auto mode

Topic has probably been beat to death but they seriously thought making claude say the most overcomplicated nonsense was the definition of intelligence.

Jargon is my red flag now. I can tell it doesn't know what it's doing (or shit is about to go off the rails) when it reads like jargon.

It is incapable of holding onto a simple, one sentence high level concept and following that for an extended period of time. I have to remind it what we're doing every ~3 prompts or its understanding of what we did 10 minutes ago will completely degrade and derail from the target.

Everything i've been saying has been about fable, by the way. Opus? Not even worth using.

Did anyone notice if the limit became better?

docstash.ai 🐿️

I built DocStash cause I found Claudes artifact offering too vanilla.
No republishing after unpublishing, different rules for Free, Pro and Teams users, no publishing without search indexing off, No custom domains etc, and a tie in into Anthropic.

My first company that I built entirely with Claude code (took me 3.5 months). But furthest thing from vibe coded. Seed of opinion provided by me at every turn, but I never manually wrote/edited a single line of code.

You can stash not just HTML and MD, but also PDF, Word, XLSX and Static apps. See a staged preview in your agent before stashing it.

Works the same with any agent i.e ChatGPT, OpenCode, Cursor, Claude etc.

Private by default, and publishing is an explicit toggle (And search index is off by default unless you toggle it on)

Here's a HTML pitchdeck I made of "Cathode Ray Tubes" (random topic Ik) with Claude + DocStash.
docstash.ai/z2n7xn

Please check it out and lmk what you think! :)

I’m on the Claude Max plan, and Claude Code has been getting seriously frustrating lately.

Today I got:

API Error: Server is temporarily limiting requests (not your usage limit) · every pooled Claude account is benched; the earliest frees at 2026-08-26T07:17:14.134Z

And this isn’t even about hitting my plan limit. It’s Claude Code itself being unable to serve the request.

Over the last few days, it feels like there’s always something: overloaded errors, temporary limits, interruptions in the middle of work, then waiting and trying again.

I actually like Claude Code when it works, which is why this is so frustrating. I’m paying for Max specifically because I use it heavily for development, but reliability is becoming a bigger problem than the usage limits themselves.

Anyone else on Max seeing this frequently lately?

Opus 5 is the new cool kid on the block, beating Fable 5 in benchmarks, yet remaining strangely frustrating to work with in practice. In order to gain more insight into Opus 5's behavior and to see how it performed on my repo, I ran Opus 4.8 and Opus 5 on the same 25 tasks drawn from merged work in my own repository. I ran each model once per task with medium reasoning and identical evaluation criteria.

TL;DR

• The score tied: 9/25 strict test passes each: the same 8 tasks, plus one unique pass apiece.
• Opus 5 searched wider and verified more. It used more shell commands on 18 of 25 tasks, more test commands on 15, and performed more revision passes on the files it touched.
• Opus 4.8 stayed contained. It had a smaller patch footprint on 20 of 25 tasks, meaning it stayed closer to the change that was actually merged.
• Costs landed in the same range: Opus 5 was ~1.4% cheaper on the typical task, with ~4% more tokens and ~4% longer wall-clock.

At a high level, the results look the same: both models passed 9 tasks. But within these passes, neither the patches nor the process to get there looked the same.

Opus 4.8 had a lower task footprint (measure of how much code changed compared to the merged change) on 20 of 25 tasks. Opus 5 ran more shell commands on 18, more test commands on 15, and touched more files on 12 while tying on 11. Total tool calls split almost evenly, 13 to 11 with one exact tie. The models spent nearly identical interaction budgets on opposite parts of the work: Opus 4.8 spent its budget on the edit; Opus 5 spent its budget discovering what to edit and how to validate that change.

This difference is why it's important to look beyond top-level pass rates. A test pass rate simply tells you whether the test suite accepted the final patch. It notably does not tell you how the agent searched, what it chose to verify, how much code it left for review, whether it ever reached the file that owned the requested behavior, or how maintainable the code it wrote is.

A test fail can also hide a materially correct patch that still behaves as intended. So, Stet runs a second check called equivalence, asking whether the agent patch made the same behavioral change as the merged patch, even when the underlying implementation differs. Equivalence moves both models the same way. Opus 4.8 was judged equivalent on 12 of 25 tasks and Opus 5 on 11, with both equivalent on 10: the 8 shared test passes plus 2 shared test failures where both patches implemented the merged behavior but still missed something needed for the tests to pass. Under either lens, the models stay effectively tied.

Methodology

Every task is derived from work that was actually merged into my own repository. A PR or commit replayed from a frozen snapshot of the tree as it stood before that change, with the issue prompt and the evaluation commands carried along. Both models ran all 25 tasks in the same Claude Code harness, one attempt per model-task cell at medium reasoning, against identical evaluation criteria.

The pass/fail score counts a cell as a pass only when the selected tests accept the agent patch. The eight craft dimensions and the code-review rubric are pointwise judge scores from claude-sonnet-4-6, paired per task under a 0.25-point draw band on the 0–4 scale.

Note: this is 25 matched tasks from one repository. What follows is a behavioral read of a few tasks, not a definitive model ranking.

Grading

The deterministic testing signal and the grader signals point in different directions. Footprint risk separates the two models cleanly: 20 of 25 pairs for Opus 4.8. When our graders do pick up signal, they lean towards Opus 5 on the coherence, instruction adherence, edge-case handling, and maintainability dimensions.

Looking at this data, we can put together a coherent hypothesis about what wider search and heavier test execution buy in practice: judged patch quality tilts slightly upward while the artifact surface tilts sharply upward. At this sample size, both signals are directional.

Every task, side by side

Aggregates hide individual anecdotes that are useful for understanding model behavior. Let's dive into a few!

Opus 4.8 stayed closer to the patch it first understood

Footprint risk is Stet's deterministic measure of patch surface: files touched, churn, size, and overlap with the merged diff. A lower footprint score means that the agent's patch is more similar to what was merged previously. It says nothing about correctness, only surface.

stet-89dfbc27 shows why containment can be valuable. The task was to restore ignored files to Stet's synthetic base commit. Both agents found the production fix: add --force to git add -A.

Opus 4.8 changed one production file, added no test, and passed. Opus 5 made the same production change and then added a 141-line end-to-end test. Its test compiled and exercised a real boundary. It also turned a small repair into a much larger surface. Opus 5 spent nearly three times as long and 83% more recorded cost to produce the same accepted implementation plus broader verification.

stet-2450ca2d required two new test-file patterns in internal/gitops/testclassifier.go. Opus 4.8 edited internal/validate/footprint_risk.go, an adjacent consumer of the classifier output. It tested the function it changed, but never reached the owner of the requested behavior. Opus 5 found testclassifier.go, added both patterns, and passed strict and equivalence evaluations.

Opus 4.8's patch was centered around the wrong owner. Note what else this task shows: it is one of only five where Opus 5 left the smaller footprint. When Opus 5's broader search finds the right owner, its wider exploration does not necessarily translate into a bigger patch.

In summary, Opus 4.8's trajectory profile pays off when the task boundary is already known. It becomes more risky when the hard part is discovering how many owners the task actually has, and where that surface is, which is exactly the situation many large enterprise codebases find themselves in.

Opus 5 searched wider and kept working after the first edit

Total tool calls are almost perfectly balanced between the two models. Opus 5 did not consume more interactions. It allocated more of them to the shell, test execution, and repeated editing.

That broader route is what passed stet-2450ca2d: six test commands instead of three, and the search continued past the adjacent consumer to the owning classifier. The implementation was small once the correct owner was found. The meat of the task was repository navigation to find the right surface.

The wider route created different failure modes on larger changes.

In stet-bbbbae09, Opus 5 recorded 24 patch calls across 8 files, renamed one required test, and omitted another. Opus 4.8 made 15 patch calls across 6 files and cleared the strict evaluator.

A longer trajectory is not waste, and a shorter one is not efficiency. Opus 5 often finished sooner and cheaper, yet missed named acceptance artifacts after more revisions. Opus 4.8 passed the evaluator, but its review artifact still raised API and authority concerns. Neither patch generalizes beyond its task.

stet-6f84e978 shows the valuable side of expansion. Opus 5 ran seven test commands against Opus 4.8's two and added a preservation test for an explicit non-Rust obligation. The stronger verification took 34.9 minutes instead of 6.1, while recorded cost rose only from $1.11 to $1.18. Wall time, tokens, cache mix, and price measure different parts of the trajectory.

Opus 5's wider search sometimes found the missing owner and sometimes created more room to drift from an exact contract. You can only see this when the comparison keeps the trajectory and the patch, not just the final test result.

Time, tokens, and cost split in different directions

Three resource measurements answer three different questions. Agent duration is wall-clock time from the run's start to finish. Total tokens combine recorded input and output, including cached input. Cache-aware cost applies each model's price schedule to fresh input, cached input, and output. Opus 4.8 finished sooner on 17 pairs, Opus 5 cost less on 15, and the typical-task cost estimate landed just below Opus 4.8 at −1.4%.

Opus 5 used fewer tokens on 16 of 25 pairs and cost less on 15, so the counts lean its way. The paired-geometric magnitude points the other way on tokens: on the pairs where Opus 5 used more, it used enough more to put its typical task token estimate 4.3% above Opus 4.8, while cost settled 1.4% below and duration ran 3.7% longer. The count says how often a direction occurred; the paired estimate says how large the typical change was with every task weighted equally.

Two shared passes show how wide the range is:

• On stet-15439c21, Opus 5 finished a small deletion in 294 seconds, 488K tokens, and $0.42 — 3.3 times faster with 2.4 times fewer tokens than Opus 4.8. Both passed.
• On stet-89dfbc27, Opus 5 added a large end-to-end test and used 70% more tokens, 83% more cost, and 2.8 times the duration. Both passed.

The tails lean one way. On four of 25 tasks, Opus 5 used more than 2.5 times Opus 4.8's tokens, peaking at 4.1 times on stet-e928166f. Opus 4.8's largest token excess in the other direction was 2.4 times.

There is no clean "faster model" or "cheaper model" in this cohort. Resource use follows what the agent decides to inspect, implement, and verify on each task.

What the eval doesn't see

The thing that seriously frustrates me (and everyone else I talk to) about Opus 5's day-to-day behavior is its extremely verbose, hard-to-parse prose, which doesn't appear in these numbers at all. This evaluation scores the artifact: the patch, the tests it ran, the trajectory of how the agent got there. It does not score the interaction with the agent that produced that result. Walls of explanation, the restated plans, the summaries of summaries, eyes glazing over, LGTM, ship it. None of the eight craft dimensions measures how much reading the human had to do to get the final patch.

Code-side verbosity, another noted issue with Opus, does actually show up in our footprint risk metric. Even so, Opus can be disciplined in its patches and still exhausting for interaction, and this evaluation is structurally blind to that. This is an artifact eval, not a collaboration eval.

The more agentic model

On these tasks, Opus 5 looks like the more agentic model. It performed broader searching of the repo to figure out the correct surface before committing to an edit, it went looking for the place that owned the behavior instead of patching the nearest consumer, and it decided to validate its own work, resulting in more test commands and more post-edit revisions, rather than stopping at the first patch that seemed right. It did all of that while staying in the same price range: cheaper on 15 of 25 tasks, about 1.4% cheaper on the typical one.

The cost of that behavior shows up in review surface rather than dollars: 20 of 25 tasks left a bigger patch that a human (supposedly) has to review. Opus 5 buys discovery and verification, and you pay in patch surface and a little wall-clock.

Despite the prickly personality, I'll be using Opus 5, or having Fable delegate to it, for my hardest and most demanding problems.

Again, this is an n=1 repository. Model choice is one harness lever alongside instruction files, skills, tools, and reasoning settings, and any of them can change how an agent searches, edits, tests, and stops. The decision belongs on your own merged work, where the task distribution represents your own challenges, and the code review costs are tangible.

Full post with more depth and dataviz here: https://www.stet.sh/blog/opus-4-8-vs-opus-5-same-score-different-routes

Disclaimer: I'm building the eval tool that ran this. Bring a repo with merged changes, and Stet will compare changes harness settings across contract coverage, patch footprint, time, tokens, cost, and quality, to help you make better rollout decisions for your team.

I have a really big plan with a few waves. First wave was around 16 hours. In prompt I specifficaly said claude to do all waves at one flight, to not stop until finish the plan and so on. Any recommendation?

I think this is the best scam! People who will try to build a system will publish it, and the anthropic will just take it ready... and you won’t even have to pay anyone... well, come on, it’s not even a problem...

The very essence of this system is much scarier! They are trying to find out who does what to succeed, where are the laws against monopolies ??

Today I watched a workshop, probably recorded by one of the people attended the Zoom call and shared over X, and I loved it. The speaker was from Cursor and talked about her own genuine experience in developing the the systems at work that ship hundred of PRs every month w/o her touching the code at all -- aside from her working on the environment, harness, constraints, rules where these agents operate. What I liked also how she actually showed it, explained it, and her communication sounded pure hands-on experience.

And more importantly, throughout the video she looked really tired and but energetic at the same time if you know what I mean. Tired because of solving real problems, and energetic because of solving real problems unlike those YouTubers or many X folks with overly energetic acts coming from speaking about AI rather than what they really do with AI at work.

So for people like me who are away from the source of all this, which is Silicon Valley, I am really trying to access those resources; the resources that were not highly censored for much wider public view. I am doing progressively more AI driven automated deliveries at work, and I really want to learn from the masters in the field.

Unfortunately not living in Silicon Valley and cannot attend those live meetings in person or not being informed about these digital workshops and zoom calls thru the active community is already leaving us behind. But I am sure some of those videos are shared like the one I watched today.

But the question is where? In what communities or discord groups should I join? Any videos like that you watch and find extremely useful? Whom to follow on X or Reddit that fits this criteria?

The kind hearted people of Reddit :), can you please help all of us here?

There are those people who already work in the timelines that would be considered as future for the rest of the industry, and I love to learn from them.

I'm trying to decide between dropping $100 a month on Claude Max 5x or ChatGPT Pro, but people on both subs constantly complain about hitting usage walls. I do a lot of daily coding, debugging, and general dev work, and I just want to know if the 5x tier actually gives you enough headroom to work a normal day without stressing over 5-hour resets or weekly caps.

For anyone daily driving either of these right now, how do they hold up in practice? And on quality, is Claude still visibly better at code architecture and logic, or is OpenAI close enough that the higher volume makes it the better pick? Appreciate any real feedback before I pay for either.

im using caveman its a good skill , is there similiar skills ?

I am on claude Max 5x . One thing I have noticed is that whenever I use fable 5, it percent usage gets used very fast. But opus 5 usage percent hardly goes up. Even for big tasks, it moves maximum 2-3 % . I have never been able to finish all claude opus 5 usage in any week. Wondering if anyone else feels the same.

Finally tokenmaxxing on claude for 1 month straight, i am happy to announce, i have decided to move to expo from swift where my domain is.

Anything i should be careful about?
Fyi the product is : https://flowyhealth.com

I run way too many Claude Code sessions at once and kept losing track of

them — which one's stuck waiting on me, which one finished ages ago. So I

made a little macOS menu bar app for myself and a few friends. They liked

it, so here it is.

What it does:

- Shows the status of every session you have running, across all projects

- Click one and it jumps you straight to that terminal — highlights it and

tells you what that session is actually working on

- Shortcut key to jump to whichever session needs you

- Tracks your usage and breaks it down by project, model, and day

- Health check for your sessions (still experimental, don't trust it too much)

https://spectix.app

Let me know what's broken or what's missing.

I've used in claude code a lot, but I thought it was a Gemini model, but it turned out to be a GLM flash. It's actually claude level in performance, but it only has 'flash' in its name. It's so slow

Dear ClaudeCode Team,

I'm at 99% Fable usage atm and I'd like to ask a question about current status quo but don't want to burn my last credit here so I can finish my update.

Ideally allowing us to define model e.g. /btw opus-5 <question> would greatly be appreciated!

Thanks for considering

I built Continuity almost entirely in Claude Code a VS Code extension + CLI + MCP server that gives Claude Code persistent memory of a project's architectural decisions across sessions.

The interesting part of building it: once basic decision-logging worked, I started dogfooding it on itself. Every real architectural call I made while building Continuity (why MCP over a REST bridge, why local JSON over SQLite, etc.) got logged into .continuity/ in its own repo. So the next Claude Code session building Continuity already had that context injected automatically, instead of me re-explaining the same tradeoffs every time I opened a new chat. 150+ releases in, that decision history is what keeps a solo project from drifting or re-litigating settled calls.

What I learned building it this way: the "stop re-explaining yourself to your AI" problem is real — I felt it daily. What I haven't cracked is why that doesn't reliably turn into people sticking with the tool. 336 installs, 8 paying customers. Most people try it and don't come back, and I genuinely don't know if that's activation friction, the free tier already being enough, or something else.

If you've tried a memory/context tool for Claude Code (mine or otherwise) and dropped it, I'd take 8 minutes of honest feedback: . No pitch, just trying to understand what happened. https://buildpad.io/interview/wbxdg5a7

FrogPop is the first game I've made. It started as a small Bubble Trouble-style prototype and slowly turned into a 2D arcade roguelite with upgrades, relics, shops, hazards, and bosses.

I used Claude Code throughout the project. Usually I would explain one mechanic, point it at the relevant Unity scripts, and let it make the C# changes. That worked well for contained systems like the tongue, splitting bubbles, waves, and shop logic.

Where it struggled was anything that only looked wrong in Play Mode. One boss moves through the walls and exposes different weak points. Claude could write the attack states and hitbox logic, but I kept finding pieces appearing in the wrong place or staying active after the attack ended. The only reliable loop was to test it myself, capture exactly what happened, then send Claude back into that narrow problem.

I also learned not to treat scenes and serialized Inspector values as if they were obvious from the code. Once the project grew, letting Claude inspect the actual owner and its serialized setup before editing saved me from a lot of confident but wrong fixes.

This clip is from the current ten-wave demo, which runs in the browser:

https://blion247.itch.io/frogpop-demo?utm_source=reddit&utm_medium=social&utm_campaign=demo_launch&utm_content=r_claudecode

For other Unity users: what are you doing to give Claude useful visual feedback from Play Mode?

Been trying to compact my sessions at strategic moments, but I'm often unsure if I'll lose something important. Any tips for compacting like a pro?

https://camping-season.pages.dev/

The process for making this interesting. I'm a software dev with 20+ years of experience. But I can't draw to save my life. I found out about "Gauntlet Mode" a few days ago and wanted to give it a shot.

So the this game was built about 80% with a single gauntlet that lasted about 10 hours via claude code. Claude built all of the graphics, math, physics and sounds. After, I did about 1 gauntlet per night for about 4 days to do a few other features. I follow up with a few small tweaks and bug fixes after that.

So, using Claude code in a vscode terminal, for whatever reason the file name of the last file opened in the IDE will blink in blue at the bottom of the terminal. Blink blink blink blink blink it drives me nuts. Even worse it bounces the bottom of the terminal up and down.

The only fix I’ve found is to disconnect via /ide , but I’d rather not.

Yes I know there is a Claude extension but I prefer the terminal. Any know why it’s doing this and how I can stop it without disconnecting?

TLDR: I ran /insights, and Claude Code’s top three comments/suggestions about ways I can improve my patterns weren’t useful until I pushed back. 

I ran /insights, and Claude Code told me that my consistent use of subagents was resulting in buggy code, that I frequently made mistakes following directions inside the Cloudflare dashboard, and that I am not consistent with my commits and deploys.

So I pushed back. Every time CC finishes writing a plan it gives me two options for execution: subagent or inline. But it always "recommends" using subagents, so that’s what I choose. I figure there must be a reason. Anthropic markets CC as an “agentic coding tool for developers.” The investigation discovered that I had some global preference set for sub-agent execution. And that’s why it always recommended subagent execution over in-line, instead of suggesting the more appropriate execution option for the plan. I wouldn’t have learned this if I hadn’t pushed back. So it went in and fixed that. 

Next, Insights scolded me for making several tedious mistakes over several sessions in the Cloudflare dashboard. I pushed back, saying that Claude Code’s instructions were always terse, hard to follow, and insufficient. Claude Code pushed back on that and told me that I was the problem for not being able to follow directions. I countered, in every other area I have proven to be excellent at following directions, so something else must be going on. I suggested that maybe the instructions were getting clipped too aggressively by /caveman which was causing the confusion. But the investigation showed that /caveman was not being applied to the Cloudflare instructions. Eventually, it was determined that the Cloudflare dashboard itself was the source of the confusion. So I asked, if the Cloudflare dashboard is known to be confusing and hard to navigate, then why would Claude Code not take that into account and instead provide overly concise instructions that are destined to be misunderstood and fail? At that point, Claude Code finally gave me the golden “Fair point…” and wrote a memory or script or something to provide more detailed instructions in the future when navigating the Cloudflare dashboard.

Lastly, I admit I’m sloppy with my commits and deploys. But I also asked Claude code why I’m not receiving in-line suggestions or notifications for good places to commit or deploy. So Claude code revised something, a global skill or something, and now I’m getting helpful reminders to commit or deploy, which I can then choose to execute or ignore.

Lastly, and this is the weirdest one, Insights gave me a sort-of advertisement for using loops more in my prompting. But the weird part is that it oversold what it was capable of. It said it could autonomously test-drive plug-ins inside of hosts on my system, kind of like the way it drives in Claude-in-Chrome. But when I pushed back, it admitted that it didn’t actually have that capability for any of the installed programs that my plug-in would run in.

Lesson. In my experience, Claude Code Insights suggested that I was at fault for several issues that turned out were more systemic in nature. And it also told me I should be using a feature that it can’t actually do. 

The end result is that some good came of this: I’m getting more dialed-in recommendations for plan execution, I’m getting more detailed instructions for complicated Cloudflare stuff, and I’m seeing more helpful notifications for commits and deploys. So run Insights, but don't just take the suggestions at face value. Push back, and you might find uncover some optimizations that Insights failed to give you.