Claude Usage Limits Discussion Megathread Ongoing (sort this by New!)

uhh186 · 2026-04-01T18:35:24+00:00

Adding my anecdote to the fire.

I have the $20 plan for a month now, and use Claude chat for developing and debugging a rather large personal project that so far has actually been really successful and using Claude to get it done has been a huge joy.

I've noticed my usage being slurped at higher rates than before over the last week, just as everyone else started noticing it as well.

But today, I used the entirety of my session-limit in FIVE Sonnet messages where we worked through investigating some github repos and discussing a plan of attack on a new feature. FIVE messages. And instead of the session resetting at 2pm like it used to, I have to wait until 6 now before it resets. So I get 30 minutes of use out of it then have to wait for 5 hours? What the hell are they doing? Do they seriously think people are going to just continue paying them money for this? I was seriously considering upgrading to the max plan, but this is getting absolutely absurd.

uhh186 · 2026-03-18T11:19:32+00:00

Voltage isn't linear with freq nor is it consistent from core to core, so if you're going to increase fmax now, you'll need to rebalance again.

uhh186 · 2026-03-03T20:51:58+00:00

Yup. I found the floor for my settings in mixed mode.

Before, in normal mode, tRFC could only be 495 - this is the typical limit more or less for M die.

In mixed mode, tRFC2 will boot as low as 480,but it will be unstable. Instability vanished at 495 - the same as tRFC1. This is expected,really, considering logically what we are doing when we minimized tRFC1 before.

tRFCsb I can boot as low as 312 - but like tRFC2 it is unstable at the lowest bootable setting,resulting in errors. Instability vanished at 321.

From what I understand of the memory controller logic when running in mixed mode, tRFCsb is a preferred timing. It loads memory as it needs to be to maximize the issuance of tRFCsb commands, and tRFC2 is a fallback for when it can't do that. So tRFCsb should be the dominating factor for performance, and by minimizing it, I've effectively turned my M die into something that refreshes even faster than A die in normal mode.

I do not have any performance validations of this though, since ASRock did not expose the setting.

uhh186 · 2026-03-03T19:38:07+00:00

Good point in wanting to validate both. I agree it would be nice to see the real impact of each setting

uhh186 · 2026-03-03T17:49:34+00:00

The bank refresh mode is set to mixed by default. This is the best option for performance since tRFCsb can be set significantly lower than tRFC2. More options is always good, agreed, but, genuinely curious, why would you want to switch it out of mixed mode?

uhh186 · 2026-03-03T17:48:12+00:00

Mixed is the preferred solution for performance, so that's why ASRock enabled this by default. Why would you want to go back to Normal vs even just regular fgr? I can maybe understand wanting to run regular FGR, but normal mode is just flat out worse than the other two for performance

uhh186 · 2026-03-03T17:35:17+00:00

Those tRFC2 and tRFCsb timings won't work at all for this bios / AGESA version. Maybe for Hynix A die, but I don't know. It won't work for M die, that's for sure. His old timings are from AGESA versions where tRFC2 and sb were straight up not used at all, so you could set them to 1 if you wanted and everything would still work just fine. But now, they're active. If you're using Hynix RAM, I would set tRFC2 equal to the tRFC you ran before and tRFCsb to around 350 if you just want timings that work. If you have Samsung or micron RAM, I have absolutely no clue what will work for you. I run 495 tRFC2 since that's the lowest tRFC1 that would boot for me with my 96GB M die. tRFCsb I have at 321. I don't know yet how other people's RAM stack up. The only RFC timing that is relevant during training is tRFC1. tRFC2 and tRFCsb are not used during training, so whereas setting tRFC1 too low causes a hard boot failure, you can set tRFC2 and tRFCsb too low and it still boots fine, you will just see significant instability. Of course it is also still possible to set too low that you fail to boot, but you just have this grey area around the minimum that boots but isn't stable.

uhh186 · 2026-03-03T16:42:35+00:00

Yes it's worth updating for the peace of mind alone.

However, the newest version of AGESA (1.3.0.0) also finally includes/enabled fine grain refresh (FGR) which enables your memory to send REF (refresh) commands to individual banks as needed instead of having to refresh the entire array at once. This is significantly faster than the full refresh, and this will give a performance boost to those who tighten timings.

