Independent corroboration: 179K API calls confirm cache_read weight change is the dominant factor

[seanGSISG]

quota-composition-breakdown.mjs.md
cache-read-weight-transition.mjs.md
dual-window-simulation.mjs.md
thinking-token-estimation.mjs.md
rates.json.md
tool-use-deep-dive.mjs.md

Independent corroboration of dual-window findings with 179K API calls (Dec 2025 - Apr 2026)

Your rate-limit header analysis in 02_RATELIMIT-HEADERS.md identified the dual sliding window system and measured per-1% utilization costs. You noted a key limitation: "No before-data. Proxy started April 4."

We have before-data. 178,009 API calls across 5,605 session files from a Max 20x ($200/mo) account, spanning Dec 23, 2025 to April 11, 2026. We built four analysis scripts to validate your findings against the full transition period.

Your benchmarks hold up

Our CacheRead per estimated 1% utilization: 1.62M-1.72M tokens. Your range: 1.5M-2.1M. Dead center.

Our cache_read share of visible tokens: 89.8-95.2% across months. Your measurement: 96-99%. Close match. The slight gap likely comes from our higher cache_write share in months with more cold starts.

The cache_read weight change is the whole story

We computed daily quota under two formulas: the old (cache_read = 0x) and the new (cache_read = 1x).

Month	Quota (0x)	Quota (1x)	Multiplier
Feb	219.1M	2,153.6M	9.8x
Mar	394.2M	4,838.0M	12.3x
Apr	150.1M	2,200.9M	14.7x

The multiplier is 10-15x on every single day since December 2025. Cache_read has always been 90-95% of visible token volume. The ratio doesn't jump at a transition date. What changed is whether the quota system applies that weight.

Under the old formula, our maximum quota consumption in any 5-hour window across the entire dataset was 21.2M tokens, or 11.8% of the budget. We would never have been rate-limited. Not in any month.

5-hour window simulation confirms the transition

We bucketed all calls into 5-hour tumbling windows using your midpoint (100% = ~180M visible tokens):

Month	Windows	Avg Util	Max Util	>80%	>100%
Feb	70	17.0%	57.4%	0	0
Mar	103	27.0%	123.9%	7	1
Apr	47	23.1%	156.1%	1	1

February: zero windows exceeded 80%. March: seven crossed 80%, one crossed 100%. That lines up with when we first hit rate limits.

Under 0x weight, every one of those windows was fine. The March window that crossed 100% had a quota(0x) of just 15.3M, or 8.5%.

The thinking token "blind spot" is not a blind spot

You flagged thinking tokens as a major unknown. We can measure them because our JSONL logs contain the actual content blocks.

Thinking blocks appear in 1.9-36.7% of calls. Average size: 112-664 characters (~28-166 tokens). Quota impact:

Month	Gap Tokens	Gap * 5x Weight	% of Total Quota
Feb	0.01M	0.03M	0.0%
Mar	0.06M	0.29M	0.0%
Apr	0.49M	2.44M	0.1%

Thinking tokens contribute 0.0-0.1% of total quota. The real hidden output comes from server-side iterations (a usage field that grew from 7.7% of calls in Feb to 52.4% in Apr, each producing 60x more output tokens). We documented this separately in anthropics/claude-code#45756.

@fgrosswig's 64x reduction in our data

Our heaviest pre-transition day (March 21): 356.2M visible tokens, quota(0x) = 27.4M, quota(1x) = 359.0M. A 13.1x multiplier. On peak days the multiplier reaches 18.9x to 31.0x.

A 64x multiplier requires cache_read at ~98.4% of visible tokens. You measured 96-99%. The numbers fit. Accounts with higher R:W ratios (less cache_write from cold starts) would see multipliers closer to 64x.

Counterfactual

Month	Active Days	Days > 180M quota(0x)	Days > 180M quota(1x)
Feb	26	0	1
Mar	31	0	11
Apr	11	0	6

Zero days exceed budget under the old formula. Eighteen exceed it under the new formula.

Scripts

All four scripts read the same 5,605 session files. They're in our analysis repo if you want to cross-reference:

