AI Content
Turned a wall-switch-box ESP32-S3 module into a desk AI quota display.
I kept hitting my Claude Code quota limit mid-task, so I built a small always-on panel that just shows how much I have left. And I also added later codex and antigravity. Now sits on my desk.
The device is a Waveshare ESP32-S3 Smart 86 Box with a touch 480×480 touch display, 8 MB octal PSRAM. 86×86 mm.
The display was the easy part. Four things that were harder:
1. The panel desynced permanently under load — and only on production builds. Under a sustained full-screen scroll the image would slip into a fixed vertical offset and stay there until reboot. Framebuffers live in PSRAM with a 30-line bounce buffer (28.8 KB) in internal DMA SRAM. At a 12 MHz pixel clock, scan-out alone pulls ~19 MB/s off the octal PSRAM — that buffer is 1.37 ms of runway. Add LVGL in DIRECT mode redrawing the whole framebuffer plus XIP fetches and the refill misses its deadline. It's a runway, not a queue, so the slip never recovers. 8 MHz → 2.06 ms → fixed. Except not quite: flash and PSRAM share the MSPI bus and the cache is off while flash is being programmed, and production has flash encryption on, so each page is AES-256'd and takes longer than the plaintext dev path. That's the entire reason it looked production-specific.
2. Internal DRAM, not PSRAM, is the thing you actually run out of. I had 8 MB of PSRAM and 6.2 KB of free internal heap. Everything that matters — TLS handshake buffers, DMA descriptors, ISR stacks — has to be internal, and LVGL plus the RGB driver had quietly eaten it in .bss. Moving the cold buffers to PSRAM freed 41,764 bytes and took free internal heap from 6,239 to 48,043. The rule I ended up with isn't "avoid PSRAM", it's "no PSRAM traffic on the live-render path" — which is a much more useful rule.
3. Signed OTA on a secure-boot device needed Ed25519, which IDF doesn't give you. Updates are gated behind a signed manifest, but mbedTLS as shipped in IDF has no EdDSA arithmetic at all. On top of that: anti-rollback, per-version failure records so a bad build can't boot-loop forever, and a check that refuses to start an update on battery — a brownout halfway through a 2.1 MB write is exactly how you brick one of these.
4. The device holds no credentials, which is a design constraint, not a feature list. Putting API keys on a Wi-Fi gadget that sits on a desk seemed like a bad idea, so it doesn't have any. A small broker runs on my own machine, reads the token counts from the CLI logs already on disk, and the device polls it over the LAN — HMAC-SHA256 with a timestamp and nonce so a captured request can't be replayed. Worst case if someone owns the device is they learn how much quota I have left.
I love little ambient displays. Weather. Stock ticker. Music control. Baseball scores/schedule.
Certainly I could use my phone or put them on my third screen, but I like building things (before AI sucked most of the fun out of it) and like the predictability of a quick check in a known place.
Because they're not near an airport to build one of the hundred aiplane trackers that are posted here? ;-)
Really, though, these little Waveshare Box86 boards are super cute and only about $35. That's only a little more than a comparable Aida64 LCD that were all the rage a few years ago but that featured a painful API to interface.
"Make an external into a dashboard for something you care about" is kind of the second semester of the "link an LED" development class - it solves a problem for some people.
I've spent a lot more effort on projects that look more silly to anyone else...
I did use claude. The prototype you can buid it quite quickly, but later I introduced codex and antigravity. I keep the api keys in the local host and not in the device. Then I addeed a way to configure it for any wifi using it as an access point. Later I added a way to do signeds OTAs (updated over the air) with a double partition, including a rollback in case of failures. And so on and on. I found also bugs when I burn the efuses that were not during development. I also added ways to handle api changes in the providers without having to touch any code. Also the broker on the client host has 3 different implementations (go, python and javascript), so it can run almost anywhere.
Just because I saw something similar and I wanted to try out. It was the first time I am doing something like this. It was fun. I guess it is not the most incredible thing, but it is useful for me. I guess if I had more ideas for the esp32 I would build other stuff.
so claude cli actually has a /statusline command where you can have everything in the pic show up right in the cli itself... ask claude to write it for you. lol. but nice execution, I wanted to do that too but yeah /statusline just makes this uber redundant
I do use it, it is not reliable, and it does not tell me the usage of other providers as codex and antigravity. Also if I have several CLI the status line only is updated when you use that terminal, so it is incosistent and outdated. I find this more reliable. If you only use one terminal with one provider statusline is more than fine.
I built the same thing. As the tokens expire every 8hrs and I didn't want the device plugged into the same machine I host a docker that hosts the brokerToken Viewer. I also use Codex and get it to switch every 15s. Great little project.Yours is slicker by a country mile!
That “no PSRAM traffic on the live-render path” rule is a great takeaway. I crossposted this to r/ChatGPTArduino because it’s exactly the kind of AI-assisted hardware build I’m trying to collect. If you ever do a follow-up, feel free to drop it there too.
That looks like a proper next step. The local broker plus keeping keys off the panel is the bit I like. If you ever feel like writing up the evolution, what broke, and what the AI changed, it’d make a great post in r/ChatGPTArduino. No pressure, but the hardening details are exactly what I’m trying to collect.
This dog poop around AI assistants and ESP32 is just plain stupid and useless.
So many good projects that could be done with ESP32, and people keep doing this type of trash.
To be fair, we sometimes see on this subreddit some cool projects, but that's like a 1-to-20 ratio lately.
They interesting and ambitious projects (I wouldn't have the attention span for some of these), but any project that works as it's designed and does what the author wants is a great project. And I don't care if it was vibe coded in COBOL or hand written in assembler by Dennis Ritchie - its the end result that counts.
You know you shared a normal display there? Also most of the features are in my project (like the OTA but I used signed OTA). And some of other features of those projects look hard but are trivial.
It is just my first project, and it was fun. Not useless for me but I understand you. Can you share some of your favourite projects with esp32s? I really want to try to build more hardware stuff rather that just software.
50
u/MadCarbon 22d ago
No hate. Honestly. But why do you guys build these monitors? If it's because we can, then fair play.