DEV Community: John

How to Track Claude Code Token Usage Before It Surprises You

John — Thu, 21 May 2026 20:16:42 +0000

Claude Code and Codex are getting good enough that the real problem is no longer whether the agent can do the work.

The problem is knowing what it is burning while it works.

Most developers only check usage after the session is already expensive. That is backwards. If an agent is running for an hour, switching models, hitting reset windows, or quietly chewing through context, the useful number is the one you can see while you are still working.

The visibility gap

Built-in usage commands are useful, but they are usually reactive. You run a command, check a dashboard, or dig through logs after the fact.

That is fine for audits. It is not great for live work.

When I am using AI coding tools, the questions I want answered immediately are:

how fast am I burning tokens?
which model is doing most of the work?
am I close to a reset or limit?
is this session becoming expensive enough to stop and rethink?
is my Mac also getting cooked by the workflow?

Those are tiny signals, but they change behavior.

Why a menu bar view works

A menu bar token tracker is boring in the best way. You do not need a new dashboard. You just need the number to stay visible.

If usage is always one glance away, you catch runaway agent loops earlier. You notice when a simple task turned into a huge context burn. You stop treating token usage like a mystery bill.

That is why I built TokenBar for macOS.

It keeps AI usage, credits, reset windows, top model/activity, and Mac load visible from the menu bar while you work.

Who it is for

TokenBar is most useful if you:

use Claude Code, Codex, Cursor, or agent-heavy workflows
run long coding sessions
care about token spend before the invoice arrives
want live visibility instead of another analytics tab

It is a small Mac utility, not an enterprise observability platform. That is the point.

If you want to try it, it is here: https://tokenbar.site

The bigger lesson: AI coding tools are becoming powerful enough that usage visibility should be ambient, not something you remember to check later.

I built a $2.99 Mac app that warns before one AirPod dies

John — Thu, 21 May 2026 04:02:13 +0000

The most annoying AirPods failure is not that the battery dies.

It is that one AirPod silently fails to charge, and you only find out when you are already leaving, joining a call, sitting in class, or starting a workout.

You open the case and see something like:

Left AirPod: 100%
Right AirPod: 18%
Case: charged

At that point the fix is obvious, but too late. Reseat the AirPod, clean the contact, switch headphones, or delay the call.

So I built AirPod Guard, a tiny macOS menu bar utility for this exact problem.

It watches the battery levels macOS exposes for:

left AirPod
right AirPod
case
last checked time

Then it warns you when the pattern looks wrong, especially when one side is much lower than the other.

The point is not another dashboard. The point is a simple Mac notification while the case is still on your desk.

Use cases:

catch a low AirPod before a Zoom, FaceTime, Discord, or client call
avoid starting a commute with one side dying
avoid a one-sided gym session because one bud did not seat properly
stop opening Bluetooth settings just to guess what charged

It runs locally, has no account, no analytics, and costs $2.99 lifetime.

Site: https://www.airpodguard.com

If you use AirPods with a Mac every day, this is a tiny fix for a very specific irritation.

I added Mac heat and system load to my AI token tracker

John — Tue, 19 May 2026 01:59:11 +0000

I built TokenBar because I wanted one small place to answer a boring but important question:

What is my AI workflow actually using right now?

When you work across Claude Code, Codex, Cursor, OpenAI, Claude, Gemini, OpenRouter, and whatever else gets added to the stack next month, usage visibility gets messy fast. Each provider has its own dashboard, reset window, credits model, and vocabulary. Some tools show tokens. Some show dollars. Some only become clear after you hit a limit.

TokenBar is my attempt to make that visible from the macOS menu bar.

It is a local-first Mac app for tracking AI usage without turning the workflow into a spreadsheet. The menu bar view shows the things I kept checking manually:

current AI usage
remaining credits or limits where available
reset windows
alerts before limits become a problem
top model and activity
provider mix
supported provider and app activity

The new layer I just added is system visibility beside AI visibility.

That means TokenBar now shows CPU, memory, energy pressure, heat, and active apps alongside AI spend and usage. The goal is not to replace Activity Monitor. The goal is to connect two things that usually live in different places.

If I am running an agent loop, editing in Cursor, testing with multiple providers, and watching my Mac get warm, I want to see the AI side and the Mac side in one glance.

In practice, it feels like Activity Monitor for AI spend, tokens, reset windows, and Mac heat.

Why system load belongs next to AI usage

AI tools are not just a line item on a bill. They affect the whole development environment.

Sometimes the expensive part is obvious because a provider dashboard shows a spike. Sometimes the pain is local. The fan spins up. The machine gets sluggish. Energy pressure climbs. A background app is doing more than expected. A coding agent is busy, but the provider dashboard does not tell you why your Mac feels worse.

