The Bard · a transformer telling stories on a $3 microcontroller

IThe tale so far

Every word below came out of the 260,000-parameter model itself — no server-side API, nothing written by a person. The tag on each tale says where it ran: device for the chip in the field, reference for a bit-identical run of the same weights on a host. Only the first kind is interesting, and it is what phase IV exists to deliver.

…

Waiting for the bard to speak.

72 × 40 oled · 5 lines × 14 chars

IIHow it holds a story that never ends

The model's weights are int8 and executed in place from flash, so they never occupy RAM. What does occupy RAM is the KV cache — and a fixed sliding window of 80 tokens means it occupies exactly the same amount at the ten-thousandth token as at the first.

The screen is not a viewport onto a finished text. There is no finished text. Five lines of fourteen characters are all that exist at once, and the story moves past them the way a river moves past a stone. That is what makes an unbounded tale possible on a chip with less memory than a single JPEG.

260Kparameters

202 msper token

80token window

~281 KBmodel in flash

55,440 Bstack high-water

bit-exactvs python reference

The high-water figure was byte-identical across five consecutive reports spanning many tale boundaries. The window does not creep — which is the difference between a demo and a thing that runs until you unplug it.

IIIWhy it left the mesh firmware

The Bard was built inside smol, a mesh firmware for a fleet of dollar microcontrollers, and shipped there. Living in the same binary as the radio stack, it costs:

Section	What it is	Cost
`.rodata`	the model blob, XIP from flash	+287,392 B
`.bss` + `.data`	working DRAM	+39,072 B
`.stack`	the DRAM that was left over	−39,072 B

The third row is not a separate cost — it is the second row. On this chip the linker hands the runtime stack whatever DRAM remains after everything else, and it shrinks that region silently rather than failing the build. A binary that links is not therefore a binary that runs.

On the current fleet image both fit. On the async re-platform, where the radio stack is materially larger, they do not: the shared image links with a 67,488 B stack against a 74,208 B floor. The same commit without the Bard links with 106,560 B — a 32 KB margin in place of a 6.7 KB deficit.

So the storyteller gets its own chip. It keeps a sigil name, keeps its place in the mesh roster, keeps reporting telemetry — but it stops competing with a radio for single kilobytes.

What it does not get is its own copy of the code. The Bard stays a smol feature; only the shared C3 fleet image lost it. On an ESP32-S3 — the next fleet target — there is memory for the radio and the model at once, and the Bard is simply switched on. This site is the device's public face, not a fork.

IVWhere this is going

IThis repo, this page, versioninghere
IIsmol-core — wire format, election, OTA relay, names, telemetry, shared by three consumersnext
IIIThe Bard device — a smol build with bard on, most likely an S3, where radio and model both fitafter II
IVStories published over MQTT and rendered here, with node and version attachedafter III