• quota-composition-breakdown.mjs - Token composition under 0x vs 1x weight, ArkNill benchmark comparison
• cache-read-weight-transition.mjs - Daily/weekly quota under both regimes, transition detection, counterfactual
• dual-window-simulation.mjs - 5h tumbling window simulation, utilization distributions, 7d rolling peaks
• thinking-token-estimation.mjs - Thinking block prevalence, output gap analysis, blind spot cross-reference

Dataset: 178,009 non-synthetic API calls, 5,605 session files, Dec 23, 2025 to Apr 11, 2026, Max 20x ($200/mo), two machines (Linux workstation + Windows laptop).

[ArkNill]

First of all, thank you for taking the time to bring this here. Getting independent corroboration from a 179K-call dataset spanning 5 months is not something I expected — and the fact that you came to this repo to share it rather than just posting elsewhere means a lot. Seriously, this is the kind of contribution that makes open research worth doing.

I went through all six scripts you attached. The level of effort here is clear — these aren't quick throwaway analyses, and I want to make sure that effort gets the response it deserves.

Your data fills my biggest gap

My proxy started April 4, so I had no March baseline — that was the single biggest limitation in my analysis, and I said so explicitly in Section 6 of 02_RATELIMIT-HEADERS.md. Your Dec 2025 – Apr 2026 dataset resolves this completely. The counterfactual showing zero days exceeding budget under the 0x formula across the entire period, while 18 days exceed under 1x — that's a powerful result I couldn't have produced on my own. Thank you for filling this gap.

I'll update the document to note this limitation as resolved, with a cross-reference to this issue.

The numbers converge

Your CacheRead per estimated 1% (1.62-1.72M) landing inside my range (1.5-2.1M) from a completely independent dataset — different account, different geography, different time period — is exactly the kind of convergence that builds confidence in both measurements. It's reassuring to see this hold up across such different conditions.

One small note on the cache_read share comparison: your 89.8-95.2% and my 96-99% are measuring slightly different things (yours is a monthly average including cold starts, mine is per-1% within active windows), which explains the gap. Not a discrepancy — just different lenses on the same phenomenon.

Script feedback

Since you took the time to share the scripts, I wanted to give them a proper read rather than just skimming. A few observations that might help if you're iterating on these:

dual-window-simulation.mjs — The simulation uses tumbling (non-overlapping) windows, but the actual system uses sliding windows. This means peak utilization at window boundaries gets split across two buckets, which would systematically underestimate the worst-case spikes. Also, there may be an edge case with callIdx at window boundaries — calls that straddle the boundary could be skipped since callIdx advances past them in the inner loop without resetting. Your results would likely be even stronger with a sliding window implementation.

cache-read-weight-transition.mjs — The ratio analysis and the counterfactual analysis are testing the same hypothesis from different angles, but I think the counterfactual is the stronger evidence — it directly shows "budget breaks under 1x, never under 0x" without needing to pinpoint a transition date. Might be worth leading with that framing if you present this elsewhere.

thinking-token-estimation.mjs — I appreciate that you acknowledged the 4-chars/token and 80-tokens-per-tool_use heuristics as rough estimates. The decision rule you propose (gap <20% = separate, gap >50% = included) is a useful framework. Curious whether tightening the tool_use estimate (they vary enormously — a simple Read might be 20 tokens, a large Edit could be 500+) would change the gap distribution meaningfully.

Thank you for being transparent about the limitations in your own scripts — that kind of intellectual honesty makes the findings more trustworthy, not less.

Thinking tokens — your data moves the needle

I've been calling this a "blind spot" because the API doesn't return thinking token counts. Your JSONL-based measurement is the first concrete data point anyone has brought to this question, and I'm grateful you dug into it. I'll update the framing from "blind spot" to "partially measured" in the next revision.

That said, I'm curious about the iterations field growth (7.7% → 52.4% of calls, 60x more output per iteration) from your tool-use-deep-dive.mjs. If iterations represent server-side computation overhead, they could be a much larger factor than the content block text suggests. Have you looked at whether iterations correlate with the quota jumps in your 5h window simulation?

On the dominant factor

