Four checks on whether a datacenter lease shows up in my own usage data

I assumed a compute deal signed in Tennessee was measurable in my own Claude Code usage. Below are the four checks I ran against my own telemetry, and the result: the assumption does not survive any of them.

The claim being tested

On 6 May 2026 xAI granted Anthropic exclusive access to all of Colossus 1 near Memphis — more than 220,000 Nvidia GPUs (H100, H200, GB200) and 300 MW. The price became public on 20 May in SpaceX's S-1 filing: $1.25 billion a month through May 2029, terminable by either side on 90 days' notice. Separately, Google leases roughly 110,000 GPUs at Memphis and Southaven for $920 million a month from October 2026.

My claim was narrower than the deal: that the added capacity was visible in how Claude Code behaved for me, and specifically that my usage stepped up at the start of May because of it.

The data

Claude Code writes every session to ~/.claude/projects/**/*.jsonl. The script scripts/mine-claude-history.mjs in this repo aggregates those transcripts together with daily git snapshots from dotclaude-sync and Claude Code's own stats cache. Token counts are deduplicated by message.id:requestId and priced from public per-model API rates. Totals as of 26 August 2026: 4,157 sessions, 195 projects, 444,234 messages, 21.27 billion tokens.

Check 1 — when the step actually occurs

Daily token averages over the days that have data:

period	average	days with data
15–30 April	94M/day	10
1–11 May	51M/day	9
12–31 May	182M/day	19
June	218M/day	29

The first eleven days of May are the quietest stretch in the window, below the second half of April. The step is at 12 May, six days after the contract date and eight days before it was public. The strongest single day in May is 26 May at 483M tokens.

Check 2 — which model was running

First appearance of each model in my transcripts, taken as the earliest timestamp on an assistant event carrying message.usage:

model	first seen
opus-4-6	10 Feb 2026
opus-4-7	17 Apr 2026
sonnet-4-6	28 May 2026
opus-4-8	29 May 2026
fable-5	9 Jun 2026
sonnet-5	30 Jun 2026
opus-5	24 Jul 2026

Every session in May ran opus-4-7. The model did not change at any point during the month, so a model swap cannot account for the step. Opus 5 — the model I had named as the cause — does not appear until 24 July, eleven weeks later.

Check 3 — when the measuring instrument changed

Claude Code prunes local transcripts after 30 days by default. My history survives that only because dotclaude-backup commits a daily snapshot of ~/.claude. Its first commit is 12 May 2026, the same date as the step.

Coverage on either side of that date:

window	days missing from the daily series
1 Mar – 11 May	45 of 72
12 May – 31 Jul	2 of 81

Before the backup existed, 63% of days are absent; after it, 2%. The apparent tripling in daily tokens sits exactly on the boundary where the record stopped being lossy. That is sufficient to explain a large part of the step without any change in the world.

Check 4 — a metric that measures supply rather than demand

Token counts measure how much I asked for. They say nothing about how much capacity was available. The nearest supply-side signal in the transcripts is the rate of overload and limit errors, normalized by assistant messages:

month	errors per 1,000 assistant messages
May	0.33
June	1.85
July	1.36
August	1.22

The rate rises after May. If the lease had relieved capacity pressure on my sessions, this is the series that should fall.

Result

Checks 1, 2 and 4 contradict the hypothesis. Check 3 offers a sufficient alternative explanation for the observation that produced it. The correct statement is that my usage data cannot detect the lease, not that the lease had no effect.

The general error is worth naming precisely, because it is easy to repeat: a consumption metric collected by the consumer measures demand. Attributing a change in it to a supplier-side event requires either a supplier-side metric or a controlled comparison, and I had neither.

Limitations

• Coverage before 12 May 2026 is reconstructed from the union of older snapshots and stats-cache.json. The April baseline is therefore unreliable in both directions; actual April usage may well have been higher than recorded.
• Session counts are not comparable across the whole series — May shows 170 and June 2,016, a difference too large to be real. Something changed in what counts as a session, so this analysis uses tokens throughout.
• Overload errors also rise with my own concurrency, not only with service load. Their increase is not evidence that capacity got worse, only an absence of evidence that it got better.

What would actually test the claim

Serving-side measurements, collected before the question is asked: time to first token, tokens per second, and the share of 5xx responses, each segmented by model and hour of day, with a baseline predating the event. Claude Code transcripts contain some of this, but I had defined no baseline, and a baseline chosen after you know what you are looking for is not a baseline.

The measurements, the reproducible commands and the full limitations are in docs/2026-08-27-colossus-hipoteza-dvije-verzije.md.