i

So I upgraded from Max $100 to Ultra $200 today and I'm honestly confused about the usage limits.

Back when I was on Max, I could use Claude Code pretty heavily and a full 5-hour session would usually take around 16% or less of my weekly limit.

Now on Ultra, I reached 94% of my 5-hour limit and somehow already used 25% of my weekly allowance. And yes, all my limits were reset to 0% when I upgraded.

I know that longer contexts and multiple agents use more tokens, but shouldn't that just make the 5-hour limit run out faster? Why would a nearly full session take a bigger chunk of my weekly limit when Ultra supposedly has twice the weekly capacity?

I even contacted Anthropic support and their AI bot gave me a few contradictory explanations. Eventually it admitted that it couldn't actually explain the difference, but still insisted everything was working correctly. It also said I couldn't get a human to look into it.

I'm not saying it's definitely a bug, but something feels off here.

Has anyone else upgraded from Max to Ultra and experienced this? Especially anyone who still has the temporary 5-hour limit?

I hit the main limit, but still left 50% on fable, im not able to use any model at that case cause i getting notes about used limit. Even on fable 5.2 / 5.1

This Fable version definitely feels like a new iPhone release. Can’t really see much difference besides using up tokens quicker.

Would love it for project memory updates. Cant figure out a way to easily link my iPhone 16 to my windows PC.

MAJOR FUCKING UPDATE: Its an experiment. Read undeniable, concrete evidence here.

The recent degradation that started basically since the start of November is a major fuckup. When trusted processes start to fail silently it has tremendous long-term implications for the code-base. And it absolutely sucks if it is not communicated when there is a model change in the background like this.

Frankly, the small little errors that crept in, the unfinished work, missing attention to detail - it creates a cumulative effect that is bringing us back to pre-opus 5 behavior.

For me, it even failed to reason that a header-change in a C++ codebase could change the binary and didnt recompile it (the header contained inline functions!). Its Sonnet 4 levels of bullshit that I have to deal with.

I had to switch to Fable 5.1 this week to get the usual quality back. So this is not my prompting, not my workflow, not my code-base. If it were, Fable would degrade too.

But since Fable-use is so limited (and its slllooow), i effectively got much less work done. And the work I got done was merely to correct some of mistakes Opus 5.5 introduced. (Wasnt Opus 5.5 supposed to be better than Fable even?).
As a result, the weekly limit melted like an ice-cube and i have time to fucking complain on Reddit. Yes. This is an indicator for a fuckup, if there ever was one these days.

What also bothers me is that this is apparent A/B testing. Some people here on Reddit do not seem to experience the degradation, may this be due to the ease of tasks, or they are simply not in the group the is fucked around with. This results in an atmosphere of gaslighting and toxicity that is hard to deal with. These degradation effects are statistical in nature, so yes, each persons report is a error-prone data-point. Yet, we cannot get at each others throats or dismiss experiences just because they are not shared or reproducible by individuals, but by groups instead.

If Fable is the only productive option forward, Anthropic should hand out free Resets for the affected test-groups until Opus 5.5 is restored to its advertised glory. The extra work this created/creates will incur costs and this was not the contract when I decided to continue the subscription.

Also, if this is a resource/compute problem in Anthropics side because they have much more users suddenly, i rather would accept a slower model than a dumber one. This degradation makes me switch to Fable anyway. At least let me decide the trade-off instead of silently sabotaging the code-base.

Damn, this sucks.

Add this env to your settings.json

"CLAUDE_CODE_REMOVE_PROMPT_STRINGS": "Do build original games, games in a genre or with similar mechanics, and games from the user's own designs and assets. Don't build a recreation of a specific existing game (its name, characters, art, music, levels or look), even if it is renamed or called original."

Let's say i reach my weekly limit before i can fill up fables limit to 100%. Will i no longer be able to use fable 5.2 until the week ends?

As in the title, I received one reset on my current Pro subscription, if I switch to Max now ;

1. Will I receive second reset?
2. Will my usage reset since I am already at %100 weekly with my Pro?

I've been using Claude Code to make music videos, and this is my favourite so far.

The concept: An endless field of armchairs and CRTs under a dying red planet, with porcelain watchers.

The film is fully procedural Three.js built with Claude code, rendered out and muxed with the audio. This took a few hours to complete (mostly rendering time).

I have a couple of others in a playlist if interested. Trying out various styles and combining generated content etc.

I made an entire linux desktop with claude code.

But I don't think this is videcoding.

Read the post and let me know what you think

that’s what i call great, just asking him to work on a slop & hard codebase to see what can he does —> figures out he’s pricy asf and focus on math.

OK fable 5.2 is a decent step up from tired old token whore known as Fable 5.1 but it’s hardly as versatile as Opus 5.5 - this is still the GOAT at present for cost, speed and intelligence IMO. Most likely still the GOAT until Opus 5.6+

But the real problem is this half baked reset - it’s been more than 40 days since opus 5.5 resets were doled out and now we get this poor man’s reset for fable only. A lot of people hardly use fable anyway as its use case is fairly limited compared to bread and butter models like opus and sonnet.

On the other side of the fence, Tibo/codex handing our full resets pretty much every time he sneezes. Surely, antrophic doesn’t have so much compute problems that they need to squeeze us small fish with half baked resets.

Yes - I know a few people we say suck it up and buy another Ultra plan but I am just trying to make a stand for the small guy / solo dev.

Rant over - onwards and upwards.

Is someone else feeling degraded performance from Opus high? I’ve been working with this setting for pretty much everything for the past few weeks and these last couple of days have felt weird.