Your data makes a strong case that the cache_read weight change is the primary driver — no argument there. I'd just add that client-side cache bugs (the ones @cnighswonger's interceptor fixes) and server-side context management mechanisms compound on top of this, affecting some users more than others depending on their usage patterns. Your dataset captures the macro picture really well; these other factors show up more at the per-session level.

Next steps

I'll update the analysis repo to credit your work and cross-reference this issue. Your contribution deserves proper attribution. Would you be open to linking your scripts directly here (or in a separate repo) so others can reproduce against their own data?

I genuinely appreciate what you've done here. This kind of independent, rigorous cross-validation is rare in community-driven research, and it strengthens the entire investigation. Thank you.

[seanGSISG]

Scripts v2 is up — https://github.com/seanGSISG/claude-code-hidden-problem-analysis/tree/main/scripts — with the three fixes landed, your iterations question answered, and (new since I started drafting this) a first-pass test against 16_OPUS-47-ADVISORY.md on our own data.

Opus 4.7 vs 4.6 on our JSONL

My logs caught up further than I expected. The 215K-call dataset now runs through Apr 21 and includes 2,615 Opus 4.7 calls across Apr 16–21. Script: opus-47-comparison.mjs. Sample output is in sample-output/opus-47-comparison.out.

4.6 comparison window: Apr 2–15 (same user, 14 days pre-launch, 32,299 calls on claude-opus-4-6). Fair-span as I can manage this early.

Per-call averages:

Metric	4.6	4.7	4.7 / 4.6
Avg input tokens	40	4	0.10x ← flagged, see below
Avg output tokens	413	1,079	2.61x
Avg cache_read tokens	103,632	124,086	1.20x
Avg cache_create tokens	5,046	6,894	1.37x
Iter-call share	57.9%	78.8%	+20.9 pp
Iter-output share	98.5%	99.9%	+1.4 pp
Quota per call (1x)	110,782	136,380	1.23x

5h sliding window utilization (Apr 2–21, dominant-model labeling):

Dominant model	Windows	Mean util	p90 util	p99 util	Max util
4.6	963	45.8%	132.1%	574.6%	630.6%
4.7	174	19.8%	59.1%	104.1%	110.8%

How I read this against the advisory

Output tokens 2.61x per call — strongly consistent with your adaptive-thinking-heavier claim. Mean per-call output more than doubled. Iter-call share jumping 20 pp in the same direction (57.9% → 78.8%) is what I'd expect if adaptive is routing more work through iter-bearing responses.

Cache_read 1.20x per call — lands in the middle of the 1.0–1.35x tokenizer-inflation range you documented. Directionally supports the tokenizer hypothesis.

Quota/call is only 1.23x — here's the twist. Since cache_read is ~95% of visible tokens, its modest 1.20x ratio mostly determines the per-call quota multiplier. Output going 2.61x only moves the per-call quota a fraction because output is <1% of tokens by mass. So at per-call granularity, my data supports tokenizer inflation but doesn't reproduce the full 2.4x averaged Q5h burn number — at least not as a per-call effect.

Section 4 (window comparison) runs the wrong way — 4.7 mean util is lower than 4.6 (19.8% vs 45.8%, 0.43x). I don't think this contradicts the advisory; I think it's sample bias. My 4.6 comparison span had several of my heaviest coding days (Apr 5 = 7,392 calls, Apr 10 = 8,099, Apr 11 = 5,620) while my 4.7 window (Apr 16–21) was a migration period with lighter use (peak was Apr 21 = 1,130 calls on 4.7). With n=174 windows on the 4.7 side and workload mix not matched, the 5h comparison is directional only. I wouldn't publish the "4.7 Q5h is higher" claim from this dataset yet — I'd want a fair-workload comparison, probably from users who moved to 4.7 and kept the same kinds of sessions.

Anomaly: avg input tokens 40 → 4 on 4.7. Suspicious enough that I'm flagging it explicitly. Two candidate explanations: (1) 4.7 caches more aggressively, routing what used to count as input_tokens into cache_read/cache_create (cache_create did rise 1.37x); (2) the usage field semantics changed. Someone with proxy access to a 4.7 API response could disambiguate this in minutes; I can't from JSONL alone.

What landed from your review

