Most Claude Code token waste comes from bloated tool-call output and system prompts rather than the model itself, and eight concrete fixes — from output minification to capping thinking effort — can cut total usage by 30-50% or more with no quality loss.
Who This Is For
Read if. Skip if.
READ IF YOU ARE…
You run Claude Code or a similar agentic coding tool daily and have hit usage limits or a surprising bill.
You maintain CLAUDE.md or system-prompt files and suspect they're bloated with filler language.
You've had an agent read entire log files, CSVs, or large text dumps instead of searching them.
You're curious what's actually eating your context window and want a way to audit it.
SKIP IF…
You use Claude only through the consumer chat app, not Claude Code or an agentic coding workflow — the tool-call-level tricks don't apply.
You're not currently token- or cost-constrained and have no interest in the mechanics.
TL;DR
The full version, fast.
After spending $1,486 in four hours testing Fable, the creator distilled eight token-reduction tactics for Claude Code that together cut usage by roughly 30-50% with no quality loss. The core mechanism: most waste isn't the model thinking too hard, it's bloated plumbing — repetitive tool-call output, verbose system prompts, full-file reads of huge logs, non-English prompting, and default-high thinking budgets. Fixes include minifying tool-call text (RTK), semantically compressing CLAUDE.md and memory files, routing log/large-file reads through search or a SQLite query instead of a full read, prompting in English, adding explicit context-frugality rules, periodically running /context to audit hidden bloat, and capping thinking effort to low by default. The actionable conclusion: audit your context window regularly and default to the cheapest settings, escalating only when a task actually needs it.
Free for members
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
States the premise — burned $1,400+ testing Fable, wants to show token-reduction methods with near-zero quality impact.
01:06 – 02:36
02 · 1. Rust Token Killer (RTK)
Minifies repetitive tool-call input/output; demo shows a 612-line/36,700-character call reduced to 4 lines/177 characters, a 99% cut on that example.
02:36 – 04:22
03 · 2. Semantic compression
Rewrites verbose CLAUDE.md / system prompts / memory files to minimum word count with identical meaning; live Sonnet 5 demo compresses an 865-word doc to 211 words.
04:22 – 05:53
04 · 3. Logs to SQLite
Instead of reading a massive log file as raw text, route it through a SQLite-backed query script so Claude asks the database for the relevant lines.
05:53 – 07:20
05 · 4. Block huge reads
For very large files, instruct Claude to sample the start/end and use a targeted search (sed -n) instead of reading the entire file top to bottom.
07:20 – 08:09
06 · 5. Prompt in English
English is more token-dense than Italian, German, or Japanese for the same query; shows a token-count comparison across languages.
08:09 – 10:25
07 · 6. Context frugality rule
Adds an explicit system-prompt rule to only read directly relevant files and ask before expanding scope; demoed via a 'frugal-claude.md' example.
10:25 – 11:53
08 · 7. Periodic /context
Recommends regularly running /context to audit hidden token consumers (e.g. accidentally running a dozen loaded Chrome MCP instances at once).
11:53 – 15:01
09 · 8. Cap thinking effort
Compares low vs. extra-high thinking on the same bug-finding task: low took 7 turns/16 cents, extra-high took 9 turns and ~1.3x the tokens for the same result; closes with a Maker School pitch.
Atomic Insights
Lines worth screenshotting.
Minifying repetitive tool-call output (RTK) took one 612-line, 36,700-character tool call down to 4 lines and 177 characters — a 99% reduction on that call alone.
Most tool calls aren't that wasteful, but a majority carry some redundancy, so realistic savings across a session land around 30-50%.
Semantic compression rewrote an 865-word CLAUDE.md down to 211 words (1,125 to 274 estimated tokens) with no loss of instructional meaning.
Voice-noted or conversationally-written system prompts ('Hello, thank you so much for helping...') carry zero informational value per pleasantry.
Routing a 5,000-line log file through a SQLite query script instead of a raw read avoids treating the whole file as text Claude must scan line by line.
Telling Claude a resource is too large to read in one shot causes it to sample the beginning and end first, then use a targeted search (sed -n) instead of reading all 20,000 lines.
Prompting in English instead of Italian, German, or Japanese saved 20-80% of tokens on the same query in one comparison (51 tokens in English vs. 118 in German).
A context-frugality rule in the system prompt ('read only files directly relevant to the task, ask before expanding scope beyond three files') trades some model autonomy for lower token spend.
Running twelve Chrome MCP instances simultaneously, each loaded with full context, silently multiplied token spend without any explicit action from the user.
In a /context audit, a nearly 1,000,000-token window was already 8% consumed by system prompt (1%), tools (16,400 tokens), memory files (10,700 tokens), and skills (7,000 tokens) before any real work started.
On the same bug-finding task, low thinking effort took 7 turns and 16 cents; extra-high effort took 9 turns and roughly 1.3x the output tokens for the identical result.
Claude's adaptive thinking can choose to use fewer turns on a hard setting but frequently doesn't, meaning higher thinking tiers cost more without a proportional accuracy gain.
Model providers are paid per token, which the video frames as a reason not to blindly trust adaptive/high thinking defaults.
Takeaway
Eight ways to cut Claude Code's token bill without losing quality
WHAT TO LEARN
Most agentic-coding token waste isn't the model thinking too hard — it's bloated tool-call output, verbose prompts, and unnecessary full-file reads, and each is independently fixable.
Minifying repetitive tool-call output (the RTK approach) can cut a single call's token cost by up to 99%, and realistically saves 30-50% across a typical session.
System prompts and memory files written conversationally (with pleasantries and filler) can be semantically compressed to roughly a quarter of their original length with zero loss of instructional meaning.
Route large log files or datasets through a search/query layer (like a SQLite lookup script) instead of letting the model read the entire file as raw text.
For any very large resource, instruct the model to sample the beginning and end first, then use a targeted search rather than reading the whole thing top to bottom.
Prompting in English instead of other languages measurably reduces token counts for the same request, since English is more token-dense per unit of meaning.
Adding an explicit context-frugality rule to a system prompt (read only what's relevant, ask before expanding scope) trades some autonomy for meaningfully lower spend.
Periodically auditing your context window (e.g. via a /context-style command) catches silent bloat like duplicate tool instances or accumulated memory files before it inflates your bill.
Default to the lowest thinking/reasoning effort setting a task needs; on a matched test, high effort used about 1.3x more output tokens than low effort for an identical result.
Glossary
Terms worth knowing.
RTK (Rust Token Killer)
A tool that minifies and strips redundant text from Claude Code's internal tool-call inputs and outputs before they consume tokens, without removing information the model needs.
Semantic compression
Rewriting a system prompt, memory file, or instruction document in the fewest words that preserve its original meaning, removing filler and pleasantries.
Context frugality
An explicit system-prompt rule instructing the model to only read files or expand scope when directly necessary, rather than exploring broadly by default.
Thinking effort / thinking budget
A setting that controls how many internal reasoning tokens a model spends before answering; higher settings (e.g. 'extra high') cost more tokens and don't always change the outcome.
/context
A Claude Code command that prints a breakdown of the current context window by category (system prompt, tools, memory files, skills, messages) so a user can spot hidden bloat.
“Instead of spending 36,700 characters, we're only spending 177. The difference pre and post RTK is literally a 99% reduction in token usage for the same thing.”
concrete, specific number, strong hook for a shorts cutdown→ TikTok hook↗ Tweet quote
14:22
“Extra high spent around 1.3x the output tokens... same bug found either way.”
“That's what Anthropic makes money off of, right? They make money off of the total number of tokens you use.”
provocative one-liner about incentives→ newsletter pull-quote↗ Tweet quote
The Script
Word for word.
Read-along
Don't just watch it. Burn it in.
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
17px
analogy
00:00So as you know, Fable has been miraculously returned to us. Well, in the first four hours since its release, I spent over $1,400. In the last twenty four hours, I spent another around a thousand dollars.
00:10And I didn't do this just because I love pissing money away, but because I wanted to figure out what the best and optimal token reduction and usage strategies were because I anticipate Fable and other extremely high intelligence models are likely to continue being compute restricted for at least some period of time. What I wanna do in this video is I just wanna show you all of those significant token reduction methods.
00:31These token reduction methods have next to zero impact on your quality, but can reduce the total token and usage consumption by at least 50%, if not more in some cases. The first is a strategy called RTK or Rust Token Killer.
00:43What this does is it takes all of the tool inputs and outputs of Cloud Code and it minifies and reduces anything that is not explicitly necessary to the model's function. Now, if that means nothing to you, never fear, I have a demo. I wanna show you guys what a tool call, like, Claude would be making internally looks like with RTK versus without RTK.
01:02For those of you guys that don't know, Claude typically has its own little internal terminal and uses that terminal in order to send and receive requests. And so this is just a brief demo of what a request would look like without RTK, sort of like the vanilla, and then with RTK down here.
01:16Okay. So without RTK, pretending this is just some internal tool call, you can see we're repeating a lot of information.
01:21Standard out, standard out, standard out, standard out. Setting up fixtures, hydrating mocks.
01:26Right? We're just saying the same thing over and over and over again. Unfortunately, Claude doesn't know the difference and neither does your token bill.
01:31So when you send these internal tool calls, which Claude constantly has to do with sending hundreds if not thousands in a typical session, It typically has to read a lot of irrelevant same information. And obviously, that's an inefficiency that we can print out. So what RTK does is it takes all of this data and then it applies a new format to it, which gives you all of the same information which Claude can use in order to do whatever the heck you want us to do, but in significantly fewer wasted tokens.
01:56And so instead of spending, let's say, 612 lines on this tool call, okay, because this is truncated, we are only spending four lines. Instead of spending 36,700 characters, we're only spending a 177.
02:10And the difference pre and post RTK is literally a 99% reduction in token usage for the same thing.
02:16Now, not all tool calls are gonna look like this. Some of them are not inefficient, but a vast majority of them are less efficient than they could be. So realistically, you're probably gonna save somewhere between 30 to 50%.
02:26The second is called semantic compression, which is essentially just taking a sentence. Okay? And then rewriting that sentence in as few words as humanly possible without removing the meaning.
02:36If that still doesn't make any sense to you guys, I wanna show you guys a demo claud.md. Over here, we have just some system prompt that somebody's created. Maybe they've voice noted it in, so it's a little less efficient than it normally would be.
02:48Project instructions and guidelines for the AI assistant. Hello. Thank you so much for helping out with this project.
02:54We really appreciate all the work that you do. This document contains all of the important instructions, guidelines, rules, conventions that we would like you to please follow whenever you're working on any part of the code base. Now, this is a learned skill, but essentially, everything up here has zero informational value.
03:09If you wanted to, you could rewrite this exact same paragraph. And instead of saying, hello, thank you, and so on and so on and so forth, you could probably just say project instructions and guidelines for the AI system, and it would have the same semantic value. And so what this is, is this is essentially taking all of your system prompts, all of the memory files and everything else in your claud on MD, and then system context, and just compressing it by removing things that are superfluous, things that are unnecessary.
03:37Again, if you guys wanna see what this looks like in practice, I have a brief demo up here where I'm actually going to spin up a Claude instance. Okay. This Claude instance is running Sonnet five.
03:45What it's doing is it's gonna read through the Claude that I'm doing that I just showed you and then rewrite it with maximum information density, which is essentially semantic compression. It's then going to show you the before and the after of the word count. And you could see that before we had 865 words, most of them junk.
04:01After, we had 211. Estimated token wise, we went from 1,125 to 274.
04:08And you can apply this approach all across your projects to significantly reduce both token consumption, but then also improve brevity and then improve the quality of the output. I do this on every single project.
04:18Also, if guys want any of these, just check the description down below. I'm giving them all to you for free. The third is logs to SQL lite.
04:25This doesn't apply for every single use case because Claude will not always be reading logs for a lot of your own projects, but it's a useful hack in situations where Claude is, for whatever reason, trying to read a log file. And the logic here is similar to Rust token killer. Instead of actually having to pour through a massive log file to look for what you want, we just use a highly compressed form of that SQL lite, which is a database which contains like location and place information and a bunch of stuff.
04:49Then we abstract away the the search function for a simple command that will send to the database that will do it for us. If I open up this brief demo over here, which is actually logging Claude code, you can see that a customer says checkout failed this morning. Find the root cause in the app dot log.
05:05Important, it's 5,000 lines. Do not read that log directly. Instead, use scripts slash log q dot py with no arguments to see usage.
05:13Report the root cause of the affected line order and even cite the line numbers. Okay. And so previously, we would have literally had to treat this like a giant piece of text and read every single line.
05:23Instead, what this is doing is it's just calling our database, which is set up in SQLite. This is extremely easy and extremely simple.
05:30And you can see we actually have if I just zoom in here and maybe move my fat head a little bit out of the way. You could see the timeline, the specific line that every one of these logs is in, um, and then all the information that you need. You can apply the same logic to any sort of database, whether it's a Google Sheet, whether it's a CSV, anything like that.
05:47Make sure that you're not actually searching through it just using text. Make sure that you're using some sort of database function to do the filtering for you. The next strategy is to block huge reads.
05:55To make a long story short, there are some resources that are just very long and not all resources need to be read start to finish. And so instead of actually doing the entire read, similar to what we did with SQLite, we're passing it off to a search function, which will do most of the procedural heavy lifting for us, and then just rely on Claude or, you know, OpenAI's or Codex's intelligence to set up the filters correctly.
06:16Here's a brief example of what that would look like. If I set up Claude and then tell it to read a massive dump of data and telling me if there's anything wrong with it, notice how it'll now say the file is 618 kilobytes or 20,000 lines, too big to read in one shot safely.
06:33Let me sample it to understand its structure first. Then instead of actually reading the entire thing, k, which is right over here, what it'll do is it'll just read the beginning section, maybe the end section, and then sort of apply its own logic to see, okay, can I match any of these patterns to potentially search through this data way more efficiently?
06:49Then if we scroll down here, rather than, you know, creating this massive massive burden on us token wise, instead of actually reading all 20,000 lines, what we do is we essentially just like make one small function, s e d dash n, and then make sure you give it the exact index of where it wants to look, uh, and then it saves us all of that.
07:06So, you know, instead of reading 20,000 lines, maybe we only read 20 or 30. This is massive efficiency savings on tool calls that are extremely long resources.
07:14You're not gonna do this like every single tool call, of course. But in the tool calls where you do read large resources, you will save like 99% of that. The next is pretty simple and most of you will already be doing this, but I'd highly recommend prompting in English.
07:25English is just significantly more of a information dense language than something like Japanese, French, German. And by doing so, you'll typically get somewhere between a 20 to potentially 80% reduction in total token usage or more.
07:38Should also note that most of these models are trained on English. Interestingly enough, if you're using the Chinese classes of models, those also work really well in English. But for instance, Mandarin is actually extremely efficient token wise because most of the language is symbolic.
07:52If I were to show you guys a brief example of the total number of tokens used for a simple query in English versus Italian versus German and versus Japanese, this is what we got. As you can see, English, you know, making some simple query, only consumes 51 tokens. In Italian, it's 87.
08:08In German, it's a 118, 2.31 x. In Japanese, it's something like 74, 1.45 x. So this one's a little bit less prescription y.
08:16Obviously, most of you guys will already be doing it in English. But just want you guys to keep that in mind if you do end up doing projects in other languages. The next hack is embedding some form of context frugality into your system prompt.
08:25We already showed you guys how to optimize system prompts by semantic compression, taking a sentence that means x and then making the sentence itself shorter, but keeping the meaning as x. Um, this is similar. It's just we actually are inserting a high level rule where our model will only ever look to a resource if we explicitly specify it.
08:43Now I will note that this is one of the, uh, tactics or tweaks that can reduce quality significantly. You know, Fable and these other models already have pretty solid built in look schemes. They sort of understand where to look through statistical pattern matching.
08:55Um, so what this will do is it'll basically make it harder for it to find the thing that you want it to unless you're very specific. But I'm imagining or assuming you guys are willing to be more specific for trade off of better usage. So I have a demo over here called frugal dash claud m d.
09:09If I zoom way in, you could see that we say customers are reporting that a 10% coupon takes off 10 times too much at checkout. Find the bug and propose the one line fix. Now, I should note that inside of our context window, we've actually inserted a Cloud.
09:23Md that says, read only files directly relevant to the task. Ask before expanding the scope beyond three files. Prefer glob or grep to locate, then read the region, not the entire directory, and summarize findings so far before deciding to read more, just in case we, you know, change our mind halfway through or something.
09:41Also, never generated files, lock files, or fixtures, those should not be read unless explicitly asked. We go back to the demo, you could see that essentially what we've done is we've just applied grep.
09:52We've applied targeted searches as opposed to, again, reading through the entire thing. And you'll find that a lot of the tactics and tweaks just really revolve around, you know, instead of just reading through the entire thing line by line, use your intelligence to build a filtering mechanism or a script that does so instead.
10:07Fable and other models are already okay at this, but this heavily biases it towards doing that. Any advanced users here will probably scoff at this, but you should be periodically slash contexting to see where things are taking up your context without telling you. I, as I was using Fable just the other day, realized that I was running like a dozen Chrome MCP instances simultaneously.
10:28Every single one loaded with its full context, so I ended up spending way more money than I actually had to. In addition, Claude was bloated. It got really confused about which one to use.
10:37This occurs even seasoned veterans. And for those of you guys that don't know, this is more or less what that looks like. Um, we see the total context window of the model.
10:44Sonnet five in this case has almost 1,000,000 token window, which is pretty sweet. The system prompt as it is consumes about 10,000 or 1%. The tools that it has access to, the grep, the glob, the s e d, and so on and so forth.
10:58Um, this gives it 16,400 tokens. My memory files, which are my own, are around 10,700 tokens.
11:05The skills are around 7,000 tokens. And then the messages that it and I have sent back, uh, and forth with each other, which I think accounts each one of these as one message, is eight tokens. So collectively speaking, I basically already used 8% of that budget.
11:18A quick and easy hack to do this is just like set up another cloud instance somewhere on a different desktop that you're not using, um, and then have it loop. Okay? So type slash loop and then set up a watcher that just runs once every day to tell you if there's anything in your Claude context that wasn't there twenty four hours ago.
11:35It'll take a quick snapshot of all the files and everything currently in your context. And in this way, you can just get periodically notified so that if something does creep its way in, like an MCP or, I don't know, a big set of skills or a bunch of other data, you'll know immediately and you'll always be able to ensure that that context is really small.
11:50Because at the end of the day, all this token management stuff is context management. The last major tweak is to cap your thinking. Now, what I mean by this is Claude has the ability to think at multiple levels.
12:00Thinking is just feeding in tokens through its loop over and over and over again to become clear and clear about a problem and come up with a better solution. Similar to how if you were to brainstorm something on a piece of paper for a thousand words, you'd probably be clearer than if you only got to brainstorm it for 10 words.
12:15The issue with Claude's adaptive thinking, which is where it sets its own thinking budget for you, is it tends to just use way more than you actually need to. And with really intelligent models like Fable, you don't actually need to be thinking all that much in order to answer questions and solve problems. And so rather than default to super high thinking, like most of you are doing, you should default to super low thinking.
12:34You should basically opt, uh, in only when you need really big thinking budgets. And this is actually massive.
12:40This is gonna improve like 30 to 40%. Let me show you what I mean. I have a little demo over here, which is basically going to ramp up the effort over two different thinking modes.
12:49The first is low. And the task that I'm giving Claude here, um, is just to find a bug somewhere in a code base. It's a simple bug, nothing super crazy.
12:59Um, all it's doing is it's basically going top to bottom and it's reading the thing. The first pass is on a low effort. This took seven turns, cost 1,028 tokens, consumed eighteen seconds of my time, and cost 16¢ in total.
13:15Okay. So it looped back on itself seven times. That's about the cap for low.
13:18Contrast that with x high, which is basically the smartest mode that we have. It took nine turns, spent 1,363 Epitokens, consumed twenty one seconds, and cost something like 3¢ more.
13:30I should note that Clot has the ability to mediate, again, how much thinking it gives to different problems. Despite the fact that it had the ability to mediate this to go fewer turns, it didn't. It used more turns, obviously, to achieve the exact same result.
13:44Um, so, you know, same bug found either way. Extra high spent around 1.3 x, the output tokens. It was nine turns versus seven.
13:51Know, if I ran this another dozen times, I bet you the delta would actually be a little bit more than that. In my testing, it's usually closer to 1.5 x. So the real takeaway there is just set it to low.
14:00Only set it to high if you explicitly need it for a specific business function. Um, don't just trust the adaptive thinking because, of course, the if think you about it, that's what Anthropic makes money off of. Right?
14:08They make money off of the total number of tokens you use. While adaptive thinking is great and all, they're probably gonna trend up a little bit versus what you would have done, uh, you know, looking at the glaring hole in your wallet. Hopefully, you guys appreciated that video.
14:20I had a lot of fun putting it together for you. You can get all of the resources as mentioned down below in the description. It's a free download, free sign up.
14:25Go ahead and, uh, take what you need. If you guys like this sort of thing and wanna monetize your Cloud Code skills to get your very first client, check out Maker School. It's my day by day roadmap where I'll personally guide you through the process of getting your very first customer for an AI service.
14:39An AI service here is loosely defined as, you know, systems that you build with Cloud Code, websites that you build with Codecs, back end automations that you build with n eight n, drag and drop builders, and so on and so forth. Um, I actually guarantee your first client ninety days, or you don't pay me a cent. I'll give you all your money back.
14:54If you guys like this, please leave a like and comment down below, and I am happy to answer any questions you have. Thanks so much, and have a lovely rest of the day.
The Hook
The bait, then the rug-pull.
Nick Saraev spent $1,486 testing Claude's Fable model in its first 24 hours back online — then mined that spend for eight concrete ways to cut Claude Code token usage by 30-50% or more, demoed live against real tool calls, system prompts, and log files.
Frameworks
Named ideas worth stealing.
01:06list
Eight token-reduction tactics
Rust Token Killer (minify tool-call I/O)
Semantic compression (compress system prompts/memory)
Logs to SQLite (query instead of full-text read)
Block huge reads (sample + targeted search)
Prompt in English
Context frugality rule in system prompt
Periodic /context audits
Cap thinking effort to low by default
A checklist of independent, stackable optimizations that together the creator claims can cut Claude Code token spend by 30-50% or more with negligible quality impact.
Steal forAuditing any Claude Code / agentic-coding CLAUDE.md and workflow for token waste before scaling usage
CTA Breakdown
How they asked for the click.
VERBAL ASK
14:23product
“check out Maker School... I actually guarantee your first client ninety days, or you don't pay me a cent”
Soft CTA delivered after the value content is fully complete, framed as a natural next step for viewers who want to monetize the skills shown, paired with a risk-reversal guarantee.
A 14-minute benchmark rebellion: seven live side-by-side demos, one OpenRouter API key, and a four-path procurement map that makes Opus 4.8 look expensive.
A creator walks through five concrete levers — effort level, model delegation, token-saving skills, research offloading, and advisor mode — for keeping Claude Code costs and weekly usage caps under control.
A full-stack engineer argues xAI's terminal coding agent drifts less, is backed by more durable money, and costs less than either Anthropic or OpenAI's tools.
00:16
00:26
00:40
00:53
01:13
01:24
01:35
01:46
01:58
02:09
02:26
02:36
02:54
03:05
03:28
03:39
03:50
04:02
04:18
04:22
04:35
04:47
05:09
05:20
05:32
05:43
06:06
06:16
06:28
06:39
06:51
07:02
07:13
07:36
07:52
07:58
08:09
08:32
08:43
08:54
09:06
09:17
09:28
09:40
09:51
10:02
10:12
10:25
10:38
10:47
10:58
11:18
11:32
11:43
11:53
12:06
12:17
12:28
12:43
12:51
13:02
13:14
13:36
13:47
13:57
14:10
14:34
14:44
14:55
Video of the Day14:34
13:24
12:01
17:48
10:21
14:56