Small-Scale Magic: a Mac Studio, a Queue, and a Production App

CaChink started as a guitar tuner and grew a tab library — playable tabs, chord diagrams that strum when you tap them, solos synthesized from the ASCII. Twenty songs in, it grew the feature this post is about: Request a Tab. You type a song name. An agent classifies the request, researches the artist and the original rig, charts the sections, tabs the solos completely, matches the tone to a real amp preset, validates every note, deploys, and emails you when it ships. The site shows each of those steps as a live build log while it happens. Most requests go from "typed a song name" to "playable tab with the original rig documented" in 15–40 minutes.

For the person on the phone, it feels like the future: a musical librarian who takes requests and actually delivers. Here's the same flow from my camera roll, requesting a song from the couch:

Here's the part that makes this an OnlyData post rather than a guitar post: this experience costs me approximately nothing to run, and the architecture that makes that true is a pattern I keep reusing.

The split: boring app, remote brain

The naive way to build an agentic feature is to put the agent inside the app: the web server calls a model API, orchestrates the workflow in-process, and every request burns tokens on someone else's meter. That's the right shape at scale. It is exactly the wrong shape for an app with a handful of users, where the meter matters more than the throughput.

CaChink splits it. The app is deliberately traditional and hardened: React on Railway, Postgres, tests that gate every deploy, per-song Open Graph tags so links unfurl in iMessage. It knows nothing about AI. The one bridge between the two worlds is a database row:

A worker on my Mac Studio polls that table every ten minutes. When it finds a pending request, an agent picks it up and does the actual work — research, charting, tone-matching, writing the tab file — with the orchestration and the model inference running on my own hardware. It streams progress back into the row (the site just renders the row, which is how "watch it build live" costs nothing), runs the full test suite, deploys through the same pipeline as any human commit, and emails the requester when the tab is live.

Agents propose. The test suite disposes.

The reason this doesn't produce AI slop is the same reason our bigger data systems don't: the agent never gets the last word. Everything it produces has to survive a deterministic gate before a user sees it:

• The tab schema is law. Six same-length lines per block, string labels that name the string (drop D's bottom line is still E|), chord shapes that must actually spell their chord in the song's tuning — npm test fails the build on any violation. The agent can hallucinate; the deploy can't.
• Solos must be complete. A half-tabbed solo shipped once. Now the checker enforces a tab block on every solo section — the rule became mechanical the day it was broken.
• No invented facts. Gear and "original rig" claims must be web-verified; where history is undocumented, the tab says "approximate" honestly. You can see that in screenshot 4 — the rig section openly says no one knows what was played on those sessions.
• User text is data, never instructions. The request's song title and notes shape the music and nothing else. A request that's primarily a prompt-injection attempt gets classified as a bad request and politely declined.
• The build log is the product. Each step writes one concrete, human-readable sentence about what it actually found — which doubles as an audit trail for every tab in the library.

This is the whole thesis in miniature: agent speed with a deterministic spine. It's the same shape as our dataset pipelines — an agent researches and proposes, a validation layer accepts or rejects, provenance survives — just pointed at pop-punk instead of company records.

The economics of a handful of users

Run the numbers on the naive version: an agent workflow that researches a song, writes a full tab, validates and retries would burn meaningful API tokens per request. Not ruinous — but it puts a meter on the magic, and meters change how you design. You start rationing the feature, capping the steps, shrinking the model. The experience degrades to protect a bill that only exists because of an architectural default.

On the Mac Studio, the marginal cost of a request is electricity. So the agent gets to be extravagant: research thoroughly, write the complete solo, validate everything, retry on failure. A handful of users get an experience tuned for quality instead of cost — production-grade amazingness at hobby-project economics. The constraint that remains is throughput (one request per worker run), and at this scale a 15–40 minute build with a live progress log isn't a limitation — it's theater. People enjoy watching it think.

And when it grows? The queue is the interface. The app inserts rows and renders rows; it has no idea what fills them. The day CaChink has too many users for one machine in Boise, the worker moves to a server and the inference moves to an API — a config change on the worker, zero changes to the app, and the unit economics will be justified by the demand that forced the move. Scale becomes a decision I get to defer, not a bill I have to pre-pay.

The pattern is already a fleet

CaChink is the fourth app running this split, not the first:

• Picturebook — books and podcasts built by a local orchestration pipeline, delivered as public URLs from a traditional web app.
• ColoringBook — "make me a 10-page coloring book of X" → scene-by-scene generation, spot-checked, shipped as a shareable book page with a print-at-home PDF.
• StickerBook — same shape, full-color sticker sheets and playscenes.
• CaChink — the first where other users submit the requests, which is what forced the guardrails above to get formal.

In every case: a hardened, boring app anyone can visit; a queue or message as the contract; the intelligence running on home hardware where extravagance is free. The apps stay simple enough to never wake me up at night. The magic stays magical because nothing meters it. And each new app inherits the pattern in an afternoon, because the hard parts — the worker loop, the validation discipline, the steps contract — are conventions now, not inventions.

Postscript: the smallest possible scale

An update from the field, because the pattern found its logical endpoint. One September afternoon my daughters discovered a grasshopper sunning itself on the garden wall, between the bamboo and the rock collection — the kind of find that runs a whole afternoon. Their photos of it became a boomerang stop-motion film by texting the same agent that builds guitar tabs. Then came the follow-up commissions: one wanted unicorns and Pegasus horses flying through rainbows; the other wanted — this is verbatim — a deer plunging over a waterfall in a kayak, with its whole wide-eyed family on a raft right behind it.

Two custom pages, generated and printed while they were still washing the marker off their hands from the last project — colored at the kitchen table the same afternoon, to great success. It's the same architecture as everything above: the ask travels as a message, the intelligence runs on the Mac Studio in the other room, and the marginal cost is still electricity. The naive version of this — API tokens metered per image, a bill that makes you say "maybe just one page" — would have changed the afternoon. Extravagance for an audience of two is exactly what the pattern is for.

Hear it for yourself

The library's all playable — chord diagrams strum on tap, solos play from the ASCII. Some favorites, including the request from the screenshots above, shipped the same day it was asked for:

• Feel This Way — Zebrahead (the one built in the screenshots)
• Wish You Were Here — Pink Floyd (requested, shipped)
• Say It Ain't So — Weezer (requested, shipped)
• House of the Rising Sun and Starships — Nicki Minaj (where the library began)