• dual-window-simulation.mjs — sliding primary (15-min step, two-pointer sweep), tumbling retained. Peak 5h utilization under sliding: Feb 76.7%, Mar 140.9%, Apr 195.7% (vs tumbling 57.4%, 123.9%, 156.1%). As you predicted, the story strengthens.
• cache-read-weight-transition.mjs — counterfactual leads. Section 1 is now the "0 days under 0x, 18 under 1x" table.
• thinking-token-estimation.mjs — per-block tool_use estimate replaces fixed 80. Across 111,415 blocks: mean=171, p50=44, p90=221, p99=3041, max=23796. Old 80 was a poor fit for both tails. Sensitivity column added; gap verdict mostly stable, Feb/Dec numbers more sensitive than I'd expected, so I treat the gap as directional rather than load-bearing.

Iterations ↔ 5h quota jumps (your open question)

Util bucket	Windows	Mean iter_output_fraction
0–25%	3,850	51.6%
25–50%	1,346	51.9%
50–80%	552	65.7%
80–100%	137	81.0%
100%+	96	84.8%

30.9 pp gap between low-util and high-util buckets. Top-10 sliding peaks since March all sit at 96–99% iter output share; the one January peak in that top-10 is 0% (pre-iterations-prevalence). Within-month Pearson r is modest (Feb 0.22, Mar 0.04, Apr 0.23) because iter base-rate saturates inside a single recent month. The signal lives in the secular trend: 7.7% → 52.4% of calls across Feb–Apr. Iterations don't cause peaks by themselves but ride on top of almost every post-March one. Compounding with the cache_read weight change, not competing.

Compounding factors

Agreed on client-side cache bugs and server-side context management — nothing in the macro data disputes that. If your proxy has per-request timestamps, diffing cnighswonger-pattern events against the 5h windows where my data shows peaks might let the two views validate each other. Happy to coordinate on that whenever useful.

Thanks for the crediting commit and the framing updates in 02_RATELIMIT-HEADERS.md and the contributors table — I saw them. Glad the before-data and thinking-token sections could be tightened.

[seanGSISG]

Correction on my last comment — the per-call multipliers I posted are confounded and shouldn't be read as 4.7 evidence.

Someone asked me offline whether a proxy-layer change could explain the input=40 → 4 anomaly. It can't — but checking that prompted me to look at the daily breakdown on 4.6, and the aggregates I posted turn out to be workload-variance artifacts, not model effects.

The daily picture on 4.6 alone:

Date	Model	Calls	Avg input	Avg output	Avg cache_read
Apr 5	4.6	5,886	80	181	67,639
Apr 8	4.6	3,794	93	367	114,031
Apr 10	4.6	6,287	14	354	74,296
Apr 11	4.6	4,793	6	948	233,210
Apr 13	4.6	115	2	729	41,384
Apr 15	4.6	156	7	995	53,459
Apr 16	4.7	97	3	1,518	81,008
Apr 19	4.7	424	3	871	71,994
Apr 20	4.7	964	5	1,177	103,143
Apr 21	4.7	1,130	4	1,036	165,196

Per-call input on 4.6 varies 2 to 93 tokens within a single comparison window. The "avg input 40" on 4.6 was pulled up by Apr 5/8. By Apr 10–15 (the 4.6 tail closest to the 4.7 cutover), avg input was already 2–14 tokens — continuous with 4.7's 3–5. So 0.10x input is an averaging artifact, not a tokenizer or proxy effect.

The same confounding applies to the other numbers. Avg output on 4.6 ranged from 181 (Apr 5) to 995 (Apr 15). Avg cache_read ranged from 41K (Apr 13) to 233K (Apr 11). Picking different slices of the 4.6 window gives wildly different "4.7 vs 4.6" multipliers. The aggregate I reported happens to place 4.6 in the middle of that spread, which is not a strong claim.

What I can and cannot say from this dataset:

• Cannot say: whether tokenizer inflation (1.0–1.35x) or the 2.4x Q5h-burn claim is corroborated at per-call granularity. Sample is too small and workload-mix between spans is too different.
• Can say: 4.6 and 4.7 tail days both show a low-input, cache_read-dominated profile. And iter-call share differs between spans (57.9% on the 4.6 comparison vs 78.8% on 4.7) — but even that could be workload-driven rather than model-driven.