Putting both views together makes the workflow easier to reason about.

For example:

Is my token usage climbing because I am actively prompting, or because an agent loop is running in the background?
Am I near a reset window, or do I need to slow down for the day?
Which model or provider has been doing most of the work?
Is the Mac under real pressure, or does it just feel warm for a moment?
Which active apps are part of the current workload?

None of these need a giant analytics dashboard. They need a small, persistent readout that is there when you need it and quiet when you do not.

Local-first by design

The app is built as a native macOS utility, not a web dashboard. The data stays local-first, and the interface is meant to be quick enough that you can check it without context switching.

I am building it for people who use mixed AI workflows every day: coding agents, IDE assistants, direct API usage, browser chats, and provider hopping. If your day moves between Claude Code, Codex, Cursor, OpenAI, Claude, Gemini, OpenRouter, and other tools, the value is not another individual provider page. It is a single place to see what is happening.

TokenBar is priced simply: Basic is $5 lifetime, Pro is $15 lifetime.

If this sounds useful, you can check it out here:

https://tokenbar.site/

I am especially interested in feedback from people using multiple providers or running agent-heavy Mac workflows. The next question I am working on is how much signal I can show in the menu bar before it becomes noise.

This is exactly the pain TokenBar is trying to make less absurd on macOS: live token/cost visibility in the menu bar instead of constantly checking usage pages. Nice writeup, especially the status line bit. https://tokenbar.site/

John — Mon, 18 May 2026 00:20:29 +0000

Tommy Leonhardsen

Feb 19

I Got Tired of Guessing My Claude Quota, So I Made a Robot Read It For Me

#claudecode #python #powershell

Comments 6

6 min read

TokenBar | AI Usage Visibility and Spend Awareness for macOS

TokenBar is a macOS menu bar app that helps you keep AI usage, credits, and reset timing visible across OpenAI, Codex, Claude, Gemini, and other supported tools.

tokenbar.site

Claude Code and Codex need a token meter in the menu bar

John — Fri, 15 May 2026 21:47:48 +0000

Claude Code, Codex, Cursor, and agentic coding tools are getting good enough that the bottleneck is not always capability anymore. Sometimes the bottleneck is not knowing what the session is burning until the limit popup or bill shows up.

I keep seeing the same pattern:

a tiny edit sends thousands of tokens
a coding agent quietly eats a big chunk of quota
a long context window turns into invisible spend
the user only notices after the session is already expensive

That feels wrong. Token usage should be visible while you work, the same way CPU, memory, battery, or network status are visible when they matter.

That is why I built TokenBar.

It is a small macOS menu bar app for watching Claude, Codex, Cursor-style LLM token usage without opening a dashboard every few minutes.

Site: https://tokenbar.site/

It is $5 lifetime. If it is not useful, I will refund it.

The goal is simple: catch runaway usage before it becomes a surprise.

I built a $5 macOS menu bar app because AI coding token usage kept surprising me

John — Fri, 15 May 2026 15:00:33 +0000

I kept running into the same tiny problem while using Claude Code, Cursor, Codex, and other AI coding tools:

I had no good feel for how large a prompt was getting until after I sent it.

That matters because token usage is not just a billing detail. It changes how fast you burn context, how noisy a session gets, and how surprising the final cost can feel.

So I built TokenBar, a small macOS menu bar utility that keeps token count visible while you work.

Why this exists

AI coding turned a lot of dev work into prompt shaping.

You paste a stack trace, a few files, maybe a spec, maybe a transcript, then suddenly the prompt is not small anymore.

The annoying part is that the meter is usually hidden somewhere else. You only notice token burn after the fact.

I wanted the opposite:

visible while writing
native macOS menu bar
simple enough to keep open all day
useful for Claude, Cursor, Codex, OpenAI, and other LLM workflows
one-time price, not another subscription

What TokenBar does

TokenBar gives you a quick way to check token usage from the menu bar so you can trim giant prompts before sending them.

It is not trying to be a giant analytics dashboard. It is more like a tiny odometer for AI work.

If you are using AI coding tools all day, that small bit of visibility changes behavior fast. You start noticing bloated prompts before they waste context.

Who it is for

TokenBar is mostly for developers, solo founders, and anyone using AI coding tools heavily on macOS.

If you have ever thought:

“How big is this prompt?”
“Why did this session get so expensive?”
“Am I about to blow the context window?”
“I wish I could see the token count before sending this”

That is the use case.

Try it

TokenBar is $5 lifetime for macOS.

https://tokenbar.site/

I would genuinely like blunt feedback from devs using Claude Code, Cursor, Codex, or similar tools every day.

The calorie log has to survive bad lighting

