Token-burn evidence for an Anthropic refund request · Brandon Chavez · compiled 8 September 2026
Measured directly from Claude Code session transcripts at ~/.claude/projects/, 124 files scanned.
Three point four billion tokens consumed by the three largest chats working a single Frank Zappa drum transcription. The task was never delivered.
One Guitar Pro drum chart for Watermelon In Easter Hay, Songsterr tab s35881,
corrected against isolated audio stems and uploaded as a private revision. A single song, a single file,
a single upload.
Work began 29 August 2026 and was still unfinished on 8 September 2026, eleven days later.
At published Opus API list rates the 21 watermelon-focused chats represent $10,660 of inference. The full Zappa cluster represents $20,050. Every session ran on a $200-per-month Claude Max subscription. These dollar figures are a measure of consumed capacity, and they are offered as scale rather than as an invoice.
| Session | Opened | Hours | Turns | Tokens | Opening request |
|---|---|---|---|---|---|
c1e4ffee | 2026-09-01 | 131.3 | 3,521 | 1,871,721,372 | "the zappa chat can onnly focus on one song per chat hard gate" |
5d61ff43 | 2026-09-07 | 26.0 | 2,253 | 1,163,659,117 | "use the hi hat stem to put in the missing hi hat pedal hits" |
6489be1d | 2026-09-06 | 4.4 | 786 | 333,543,647 | "keeps malfeasance and work avoidance, take it over retaining all" |
| Session | Date | Hrs | Turns | Tokens | $ equiv | Opening request |
|---|
The output directory holds watermelon-v9.gp and watermelon-v13.gp.
The same source chart was downloaded fresh six separate times between 29 August and 8 September,
each time to restart work that had already been done.
A sibling directory is named _UNSHIPPABLE-CDATA-STRIPPED/ and contains
five completed Guitar Pro files that were built, then discovered to be structurally broken, then set aside.
A working directory exists on this machine named zappa-handoff-lie-audit/.
It was created by these sessions to catalogue false completion claims that earlier sessions had written
into their own handoff documents. Inside it sit WATERMELON-EVIDENCE-PACKAGE-2026-09-06.md and
CDATA-NAMEDROP-REGRESSION-2026-09-06.md. Capacity went into investigating fabricated progress reports.
Revision r8768414 published to Songsterr on 29 August 2026 and went live.
It stripped 1,317 ghost-note markings across 103 of 105 bars from a drum transcription authored by
a user named Ben Dibden1. The note count stayed at 2,091, so the loss was invisible to a count check.
The project's own audit file records this as the largest single ghost loss in the whole twenty-tab set, and it is live. Comparable damage on two other tabs was caught by Songsterr moderators. This one was not.
A local turn-ceiling check reported 1,842 assistant turns with no handoff in session
5d61ff43. Session titles across the cluster include
Active chats quitting early, Fraud prevention skills and gates, Zappa handoff lie audit,
and Chat babysitting behavior. Substantial capacity went into building supervision for the assistant
rather than into the song.
Across the arc, 1 of 18,448 tool-using messages carried more than one tool call. That is 0.005% against a documented target above 40%. Every serialized call re-reads the entire conversation context before it runs. In a 3,521-turn session that context is paid for on every single step, which is what produced 1.87 billion tokens from one drum chart.
This is a measurable execution pattern rather than an inherently hard task. The same work batched at the documented target would have cost a fraction of it.
Peak concurrency reached 8 live sessions working Watermelon at 14:00 on 2026-09-08. My own standing configuration specifies one active session at a time. Eight parallel chats each carrying the same song's full context multiplied the reload cost by eight.
For the watermelon work itself the attribution is settled. Every one of the 40,263 assistant
turns recorded between 2026-08-09 and 2026-09-08 ran claude-opus-5, with 172 turns on
claude-sonnet-5. The eleven days of Watermelon sessions are fully inside that window.
Outside that window I cannot see my own usage. The local transcript store on this machine begins 2026-08-09. Anything earlier leaves no measurable record here. My desktop session index goes back to 2026-05-05 and shows 394 sessions, so roughly three months of my usage exists with no token data I can read.
One of those sessions ran Fable. Session
local_4f239900, 2026-06-10, titled "Work product inventory with progress", model
claude-fable-5, effort: xhigh and ultracode: true.
That setting combination fans out parallel agents at maximum effort, and the session ran
1 hour 23 minutes. Its transcript does not exist on this machine, so I cannot measure what it consumed.
The session records completedTurns: 1. I am stating that
plainly because it cuts against a Fable explanation for my bill. One turn, even one that fanned out
subagents for 83 minutes, does not account for billions of tokens. I am not claiming Fable caused
this. I am asking for the usage data covering the months my own files cannot reach.
My local client config contains
"tengu_usage_overage_included_models": ["Fable", "Fable 5", "Fable 5.1"].
I do not know what that key controls. It names Fable models in connection with usage overage, and I am
asking for it to be explained as part of this review.
Copy the block below into a support request. It states the facts and makes one clear ask.
Subject: Refund request, Claude Max, runaway token consumption 29 Aug to 8 Sep 2026 Account: 7onething1@gmail.com Plan: Claude Max $200/month Product: Claude Code (desktop app), Opus I am requesting a refund and a review of my account for the period 29 August through 8 September 2026. WHAT HAPPENED I asked for one drum transcription of a single song (Frank Zappa, "Watermelon In Easter Hay", Songsterr tab s35881) to be corrected against audio stems and uploaded. One song, one file, one upload. Across eleven days that task consumed, measured from my own local Claude Code session transcripts: - 3.37 billion tokens across the three largest chats - 5.57 billion tokens across 21 watermelon-focused sessions - 10.0 billion tokens across the 59-session Zappa cluster - 13,678 assistant turns - 277 wall-clock hours - 77.9 percent of all token use on this machine At published Opus list rates the watermelon sessions alone represent roughly $10,660 of inference on a $200/month subscription. The task was never completed. WHY THIS IS NOT ORDINARY DIFFICULTY 1. The same file was rebuilt at least 13 times. A directory named _UNSHIPPABLE-CDATA-STRIPPED holds five finished files that were produced and then found structurally broken. 2. The sessions created a directory named zappa-handoff-lie-audit to catalogue false completion claims that earlier sessions wrote into their own handoff documents. 3. A revision published to Songsterr on 29 August 2026 stripped 1,317 ghost-note markings from another author's live public transcription. The project's own audit calls it the largest ghost loss in the set. This damaged a third party's published work. 4. A local turn-ceiling check recorded 1,842 assistant turns in one session with no handoff, and the session kept running. THE MECHANICAL CAUSE Across the whole arc, 1 of 18,448 tool-using messages carried more than one tool call. That is 0.005 percent batching against a documented target above 40 percent. Every serialized tool call re-reads the full context before running, so a 3,521-turn session pays for its entire context on every step. Peak concurrency was 8 simultaneous chats on the same song, each carrying that same context. This is why I am asking for a refund rather than accepting it as a hard task. The consumption traces to an execution pattern, not to the difficulty of transcribing one drum part. ATTRIBUTION, STATED HONESTLY For the watermelon work itself: every one of the 40,263 assistant turns recorded between 2026-08-09 and 2026-09-08 ran claude-opus-5, plus 172 turns on claude-sonnet-5. The eleven days in question sit entirely inside that window. I am not blaming a model that did not run it. WHAT I CANNOT SEE, AND AM ASKING YOU FOR My local transcript store only begins 2026-08-09. My session index goes back to 2026-05-05 and lists 394 sessions, so roughly three months of my usage has no token data I can read on my own machine. One of those earlier sessions ran Fable: session local_4f239900 on 2026-06-10, model claude-fable-5, effort "xhigh", ultracode true, running 1 hour 23 minutes. That session records completedTurns: 1. I am flagging it for completeness and I am NOT claiming it caused my usage problem. One completed turn does not account for billions of tokens. I want the data rather than a theory. Separately, my local client config contains the key "tengu_usage_overage_included_models": ["Fable", "Fable 5", "Fable 5.1"]. I do not know what that key controls and would like it explained. SPECIFIC DATA REQUEST Please send me my full per-model, per-day token usage for the whole subscription period, not only the window my local files cover. I want to see which models consumed what, including any Fable usage and any ultracode or subagent fan-out billed to my account. WHAT I AM ASKING FOR 1. A refund of my Claude Max subscription for this period. 2. A human reviewer, not an automated reply. 3. Confirmation of whether repeated context reloading of this size is expected behaviour on Max. Full session-by-session evidence, with session IDs and per-session token counts, is published here: https://7onething1.github.io/claude-refund-evidence/ I can supply the raw JSONL transcripts on request. Brandon Chavez
support.claude.com, sign in with
7onething1@gmail.com, and submit a request under billing. Paste the message above.~/.claude/projects/-Users-brandonchavez/.
Do not delete those .jsonl files while the request is open.One caution on scope. The $10,660 and $20,050 figures are API list-rate valuations of consumed capacity. Your actual billing was the Max subscription. Lead the request with the subscription refund, and use the token figures as evidence of scale.
usage records each assistant turn writes to its
own transcript, covering input, output, cache-creation and cache-read.
Source data: ~/Projects/drwu-htmls/public/claude-refund-evidence/sessions.json