What would actually test the advisory:

A workload-matched comparison — same task, same context, run on both 4.6 and 4.7 back-to-back, with the usage objects captured. Probably more useful from your benchmark setup than from my session-log-based observational data. My script (opus-47-comparison.mjs) has been updated to include the daily breakdowns for both models and explicit warnings in Key Findings, so the raw numbers are still visible but the interpretation is now honest about what it can't distinguish.

Sorry for the over-reading. Everything else in my prior comment (scripts v2, iterations correlation, the 179K counterfactual) stands — the 4.7 claims don't.

Updated script and output: https://github.com/seanGSISG/claude-code-hidden-problem-analysis/blob/main/scripts/opus-47-comparison.mjs · sample-output

[cnighswonger]

@seanGSISG — we ran your scripts against our dataset (101,506 calls, Jan–Apr 2026, Max 5x) and the results corroborate your findings with even higher multipliers.

Quota explosion (your script, our data):

Month	Quota (0x)	Quota (1x)	Multiplier
Jan	1.54M	36.88M	23.9x
Feb	30.92M	428.23M	13.8x
Mar	291.85M	8,178.85M	28.0x
Apr	307.09M	11,843.36M	38.6x

CacheRead per estimated 1% utilization:

Month	Our data	Your range	ArkNill range
Jan	1.73M	—	1.5–2.1M
Feb	1.67M	1.62–1.72M	1.5–2.1M
Mar	1.74M	1.62–1.72M	1.5–2.1M
Apr	1.77M	1.62–1.72M	1.5–2.1M

Three independent datasets, same range.

5-hour window simulation (your script, our data):

Month	Windows	>80%	>100%	Max Util	Max Util (0x)
Feb	75	0	0	16.3%	1.2%
Mar	111	19	17	392.0%	10.9%
Apr	98	33	21	284.9%	25.8%

Our heaviest window (Mar 25, 1,550 calls): 392% under 1x weight vs 10.9% under 0x. A 36x multiplier on a single 5-hour window.

Our multipliers are higher than yours because we run multi-agent sessions with sustained high cache-read ratios (97–99%). The pattern is identical: zero rate-limit events before the weight change, dozens after.

One data point you don't have: We have January 2026 data (474 calls). Under the old formula, the heaviest window was 1.2% of budget. Under the new formula: 13.8%. Even low-volume months show a >20x multiplier.

Your scripts, our data, same conclusion. Thanks for publishing the methodology — reproducible analysis across independent datasets is how this gets taken seriously.

[ArkNill]

Three datasets, one answer

@seanGSISG @cnighswonger — I saw these last night but wanted to cross-check against my own proxy data before responding — glad I did, because a few new numbers came out of it. Quick update from my side first: proxy dataset is at 45,884 requests now (31,535 Opus, 10,067 Haiku, 320 sessions). Model substitution check grew from the published 36,956 to 41,306 — still zero mismatches.

One thing I hadn't looked at before — Q5h vs Q7d utilization shapes from ratelimit headers. Neither of you have these from JSONL, so here's what Max 20x looks like from the header side:

Q5h utilization (Opus, 27,802 requests with headers):

Q5h bucket	Calls	% of total	Avg cache_read
0–25%	18,267	65.9%	152,695
25–50%	7,711	27.8%	165,030
50–80%	1,655	6.0%	129,876
80–100%	169	0.6%	113,976
100%+	0	0.0%	—

Q7d utilization (Opus, 27,835 requests with headers):

Q7d bucket	Calls	% of total	Avg cache_read
0–25%	6,804	24.5%	144,713
25–50%	7,677	27.7%	138,431
50–80%	9,598	34.5%	159,330
80–100%	3,756	13.5%	193,474

Two things jump out. First, Q5h on Max 20x almost never touches the ceiling — 0.6% in 80–100%, zero above 100%. Compare that to cnighswonger's Max 5x: 33 windows >80%, 21 >100% in April alone. Same cache patterns, different budget headroom. Second, Q7d tells a completely different story — 13.5% in 80–100% vs Q5h's 0.6%. The 7-day window accumulates pressure that the 5-hour window resets away. For sustained heavy users, Q7d is the binding constraint, not Q5h.

