{"slug": "i-stopped-running-out-of-tokens", "title": "I Stopped Running Out of Tokens", "summary": "An engineer on a Claude Enterprise team hit the org's monthly spend limit mid-month, prompting a search for token-saving techniques. The engineer now uses a usage meter in Claude Desktop and a separate CLI tool called Claude Code Usage Monitor to track burn rate, and has installed rtk (Rust Token Killer) to condense command outputs before they are sent to the model, cutting token usage without sacrificing quality.", "body_md": "# How I Stopped Running out of Tokens\n\nThese days nearly all my engineering work runs through AI: analysis, design, coding, code review, debugging production issues, documentation. At work my team is using Claude Enterprise, and I assumed that meant I didn't need to think about usage or limits. Then, mid-month, I got this error message from Claude in the middle of a session:\n\nYou've hit your org's monthly spend limit · ask your admin to raise it at claude.ai/admin-settings/usage\n\nAfter posting in Slack to ask if anyone else had seen it, turns out several other engineers on the team had hit the exact same wall, right around the same point in the month. Someone pointed me to the individual usage meter on Claude desktop, which I hadn't known existed on Enterprise plans. Our workspace admin also gave everyone a bump in tokens, buying some breathing room. But now that I could see the meter and watch the burn rate, it was clear that even with the extra tokens, it wasn't going to last to the end of the month.\n\nThat's when I realized this wasn't sustainable. This post walks through the tools and techniques I've since put together, which have cut my token usage without giving up quality or slowing down.\n\nWatching Usage\n\n**Usage Meter**\n\nThe first thing to know is you can check your usage directly. In Claude Desktop, click your name at the bottom left, then Settings, then Usage. Ever since that mid-month scare, I keep this open in a window off to the side. Here's what it looks like on my personal Pro plan but it's a similar process for Enterprise:\n\n**Claude Monitor**\n\n[Claude Code Usage Monitor](https://github.com/Maciek-roboblog/Claude-Code-Usage-Monitor) is a separate CLI tool that gives you a live read on burn rate within a rolling 5-hour session window. It's not connected to your account, so it's estimating, not reading real numbers. You can tell it what plan you're on (there's no Enterprise option, but there is a \"custom\" plan you can configure), and it'll show you things like a prediction for when you'll run out at your current rate. Treat it as a gut check on how fast you're going, not an exact figure. It aggregates across every active Claude Code session on the machine, so the burn rate and prediction reflect all of them combined, not just the session you're currently working in.\n\nI keep this running in a terminal window in VS Code, beside my Claude Code terminal. Here's a sample screenshot:\n\nInput tokens vs output tokens\n\nBefore getting into the tools to optimize usage, it helps to know that pricing is split into two buckets: input tokens (everything sent to the model: your prompt, the conversation history, any files or context loaded) and output tokens (what the model generates back). They're priced differently, with output tokens typically costing more per token than input.\n\nTools\n\nThese are dedicated tools I installed, each targeting a different part of the token pipeline: input, output, and search efficiency.\n\nrtk\n\n[rtk](https://github.com/rtk-ai/rtk) (Rust Token Killer) saves input tokens. It acts as a proxy for common CLI commands. For example, when Claude runs a command like `git log`\n\n, instead of the raw output going straight into the conversation, `rtk`\n\nintercepts it, runs the real command, and returns a condensed version. That condensed version is what actually gets sent to the model.\n\nTo demonstrate, the screenshot below shows `git log`\n\noutput on one of my projects. On the left, the raw output (truncated; there's more to scroll), and on the right, the `rtk git log`\n\nversion. Notice how much more condensed it is.\n\nMultiply this by all the commands Claude typically runs for coding sessions and the savings add up significantly. You can see your savings with `rtk gain --daily`\n\n. For example:\n\nThe \"Input\" and \"Output\" columns in the savings table refer to the size of the *command's* output before and after rtk compresses it, not input/output tokens in the model-pricing sense. The words overlap, but they mean different things here: \"Input\" in this table is the raw stdout from the shell command, and \"Output\" is the smaller, compressed version that actually becomes input sent to Claude.\n\nFor example, the table shows that on May 23, I ran 221 commands, which produced 102.3K of raw output. That's what would have been sent to the model had I not been using `rtk`\n\n. But `rtk`\n\nintercepted those and compressed the output so that only 70.4K was actually sent to the model. That yields a savings of 32.1K (31.4%) input tokens from running commands.\n\n**How does Claude know to invoke rtk?**\n\nIf you're curious how Claude knows to use `rtk`\n\n: installing it adds a reference in your user-level `~/.claude/CLAUDE.md`\n\n, like this:\n\n```\n@RTK.md\n```\n\nThat `@`\n\nreference tells Claude to load `RTK.md`\n\n, which has the actual instructions for how and when to route commands through rtk. It's set up this way so it's active on every conversation.\n\nThe install also generates `~/.claude/RTK.md`\n\nalongside it, containing the actual instructions. From my install, it looks like this:\n\nCaveman\n\n[Caveman](https://github.com/JuliusBrussee/caveman) saves output tokens. It changes how Claude responds by stripping out filler, hedging, and pleasantries, while keeping the technical content intact. It's not just shorter responses, it's a different shape. Caveman trades prose for fragments, bullets, and arrow chains (`→`\n\n), and front-loads file:line references instead of burying them in sentences. That structure carries more signal per token, not just fewer of them.\n\nYou can turn it off mid-conversation by starting a prompt with `normal mode`\n\nto compare the more verbose output that Claude otherwise responds with. The screenshot below shows the model responses side by side with and without caveman to the same prompt, asking how referrer normalization works on an analytics project. On the right side, non-caveman explains the flow in paragraphs. On the left, Caveman gives the same flow as a numbered list. Caveman comes in at ~424 tokens vs ~487 (13% savings), but the real gain is how much of each response is signal instead of connective words.\n\n`/caveman-stats`\n\ngives you an estimate of output token savings for the current session. It's not re-running your actual commands against the model without caveman for a real comparison. Instead it estimates against benchmarks from its own repo. Treat the number as a rough estimate, not an exact accounting.\n\nCaveman's repo claims up to 65% output token reduction across its test prompts (this post's 13% example is one data point, not the tool's ceiling), and cites research suggesting brevity-constrained answers can improve accuracy, not just cut cost.\n\n**How does Claude know to invoke caveman?**\n\nCaveman is installed as a Claude Code plugin. You don't have to remember to type `/caveman`\n\nevery time you start a conversation because the plugin registers two hooks: a `SessionStart`\n\nhook that turns the mode on at the start of a session, and a `UserPromptSubmit`\n\nhook that re-applies it on every single message you send. Check your `~/.claude/plugins/marketplaces/caveman/.claude-plugin/plugin.json`\n\nfor how the hooks are set up.\n\nCodeGraph\n\n[CodeGraph](https://github.com/colbymchenry/codegraph) parses your codebase into a graph of nodes and edges (symbols and their relationships) stored in a local SQLite database. When you ask a structural question such as \"what calls this function\" or \"what would break if I changed this\", Claude can query the graph directly instead of grepping and reading through files to piece the answer together.\n\nWhile this tool does not offer a token savings report, my understanding is that it helps because querying a database is a more direct path to the answer than searching and reading files. It also tends to be faster.\n\nHere's an example of the model using CodeGraph to trace a \"share plan\" flow across controller, serializer, and nutrition-calculation code, narrowing in on the right entry point over several calls:\n\n**How does Claude know to invoke codegraph?**\n\nAfter running the `init`\n\ncommand, CodeGraph adds a gitignored `.codegraph/`\n\ndirectory to your project root containing `codegraph.db`\n\n. Since it's just a SQLite file, you can open it yourself with any SQLite tool. For example, I used [DBeaver](https://dbeaver.io/) to open it and inspect the first few rows of the `nodes`\n\ntable:\n\nLike rtk, CodeGraph adds itself to your project-level `CLAUDE.md`\n\nso it's part of every session in that repo. It does this by adding the following section at the end of your `~/.claude/CLAUDE.md`\n\nfile:\n\nIt also runs a background process that watches your files and keeps the graph in sync as you edit. You can see it with `ps aux | grep -i codegraph | grep -v grep`\n\n(condensed here to just the CPU/MEM columns):\n\n```\n0.0  0.2  .../codegraph-darwin-arm64/node --liftoff-only .../codegraph.js serve --mcp\n```\n\nSettings and Habits\n\nThis section walks through some of the settings and habits I've developed to further reduce token usage.\n\nDefault to Sonnet\n\nI used to default to Opus, and then try to remember to switch to Sonnet for simpler tasks, but kept forgetting and burned Opus-level tokens on stuff that didn't need it. Since then I've learned Sonnet is good enough for the majority of day-to-day work, so now it's my default, with effort set to `medium`\n\nrather than the default of `high`\n\n.\n\nSet advisor to Opus\n\nClaude Code has an [advisor](https://code.claude.com/docs/en/advisor) feature. With it set to Opus, Sonnet handles the day-to-day and delegates Opus in when it hits something that genuinely needs the stronger model. Use `/advisor`\n\nto set this. Here's an example of Sonnet calling advisor mid-task, catching an untested edge case before wrapping up:\n\nThe effect is you get cheaper execution most of the time, since Sonnet is doing the bulk of the work, and you only pay Opus rates for the parts that actually need it.\n\nScope your prompts\n\nNot every question needs the full history of a task loaded in. If you're reviewing one piece of PR feedback on a single method, you don't need the entire planning discussion or every commit that led up to it. The more narrowly you can scope what's relevant to the actual question, the less gets sent as input on every turn of that conversation. This one takes some judgment. There isn't a command for it. It's more about noticing when you're carrying context that has nothing to do with what you're currently asking.\n\nRun /context periodically\n\n`/context`\n\nshows you what's currently loaded into the context window during a session. This is worth checking on longer sessions because loaded context counts as input tokens, and it gets resent on every message in that conversation.\n\nRunning this at work is what led me to the biggest single win I found, covered next.\n\nAudit your CLAUDE.md\n\nMy team's project-level `CLAUDE.md`\n\nhad accumulated a lot of `@`\n\nreferences over time: frontend docs, analytics how-tos, Stripe subscription details, third-party integration guides, and more. Each `@`\n\nreference tells Claude to load that file's contents into every session automatically, even if not relevant to the question at hand.\n\nI had Claude audit the file and help whittle it down. First pass: some of those `@`\n\nreferences turned out to be redundant, already covered by Rails-specific skills we had set up in the project. For the rest, the fix was to reword them from always-load references into conditional ones. For example, *\"When asked about subscriptions, read path/to/subscriptions-doc.md.\"* Claude only pulls that file in when it's actually relevant to the question being asked.\n\nTo make sure I wasn't losing fidelity in the process, I asked Claude to generate sample prompts that I could run after the file was trimmed down, to confirm it could still find the same details as before. I also had Claude check its own context size before and after the edits, then share those numbers in the PR description so my team could see the impact. Here's a snip from one of the PR's I submitted to edit the project level `CLAUDE.md`\n\nto reduce the amount of context it was consuming:\n\nThis one is definitely worth doing if you're on a team because it's not just your own savings. It multiplies by every team member, on every conversation, for as long as that file stays bloated.\n\nClear often\n\nClaude Code doesn't hold state between messages the way you might assume. The model is stateless, so the only way to maintain continuity in a conversation is to resend the entire thing each time you ask something new. A long-running session doesn't just accumulate context, every additional message costs more than the last, even if the new message itself is short.\n\n`/clear`\n\nwhen you finish a task or switch to a new one. I'll also clear mid-task if I'm taking a different approach on the same problem, even before it's done, if the earlier back-and-forth isn't useful anymore.\n\n**Nuance:** Prompt caching softens the resend cost somewhat. Cached portions of a conversation are cheaper to resend than fresh input, but there's still a (smaller) cost to writing to the cache, and cached entries expire after a TTL that varies by plan. The [documentation](https://code.claude.com/docs/en/prompt-caching) goes into more details, but the short version is that while caching helps, it doesn't eliminate the cost of a long conversation.\n\nIs It Working?\n\nAt this point you may be wondering: Is all this effort actually worth it, is it really saving anything? In my case the answer is a resounding yes. The chart below (which you can find from the Claude Desktop usage view for Enterprise plans) shows my daily spend by model. There's a clear cluster of high-cost days around mid-June, before I started optimizing, followed by a noticeable drop in daily cost once I started applying these techniques:\n\n**Haven't tried yet**\n\nA few more things on my radar that I haven't gotten to yet, but seem like they would also be helpful:\n\n[Headroom](https://github.com/headroomlabs-ai/headroom): another token-efficiency tool, similar territory to rtk and Caveman.[Tool Search Tool](https://www.anthropic.com/engineering/advanced-tool-use): Anthropic's own guidance on trimming token usage from tool definitions.`/checkup`\n\n(alias`/doctor`\n\n): flags further inefficiencies in your setup, like unused MCP servers and skills. See[this X post](https://x.com/bcherny/status/2074997570317779038)for further details.\n\nSummary\n\n| Tool / technique | Saves | What it does |\n|---|---|---|\n|\n\n[Caveman](https://github.com/JuliusBrussee/caveman)[CodeGraph](https://github.com/colbymchenry/codegraph)[Claude Monitor](https://github.com/Maciek-roboblog/Claude-Code-Usage-Monitor)[advisor](https://code.claude.com/docs/en/advisor)→ Opus`/context`\n\n`CLAUDE.md`\n\n`@`\n\nreferences with conditional, on-demand ones`/clear`\n\noftenMost of what's here I picked up from the [Code newsletter](https://codenewsletter.ai/subscribe). Sign up if you want more like this.\n\nClosing thoughts\n\nIf you're feeling exhausted reading this, I don't blame you. Learning to use AI tools effectively is already a big shift in how software engineering gets done. And just as that starts to feel normal, here comes another layer: \"also, watch your spending,\" and a laundry list of further things to incorporate.\n\nAn analogy I keep coming back to: a high-efficiency washing machine uses less water by design. You don't buy a separate gadget and bolt it onto your washer to make it use less water. It's just built that way. I'm hoping token efficiency eventually gets baked into the AI tooling the same way, so we can spend less time watching meters and more time focused on shipping things that solve problems for the people using our software.", "url": "https://wpnews.pro/news/i-stopped-running-out-of-tokens", "canonical_source": "https://danielabaron.me/blog/how-i-stopped-running-out-of-tokens/", "published_at": "2026-07-20 15:48:41+00:00", "updated_at": "2026-07-20 15:55:42.364440+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-tools", "ai-products", "developer-tools"], "entities": ["Claude", "Claude Enterprise", "Claude Code Usage Monitor", "rtk", "VS Code"], "alternates": {"html": "https://wpnews.pro/news/i-stopped-running-out-of-tokens", "markdown": "https://wpnews.pro/news/i-stopped-running-out-of-tokens.md", "text": "https://wpnews.pro/news/i-stopped-running-out-of-tokens.txt", "jsonld": "https://wpnews.pro/news/i-stopped-running-out-of-tokens.jsonld"}}