John — Mon, 11 May 2026 14:56:28 +0000

The cleanest demo for an AI food logger is usually a bright plate on a table.

That is not the moment that decides whether someone keeps using it.

The real test is a late dinner under bad kitchen lighting. A half eaten bowl. Leftovers in a container. A packaged snack you grabbed between calls. A meal where you remember most of it, but not enough to feel confident typing every ingredient from scratch.

That is where a lot of calorie tracking products quietly lose people.

Not because the user stopped caring. Not because one estimate was a little off. They quit because the next step felt like admin.

If the app says, in effect, "give me a perfect photo or go do data entry," the habit breaks fast.

I think the better pattern is to let the user be imperfect first.

Start with the fastest input they have:

take a photo when the food is visible
scan a barcode when it is packaged
type a rough meal from memory when the moment is already gone
correct the result quickly instead of rebuilding the whole log

That last part matters more than the first scan.

A nutrition app can look impressive when it guesses a polished meal. But retention comes from the correction path after a normal meal. Can the user fix the portion? Can they swap an item? Can they log something boring in ten seconds and move on?

MetricSync is built around that less glamorous moment.

It is an iPhone AI nutrition tracker with photo, barcode, and text logging, plus fast correction for real meals that do not behave like demos. The goal is not to pretend every estimate is final. The goal is to make logging easy enough that the user does not drop the habit when dinner is messy.

It is also cheaper than CalAI and has a 3 day free trial.

If you are trying to track food consistently, the winning product is not the one that only works when the plate looks perfect.

It is the one you can still use when the lighting is bad, the portion is fuzzy, and you just want to be done.

MetricSync: https://www.metricsync.download/

The best food log lets you be imprecise first

John — Mon, 11 May 2026 08:06:24 +0000

I have been thinking about the moment where most calorie tracking apps quietly ask too much from the user.

It is not usually the first clean demo. A single plate, good lighting, obvious ingredients, and a motivated user is the easy case. The harder case is when someone is already tired, already hungry, or already halfway through the day and they only remember the meal in fragments.

That is the moment where precision can become friction.

A lot of food logging products act like the user should know the exact answer before they start logging. Exact portion, exact brand, exact sauce, exact serving size, exact everything. That sounds responsible, but in real life it can make the first step feel heavier than the meal itself.

For MetricSync, I wanted the first step to be allowed to be rough.

Take a photo if the plate is still in front of you. Scan a barcode if it was packaged. Type a quick note if the food is gone and all you have is memory. Then fix the parts that matter.

That sounds small, but it changes the feeling of the product.

The goal is not to pretend every first estimate is perfect. The goal is to make the path from messy input to useful log short enough that people actually stay with it. If the user has to stop their night to become a nutrition data-entry clerk, the app already lost.

This is also why I think AI nutrition apps should not treat manual correction as an edge case. Correction is part of the product. A good estimate that is easy to adjust beats a confident estimate that is annoying to fix.

Some examples that shaped the way I think about it:

A sandwich where the bread is obvious but the sauce is not
A takeout bowl where the rice and protein are easy, but the oil is a guess
A packaged snack where barcode is faster than camera
A meal logged from memory two hours later
A shared plate where the real serving was half of what the photo shows

None of these are rare. They are normal eating.

That is the founder lesson for me: nutrition tracking retention is less about impressing someone with one scan and more about respecting the messy second, third, and tenth logs.

MetricSync is my attempt at that. It is an AI food logger for iPhone with photo logging, barcode scanning, text input, quick corrections, and a 3 day free trial.

If you are comparing AI calorie trackers, the question I would ask is not just "how good is the first guess?"

I would ask: "how fast can I turn an imperfect meal into a log I trust enough to keep going?"

That is the part I care about building.

https://www.metricsync.download/

The meal you log from memory is the one that matters

John — Mon, 11 May 2026 04:55:14 +0000

Most calorie tracking products are built around the best case meal.

Clean plate. Good lighting. Clear portions. You remember what everything was. You have enough patience to fix the estimate if the app misses something.

That is not the meal that decides whether someone keeps using a food logger.

The harder meal is the one you log from memory at the end of the day.

You ate in a rush. The sauce was mixed in. Half the snack was packaged and half was not. You remember the shape of the meal better than the exact portion. You know enough to make a useful entry, but not enough to turn logging into a research project.

That is where a lot of calorie trackers become annoying.

If the app only works when the user gives it a perfect photo, it is fragile. If it treats barcode scan like a backup path, it is backwards. If every correction feels like admin, the habit starts to slip.

MetricSync is built for those normal messy meals.

You can log with a photo when that is easiest. You can scan a barcode when packaged food is the honest source. You can type a quick note when the meal already happened. Then you can correct the result without turning the entry into a chore.