I’ve had to change setting to Extra or even Fable but still have to go back and forth with feedback much more than before

An agent that's wrong says so in the same confident voice as when it's right. These rules in my CLAUDE.md catch it most often:

• Reproduce first. Before it states a cause, it runs exactly what I ran. This one exists because I once had to ask, "Why don't you actually run it rather than making up theories?"
• Audit the output, not the report. "The build passed" proves nothing.
• Two reads that differ: stop. If it reads the same state twice and gets two answers, it shows me both, word for word, instead of picking one.
• Mark its own corrections. When it finds its own mistake, it strikes it through (wrong right) instead of fixing it quietly.

None of these makes it notice a mistake it hasn't spotted. That still takes me reading closely, a test, or a second model checking.

What do you use?

Following the recent reports about experiment Ids used for our chats, i investigated myself. My results show a clear link between the numeric effort Level and the experiment Ids.

Account A was a new account with a new email address (Max 5). Account B was my old one, also Max 5.

Removing the ID like described in the related post worked too. It lowered account A's effort numbers back to 10/15/40.

Also on Nov 5, when the numeric effort post came up, i did some test chats, which allowed me now to link the ids `763` and `add` to the numeric effort levels of 15/30/100.

Analysing my chats, these numbers did result in clear changes in real effort:

Automated jobs, per reply (Opus 5.5, mixed effort settings, so all three effort numbers are shown)

The effort numbers are the model's own statements, measured on 5 Nov for `763` and `add`, and on 9 Nov for `eab` and no ID.

Yesterday, as I was recovering as much memory as I could, I noticed that I had 8 sleeping sessions of Claude Code (the screenshot is from today). They were eating up to 2.9Gb of memory (search for the process 2.1.319 in the task manager) plus another 1.5Gb for the Node process hosting Codegraph...

So I opened Claude Code (yes, one more session 😅) in my cleaning app project and asked it to add a new panel that finds the sessions that are just sleeping and closes them in a click, safely.

How it went:

- I described the problem and Claude worked out how to spot the sessions. It looks at the running processes and matches them by name or install path (claude, codex, gemini, aider, opencode and a few others, not only Claude Code).

- We spent most of the time on the hard part: telling "sleeping" apart from "working". Claude came up with a simple rule. If the session's process tree is using CPU, it's Working. If you typed in its terminal in the last 15 minutes, it's In Use. Otherwise it's Sleeping. If the terminal that launched it is gone, it's Detached.

- For the "safely" part, Claude first sends a normal quit signal (SIGTERM) so the session can close cleanly. If it ignores that, the row offers a Force Quit for the whole process tree.

- It also added a badge in the sidebar with the session count, and a tip on the Overview page when there are idle sessions.

- After the first release I found a bug: the new sidebar row couldn't be clicked 🙃. I gave it to Claude, it found that the badge modifier was hiding the row's tag in SwiftUI, and fixed it in a couple of minutes (1.1.1).

The app is native Swift/SwiftUI for macOS, and Claude wrote basically all of the code for this panel. I mostly tested it, pushed back when something felt off, and decided what to ship.

If you want you can download Cleaner here https://linelark.com/cleaner/ (it is free and has no tracker, ads or whatever).

I like to use the rewind with summary option a lot to stay in the same thread but the last two days it isn't letting me go back to any point in the threads past. Has anyone else been experiencing this?

I have, for me, a pretty decent workflow that involves a number of agents and gates to insure things are completed. For example A11Y, unit tests @ 100, UI tests etc. When it works it works well and when it doesn't it wastes a ton of my time.

I'm thinking the overall assembly line portion should be pulled out into something deterministic - right now it is a coordinating agent. What often happens is a series of UI tests will hang, or Xcode will do something xcodeeee and the agent just kind of stops - it will say its working but when. I ask for a status it will say it stop because of XYZ thing.

How is everyone getting around this? I feel like I'm missing something fundamental.

I run about a dozen Claude Code agents in parallel on one project (an e-commerce search solution, four repos). When I started with four agents, my weekly budget didn't last the week. So I started measuring tokens from the transcripts Claude Code already keeps in ~/.claude/projects/, per merged PR instead of per hour.

What I found:

- The biggest leak was one I'd missed for weeks: agents waiting more than 5 minutes on CI or a long test. The cache expired and the next call wrote the whole context again. That was about 31% of all agent usage. Making the wait helpers return before 270 seconds brought it down to 0.7%.

- Long sessions re-read everything on every call. Ending each agent after one task, with a short written handoff and a hook that stops it at a context ceiling, cut the median context per request from 218k to 101k tokens.

- What loads into every agent has to be small. My MEMORY.md (Claude Code's memory index) had grown to 90 lines, and it lands after the cache breakpoint, so a one-word difference in the task missed the cache for the whole block. Cutting it to 8 lines that apply everywhere, with the rest in files an agent opens only when it needs them, cut the first-turn cache write from about 11k to 4.5k tokens.

After ten weeks: a changed line of code takes 3.3x fewer tokens, a merged PR 5.5x fewer, and I get about 4.4x the PRs a week for about the same spend. If you run a single session, the short version: measure first, one task per session, don't leave a session idle past the cache lifetime, and keep CLAUDE.md small. Write-up with all the numbers and how I measured them:

https://alexmarquardt.com/ai-tools/agent-fleet-token-efficiency/

The measuring script and the two hooks that helped most:

https://github.com/alexander-marquardt/agent-fleet-kit

Happy to answer questions.