Hi all,

No layoff talk brewing at my company. Yet.

But I’m definitely at the point where the model is so good, I crush anything that is assigned to me in 1-2 hours. I’m having a hard time filling an 8 hour workday.

All tech debt : gone. I solved it.

I ask for more work: “we’re still gathering requirements.”

I’m worried that it is only a matter of time before senior leadership notices that there isn’t enough work to feed the amount of devs we have.

I feel like Opus 5.5 was another inflection point. Previously, I had to build sophisticated orchestration, baby sit models, and curate context. And that took a lot of my time. This model needs very little of that.

Maybe it is just me, but definitely feels like I'm hitting my limits a lot faster.

And I'm on the 20X plan. Never was an issue until past 48 hours.

New Claude Code UI update. What do you guys think?

In 1967 Ted Nelson described stretchtext: text that grows where you want more and shrinks back where you don't. It stayed a quaint idea because writing every level of fidelity by hand is just tediously hard. Text is generative now, so Claude can just write it for us for free.

I've always tried to implement this idea with LLM in various ways. Claude Code Mods finally proivded a platform to share.

cc-stretch is a Claude Code plugin. It cuts Claude's reply by 83% so you read much less, yet still have the option to expand / shrink on demand. The plugin also tells Claude which parts you opened, so it doesn't assume you read the rest.

Install in a Claude Code session:

/plugin install cc-stretch --marketplace pro-vi/cc-stretch
/tui fullscreen

Repo: https://github.com/pro-vi/cc-stretch (MIT)

I just came across someone with practically no coding experience releasing an open-source password manager called KAPEVault.

Project: https://kapevault.brewedops.cloud

And we're not talking about some basic tutorial project. This is an actual downloadable Windows and Android application being publicly distributed for storing passwords, 2FA codes, API keys, government IDs, and other sensitive information.

I'm a software engineer, and I actively use AI coding tools myself. I think they're incredible. But seriously, of all the things you could build with little to no programming experience, why the fuck would you choose a password manager?

To give credit where it's due, the project is open source, has a documented threat model, automated tests, and a self-conducted security review. But the repository also explicitly acknowledges that it hasn't undergone a third-party security audit.

That's a pretty important distinction when you're asking people to trust your software with practically their entire digital identity.

Using AES-256-GCM and scrypt doesn't automatically make a password manager secure. Neither does having a polished interface, passing automated tests, or getting an AI to review its own output.

Security isn't just about choosing the right encryption algorithms. It's about understanding the entire attack surface, handling secrets properly, identifying edge cases, and knowing what can go wrong even when everything appears to work.

I'm not saying this particular project is insecure. I haven't performed a security audit, and that would be an irresponsible claim.

My concern is the growing confidence with which people are releasing security-critical software they may not fully understand.

There's absolutely nothing wrong with beginners experimenting, learning, and open-sourcing their projects. That's how people improve. But building something for educational purposes and distributing something that real users might entrust with their banking credentials are two completely different levels of responsibility.

AI has made it ridiculously easy to produce working software. Unfortunately, it has also made it ridiculously easy to mistake a working application for a secure one.

You can outsource writing code to an AI. You can't outsource accountability when something goes horribly wrong.

At what point should we start taking this seriously?

been hitting limits less since i changed a few habits, sharing in case it helps someone:

1. ask it to read files in line ranges, not the whole file. a big read stays in the context for the rest of the session and you pay for it every turn
2. send wide searches / research to a subagent. only the conclusion comes back to the main thread instead of 20 file dumps
3. put these as rules in CLAUDE.md, otherwise it slowly goes back to old habits
4. start a fresh session for a new task instead of dragging a long one along
5. when a session gets long, ask it to summarize the state into a file and continue from there

anything else that worked for you?

Hi, I'm from Korea and my english is not good, so I write this with translator help. sorry if some sentence is weird.I'm making Spearhead alone. It's WW2 eastern front RTS in Unity, and you can press H and ride any tank and drive it yourself. Almost all code is written by Claude Code. I started end of May and now it's about 400k lines C#. Honestly I can't read all of it, so my job is play the build and tell Claude what is wrong.