That correction path matters more than people give it credit for.

AI food logging is not useful because it can produce a confident first guess. It is useful when it helps someone create a reasonable log fast enough that they actually keep doing it.

A close estimate that is easy to fix beats a magical estimate that is painful to edit.

That is the product direction behind MetricSync: flexible logging, quick correction, and less friction around the meals people normally skip.

It is cheaper than CalAI, includes more logging paths, and has a 3 day free trial.

If you are trying to track food without making every meal feel like paperwork, you can try it here:

https://www.metricsync.download/

AI coding sessions need an odometer

John — Mon, 11 May 2026 04:06:52 +0000

Most AI coding tools still feel like driving without an odometer.

You can move fast. You can cover a lot of ground. But unless you are checking a dashboard after the fact, you do not really know how much distance you burned getting there.

That matters more than it sounds.

A lot of AI waste does not show up as one dramatic mistake. It shows up as a session that slowly gets heavier:

old logs still sitting in context
files pasted once and carried forever
three retries after the answer was already good enough
switching to a bigger model because the current chat is muddy
asking for one more polish pass when the work is basically done

By the time you notice the bill, the useful decision already passed.

That is why I built TokenBar as a tiny macOS menu bar app instead of another end-of-month dashboard.

I wanted the signal while I was still working.

If a simple bug fix starts turning into a huge token session, I want to see that early. Maybe the right move is to restart with a cleaner brief. Maybe it is time to trim context. Maybe I should stop asking the model to clean up a task that is already solved.

The point is not to obsess over every token.

The point is to make token usage visible enough that it changes behavior in the moment.

AI tools are getting faster, bigger, and cheaper, which is great. But bigger context windows can also hide sloppy workflows for longer. When there is no live meter, waste feels invisible until it becomes normal.

TokenBar is my attempt to add that missing odometer for AI work.

It sits in the macOS menu bar and shows live token usage while you work, so you can catch bloated sessions before they quietly become your default workflow.

If you build with AI on a Mac, it is here:

https://tokenbar.site/

I built MetricSync around the meals people are too tired to log

John — Mon, 11 May 2026 03:20:32 +0000

Clean demo meals are not where calorie tracking apps win or lose.

The real test is the late dinner, the post-workout snack, the half-finished bowl, or the packaged food you only have patience to scan because typing everything out feels like admin.

That is the situation I kept designing around with MetricSync.

The goal is not to pretend AI gets every meal perfect on the first try. The goal is to make logging fast enough that you still do it when your motivation is low, then make corrections painless when the first estimate needs cleanup.

So MetricSync supports photo logging, barcode scanning, and quick text input. If a meal is messy, packaged, split, or just not worth staging for a perfect photo, there is still a path that works.

That matters because nutrition tracking is mostly a retention problem. People do not usually quit after one imperfect estimate. They quit when the next meal feels like work.

MetricSync is an iPhone AI nutrition tracker with a 3 day free trial: https://www.metricsync.download/

If you have tried food logging apps before, I am curious where they usually lost you: bad estimates, too much typing, weak barcode coverage, or just the daily friction?

The meal that breaks calorie tracking is usually the boring one

John — Mon, 11 May 2026 02:54:48 +0000

Most calorie tracking apps are judged on the wrong meal.

The demo meal is clean. A plate is centered, the lighting is good, the portions are obvious, and the app gets to look smart.

That is not the meal that decides whether someone keeps tracking.

The real test is the boring one. The half sandwich between meetings. The leftovers eaten standing up. The packaged snack you do not want to photograph. The dinner where the sauce matters more than the photo. The meal you almost skip logging because it feels like admin.

That is where calorie tracking habits usually break.

A food logger can be impressive on the first estimate and still lose people if the correction path is annoying. If the user has to fight the app after every close-but-wrong guess, they stop trusting it. Worse, they stop opening it.

That is why I think the best AI nutrition trackers are not just camera-first products. They need to be correction-first products.

Sometimes a photo is fastest. Sometimes barcode scan is the honest answer. Sometimes typing "two eggs and toast" is less friction than staging a perfect image. The product should meet the meal, not force every meal into the same input path.

MetricSync is built around that idea: log with photo, barcode, or text, then fix the result quickly when real life is messier than the demo.

The goal is not pretending AI gets every portion perfect on the first try. The goal is making the second step painless enough that users keep the habit.

Because the boring meal is the one that compounds. If someone logs that meal, they probably log the next one. If they skip it, the whole day gets fuzzy fast.

MetricSync has a 3 day free trial here: https://www.metricsync.download/

If you are building in health or habit tracking, I would bet retention is hiding in the boring flows, not the flashy demo moments.