@duggan — claude-code

microgpt on the ESP32 – but... why?

2026-03-03T11:17:43.000Z

Yesterday I was looking at the zclaw project, and I thought it would be cool if the ESP32 could run an actual language model instead of phoning out to OpenAI, Anthropic, or some other provider.

Then I remembered that Andrej Karpathy had dropped microgpt a couple of weeks ago, and thought it might be fun to try and get a GPT running on the ESP32. I've got a couple of them lying around from a few other tinkering projects, as well as a functioning ESP32 Rust project to base it on.

I am very much the dog-on-computer meme regarding this stuff. I have trained and run LLMs for years, but I have not tried writing them. I have the general idea, tokenizers, transformers, gradient descent, yada yada, but they're mostly just words.

With the blog post and my other project as a starting point, it was, however, pretty easy to get to a functional port of microgpt training and then generating a continuous stream of names on the ESP32!

The code is here, and the Claude session that produced the first functioning variant of the project is below:

rockstar.ninja

For a fun technical challenge, and based on our work in ~/Projects/stripe-dashboard, and the informa

opus 4.6 · haiku 4.5 · 92 turns · For a fun technical challenge, and based on our work in ~/Projects/stripe-dashboard, and the information in https://k...

rockstar.ninja

I also had a fresh session of Claude conduct a review, which spotted that the implementation was missing RMSNorm, and filled in the gaps:

rockstar.ninja

Let's do a thorough review of this repository, and evaluate whether it meets the goal of reproducing

opus 4.6 · haiku 4.5 · 48 turns · Let's do a thorough review of this repository, and evaluate whether it meets the goal of reproducing microgpt on the ...

rockstar.ninja

#What's the point?

Well, I learned that training a language model on an ESP32 is something that can be done. I did not know that yesterday. I also found this is not by any means the first or even most interesting attempt. David Bennett used a slightly larger ESP32 variant (1MB of RAM, still minuscule) to spit out 20 tokens a second of much more recognizable "LLM" output. Two years ago!

I think I've learned a little more than I'd have learned reading a blog post from someone else describing how they'd done it. I did a little post-Claude tinkering with stuff I'd remembered from the last ESP32 project (core pinning, RNG).

Does this magically make me able to understand the math? No, I'd have to use my brain more for that, but I've read some of the code, and have given Karpathy's post a closer read than I might have done otherwise.

This was a shower thought that was turned into a working demo. A year ago, I'd have forgotten about it and moved on, or jotted something down in a list of rainy day projects that I would realistically never get around to.

Some people will find this unsatisfying, maybe even a quintessential example of the missed learning opportunity that happens when someone uses LLMs. I'm not sure I even disagree in principle. I just know that I was very unlikely to ever even attempt to do this. There are lots of random ideas that I'll never get around to.

The space of possible ideas is large, and time is finite. Maybe noodling on this for an hour or two will open me up to other possibilities. Too early to tell.

I played video games a lot as a teenager, and watched television, and both of these were going to rot brains. Brains are more resilient than they seem to get credit for.

There is currently no comments system. If you'd like to share an opinion either with me or about this post, please feel free to do so with me either via email (ross@duggan.ie) on Mastodon (@duggan@mastodon.ie) or even on Hacker News.

Changelog:

Mar 3, 2026, 5:02 PM — Fixed a typo.

I built a terminal monitoring app and custom firmware for a desktop clock with Claude

2026-02-07T16:17:21.000Z

The way that I've used AI for coding has changed drastically over the last year.

In fact, the rate at which it is changing is probably the most drastic element of it – I can't recall any time since my first year of college, twenty years ago, that I've experienced such a rapid evolution in my own ability to do stuff.

This week I have written a fully self-contained system monitoring daemon and terminal UI, based on the Charm toolkit and using DuckDB. It archives metrics to parquet, shows ECC status, SMART health, temperature, sparklines, historical charts, and even has an alerts system.

bewitch comes in one colour: hot pink.

I am passingly familiar with Go, but this is a project that's been in the back of my head for a while, and would have been a monumental undertaking. It already works well enough, and I'm using it for a handful of servers.

Also this week, I built custom firmware to show Stripe subscription metrics for the Ulanzi TC001. I've linked to a good overview below if you're not familiar with it – basically a cheap and hackable desktop clock.

Blakadder’s Smarthome Shenanigans

Ulanzi Desktop Pixel Clock TC001 Review

As I was trawling AliExpress in search for a decent but cheap photography light I found Ulanzi, a Chinese brand specialized in making video and photography equipment. Browsing their product list something peculiar jumped out in the recommended tab. A desktop pixel clock targeted to YouTubers, the Ulanzi TC001, priced at 59.99$. After various sales and coupons the price dropped down to a very affordable 43$ and that made me click the buy button.