How I use it: I send many complaints at once with screenshots. Main session find where the problem is and give each one to sub agent. Each agent can edit only its own files so they don't break each other. After that it compile everything and make checklist image on my desktop, then I test.

Today example. The tank riders (desant) jump off pose was strange, so I put 2 old photos of soviet soldiers jumping from T-34 on my desktop and said "look this, they must jump like this or they get hurt". It fixed the seat position on the tank and made the jump pose from the photos. What I learned is memory file with rules is more important than good prompt (like never commit if I don't say, and compile ok is not fixed). Also 1 agent for 1 group of files, before this agents broke each other work a lot. And don't send message to agent while it's working, it get lost often.

voice, music and some store art is AI placeholder now, 3D models are bought assets. steam page in comment.

Almost got the hat trick!

Been a good boy all week, rationing my tokens carefully, clearing and compacting with care, and ended up 2 hours away from reset time with like 60% weekly and 45% Fable usage....

So f*ck it, Fable on Max, do a full audit of the control panel, look for bugs, vulnerabilities, performance bottlenecks, and suggest improvements... And 30 mins later we're here, "with room to spare", sure :D

3 weeks ago (after the usage correction) I posted that 4 five hour sessions consumed 100% of my weekly Fable use (20x).

Now 2 five hour session consumes 100% of my weekly Fable.

Have I missed communication regarding a change in usage?

I use Claude Code Sonnet 5.5 with Haiku 5.5 subagents

I use Codex Sol 6.1 with Luna 6 subagents.

I constantly hit the 5 hour limit with Codex.

I haven't hitted the limits even once with Claude.

The rumors are no longer rumors, Claude gives much more value. And I personally found the results much better than in Codex.

I noticed that the last three days I am way more likely to hit my session limits, and my weekly limit is getting eaten quicker too.

This could very easily be my behaviour, ie I think I am trusting the model more so letting it do bigger tasks in fewer steps, but I wanted ask if anyone else noticed the same thing this week.

You ask for an exploded view of a real thing (a lock, a Rubik's cube, WinRAR, React). The agent looks up the numbers and tags each one SPEC / MEASURED / DERIVED / ESTIMATED with its source. A gate script compares the model with what is published, and if it disagrees, nothing renders.

Examples of what the gate checks: a pin tumbler lock must put all five splits on the shear line with the right key; Enigma must reproduce the published test vector (AAAAA becomes BDZGO); a model of React's rules must predict the 1 of 8 DOM nodes the real React 18.3.1 touches.

The part that worked for me as a skill author: a gate the agent cannot argue with, and testing the skill with fresh sessions that know nothing about it, then fixing everything they tripped over.

Output is a 30 s film with sound, an interactive viewer and an STL/GLB. Built with Claude Code (three.js in a headless browser + ffmpeg).

Limits: films need a GPU, I have not tried macOS, and the gate checks the model against the published number, not against reality.

Repo (MIT): https://github.com/DiegoLopez0208/mechanism

Films and viewers: https://diegolopez0208.github.io/mechanism/

Install: /plugin install mechanism --marketplace DiegoLopez0208/mechanism

Which object should it model next?

I can confirm that the issue seems to have been resolved today. However, we've already burned through a significant portion of our weekly quota because of it.

Personally, I have four days left until my quota resets, with only 30% remaining. Most people in the original thread reported similar usage issues, although there were some differences from one user to another.

Even if usage is back to normal now, the damage has already been done. Those of us who experienced unusually high usage are still left with depleted quotas for the rest of the week.

Anthropic shouldn't just fix the issue and leave it at that. Given the impact on users, I think they should make another gesture to compensate those affected.

Original discussion: https://www.reddit.com/r/ClaudeCode/comments/1x64hj9/comment/pgx8ai2/

I had an issue where I downgraded from Max to Pro but still had a week left on my Max subscription. Anthropic immediately dropped me to Pro usage. Even after they confirmed it was a bug and others were reporting the same issue, they didn’t prorate my fee or give me back the week of Max usage. Literally confirmed in an email “yeah, you paid for something you didn’t get, but we’re not going to do anything about it.”

Tonight I went to write some code as per usual and I tend to be very pedantic, so I review and adjust a lot. I was re-implementing an older app in go so I had left claude to copy over some of the logic. Once it was done I went to review and the whole codebase was an absolute MESS.

This was one of the most brutal examples that literally had me questioning whether I had written a single line of go code in my life...

func (h *Handler) registerCars(g huma.API) {
    huma.Register(g, get("/cars/{id}", "getCar", "Cars", "Car details"),
        func(ctx context.Context, in *IDPath) (*Body[store.CarDetail], error) {
            car, err := h.store.Car(ctx, in.ID)
            return result(ctx, car, err)
        })

    create := op(http.MethodPost, "/cars", "createCar", "Cars", "Register a car and its client")
    create.DefaultStatus = http.StatusCreated
    create.Errors = []int{http.StatusBadRequest, http.StatusConflict}
    huma.Register(g, create, func(ctx context.Context, in *CreateCarInput) (*Body[Created], error) {
        b := in.Body
        id, err := h.store.CreateCar(ctx, store.NewCar{
            RegistrationNumber: strings.ToUpper(strings.TrimSpace(b.RegistrationNumber)),
            // ...
            CreatedBy: currentUser(ctx).ID,
        })
        return result(ctx, Created{ID: id}, err)
    })
}

This is a slightly truncated version of the code but this is genuinely atrocious by my standards.

Once rewritten by me my implementation now looks like this:

func registerCarRoutes(group huma.API, carHandler *handlers.CarHandler) {
    huma.Register(group, helpers.Huma.Operation(http.MethodGet, "/cars", "searchCars", "Cars", "Search cars", http.StatusOK), carHandler.SearchCars)
    huma.Register(group, helpers.Huma.Operation(http.MethodGet, "/cars/recent", "listRecentCars", "Cars", "Recently repaired cars", http.StatusOK), carHandler.ListRecentCars)
    huma.Register(group, helpers.Huma.Operation(http.MethodGet, "/cars/{id}", "getCar", "Cars", "Car details", http.StatusOK), carHandler.GetCar)
    huma.Register(group, helpers.Huma.Operation(http.MethodGet, "/cars/{id}/repairs", "listCarRepairs", "Cars", "Repairs of a car", http.StatusOK), carHandler.ListCarRepairs)
    huma.Register(group, helpers.Huma.Operation(http.MethodGet, "/cars/{id}/images", "listCarImages", "Cars", "Images of a car", http.StatusOK), carHandler.ListCarImages)
    huma.Register(group, helpers.Huma.Operation(http.MethodGet, "/cars/{id}/images/{imageId}", "getCarImage", "Cars", "Car image binary", http.StatusOK), carHandler.GetCarImage)


    huma.Register(group, helpers.Huma.Operation(http.MethodPost, "/cars", "createCar", "Cars", "Register a car and its client", http.StatusCreated, http.StatusBadRequest, http.StatusConflict), carHandler.CreateCar)
}

And the handler:

func (handler *CarHandler) GetCar(ctx context.Context, input *GetCarInput) (*GetCarOutput, error) {
    car, err := handler.db.Cars.ByID(ctx, input.ID)
    if err != nil {
        return nil, apierror.FromDBError(ctx, err)
    }
    return &GetCarOutput{Body: car}, nil
}

Now, to me this is a million times more readable and claude actually had references like this in the code. I actually am not sure where it misunderstood me or what happened but that first piece of code just felt like an actual flashbang when I read it...

Is this some A/B test where I got something like Haiku 1.1? Or is this is the standard way other go devs write code and I am just super weird with my structure? Or did I just get INSANELY unlucky??

I'm genuinely trying to figure out if other go devs would find that implementation acceptable and I'm at fault here or if claude really just wrote slop.

(I purposefuly included screenshots and code to get benefits of syntax highlighting and being able to copy code)

I'm using Fable as a reviewer. It spawns Opus agents if needed. I get a reset every wednesday at 9 PM. I'm on Max Plan 20x. Never had an issue with running out. For the past two weeks I've been working on two projects, using mostly the same workflow. Always had plenty in the tank with Fable. After the latest reset it's been eating my usage like crazy. I'm already on 25%. Has anyone noticed something similar?

I ran a task overnight, using ONLY opus 5.5 max (I have not used Fable in a while). However, here is the usage.

Anyone has similar experience or has any idea why Fable is used? Thanks.

The difference is so striking, my context usage suddenly hits 80%+ on a single prompt (20x plan), tasks are taking at least 2x longer than they did before AND producing far more mistakes.

Several mistakes it already made months back, which I set up rules to prevent from happening again, are now happening again for the first time since I made those rules.

This is the worst state I've ever seen Claude code in since I started using it. Curious if anyone else is experiencing the same to determine how wide spread this is.

I'm James Luan, CTO of Zilliz, the company behind the open-source Milvus vector database. These are notes from using Claude Code on our cross-platform database build.

The lesson I kept returning to after using coding agents on our cross-platform build was about the target I had given them. Getting the code to compile on one machine and making it work across supported environments were different engineering problems. The agent could satisfy the narrower request without knowing the broader one existed.

That distinction matters when building infrastructure for other people. A personal project can optimize for the author's machine and familiar edge cases. A distributed system has to preserve behavior across platforms and components that a single patch may not describe.

Some of the hardest production bugs we encountered were syntactically valid changes. The missing information was an assumption about how several components were supposed to coordinate. It was absent from the diff and existed only in a developer's mental model. The AI review approaches we tried did not catch those bugs.

That is why I put so much weight on explicit constraints and tests that express system behavior. They give an agent something more useful than an instruction to produce cleaner code. They also give a reviewer a concrete way to challenge whether the requested change actually solves the whole problem.

A passing local build is evidence about one environment. Turning that into confidence for infrastructure users still requires an engineer to identify the assumptions that the build never tested.

I ran a workflow that is not at all new to me. It's been tried and true.

Claude Code, Opus 5.5 high effort as main agent, Sonnet 5 (5.5 not yet available in company gateway) subagents for most tasks, sometimes Opus subagents for debugging delegation. Got my `promptCacheTtl` (main session's cache lifetime) set to 1h, subagents at 5m. Skills and instruction files to represent team coding practices, codebase actions, and such.

Needed to find bugs within an app developed by another team. Came up with a plan up front on what mattered most to our team as far as the app's priorities, then set my Claude Code to go on its bug hunt accordingly, and asked it to verify practicality of findings by reproducing them at runtime so that these findings weren't extremely unlikely hypotheticals.

I've done this before, no big deal. And the results were good as expected.

Only problem was, as I was tracking my credit usage (company uses single credit unit that translates to different model token amount, because we have a company gateway to access different models through one API key), I found that it was WAAY higher than expected; like maybe 5-10x higher than normal.

And... the token gatekeeper came knocking on my door...

This person came in, high and mighty, claiming my context size for prompts was excessive (turned out some of the subagents were going up to 800k in size as time went on for some of the more difficult bug reproductions), and this was driving heavy cost. Said it should hardly ever be more than 200k. I was like okay, I don't necessarily disagree, but some of the bugs were tricky and took more context to figure out, it happens, most of them were quick in-and-out at much less.

Then they drop the bomb that the LLM gateway we were using occasionally doesn't uphold CACHE reads/writes... It's been "broken recently."

I'm like well... I think I've found my problem.

Dude goes "caching or not, that's pennies on the dollar; context size is context size."

I was like that's way off. Yes, context size matters, but I could have ~5-10x the context size and it cost the same if caching worked right. Dude didn't buy it.

Now I've set my Claude Code autocompact size to 300k to appease the gatekeeper (which I don't necessarily agree with) but am I wrong here in saying caching being broken is a BIG DEAL???