Nolen began their writing career in 2019, with three years dedicated to editing the Creative section at MakeUseOf. Their expertise lies at the crossroads of technology and creativity, covering areas like photography, video editing, and graphic design.
Outside of work, you'll often find Nolen diving into a good book, writing their own stories, or playing video games.
Claude Code is pretty upfront about your usage while you're working. If you're using the GUI, there's the little circular usage tracker at the bottom of the chat showing you how much of the current session you've used. And in the terminal you can check your usage with a couple of slash commands. But what these don't do is give you an overview that helps you recognize which habits exactly are draining your usage.
There are other tools available to help you dig into it properly, though. Claude Code has a built-in /insights command that reads your local session history and writes a report on how you use it, including where things tend to go wrong. It doesn't count tokens, though, so I paired it with ccusage, a free community tool that reads the same local files and breaks usage down per session and model.
Insights gave me an html file and ccusage gave me a JSON file - I fed both to Claude to parse properly and give me the proper breakdown of my usage this past month or so. Some of my habits were surprisingly wasteful of my tokens, and your tasks might not be the same as mine, but you might be overlooking these same habits.
The memory file I never opened
And treating the conversation like a memory file instead
Renaming my images and screenshots is one of the jobs I delegate to Claude the most - since Claude came into my life, I simply don't have the patience to type ten variations of "figma pen tool on desktop app" anymore. The Insights command counted a whopping 28 naming requests across the month it looked at (for reference, no other task even made it past 3 requests). My setup is pretty simple: I have a session that sits in my screenshots folder so Claude can see every file that comes in, and it renames each image based on what it sees.
I assumed my screenshot renaming rules only lived in the chat. There's no CLAUDE.md or skill in that folder (yes, I know, not the smartest move) so ending the session meant I would have had to teach Claude everything again. At this point, I just kept opening up the same session out of habit and never bothered to set up any persistent instructions.
It turns out Claude has been saving the rules to its auto memory in a file under .claude in my user folder rather than in the screenshot folder. So it was operating on a set of rules that were already permanent, I just didn’t know it. Auto memory is Claude’s own set of notes, separate from the CLAUDE.md you write or generate per-folder, and it loads into every session.
The lesson here is to, first of all, set up your CLAUDE.md and skills in the actual folder you're working on. The second lesson is to periodically check the memory in the global .claude user folder because that's where Claude automatically saves persistent notes, debugging history, and so on.
Idle chats
The session I never closed
ccusage made the cost of all my laziness obvious. The screenshot session started on September 17 and was still open on October 12, and it accounted for about 90% of my Claude Code usage of the month and over $100 when measured by what it would have cost at API rates. The other 27 sessions combined, vault builds and wireframes included, came to roughly $18 at the API rates. I've been trying some tricks to reduce my rate limits, and turns out the culprit was a seemingly harmless daily session right under my nose this whole time!
Part of that is just how these models work. Claude doesn't remember anything between messages, so every new message sends the entire conversation back. After just one month that's a lot of history that catches a ride along with every batch of filenames. Claude Code uses caching to cut the cost of this, which stores recent context so it can be re-read at a fraction of the regular price.
The catch is that the cache expires when a chat sits idle for about an hour. So every time I'd wander off and come back to the same session, the entire history got cached again at a premium rate. By my math, those rebuilds made up roughly $140 of the session’s API-equivalent cost.
Now that the rules sit in my files, there’s no reason to keep one chat alive. Each batch can get a fresh session, and I’ll frequently run /clear, or /compact when I still need the context, which shrinks the history to a summary. The lesson here is to basically not let sessions sit for days or even weeks on end like I do.
Using Opus for tiny tasks
No use running a premium model on the simplest chores
My model breakdown revealed another thing I didn't think much of. I keep coming back to my screenshot folder because it's the clearest example of where I keep messing up: that entire session ran on Opus 4.7, which is billed at $5 per million input tokens. Now, it was actually a deliberate choice because Opus is less chatty and friendly than Sonnet, and it's thorough without the rambling I used to get from older Opus models.
But conciseness didn't actually matter here. Claude's replies on their own, without the rebuilds and cache reads, cost under $4 across the whole session, so even a much wordier model wouldn't have moved the total much. Most of the other costs came from Claude just reading all the stuff I pointed it at. Sonnet 5.5 is listed at $2 per million input tokens, which would put the same session somewhere around 40% of the cost, give or take.
There's honestly no reason to not pick a lighter model for the lighter tasks.
Your best workflow is probably the priciest one you have
The Insights command filed my screenshot setup under "Impressive Things You Did", which isn't entirely wrong, it was a pretty efficient system. But usage wasn't part of that picture until ccusage put a number next to it. I think it's worth running both if you've got one workflow you lean on constantly - you might be surprised by some wasteful habits.