blakadder.com

This is the kind of project I have dreamed about putting together, but I've never found the time required to become familiar with firmware development outside of a few Arduino demos many years ago.

Most of these project ideas go to a list of ideas that I look at and go, "some day, if I have the time." – I rarely have the time. This blog was one such project, and I sat on it for ten years!

AWTRIX3 is the go-to firmware for customizing the Ulanzi TC001, but customization requires running a process on another machine and sending data over the network to the device. I wanted something I could bundle up and send to my other cofounders. So, again, I leaned on Claude Code to create custom firmware in Rust that communicates with the Stripe API, providing a subscriber count, MRR, and notification for new subscribers. It runs a wifi access point that you can connect to and configure, after which it connects to the wifi and communicates with Stripe via their API.

Ironically, given how long generative AI has been threatening art, I ended up having to do a lot of the actual pixel art for the device by hand. Precise pixel art is one area chat models remain mysteriously terrible at.

The Stripe subscription firmware shown here configured with a demo sandbox to test everything out.

I have never written a line of Rust, but I know it is a relatively unforgiving language, and the ESP32 is a less forgiving environment than most I've developed for, with 8MB of flash storage and something like 160KB of RAM.

These are two projects that would have remained on the back burner forever, requiring activation energy that I just don't have to spare. They were both written over the course of a few days, here and there, between other work, and recovering from a cold.

#A year ago

When I was writing the engine that powers this blog in December 2024, I would upload a few files at a time through the Claude or OpenAI web UIs, try to get them to reshape them into something that seemed close enough to what I wanted, and then iterate on that work myself.

This was slow, but the project of putting together a custom editor using Lexical was daunting enough that I would not have attempted it otherwise. At that point I had only about six months of modern frontend development experience and my reach exceeded my grasp.

Then the startup I was working for ran out of runway, we shut down the company, I spent a couple of months learning Japanese, and then went bumming around Japan for a few months with my partner Ash.

Fast forward to August 2025, I'm starting a new company, and coding assistants are starting to generate a good bit of heat on Hacker News.

One of the first things I did after getting back was try to make some headway on my cofounder's MVP, and it seemed like a perfect opportunity to try out Claude Code. I had it write a few helper scripts, add logging, and act as a glorified find-replace in a few areas. For this tedious work it was quite useful, despite frequently giving up or failing the tasks.

I had it write the first draft of a feature that we needed, and iterated on it myself, getting Claude to throw in some fixes here and there.