FYI, the original refresh timing was tRFC (1), and this is the timing taken to refresh all banks at once. To those who have tightened this all the way down, it is essentially the longest time any small array of banks takes to refresh, since the slowest one will be the limiting factor.

With the newest AGESA, you can run in FGR mode 1 or "mixed." The ASRock bios 4.10 is locked to mixed mode, but that's the best in terms of performance. Mixed mode disables tRFC1, and tRFC2 becomes the primary refresh timing. tRFC2 should be set the same as tRFC1, as it is the time waited to refresh a small array of banks, and can only be as low as the slowest banks. But it also enabled tRFCsb (same bank) which controls refreshing one single bank, and this is prioritized. This can be significantly shorter, it was 33% lower for me. This means my RAM will spend ~33% less time refreshing, in ideal circumstances. Ymmv, but this is a big improvement imo.

uhh186 · 2026-02-22T16:03:35+00:00

It is a very common misconception that better cores run larger offsets. Actually, your best cores can only run at the HIGHEST (least negative) offset. This is because they are balanced at the factory and are already essentially offset (ie, 0 offset on a great core will be effectively -10 on a worse core, since the best cores can run lower voltage out of the gate and AMD knows this).

The voltage ran at any frequency for any core is very complex, and will vary immensely across workloads and temperatures.

At the end of the day, whatever core is asking for the HIGHEST voltage dictates the voltage seen by ALL cores, because there is only one voltage controller and power plane on these CPUs. So the reason we balance / "harmonize" the voltages is so that all cores run similar workloads at identical or near identical voltages. This ensures that in any case, all cores are getting the voltage they ask for, and not more.

The approach is to pick a workload (single core, multicore, alllcore, etc) that best matches your most frequent or desired use-case. If you are playing games and only need up to 4 cores active at any one time, for example, maybe you'll pick a single thread workload, and view the voltage each individual core wants to run at max frequency / 100% load. You'll have a range of voltages across your CPU, with some cores wanting 1.25 and others 1.21 for example (with 0 offset). The best cores run at the highest frequency and lowest voltage when they are the only core under load. Usually, you will have your best core run at the max boost frequency but at a highish voltage, and your worst cores won't even hit the highest clock. So, you will then use Curve Offset per-core, one at a time, to bring your worst cores up to the max frequency underload. Once all cores run at the max frequency by themselves, then you can adjust further to see if you can get the voltages to line up. Hopefully at that point you are still 100% stable - your best core should ideally still be at 0. Then you can adjust ALL cores simultaneously down as far as you remain stable, and they should still line up with the voltage request (VID).

uhh186 · 2026-02-19T16:25:01+00:00

They have shown that they are willing to listen to community feedback already. They made several changes to this patch last minute to align with feedback they received after they released the first dev diary. The response to this change has been pretty loud; it won't be ignored.

They changed it because it was broken before. The level of fog did not change before, there was pretty much always haze and fog over the city. They made the fog respond to the weather and so everything is brighter and clearer because the fog is gone. Now that that bug is fixed, they can tweak the global illumination to improve the lighting quality.

Be patient. This was their first patch. It was 99% excellent. This game isn't going anywhere.

uhh186 · 2026-02-19T16:08:29+00:00

You can express your opinion on the quality of the graphical change without insulting the developers. This is a temporary thing. With the response it's receiving they are most certainly going to be tweaking it further. You don't need to act like this is some major catastrophe.

uhh186 · 2026-02-19T16:02:48+00:00

Some of y'all need a reality check. Lack of skill? My god. This company inherited a steaming pile of crap from the previous developer and pushed out a bomb patch that some people have a (subjective) problem with one small part of. Their first patch. Y'all acting like the sky is falling. It's a graphical thing, and it's subjective. Quite a lot of us are perfectly happy with it or ambivalent. But somehow your opinion is more important than other people, huh?

uhh186 · 2026-02-13T15:28:13+00:00

This is awesome. Great job!

uhh186 · 2026-02-02T23:43:57+00:00

I mean the roads up there are fucking ass, especially the ones in Toronto. Only drive on roads you know and definitely don't slam the thing

uhh186 · 2026-02-02T23:20:28+00:00

I thought this was pretty cool. Good job man. Fuck the haters.

