The idea showed up on a beach. I was watching my thumb tap idly at nothing, the way you do when the sun has cooked most of the thinking out of you, and I started sketching a game where tapping was the mechanic: tap to charge, build to hold. My first prompts were written right there, on my phone, feet in the sand.
The mash-up was the whole point. I have loved two genres since I was a kid: classic tower defense, where you place towers and hold a line, and cookie-clicker idle games, where the number goes up as fast as your finger will move. Thumb & Pylon is my attempt to fuse them, so the clicking is not a side meter but the very thing that powers your towers.
Before writing a line of code, I brainstormed the idea into a complete game design document: one markdown file laying out the mechanics, the towers, the economy, the scoring, all of it. That file became the spec I prompted against, and it is still the source of truth the simulation is measured against today.
Thirty or so days later there is a real game. It is called Thumb & Pylon: a tower defense crossed with an idle clicker, on a neon grid, one TypeScript codebase running native on both iOS and Android. Thirty-four levels across four acts, each level teaching exactly one new thing, with a deterministic simulation core and server-verified leaderboards.
This post is the honest write-up: what it is, how it was built, what the machine did, and what it cost.
What it actually is
Tap the core to make Charge. Your towers fire automatically, but they run on Charge: a small idle upkeep just to stay lit, plus a cost for every shot. Let the pool hit zero and they brown out and stop firing entirely. So your thumb is the power supply, and it is never quite enough. Building towers is a separate economy, paid for with Credits you earn by killing, so the game pulls in two directions at once: keep tapping to fund the firing, keep killing to afford more line. Tower defense asks you to place well; the idle-clicker half asks you to keep the lights on. Later you can buy daemons that make Charge for you, which frees your thumb, and knowing when to stop tapping and start automating is half of it.
The campaign is thirty-four hand-authored levels in four acts, opening on one lane and one tower and closing on five lanes and three bosses. Every level introduces one idea the previous one did not have, and every star threshold was measured by playing a scripted build through the level, not guessed.
The stack
One TypeScript codebase, native on both iOS and Android. The decision that shaped everything else: the game simulation is a self-contained core with no rendering or platform code in it at all. That buys three things.
- Deterministic replays. The same code produces bit-identical results on an iPhone, a Pixel, and a server, because the simulation runs on fixed timesteps with integer math and never touches floating point.
- Score validation by re-simulation, not trust. A submitted run is just a seed plus the list of inputs. The server replays it and computes the score itself, so the client’s claimed number is never believed. It runs the exact same simulation the phone ran.
- A replaceable renderer. If a later, busier act ever outgrows the graphics layer, the game logic does not move a line.
That is also why the leaderboards live in a Postgres database rather than Game Center or Play Games: neither store can run server-side re-simulation, a tap-rate cap, or a weekly rotating challenge level. They can only take a number from the client and believe it.
Measure, don’t guess
The part I did not expect to enjoy so much: the simulation doubles as a ruler. It is fully deterministic, so scripted bots replay every level and score it the same way every time, which lets the star thresholds be fitted from measured runs rather than authored. Difficulty, the hardest part, is tuned the same way: a search finds the smallest enemy bounty at which a level’s teaching build can just clear it, so danger is set by measurement, not by feel. And measuring overturned the obvious, moving a row of tower pads one tile closer to the path took map coverage from 70% to 100% and cut leaks from 21 enemies to 4, with no change to a single tower or enemy stat. None of that was vibes. It was a test suite for game feel.
The build stats
The whole thing was built with Claude Code , mostly Claude Opus 5, across about a dozen working sessions in roughly a month. Here is the shape of it.
| Metric | Value |
|---|---|
| Timeframe | About 30 days |
| Working sessions | ~12 |
| Tool calls (edits, commands, browser and sim actions) | 9,436 |
| Output tokens (what the model actually wrote) | 17.7M (~13M words) |
| Input tokens (fresh) | 38.4K |
| Cache-creation tokens | 241.3M |
| Cache-read tokens (context re-read each turn) | 8.98B |
| Grand total tokens | 9.24B |
| Model | Mostly Claude Opus 5 (~18k responses), a little Fable 5 and Opus 4.8 |
The number that surprises people is the 9.24 billion tokens against only 17.7 million written. Almost all of it is cache reads: every turn re-reads the accumulated context, so a long project pays for its own memory over and over. That is the real cost structure of agentic coding, and it is why prompt caching exists.
The bill
This is the part everyone actually wants. Metered at API-equivalent token prices (via ccusage), scoped to this game’s own transcript files, the total came to roughly $2,755. The split by model:
| Model | Cost | Share |
|---|---|---|
| Claude Opus 5 | ~$2,555 | 93% |
| Fable 5 | ~$186 | 7% |
| Opus 4.8 | ~$14 | 1% |
| Game total | ~$2,755 | 100% |
Two honest caveats. First, it is the pay-as-you-go token price; on a subscription plan the out-of-pocket number is very different. I am publishing the raw meter because it is the interesting figure: this is what the compute was worth, whoever paid for it. Second, the token counts in the table above and this dollar figure come from two different tools that count cache reads differently, so read the tokens as scale and the dollars as the bill, not as two views of one number.
What I take from it
I have written before that vibe coding is not abdication: it is deliberate prompting paired with real testing. Thumb & Pylon is the largest thing I have built that way, and the lesson held. The parts that went well went well because the architecture made verification cheap: a deterministic core the machine could test against itself, bots that scored every level, a build that either compiled or did not. The machine did the tireless work; I kept the taste and the judgment, the part no model can hold for me. That division of labor is the whole game.
And the thing I dreamed up on a beach, thumb tapping at nothing, turned into a game people actually sit down and play.
The best part
None of the numbers in this post come close to it: the most satisfying thing, by a distance, is watching my own kids pick up the phone and play a game their dad made. That is the payoff no bot can score.