Also — saw the crediting commit acknowledgment. Glad the framing updates and contributors table landed well.

Now, to your work.

Scripts v2

The sliding window fix was the one I was most curious about. Tumbling splits peaks at boundaries — I flagged this on 4/15 suspecting the real numbers were higher. They are. Mar 123.9% → 140.9%, Apr 156.1% → 195.7% under sliding. The 15-min step sweep is much closer to how the headers actually behave. Good call implementing both so the comparison is visible.

Moving the counterfactual to Section 1 was smart. "Zero days exceed budget under 0x, 18 under 1x" — that's the whole argument in one line. Everything else supports it.

The tool_use rewrite (mean=171, p50=44, p99=3,041, max=23,796) is a big improvement. Fixed 80 clearly didn't capture the distribution — tiny reads at the median, huge edits at the tail. Makes sense for CC's tool mix. The gap verdict holding up under better estimates is reassuring, even with Feb/Dec getting more sensitive.

Iterations — agreed, compounding not competing

30.9pp gap between low-util and high-util buckets says it clearly. Within-month Pearson r is weak (0.04–0.23) because the iter base-rate saturates month-to-month, but the secular trend (7.7% → 52.4% of calls Feb–Apr) is unmistakable. Top-10 sliding peaks all at 96–99% iter share, except the one January outlier at 0% — that's a clean before/after signal.

This answers what I asked on 4/15. Iterations amplify the cache_read weight change. They don't create a separate problem.

The 4.7 self-correction

I want to call this out specifically because it matters. You posted a detailed 4.7 vs 4.6 comparison, noticed the numbers were off, and corrected yourself 11 minutes later — showing the per-call aggregates were confounded by workload variance within the 4.6 window alone. Avg input swinging 2 to 93, avg output 181 to 995 on the same model. That kills the aggregate comparison. The updated script with daily breakdowns and explicit warnings is the right way to handle it.

This is exactly how open analysis should work. The retraction is clean, what stands is clearly separated (scripts v2, iterations, counterfactual), and the data is better for it. Respect.

On whether a workload-matched 4.7 test is worth running: my proxy could do it (same task, same context, 4.6 vs 4.7 back-to-back). But I keep coming back to the same conclusion — 4.7's cost comes from invisible adaptive thinking tokens, tokenizer inflation (~35%, documented in this repo's Opus 4.7 advisory), and server-side metering changes. Whether these are deliberate pricing moves or side effects of model evolution, the practical result is the same: not something we can patch from the client side. DISABLE_ADAPTIVE_THINKING reduces the burn (cnighswonger measured 3.3x), but you're trading away the reasoning depth that's supposed to be 4.7's value proposition.

A precise "2.4x vs 1.8x" probably won't change that structural picture. Though if someone needs it for plan economics or comparing CC against alternatives, a clean measurement would be useful — just not where I'm spending time right now.

@cnighswonger — the 101K validation

This is what turns individual findings into something people can trust. You took seanGSISG's scripts, ran them on a completely different dataset, and got convergent numbers. That's the bar.

CacheRead per estimated 1% utilization:

Source	Dataset	Plan	Jan	Feb	Mar	Apr
ArkNill	45.8K calls (per-1% from 23.3K with headers, Apr 4–14 window)	Max 20x	—	—	—	1.5–2.1M
seanGSISG	215K calls, JSONL	Max 20x	—	1.62–1.72M	1.62–1.72M	1.62–1.72M
cnighswonger	101K calls, interceptor	Max 5x	1.73M	1.67M	1.74M	1.77M

Different accounts, different tiers (5x vs 20x), different geographies (US, Asia), different methods (proxy, JSONL, interceptor). The ranges overlap: 1.5–2.1M per 1% of Q5h.

Honesty note on my own range: 1.5–2.1M is wider than yours because I computed it per-window across fewer windows in an April-only dataset (02_RATELIMIT-HEADERS.md §3 for methodology). Your script-based estimates are tighter. The fact that both of your narrower ranges (1.62–1.77M) land inside mine is the convergence — your precision sharpens my initial estimate.

Quota multiplier (0x vs 1x):