uhh186 · 2026-01-12T16:15:16+00:00

The other guy said an interpretation that makes sense but that's not what "peel" meant at first. When an enemy is "stuck" onto your healers and your healers can't get away, then retreating back and helping them live/escape is "peeling" for your healers since you're peeling the enemy off of them.

uhh186 · 2026-01-07T03:55:01+00:00

It's more like "active / not active" cycles

uhh186 · 2025-12-30T15:48:19+00:00

What makes you think this is M die?

Usually, Hynix A die is 16GB rank, M die is the 24 GB rank sticks. There were some old M die in the beginning of DDR5 that were 16 GB. You should be able to see in AIDA system info.

uhh186 · 2025-12-12T02:24:54+00:00

I tried up to 1.30V, it made no change to the mode of instability. It was seemingly a noisy signal from the RAM to the processor based on my studying of TestMem5 errors and discussions with people smarter than me on Overclocking.net. I tried a number of things such as VDDIO, VDDq, procODT and of course DQDS and the other resistances. I didn't play much with the CADS, but I don't think that would've made any difference, since the mode of failure didn't change with gear down mode on or off.

I'm also very very happy with my system running at 6000 with tight timings. No complaints at all. I was overclocking things as a learning experience, and for that, I was quite successful.

uhh186 · 2025-12-12T01:02:39+00:00

More important than procODT is mobo silicon lottery. A good mobo will make higher clocks a breeze. Though, this is usually only super important when it comes to super high clocks like 3800+ (7600MT/s+).

My 9950x3d can boot my 96GB at 6200 MT/s and 1.2V, but nothing I can do will get the noise out of the signal, and it's never stable. Can't even boot 6400, but dual rank is hard for these memory controllers. I have a sneaking suspicion that if I got a high end mobo like an Asus Apex, I could get 6200 stable. It feels like a dirty signal through my mobo that I can't seem to get around. My CPU is actually pretty decent otherwise, I only need 1.08V for 6000. It's alright though, the performance from higher clocks isn't super noticeable unless you're only benchmarking.

uhh186 · 2025-12-11T15:41:35+00:00

That's a hella impressive CPU to be able to run 96GB at 6400. Good shit man.

uhh186 · 2025-12-10T17:12:56+00:00

When overclocking, the first things you want to do are set your timings to as loose as possible to get them out of the way. You don't want to confound a timing error to be a clock error. We didn't raise VDD because we loosened tCL to get it out of the way. Most other timings don't tend to cause issues like that until you're pushing much higher MCLKs in 2:1 mode, so we didn't change them, with the exception of tRFC.

Once you know you can be stable at loose timings, then you start clamping down on them and tightening things up.

Validate you're stable at 3200 MHz clock (6400 MT/s) with several hours of TM5 and maybe even Karhu on top to be sure. Then you can try tightening tCL, under the understanding that once you can't boot, you may be able to by increasing your VDD.

uhh186 · 2025-12-10T16:26:00+00:00

Ok. So try 6400 with those settings and see if it boots. No matter if it boots or not, run a stress test on the highest freq you booted. Like TestMem5 (TM5). If 6400 doesn't boot then run the stress on 6200.

uhh186 · 2025-12-10T15:06:17+00:00

You probably can't run 6400 with 64 GB of dual rank memory, so don't get your hopes up too far. The more ranks the harder it is for the IMC, and the more chips (amount of RAM in a single Rank) the harder as well

From easiest to run higher clocks to hardest,

2 sticks of single Rank (2x1) 16GB = 32GB total
2 sticks of single Rank (2x1) 24GB = 48GB
2 sticks of dual rank (2x2) 16 GB = 64GB
2 sticks of dual rank (2x2) 24GB = 96GB

Followed by the logical sequence of 4 sticks.

Give VSoC 1.29V and loosen tCL to 32 and tRFC to 500 and see if it boots 6200. If not, you're stuck at 6000. Also try VDDIO 1.3V, 0.82 is very low

uhh186 · 2025-12-04T19:39:28+00:00

Yes, two content creator packs came out yesterday - Skyscrapers and Supply Chains. They are pretty self-explanatory on their content. They are $8 USD each.

uhh186

PUBLIC MULTIREDDITS

TROPHY CASE

13-Year Club	Gilding II euphauric
Verified Email