Actually, it now reminds me of the accounts recorded by the engineers using the first computer being built at Princeton in the 1940s (from Turing's Cathedral, by George Dyson).

Essentially, the ENIAC often produced incorrect calculations, overheated and shut down during jobs, and was generally a hassle to work with. Despite all that, it was still better than doing it by hand, turning what would be months of human calculation into mere weeks of computer assisted work.

#December 2025

By December, I had written one major piece of functionality with Claude Code. Arguably I would have done a better job doing it by myself, maybe in a similar timeframe if I had been really dialled in and had no distractions.

All of my experience was with Sonnet at this point, and while it was useful and sometimes surprisingly good, it wasn't a huge accelerant. If pushed, I'd have said something like 1.5x, maybe. My €22/month usage plan was enough to help me write helper scripts and break ground on new features though, which was already worth it.

At the end of November though, Opus 4.5 had been released, and some time in December I decided to give it a try. It didn't seem massively different at first, but I was still working with it like it was Sonnet – giving it small tasks, writing scripts, etc. It absolutely burned usage though, and until Opus I had never run into a limit before my usage counter reset. I literally didn't even realise there was a limit.

It wasn't until I started asking it to implement features that I found it was making far fewer mistakes, and was in fact producing relatively good first passes.

In October I had begun adding Github Copilot to some pull requests, and it had found a few issues. This was great, even if it came with some mistakes and noise. When you're a team of one and a half developers, an extra set of eyes is absolutely worth the trouble.

Eventually the Co-authored-by: Copilot notes start showing up more frequently in the commit logs, and I found it useful enough to pay for the basic subscription once my free tier limits ran out.

By the end of December, I was hitting my Claude Code limits constantly. I started using "extra usage" which lets you spend a little more to get to the end of whatever was being worked on when the included limits were reached.

I experimented with using GPT-5 and Opus via the Copilot extension included with VSCode. Once I run through the limits there, I start going through extra usage on that.

The point at which Copilot started being very useful.

Using Copilot, I built the first application that I have not read line-by-line, a VAT invoice generator. I needed to generate mock invoices to do some basic interactive testing of the OCR flow for Manano. As long as it generated something that looked plausible, it was fine, but I found that with GPT-5 doing the bulk of the actual coding, I was able to freewheel on ideas about design and local-first software.

I wanted it to be like Tiddlywiki, where it could be used as a file on the desktop as easily as something at a URL. I wanted it to be WYSIWYG rather than a set of dull forms to fill out. And having a bunch of visually distinctive templates to make sure a variety of visual styles would work.

#Christmas break, structured prompts

Over the Christmas period, while Ash was visiting her family, I had the opportunity to get stuck into the feature idea backlog for my blog. This felt like a good testing ground for the coding assistants, as it was a bit cobbled together, had gone through a few architectural lurches, but I had written enough of the codebase myself to evaluate the results.

Also, being a blog, the stakes were low. Every time I'd have some idea for the blog I'd jot it down in Apple Notes. Here was what I had built up:

duggan.ie features/bugs

Saving/updating published posts
When a post has been published, any subsequent updates should include an optional reason for the update.
If a post is published, hitting save or using the save shortcut (Cmd+S) should pop up a dialog with a textbox to describe the reason for the change. This should be plaintext only, no special formatting.
It should still be possible to change without including a reason. In that case, the update should not change the updated_at marker.
The “save” target should move to the dialog box, so that hitting Cmd+S again will save the post.

Changelog
Include the post updates in published posts.
It should be implemented as a collapsed summary + details element at the bottom of the post.
It should also be included in the Atom feed.

Feedback system for shared drafts

Goal: Create a feedback system for shared links.
Context:
Shared links are designed to be shared with a single person. The URLs are deliberately obfuscated and they have configurable expiry, after which they return 404.
The editor is built using Lexical, and stores the lexical node data in the post_revisions table, with a posts table to hold the rendered html and reference to the currently fresh post_revisions record.

Implementation details:
Implement the feedback system as a Lexical plugin.
The shared links can use a Lexical editor with our feedback system plugin.
Other than using the feedback system, the shared link editor should be read-only – the user should just be making notes, not editing the text directly.
Each shared link will likely need to make a copy of the main editor node data on creation.

Open questions:
How best to handle when the main editor updates the post data. Should the shared links be updated? Should the user get a note/bar at the top of the screen saying something like “the author has updated the draft, would you like to refresh?” etc.

Opengraph integration for links
When pasting a link into the editor, it should give me the option to include it as nicely formatted block with OpenGraph data (image, title, content, etc) like Notion.

Video/image loading skeleton
Context: images and videos can be dragged and dropped into the editor, and are displayed inline.
Goal: While the images are uploading, there should be a loading skeleton in place to show that it is being processed.

Enhanced video/image resizing controls
Context: image and video resizing in the editor is very basic
Goal: enhance the resize functionality so that arbitrary resizing is supported.
Additional support: helpful resize controls, like “original”, “full width”, etc., should be included

Light / Dark mode
Initial change to light mode seems to result in a white screen
Continue button flashes when changing, sometimes on loadMake tags distinctive

Tag management area
Include emoji / stickers / SVG images as part of the tags
Should be able to specify a colour for each tag using a colour wheel, etc.
V2
More comprehensive emoji selector (with keyword search)

Post list
Add a new post status: archived
The post list navigation should be broken out by published vs draft vs archived in the left navigation.

It was quite a decent chunk of work in my book.

These notes were originally just for my own reference, but you'll notice that at some point I started editing the notes with a basic structure for Claude Code that I felt was clearer.

I thought I'd make good headway on a few of them, but over the Christmas break I steamrolled every one of them, iterated on a few, and even added some extras once I ran out.

I started out just about coming up short on Claude limits, having to wait 30 minutes or so before starting again. But by the end of this process I was smashing through those limits really quickly, and had to start getting more targeted and careful about what I wanted to work on.

Eventually though, I was paying extra usage on both Copilot and Claude Code, still cheaper than springing for a higher usage plan, but chafing at the limits.

#The Yegge Inflection Point

This month, I finally sprung for Claude Code Max – though only 5x, not yet the 20x. It's just too powerful an upgrade on my capabilities as a developer to pass up. Other people can wait to see where it goes and look back on this period with sagacity and the wisdom of hindsight.

I am still using Claude Code interactively in VSCode, I haven't gotten to the stage where I never read the code that's being produced, though maybe I'll get there, too. Steve Yegge is there with a few other people, and they are probably living in a version of the future, but it's not the only version of the future.

There are lots of different kinds of software. Not all of it will be amenable to this style of development.

For a 20 year old aspiring software developer in college, I have no idea how they are going to get to their version of mastery. I suspect it will be very different to mine, and will take a very different route. I think it will be daunting, but I hope exciting. Nobody starts off knowing how everything works.

For me, it's exciting. If at the end of the day all I end up with is a bunch of completed side projects, it will have been money well spent.

Changelog:

Feb 8, 2026, 11:21 PM — Fixed formatting in notes.