One thing gets old fast when you work with several AI tools in parallel: you never really know, at a glance, how much usage you still have left. Claude is on one side, Codex on another, Gemini somewhere else, Cursor has its own story, and before long you are juggling dashboards, tabs, and accounts just to check something that should be obvious.
That is why PocketMeter is such a smart idea. Instead of burying that information inside yet another admin panel, it pulls it out of the browser and puts it physically on your desk with a small AMOLED display and an ESP32 board. You see it while you work, without breaking focus and without that low-grade anxiety of wondering whether a session is about to die halfway through.
The nice part is that this is not some closed gadget or a throwaway demo. The project is open source, it builds on an earlier idea called Clawdmeter, and the architecture has been reworked enough to fit real-world use much better: WiFi, a local daemon, a web panel, and support for several providers instead of stopping at Claude.
What PocketMeter Actually Is
PocketMeter is a physical usage meter for AI tools. The hardware base is a Waveshare ESP32-S3-Touch-AMOLED-2.16, which already comes with a battery, a display, and a compact format that makes sense on a desk without turning the whole thing into a weekend soldering project.
The clever bit is not just the device itself, but how the work is split. On one side you have firmware running on the ESP32 and rendering the interface. On the other side there is a Python daemon running on your computer, reading local credentials or API keys, checking provider status, and sending the payload to the device over WiFi. On top of that, there is also a local web panel at http://localhost:8080 where you can manage part of the configuration without digging through random files by hand.
Put simply: the ESP32 shows the information, but your computer is the part that actually gathers it. That separation makes a lot of sense because it keeps the device lightweight while still letting you reuse the logins or tokens you already have on your machine.
Why This Makes More Sense Than Yet Another Dashboard
Yes, desktop apps already exist for showing usage and limits across different services. The problem is that they still live inside your computer, usually in one more window you do not open until it is already too late. And that is exactly the important point.
When a critical part of your workflow depends on usage limits, the last thing you want is to remember to check them only after something breaks. Having a physical object in front of you changes that quite a bit. Not because it performs magic, but because it turns hidden information into a visible signal that stays in your field of view all the time.
There is also a slightly silly but very real factor here: it is fun. There is something undeniably good about having a small device on your desk showing how Claude, Codex, DeepSeek, or whichever provider you use is doing. Everything does not need to be terminal asceticism and black-window suffering all day long.
From Clawdmeter to Something Much More Serious
PocketMeter did not appear out of nowhere. The starting point was Clawdmeter, an open source project that already explored the idea of measuring Claude usage with a physical device. The difference is that this is not the usual cosmetic fork where somebody changes two colors and ships a new name. Meaningful parts have changed.
The biggest change is how the device talks to the computer. The original idea leaned on Bluetooth as the main transport, while PocketMeter goes down the WiFi + HTTP + local daemon route. That is a much cleaner fit for real usage, avoids relying on a permanently awkward Bluetooth connection, and opens the door to a more comfortable web interface for managing providers, pets, visibility, and other settings.
The scope is different too. Instead of stopping at Claude, the project already accounts for several services such as Codex, Gemini, Copilot, Grok, OpenAI, DeepSeek, Cursor, or even names like Kimi, always depending on whether valid local credentials exist or whether the relevant APIs actually expose useful metrics. That last part matters, because not every provider gives you the same data, and certainly not in the same way.
The Most Entertaining Part: Customization and Pets
This is where the project gets a little nerdier and a lot more charming. PocketMeter does not stop at bars and numbers; it also lets you assign pets and animations to the device. Some of those assets come from the broader Clawd ecosystem, and there is also integration with PetDex to search for sprites and convert them into a format the device can actually use.
That may sound like a minor detail, but it gives the gadget personality and keeps it from feeling like just another generic screen bought off a marketplace. And if you spend all day working with these tools, having a bit of visual identity on your desk is exactly what turns the project from a technical experiment into something you genuinely want to keep using.
There is, of course, a perfectly normal limitation here: once you shrink sprites or animations down to the resolution the hardware expects, some pets look worse than they do in the original source. That is not a mysterious bug or some grand tragedy. It is simply the price of fitting pixel art and animation into a small display with finite resources.
How to Install It Without Making It Harder Than It Is
The installation is not especially difficult, but it helps to understand the flow properly. First you prepare the ESP32 firmware with your WiFi settings, then you flash it, and after that you bring up the local stack on your computer, which handles both the web panel and the daemon that pushes the data.
If you are on macOS and want the easy route for installing PlatformIO, Homebrew does the job:
brew install platformioThen clone the repository and move into it:
git clone https://github.com/edunavajas/PocketMeter.git
cd PocketMeterBefore flashing anything, copy firmware/src/wifi_credentials.h.example to firmware/src/wifi_credentials.h and put your WiFi credentials there:
#define WIFI_SSID "YourWiFiNetwork"
#define WIFI_PASSWORD "YourPassword"If you want to change the device hostname too, that is the part that still lives in firmware/src/config.h:
#define WIFI_HOSTNAME "pocketmeter"Once that is done, the normal route on macOS is to use the helper script:
./flash-mac.shIf you want to set the port manually because your system woke up in a bad mood, you can do that too:
./flash-mac.sh /dev/cu.usbmodem1101Once the firmware is on the device, the next sensible step is to start the full local stack:
./daemon/pocketmeter-stack.shThat brings up the web panel on http://localhost:8080 together with the multi-provider daemon that detects the ESP32 and keeps sending it data. From there, you can sign in to the providers you use or save their API keys directly from the panel.
Note: the author points out one very grounded but important detail: for flashing, not every USB-C cable behaves equally well. If the board is not detected, do not start blaming the gods of embedded systems. Try another cable first.
Also worth knowing: this board connects to the network configured in the firmware and, in practice, if your router splits bands, the safe bet is usually the 2.4 GHz network.
What It Feels Like on a Real Desk
The interesting part of PocketMeter is not the setup, but the effect it has once it is already working. Suddenly you stop treating usage like a number hidden somewhere inside an account page, and it becomes part of your working context. It is just there, visible all the time.
If you work heavily with tools like Claude Code, Codex, or several providers at once, that has more value than it may seem. Not because the gadget magically makes you a better programmer, but because it removes a bit of mental friction. You know what is left, you notice when something is disconnected, you can tell when a login is missing, and you stop working blind.
I also like that the project does not try to oversell itself with fake productivity mythology. At heart, yes, it is a desk toy and a technical indulgence. But that is exactly why it works so well as a maker project: it mixes hardware, software, automation, visual design, and a small but very recognizable real need for anyone who spends their day bouncing between CLIs, models, and usage limits.
The Most Valuable Part Is Not the Board
The most valuable idea here is not the ESP32 itself, but the decision to move important information outside the main screen. That pattern applies to far more than AI usage. Today it is model consumption. Tomorrow it could be deployment status, test results, job queues, or any other signal you want kept visible without opening yet another tab.
That is where projects like this stop being casual tinkering and start becoming a healthy way to think about products. You notice a small but recurring annoyance, build a purpose-made fix for it, and learn along the way about firmware, local communication, physical UX, and automation. Not bad for something that, at first glance, looked like a cute gadget with pixel pets.
Conclusion
PocketMeter feels like one of those projects that grabs your attention because of how it looks, but sticks in your head because the idea is genuinely solid. Yes, it has that nerdy desk-gadget appeal. Yes, the little pet next to your usage is part of the charm. But under that, there is a very good product decision: take a scattered, annoying piece of information and turn it into something visible, simple, and useful while you work.
If you enjoy mixing programming, hardware, and AI tools, this is exactly the kind of project worth messing with. And if you live inside Claude, Codex, Cursor, and similar tools all day, you will probably understand in about ten seconds why having usage in front of you is more useful than it sounds.
If you want to build one, the video is right there above and the public repository is open for you to tweak however you like. And if you can think of a better idea, another provider to integrate, or a more ambitious spin on the device, then you already know the drill: comment, fork, or PR.
What do you think?
Leave your opinion, question or suggestion. Comments are synced with GitHub Discussions .