Source	Jan	Feb	Mar	Apr
ArkNill	—	—	—	32.9x
seanGSISG	—	9.8x	12.3x	14.7x
cnighswonger	23.9x	13.8x	28.0x	38.6x

I can now compute April: total visible 5.22B / visible-without-cache_read 159M = 32.9x. Falls between seanGSISG's 14.7x (monthly average including lighter days) and cnighswonger's 38.6x (multi-agent sessions at 97–99% cache-read ratios). What I can't show is the transition — my proxy started April 4, so there's no pre-weight-change baseline to demonstrate the before/after. That part of the story is entirely yours and seanGSISG's.

That single-window peak — 392% on Mar 25, 1,550 calls, 36x multiplier vs the old formula — is the most striking number in this entire investigation.

And the January data is yours alone. 474 calls, >20x multiplier at minimal volume. Nobody else has anything before February. That strongly weakens the "only matters at scale" argument — the weight change hits everyone regardless of usage level.

Proxy timestamp coordination

@seanGSISG — on your suggestion to diff cnighswonger-pattern events against the 5h windows where your data peaks. I'd be up for that. My proxy has per-request timestamps paired with Q5h/Q7d utilization from the response headers, which is a different angle than either of your JSONL views.

I can share aggregated and derived data — per-window summaries, distribution tables, the same kind of output that's already in the published analysis docs. The raw request-level captures I'd keep private for now (per-session token breakdowns and request sequencing that are part of work I'm still running). But if you scope out what comparison you want, I'll produce the matching view from my side.

Next steps

Updating the repo to reflect all of this:

• 02_RATELIMIT-HEADERS.md — cross-reference this issue, mark the before-data gap as resolved
• README.md — adding cnighswonger to the contributors table (seanGSISG is already there)
• A cross-validation document pulling the three datasets together with methodology notes

Thank you both — seriously. The counterfactual proof, the January baseline, the iterations analysis, the sliding window upgrade, and the honest self-correction on 4.7. This investigation is materially stronger because you showed up with data and held yourselves to a standard. I appreciate it.

[cnighswonger]

Live data point on Q7d as the binding constraint.

We just hit allowed_warning on Q7d after 2+ days of sustained multi-agent work (4 agents, Max 5x). New headers appeared:

anthropic-ratelimit-unified-7d-status: allowed_warning
anthropic-ratelimit-unified-7d-surpassed-threshold: 0.75
anthropic-ratelimit-unified-7d-utilization: 0.76
anthropic-ratelimit-unified-representative-claim: seven_day

Note the representative-claim shifted from five_hour to seven_day — the API is now telling us the 7-day window is the binding constraint, confirming your observation that Q7d accumulates pressure Q5h resets away.

Q5h at the same moment: 36% (comfortable). The 5-hour budget isn't the problem. The 7-day budget is — exactly as your header analysis predicted.

First time we've seen surpassed-threshold and upgrade-paths headers in the wild:

anthropic-ratelimit-unified-upgrade-paths: upgrade_plan,overage

They're suggesting we upgrade or enable overage. On a Max 5x plan at 76% of the 7-day window.

[ArkNill]

@cnighswonger — that representative-claim flipping from five_hour to seven_day is the cleanest confirmation possible. My distribution tables showed Q7d was the pressure point, but that was inference from utilization buckets — yours is the API explicitly saying "this is the window that matters now." Different class of evidence.

The 75% threshold triggering upgrade-paths is interesting too. I need to go back through my headers and check whether these show up on Max 20x at the same threshold — my Q7d hit 80–100% on 13.5% of calls, so they might already be in the data and I just wasn't looking for them. Will report back.

@seanGSISG — picking up on cnighswonger's Q7d data above: your 215K-call dataset is the longest time-series any of us have (Dec–Apr). That makes it uniquely suited for 7-day window analysis. My proxy only goes back to April 4, cnighswonger's to January — but yours covers the full pre/post transition period at monthly granularity.

Question: does your JSONL capture rate-limit headers, or just token counts? If it's token-only, you could still reconstruct 7-day rolling windows from timestamps + weighted usage — and with 5 months of data, you'd have enough windows to see whether Q7d pressure builds differently across the transition. Nobody else can produce that view right now.

Separately — I went through your repos and recent activity after your work here. You're running DGX Spark with vLLM and doing inference benchmarks alongside all this API analysis. I'm on a similar setup — 2× Spark with Qwen 3.5/3.6 dual vLLM + MTP, plus an RTX 5090 for local inference baseline. Would be good to compare notes sometime — nillwithk@gmail.com if you want to take anything off-thread.

[seanGSISG]

@seanGSISG — picking up on cnighswonger's Q7d data above: your 215K-call dataset is the longest time-series any of us have (Dec–Apr). That makes it uniquely suited for 7-day window analysis. My proxy only goes back to April 4, cnighswonger's to January — but yours covers the full pre/post transition period at monthly granularity.

Question: does your JSONL capture rate-limit headers, or just token counts? If it's token-only, you could still reconstruct 7-day rolling windows from timestamps + weighted usage — and with 5 months of data, you'd have enough windows to see whether Q7d pressure builds differently across the transition. Nobody else can produce that view right now.

@ArkNill Hey It's been a busy week for me just now catching up. I can review and get back to you by this weekend.

By the way, just realized I have over a GB worth of logs from January and Feb on my old work computer. Ill grab those.

Separately — I went through your repos and recent activity after your work here. You're running DGX Spark with vLLM and doing inference benchmarks alongside all this API analysis. I'm on a similar setup — 2× Spark with Qwen 3.5/3.6 dual vLLM + MTP, plus an RTX 5090 for local inference baseline. Would be good to compare notes sometime — nillwithk@gmail.com if you want to take anything off-thread.

That's awesome! I only have the x1 Spark and kind of glad I didn't do a 2nd with the state of NVFP4 support (but apparently this may have been fixed just recently?)

I also have a GMKtec EVO-X2 AI Mini PC AMD Ryzen AI Max+ 395 with 128GB, ROCm is finally starting to get somewhat mature.

I too have a 5090 and for inferencing its just so much better, I almost want to sell the DGX and EVO-X2 and just get an RTX Pro 6000 like I should have in the beginning 🤦‍♂️

[cnighswonger]

I also have a GMKtec EVO-X2 AI Mini PC AMD Ryzen AI Max+ 395 with 128GB, ROCm is finally starting to get somewhat mature.

I too have a 5090 and for inferencing its just so much better, I almost want to sell the DGX and EVO-X2 and just get an RTX Pro 6000 like I should have in the beginning 🤦‍♂️

I'm a bit behind the curve hardware-wise. I'm just putting together a MAG B650 w/AMD Ryzen 7700x 64GB with a 3090 FTW3 24GB (w/EK-Quantum Vector FTW3 and friends). Trying to get it put together and running this week, but we'll see.

[ArkNill]

@seanGSISG — On the hardware regret, I feel you. I'm on 2× DGX Spark + 5090 + ZBook Ultra (same Ryzen AI Max+ 395 as your EVO-X2) and honestly I should've just bought a workstation with dual RTX Pro 6000s from the start. Lesson learned ;)

By the way, since you have the EVO-X2 with Strix Halo — I'd seriously recommend skipping ROCm and going Vulkan + llama.cpp instead. I spent way too long trying to get ROCm working properly on gfx1151 and it was just pain — driver issues, PyTorch barely functional, and even when it "worked" it barely hit ~25% of theoretical memory bandwidth. Vulkan through Mesa RADV gets 70-73% out of the box with zero hassle. Completely different experience.

I've been running LFM2-24B-A2B (Liquid AI's sparse MoE, 24B total but only 2B active per token) on my ZBook at Q8_0 and it does about ~72 tok/s — which actually beats my DGX Spark running Qwen3.5 with MTP (~65). One thing to watch out for though: AMD caps the BIOS GPU memory allocation at 96GB even on 128GB systems, so you can't just throw all the memory at the GPU. I run mine at a 64/64 split and Q8_0 at ~32GB fits easily.

Setup is straightforward — build llama.cpp with -DGGML_VULKAN=ON, grab LFM2-24B-A2B-Q8_0.gguf from LiquidAI/LFM2-24B-A2B-GGUF on HuggingFace, run it with llama-server --device Vulkan0 -ngl 99. No ROCm stack needed at all.