DEV Community: Nazar Boyko

Here Lies My Toaster

Nazar Boyko — Sun, 01 Nov 2026 02:55:51 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

What I Built

Every house has a drawer of dead things: the earbuds that play on one side, the charger with the split cable, the phone with the spiderweb screen. Nobody mourns them. Halloween ends tonight and Día de los Muertos begins tomorrow, two days for remembering the departed, so I gave the drawer an obituary page.

Here Lies is a small web app that runs on your own laptop. You take a photo of something that died, and Gemma 4, running through Ollama on the same machine, writes it a straight-faced newspaper obituary: a name, a cause of death, a life of service, who it leaves behind, a request in lieu of flowers, an epitaph. You can download the card as a PNG.

The rule: the model may invent a name. It may not invent a scratch. Every physical detail on the card has to point at something the model listed when it looked at the photo, and plain Go code checks that before you see it.

Living things get a notice instead.

In my tests the cat, the dog, the monstera and the person were turned away every time.

Demo

More cards on the landing page: https://nazboyko.github.io/here-lies/

The toaster survived. Mr. Chester Golden-Crust did not: "In lieu of flowers, please wipe the crumbs from beneath the toaster tray."

Agnes Petalbrook: "Survived by a terracotta shard and the faint smell of potting mix."

Mr. Arthur Glowwick: "It shone when asked, and dimmed when done."

The app, on another run of the same toast. On the right: what the model saw, and which sentence used each detail.

Run it yourself. You need Ollama, Go 1.26 and Node 20 or newer.

ollama pull gemma4:e4b
git clone https://github.com/nazboyko/here-lies && cd here-lies
make run
open http://localhost:8787

Code

nazboyko / here-lies

Obituaries for the things that died in your house, written by a local open-weight model.

Here Lies

Obituaries for the things that died in your house, written by a model on your own laptop.

Take a photo of something that died: a cracked phone, burnt toast, shoes with holes, last week's pumpkin. Gemma 4 runs on your computer through Ollama, looks at the photo and writes the thing a straight-faced newspaper obituary. The model may invent a name. It may not invent a scratch: every physical detail on the card has to point at something the model listed when it looked at the photo, and plain Go code checks that before you see it.

Point it at a cat, a person or a healthy plant and it refuses: "Still alive. Give it a treat instead."

Landing page: https://nazboyko.github.io/here-lies/

Run it

You need Ollama, Go 1.26 and Node 20 or newer.

ollama pull gemma4:e4b
git clone https://github.com/nazboyko/here-lies && cd here-lies
make run

Then open http://localhost:8787…

View on GitHub

How I Built It

Look. Gemma 4 gets the photo and returns JSON: thing, person, animal, living plant or unclear; what the object is; and what it sees, in three lists: damage, wear, features. Code numbers the details d1, d2, d3.
Gate. Plain code. People, animals and healthy plants get the still-alive notice.
Write. A second Gemma call, text only. It turns the numbered list into an obituary in JSON, and every sentence about the body carries the ids it uses.
Check. Plain Go, no model. The cause of death must cite a real damage or wear id, every life sentence must cite a real id, and everything must fit the column. A failing draft goes back once with the problems listed. If the rewrite fails too, code keeps what passes, rebuilds the rest from the detail texts, and the page says what it repaired.

Why two calls? The writer never sees the photo. It can only describe what the looking step wrote down, and because each reference is an id, my code can verify it. One call doing both would hand me prose I could either trust or not.

To measure it, I ran 17 photos from Wikimedia Commons through the real pipeline: 11 dead things, a cat, a dog, a healthy monstera, one person, an intact mug and a blurry shot. Then I opened every photo next to its details and marked each one true, false or unsure.

Measure	Result
Photos	17
Gate decision correct	16 of 17
Obituaries printed	13
Passed the check on the first draft	12 of 13
Rewritten once after the check	1
Repaired by code after the rewrite	0
Details on printed cards	65
Really in the photo, checked by eye	53 true, 4 false, 8 unsure
Causes of death resting on a false detail	2
Median seconds	0.8 to look, 2.4 to write and check

Machine: Apple M5 Max, 64 GB, gemma4:e4b through Ollama 0.35.1. A card takes about 3 seconds. The one rejected draft was the charger's: its third life sentence cited no detail, and the rewrite fixed it.

The honest failure. My first look prompt asked for one list of details, each tagged damage, wear or feature. Gemma tagged almost everything as a feature. Burnt toast came back as "dark brown toasted surfaces", so the check found no injury and printed "Natural causes. It was simply no longer needed." Only 6 of 11 dead things had any damage or wear listed, and a split laptop charger became "white wired earbuds".

So I split the schema into three lists and asked for damage first. On the next run all 11 dead things had an injury. That run had its own bug: the model wrote "no visible damage" as an entry in the damage list, the check accepted it as an injury, and a blurred green glow was buried as Miss Petunia Bloomsworth, who "passed away due to no visible damage." Code now drops entries like that.

The table shows the check's limit. It proves that each sentence points at a listed detail, not that the detail is real. Two causes of death rested on details I could not find in the photo: a cassette adapter "suffered a missing screw hole" while its real injury, heat warping, went unmentioned, and a folded umbrella died of "torn fabric". That is why the card footer prints the model's list: you can hold the obituary up against the photo.

How it was tested:

48 Go unit test cases: the check, the gate, the repair step, the HTTP routes, and the Ollama client against a fake server (bad JSON, missing model, Ollama down, timeout).
The live run above, plus two extra passes on three photos. The details barely moved, since the look step runs at temperature 0.2. The names changed each time, except the pumpkins, who were Mr. Josiah Gourdington twice.
10 Playwright tests against the real server and model: upload, card, sentence-to-detail mapping, PNG download, still-alive notices, phone width, keyboard, missing model, Ollama down, the LAN address, and a full run that fails if any request leaves the machine.

Stack: Go 1.26 with net/http serving a React, Vite and TypeScript page; Gemma 4 E4B through Ollama; html-to-image for the PNG; Old Standard TT and UnifrakturMaguntia fonts bundled from Fontsource. The Ollama request pattern (structured JSON output, timeouts, plain-language errors) comes from my earlier project Backpack. The code here is new.

Photo credits, all from Wikimedia Commons: jack-o'-lanterns by Giulia Forsythe (CC BY 2.0), burnt toast by Sheep purple (CC BY 2.0), succulent by stephen boisvert (CC BY 2.0), light bulb by Shixart1985 (CC BY 2.0), and the shoes on the cover by Wolfmann (CC BY 4.0).

Why Does Open Innovation Matter?

These photos show the inside of your home: the kitchen counter, the bathroom shelf, whatever is headed for the trash. With an open-weight model on the laptop they never leave it. No upload, no account, no retention policy. The server holds the photo in memory for one request and never writes it to disk.

It works with Wi-Fi off. The browser test records every request during a full run, and the count going to any host outside the machine is zero. Each obituary costs nothing.

Because the model runs on my machine, I could cut its job into two strict steps and check the output in my own code. The schemas, the temperatures and the check live in my repository, not behind an endpoint that can change or disappear, and HERELIES_MODEL swaps in any other Ollama model.

The limit is the eyesight of a small model. Gemma called the broken mug a "creamer jug" with a spout it does not have, and 4 of 65 details were wrong. I can see those mistakes because the pipeline shows them to me, and I prefer that to a better answer I cannot inspect.

The Spirit of It

The most surprising result was a refusal. In the first run Gemma looked at a rotting succulent, translucent and black at the edges, and decided it was alive: "This plant is still with us. Water it." Once the prompt said that brown, mushy or translucent leaves mean dead, Agnes Petalbrook got her obituary.

Día de los Muertos is about remembering through stories. A dead charger is not a grandmother, but it deserves a better send-off than the trash can: a name, a cause of death, and someone to survive it. In its case, "a set of mismatched plugs and a seldom-used surge protector."

Prize Categories

Best Use of Gemma: Gemma 4 runs locally through Ollama, does both the looking and the writing, and code checks its output against what it saw.

A Local AI Reads My Kid’s School Papers So I Don’t Have To

Nazar Boyko — Sat, 24 Oct 2026 20:53:32 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

Every Friday my kindergartner's folder comes home full. Most of it is worksheets and coloring pages, and somewhere in between there is sometimes a slip or a flyer. I have to look through all of it to find the one paper that matters.

What I Built

Backpack is a small app that reads those papers for you. You photograph each one with your phone, drop the photos on a page in your browser, and Gemma 4 reads them on your own laptop. A few seconds per paper later you have the week: every date in order with one button that puts them in your calendar, every to-do with a checkbox, and a single line for the papers that need nothing from you.

The parent who used to sort the pile is the one who gets to be lazy now.

Some things are missing on purpose: no account, no sync, no settings page, no model picker. You get one binary, one page and one folder on your disk.

Demo

The landing page, with screenshots and the install steps: https://nazboyko.github.io/backpack/

Papers are read one at a time. One that can't be read says so and offers to try again:

A date the model had to work out is underlined and marked "check". Click it and it turns into a date field:

Download calendar (.ics) gives you one file. Apple Calendar took all 14 events from the ten test papers, with their times and the two-day book fair:

Code

nazboyko / backpack

Photograph the pile, get the week. Reads school papers with Gemma 4 on your own laptop.

Backpack

Photograph the pile, get the week.

Every week a school backpack comes home with paper: permission slips, picture day flyers, "sign and return by Friday", early release, pizza night. Backpack reads photos of those papers with Gemma 4, an open-weight model that runs on your own laptop through Ollama, and gives you one page with the dates, the to-dos and the papers you can throw away. Nothing leaves your computer.

Install

On a Mac with Homebrew:

brew install go ollama && brew services start ollama
ollama pull gemma4:e4b
go install github.com/nazboyko/backpack/cmd/backpack@latest
~/go/bin/backpack

The last command opens the page in your browser. Next time, run only that one The model download is about 7 GB and happens once.

From a clone: make run.

How to use it

Take a photo of each paper with your phone and send them to the laptop.
Drop the photos on the…

View on GitHub

brew install go ollama && brew services start ollama
ollama pull gemma4:e4b
go install github.com/nazboyko/backpack/cmd/backpack@latest
~/go/bin/backpack

The last command opens the page at http://127.0.0.1:7313. The tests come in four layers: unit tests, an end-to-end test that drives the real server against a fake Ollama, make live-check, which reads ten invented school papers with the real model and scores the result, and a guard test that fails if the code ever names a host other than this computer.

How I Built It

The model is gemma4:e4b, the small open-weight Gemma 4, served by Ollama on the same laptop. Backpack sends each photo to Ollama's chat API with format set to a JSON schema, so the model can only answer in one shape. This is its answer for the field trip slip, trimmed:

{
  "title": "Field Trip to Science Museum",
  "nothing_to_do": false,
  "events": [{"title": "Field Trip to Riverside Science Museum", "date": "2026-11-04",
              "start_time": "09:00", "end_time": "14:15", "date_confidence": "read"}],
  "actions": [{"text": "Sign and return the slip", "kind": "return",
               "due": "2026-10-30", "date_confidence": "read"},
              {"text": "Send $8 per child", "kind": "pay",
               "due": "2026-10-30", "date_confidence": "read"}]
}

The prompt gives the model today's date and the school year and tells it to turn "Friday" and "next week" into real dates. It spells out the difference between an event (a trip, a day off, a fair) and an action (sign, return, pay, bring). It asks for "guessed" whenever the paper printed only a weekday or the photo was unclear.

Then the Go side checks everything, because a small model gets things wrong in small ways. Every date has to be a real day. "Friday" or "Nov. 4" gets resolved and marked as a guess. A date more than six months in the past moves to the nearest year, because in my first run the model filed a November pizza night under 2024. "00:00" means no time, "5-7 PM" in one field becomes a range, and two all-day "Book Fair" events on consecutive days become one.

With the prompt from my plan, before any tuning, the model found 11 of 13 dates and 6 of 10 to-dos on the ten test papers. It also added 13 lines that were not on the papers, four of them events on a class newsletter, all dated today. Two rounds of prompt changes plus the checks above brought it to 13 of 13 dates, 8 of 10 to-dos and 4 extra lines, and the newsletter now comes back as "nothing to do". It still misses "pack a sack lunch" on the field trip slip and "send a little money" on the bake sale flyer.

The larger gemma4:26b found all 10 to-dos on the same papers, at 3.6 seconds a paper instead of about 2, with an 18 GB download instead of 7 GB. e4b stays the default; 26b is one environment variable away.

Everything else is one Go binary with the page embedded: plain HTML, CSS and about 640 lines of JavaScript, no framework and no build step, so a parent installs one thing. It listens on 127.0.0.1 only, rejects requests for any other host name, and rejects changes sent by other websites open in the same browser. Every word the model writes reaches the page as text, never as HTML.

Where it is weak: handwriting and faint photocopies. My test papers are printed. One has a handwritten-style note ("we need 2 dozen cookies") and the model got it, but a teacher's real handwriting on a faded copy is harder. That is what the "check" marks are for.

Why Does Open Innovation Matter?

Think about what a school paper can carry: a child's name, sometimes in the child's own handwriting, the school, the teacher and the room number. A form asks for a home address and a parent's phone number. Now and then there is a note about an allergy. I don't want any of that on someone else's server, and with an open-weight model it never goes there. Backpack talks to 127.0.0.1 and nothing else, and a test in the repo fails the build if the code ever names another host.

Open weights also mean there is nothing to pay next month and nothing to sign up for. There's no API key to paste and no usage limit, and nobody can change the terms under me. It works on a plane. When a better open model comes out, I change one variable: BACKPACK_MODEL=gemma4:26b.

A large closed model behind an API would probably read a crumpled handwritten note better than a 7 GB model on a laptop does today. I chose the laptop anyway. For my kindergartner's paperwork I'll trade some accuracy for keeping it in the house, and I built the page so that I see every guess before I trust it.

The Lazy Payoff

On an Apple M5 Max with 64 GB, with the model not even loaded, I dropped all ten test papers at once. 24 seconds later every one was read: the first took 5 seconds while the model loaded, the rest about 2 each. Backpack found all 13 dates and 8 of the 10 to-dos.

Then I tried this week's real folder. I photographed 11 papers, dropped them all at once, and 20 seconds later every card was read. All 11 came back "Nothing to do", and all 11 were right: a week of worksheets and coloring pages, with no notes, no slips and no dates. The one thing I did have to do this week, return a library book, was not written on any paper, so Backpack could not know about it. It reads paper. It doesn't know what nobody wrote down. One cosmetic miss: a summary stopped mid-sentence ("A coloring and pasting activity for a"). Nothing was invented, and I fixed nothing by hand.

I don't sort the pile anymore. I drop it, look at the "check" marks, and press one button for the calendar.

Prize Categories

Best Use of Gemma. Gemma 4 reads every paper. Without it, Backpack is a drop zone and nothing else.

The repo is open under MIT, with the test papers, the scores and the prompt in it.

I Let AI Translate My YouTube Titles. Then I Asked What It Actually Said.

Nazar Boyko — Sun, 18 Oct 2026 18:44:12 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

If your videos get views from Brazil or Japan, YouTube already shows those viewers your title in Portuguese or Japanese. A machine wrote it, and you have never read it.

This month I started two faceless channels: rain and night sounds on one, slow daytime scenes on the other. Studio lets me replace YouTube's machine version with my own, but that means two fields per language per video. Fifty videos in twelve languages is 1,200 fields.

Channel Tongues is a Chrome side panel that opens next to YouTube Studio, plus a small helper on my laptop. I press Translate, and Gemma 4, running in Ollama on the same laptop, writes the title and description in the twelve languages with the biggest YouTube audiences. Under every title the panel shows what the translation says in English. I untick anything I don't trust, press Publish, and the helper adds the rest to the video through the official YouTube Data API, after taking a backup.

People already pay for tools that do this. I wanted one that runs on my own machine and never holds my channel's keys.

Demo

Screenshots and install steps: nazboyko.github.io/channel-tongues

Code

nazboyko / channel-tongues

Translate your video titles and descriptions with an open model on your own machine, then add them to the video.

Channel Tongues

Your channel's titles and descriptions in every language, translated on your own laptop.

YouTube already shows viewers abroad a machine translation of your titles, and you never get to read it. Channel Tongues opens next to YouTube Studio as a Chrome side panel; you press Translate, and Gemma 4 running on your computer through Ollama writes the title and description in the twelve languages with the biggest YouTube audiences. You read them over, press Publish, and the helper adds them to the video through the official YouTube Data API after taking a backup.

Demo video · Landing page

Install

You need a Mac or Linux machine with Chrome, Go 1.26 and Node 26.

Install Ollama from ollama.com/download and open it.

Get the code and build it

git clone https://github.com/nazboyko/channel-tongues && cd channel-tongues && make build

Run the setup. It downloads the model, walks you through your own Google…

View on GitHub

A Go helper and a React side panel, MIT license. make build, then bin/tongues setup walks you through the rest.

How I Built It

The shape. The side panel (React, Manifest V3) reads the video id from the tab address and talks to a Go helper on 127.0.0.1. It never changes Studio's page, and reads from it only in the no-sign-in mode, after you allow it. The helper runs the model, keeps the sign-in file and writes backups, and Chrome starts it when you open the panel.

Protect, translate, check. Before Gemma sees anything, the helper swaps links, timestamps, hashtags and keep words (my channel names) for placeholders like ⟦1⟧. Then the checks run: every placeholder back in place, lines and blank lines kept, the title within 100 characters, the right script, no link or keyword the original lacks. A failed check retries twice with the exact problem. After that the card says Check this one with the reason, and it goes out only if I tick it myself.

On my first real publish, the Spanish title came back as "cabina nocturna 30s · escenas nocturnas tranquilas y música suave para dormir profundamente", with the description's first sentence glued on. Now the checks reject a title that grows a new part. With the smaller gemma4:e4b, the Korean title added "ASMR" on all three tries, and the panel held it back.

The read-back line. A placeholder check can't tell me what a Thai title means. So the same model translates each translation back into English, and the panel shows it under the title. The panel marks words my original doesn't have, and a marked title makes the card Check this one. On my sample videos it caught Turkish turning the cabin into a "mountain" cabin, and Vietnamese and Thai adding "help sleep".

On my first real panel run, 10 of 15 cards came back to check, and 9 of them blamed "created": my description said "made", and nearly every read-back said "created". Now a description word that at least half the read-backs share counts as the read-back's own wording, and only title words untick a card. The same video went from 10 cards to check to 0, and the Turkish "mountain" still gets caught. The read-back is a second opinion from the same model, and still the first time I can see what my Thai title says.

Merge, never replace. YouTube deletes any language you leave out of an update. So the helper reads the video first, starts from what is there and sends the complete set: it adds languages the video lacks, updates the ones it wrote last time, and keeps everything else. It never sends the title, description or tags. Before every write it saves a backup of the video's translations, re-reads the video and refuses if anything changed. After the write it reads each language back. Undo in the panel, or tongues restore on the command line, puts the backup back.

What a run costs. tongues translate --measure prints the seconds, the tokens Ollama counted and, with macmon installed, what the whole machine drew. Twelve languages with gemma4:26b on an M5 Max with 64 GB, model already loaded:

	Short sample	Real video	Real video	Test video	Long sample
Title / description, characters	57 / 273	96 / 691	99 / 727	93 / 1,042	94 / 1,979
Start to finish	22-25 s	54 s	56 s	59-62 s	157-162 s
Retries	0	6	2	3	4-5
Output tokens, translation and read-back	2,484-2,518	5,819	6,566	6,788-6,796	17,710-18,315
Energy, whole machine (macmon)	0.59-0.62 Wh	1.34 Wh	1.50 Wh	1.33-1.40 Wh	4.00-4.03 Wh
Ready / to check / failed	10 / 2 / 0	12 / 0 / 0	11 / 1 / 0	12 / 0 / 0	12 / 0 / 0

The real descriptions on my channels run 293 to 1,042 characters, so twelve languages take a minute or less and at most 1.5 Wh. On the long sample I wrote for testing, Gemma used to get stuck in Hindi and repeat one word, पढ़ते ("reading"), until the answer limit. A retry with a repeat penalty now comes through, and the long sample dropped from 212-219 seconds to 157-162.

What I cut. Translating three languages at once. With gemma4:e4b, translation only, twelve languages took 11.9 and 12.5 seconds one at a time and 12.4 and 14.0 three at once, so one at a time stayed. A model picker and a settings page: the helper uses the best Gemma 4 you have, and your keep words live in one fold at the bottom of the panel.

Why Does Open Innovation Matter?

The person most afraid of a tool like this is a channel owner. An open tool that runs on your machine answers that fear with things you can check.

Google's consent screen for the YouTube scope says the app can "see, edit and permanently delete" your videos. Google offers no narrower scope that only writes translations, so any tool that publishes them has to ask for that much. Channel Tongues keeps the dangerous part small and visible:

The Google project is your own, the sign-in file stays on your disk, and Sign out deletes it and tells Google.
The code calls four API methods: three reads (your channel, your uploads list, your videos) and one write, videos.update, which sends only the translations. The one exception is a separate command that sets a video's language, and you run it by hand.
Every write starts with a backup and ends with a read-back, and Undo takes one click.
You can skip the sign-in. "I'll paste it myself" translates on your machine, and you copy the results or save them to a folder. No Google account appears on that path.

Running locally gives you the rest. A back catalog of a few hundred videos costs nothing per video, so you can localize all of it. Your channel and series names stay as written; YouTube's machine translation has no way to know they are names. And a better open model next month is one ollama pull and one setting away.

One cloud extension in this space states in its Chrome Web Store listing that it collects "authentication information", "web history" and "user activity". That may suit many people. For a channel owner who worries about their account, a local model and a local sign-in file decide whether they try a tool at all.

Honest limits. YouTube can't translate tags. The free API quota covers about 190 publishes a day. A Google project in Testing status signs you out every seven days. The read-back shares the model's blind spots and raises some false alarms, such as Japanese "Pleasant" for "Cozy". A translation can also pass every check and still get the meaning wrong: with gemma4:e4b, "Light Waves" at a harbor became "waves of light". Read before you publish; the panel shows the original next to every card.

My First User

I am the first user, on my own two channels, The Slow Night Hours and The Living Postcard.

The Living Postcard's three public videos had no translations. bin/tongues channel localize --langs used --apply added the 11 languages I last picked to each in 1 minute 54 seconds, with a backup before each write and none held back. By hand in Studio, that is 66 fields.
On a private test video on The Slow Night Hours, before the read-back line existed, the panel translated twelve languages in 10.4 seconds, published all twelve in one click, and Undo put the video back as it was.

Prize Categories

Best Use of Gemma: Gemma 4 writes every translation and every read-back through Ollama on the creator's own laptop, as gemma4:26b, or gemma4:e4b on smaller machines.

Credits: Gemma 4 by Google (Gemma Terms of Use) through Ollama (MIT); the Google API client for Go, golang.org/x/oauth2 and golang.org/x/text (BSD-3-Clause); modernc.org/sqlite (BSD-3-Clause); React, Vite and Vitest (MIT); the Inter typeface (SIL Open Font License 1.1); macmon for the power numbers (MIT). Audience figures from DataReportal's Digital 2025. Channel Tongues is MIT-licensed and not affiliated with YouTube or Google.

The Models Read the Release Notes. I Measured the Runtime.

Nazar Boyko — Sat, 10 Oct 2026 14:13:00 +0000

This is a submission for the Kaggle Benchmarking Challenge

What I Benchmarked

I've written PHP for most of my career and Go for the last few years, and in code reviews I repeat the same memory rules everyone repeats. A goroutine is 2 KB, don't worry about it. An int64 to int64 map entry is 16 bytes. unset() gives the memory back. Use map[K]struct{} for sets, because struct{} is free. I never checked any of them. Why would I? They've always been true.

Except some of them aren't anymore. PHP 8.2 stopped storing keys in packed arrays (php-src #7491). Go 1.24 threw out its old map implementation for Swiss Tables. Go 1.19 started picking the initial goroutine stack size from what it had seen so far. The rules stayed in our heads; the runtimes moved on. So I got curious: when a model answers a memory question, what is it actually remembering? The rule, the runtime, or the specific version?

Let's play. Guess before you scroll. Both maps hold one million keys:

set := make(map[int64]struct{})
for i := int64(0); i < 1_000_000; i++ {
    set[i] = struct{}{}
}

flags := make(map[int64]bool)
for i := int64(0); i < 1_000_000; i++ {
    flags[i] = true
}

How does the heap held by set compare with flags?

A. set is about 10% smaller
B. set is about half the size of flags
C. About the same
D. It depends on the Go version

Pick one. The answer, with the measured number, is waiting in Findings. If you enjoy this kind of thing, all seventeen cases are on this page: you pick an option, then you see what the runtime actually did.

Seventeen cases in total: seven about PHP arrays, five about Go maps, five about goroutine stacks. Three of them are controls, cases where the old rule is still right. Without those, a model could score well just by betting against every rule, and I didn't want to reward cynicism.

One thing I was strict about: not a single "correct answer" came from a blog post, including mine. A small harness builds each structure and reads memory_get_usage() in PHP or runtime.MemStats in Go. A GitHub Actions matrix runs it three times on PHP 8.1 through 8.4 and Go 1.23 through 1.26. If you don't trust my numbers, and you shouldn't have to, one command reruns everything:

sh measure/run.sh

Each case went to the models three times, as three separate Kaggle tasks:

cold: just the code and the question,
versioned: the same, plus the runtime version,
evidence: the same, plus one measured number from a neighbouring case.

Models answer in JSON: an option, an estimate in MB or KB, which mechanism they think explains it, and a confidence from 0 to 100. Plain code does the scoring, no LLM judge anywhere. A third of the point for the right option, a third for an estimate within 0.67x to 1.5x of the measured value, a third for the right mechanism.

Models Tested

Twelve models from Kaggle's list. I picked them along three lines: a small and a flagship model from each vendor, a newer and an older generation of the same vendor (did newer training data pick up Go 1.24 maps?), and a few open-weight models.

gemini-3.5-flash-lite, gemini-3.8-flash, gemini-3.1-pro-preview, gemini-2.5-flash, claude-haiku-5-5, claude-opus-5-5-default, claude-haiku-4-5-20251001, gpt-5.4-nano-2026-03-17, gpt-6.1-sol, gpt-oss-120b, gemma-4-31b-it, qwen3-coder-480b-a35b-instruct.

Nothing returned a 404 and I swapped nothing out. Eleven of the twelve have a complete run on all three tasks. The one that doesn't is gemini-3.1-pro-preview: 13 cold questions cost $0.89, one of its replies ran to 22,064 output tokens, and Kaggle gives my account $10 of model calls a day. Its partial replies are in the repository, but it's in none of the tables below.

There's also a thirteenth model in the tables, and I didn't invite it. When you create a task, Kaggle runs it once on gemini-3.7-flash. Those runs are as real as mine, so I kept them.

Findings

First, the answer to the game. On Go 1.23 the struct{} set is about 10% smaller than the bool map (ratio 0.91). On Go 1.24 and later they're the same size (ratio 1.00). So if nobody told you the version, the honest answer is D. Swiss-table maps keep key and value together in one aligned slot, and an empty value saves you nothing. When I put the version in the prompt, exactly 2 of 12 models followed the change: gpt-6.1-sol and claude-opus-5-5-default. Four others did change their answer for Go 1.24, in the wrong direction, to "half the size".

The two best models lost the same question, and it was a control. Here's the setup. I start 100,000 goroutines that each hold an 8 KB array, run a GC, then start 100,000 idle goroutines, and ask how much stack each idle one takes. The old rule says 2 KB. The Go 1.19 release notes say the runtime sizes new stacks from the average it has seen, which points at 16 KB. I measured 2.0 KB, on Go 1.23 through 1.26. Then I changed one thing: I let the first batch exit before starting the idle batch. Now each idle goroutine takes 16.0 KB.

Both numbers are right, and the runtime source explains why. newproc1 gives a brand-new goroutine a stack of stackMin, which is 2 KB. gfget hands out the descriptor of a finished goroutine again, and that one gets startingStackSize, the adaptive size. The links point at the current release, Go 1.27; the four versions I measured have the same two lines.

gpt-6.1-sol got 56 of 59 questions right. The three it missed are this control, once per task, at a stated confidence of 98 or 99. claude-opus-5-5-default missed it three times too. Both basically recited the release note back to me, with arithmetic. Across 36 runs, a model kept the control and lost its twin 19 times, did the reverse 14 times, and got both right twice. Both of those were gemini-3.5-flash-lite.

This is the part that changed how I'll use these models for runtime questions. A strong model knows the changelog better than I do. It also applies the changelog in places where the code doesn't.

The leaderboard. Task score, one complete run per model and task. The row without a slug is me, cold condition only.

model	cold	versioned	evidence	mean
`gpt-6.1-sol`	0.94	0.95	0.95	0.95
`claude-opus-5-5-default`	0.90	0.95	0.95	0.94
`gemini-3.8-flash`	0.84	0.86	0.79	0.83
`claude-haiku-5-5`	0.78	0.83	0.81	0.81
`gemini-3.7-flash`	0.80	0.81	0.78	0.80
`gemma-4-31b-it`	0.69	0.70	0.71	0.70
`gemini-2.5-flash`	0.67	0.68	0.65	0.67
author, cold only	0.67
`gpt-oss-120b`	0.53	0.57	0.56	0.55
`claude-haiku-4-5-20251001`	0.57	0.51	0.48	0.52
`gemini-3.5-flash-lite`	0.51	0.49	0.49	0.50
`qwen3-coder-480b-a35b-instruct`	0.41	0.44	0.52	0.46
`gpt-5.4-nano-2026-03-17`	0.37	0.35	0.44	0.39

Within a family, the newer generation wins by a lot: claude-haiku-5-5 at 0.81 against claude-haiku-4-5-20251001 at 0.52, gemini-3.8-flash at 0.83 against gemini-2.5-flash at 0.67. The older Gemini also burned more than twice the output tokens per question (5,445 against 2,235) to get the lower score. Not one reply failed to parse.

Version sensitivity. Four cases have a measured answer that flips with the version: three between PHP 8.1 and 8.3, one between Go 1.23 and 1.24. I asked each of those twice, once per version. gpt-6.1-sol and claude-opus-5-5-default got all four pairs right. gemini-3.8-flash and claude-haiku-5-5 got three, gemini-3.7-flash two, gpt-oss-120b one. Six models got none. All six said "2.5x" for the reversed array on PHP 8.1 and again on PHP 8.3, where I measured 1.25x and 2.50x. The Swiss-table case was the hardest (2 of 12 models), the SplFixedArray case the easiest (6 of 12).

"It depends" is a rare answer. With no version in the prompt, the right answer to those four cases is "it depends on the version". Models picked it in 13 of 48 replies. Most just answered for the newest runtime and moved on. My favourite: claude-opus-5-5-default wrote "Before PHP 8.2 the ratio was about 1.25x" in its reasoning, and then chose the PHP 8.2 option anyway.

Confidence. The stated number told me very little. Seven of the twelve models put 80 or more on every single wrong answer they gave. gemini-3.5-flash-lite and qwen3-coder-480b-a35b-instruct did it 32 times each, gemini-2.5-flash 22 times, gemma-4-31b-it 19. Only two models dropped by more than five points when they were wrong: claude-opus-5-5-default from 77.5 to 70.2, and claude-haiku-5-5 from 70.7 to 61.6. Haiku 5.5 put 80 or more on none of its 17 wrong answers, which is more self-awareness than I expected from a small model.

Right answer, wrong reason. qwen3-coder-480b-a35b-instruct picked the measured answer 27 times and explained 11 of those with a wrong mechanism. For gpt-5.4-nano-2026-03-17 it was 6 of 16. For the top two it was 0. If I had scored on the answer letter alone, none of this would have shown up.

Evidence barely helped. Handing a model one measured number from a neighbouring case moved almost nothing. From cold to evidence, the twelve models gained 14 right answers and lost 14.

Ask the same thing twice. Quota errors cut my first pass to pieces, so most models ended up answering many prompts twice. Across 501 pairs of replies to the same prompt, the answer letter matched 82% of the time. gpt-6.1-sol (19 of 19) and claude-opus-5-5-default (25 of 25) never changed their minds. gpt-5.4-nano-2026-03-17 and gemini-2.5-flash matched only 65% of the time. With one run per model, a gap of a few points on this leaderboard can be noise, and you should read it that way.

Which rules are dead, and which refuse to die. Not one model chose the folklore explanation for unset() freeing memory, for the 16-byte map entry, or for delete giving a map's memory back. Those rules are gone from the training data, it seems. The rules that were once true are the ones that live on. "SplFixedArray saves memory" was the chosen mechanism in 22 of 60 replies and "struct{} is free" in 21 of 60. I measured SplFixedArray at about half the memory of a plain list on PHP 8.1 (ratio 0.48) and about the same on PHP 8.3 (ratio 0.95). That rule held right up to PHP 8.2 and then quietly stopped.

In their own words.

gpt-6.1-sol on the control, confidence 98, measured 2.0 KB:

Since Go 1.19, adaptive stack sizing uses the average stack space scanned during the last GC, adds a stack guard, and rounds up to a power of two. The first batch dominates that average with live frames exceeding 8 KB, so the second batch starts with approximately 16 KB stacks.

qwen3-coder-480b-a35b-instruct on the game from the top, measured ratio 0.91 on Go 1.23 and 1.00 on Go 1.24:

struct{}{} takes zero bytes, so set only stores keys while flags stores both keys and bool values. Each bool is 1 byte, so flags uses roughly twice the memory for values.

gpt-5.4-nano-2026-03-17 on 100,000 three-property objects against 100,000 three-key arrays, where the arrays measured 3.12 times the memory on PHP 8.3:

In PHP, each $objects element is an object with overhead (zval + object header/handlers/property metadata), while $arrays elements are arrays with overhead too (zval + HashTable + buckets). For 3 fields, these overheads are of the same order, so memory_get_usage() is typically close.

A few more things the harness measured. All of these held on every version I ran:

unset() on every second element of a one-million-element list leaves memory_get_usage() exactly where it was (ratio 1.00 on PHP 8.1 and 8.3).
An int64 to int64 map holds about 38.1 bytes per entry on Go 1.24. The rule says 16.
Deleting every key and clear(m) both keep the full map after a GC (36.38 MB on Go 1.24).
A goroutine holding an 8 KB local array takes 16.0 KB of stack. "2 plus 8" would suggest 10.
One million two-element arrays [$i, $i] take 222.0 MB on PHP 8.3 and 390.59 MB on PHP 8.1. A pair of integers is 32 bytes, in theory.

My own score. 🤭 Before I looked at a single measurement, I answered the cold questions myself. I scored 0.67 on the same scale as the models: 10 of 17 answer letters, 14 of 17 mechanisms, 10 of 17 estimates inside the tolerance. My mean confidence was 80.5 when I was right and 70.0 when I was wrong. The cases that sting are P1, P4, P8 and G3. On all four the measured answer was "it depends on the version", and I did exactly what most of the models did: answered for the version I use, got the mechanism right on three of them, and never once said "it depends".

The quota, for whoever tries this next. Kaggle's model proxy reserves the worst-case cost of every call against a $10 daily quota: the model's maximum output at its output price, which is $2.56 for a single claude-opus-5-5-default call. I started twelve models at once and 160 questions came back refused. The fix was max_tokens on every call and no more than four models at a time. All 71 run files together cost $7.84.

What I'd measure next. Laravel collections on top of PHP arrays. The same harness on Alpine with musl, where the allocator is different. Goroutine stacks under real request handlers instead of synthetic frames.

Limits, so nobody has to dig for them. Seventeen cases and one scored run per model and task; the repeated replies above come from a partial first pass. One runner type per version (GitHub's ubuntu-24.04). Replies that never parse score zero and are counted; there were none. The Kaggle Benchmarks library sends no temperature to the model proxy, so a rerun can differ. Every call carries max_tokens=32768; the longest reply among the scored runs used 22,329 tokens. gemini-3.1-pro-preview has no complete run. The human baseline is one person, and he's biased.

My Benchmark

Benchmark and leaderboard: https://www.kaggle.com/benchmarks/nb9300/memorytrap-bench-php-arrays-go-maps/leaderboard
Tasks: memorytrap-cold, memorytrap-versioned, memorytrap-evidence
Guess-first page with every case: https://nazboyko.github.io/memory-trap-bench/
Code, measurements, raw model replies and the full report: https://github.com/nazboyko/memory-trap-bench
Rerun the measurements: sh measure/run.sh

The first four of twelve columns; the full board is behind the leaderboard link above.

Credits: the Kaggle Benchmarks library and platform ran the models; setup-php and setup-go gave me eight runtime versions in CI; the PHP and Go release notes, the pull request and the Go runtime source linked above explain the changes the harness measured.

Tabs to Trails: My Unread Tabs Became Walks, Made on My Own Laptop

Nazar Boyko — Fri, 09 Oct 2026 18:04:03 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

My reading system is a row of browser tabs I opened because the title looked worth my time, then kept open for weeks, because reading takes a chair and a chair is where I spend the day already.

Tabs to Trails turns those tabs into walks. A bookmarklet called "Walk this tab" drops the page you're on into a list, and each row shows how many minutes it takes to hear. When I've got twenty minutes, I pick 20. The app ticks what fits, oldest first, says how each piece will be read ("in full", "condensed from 27 min", "part 1 of 3"), and my laptop makes one MP3 of about that length. Gemma 4 rewrites the text for the ear and the Kokoro voice reads it, both on my machine. I scan a QR code with my phone, download the file, and put the phone in my pocket.

Everything the walk needs is inside the MP3: a short intro, the piece, a chime at the measured middle with "You're halfway. If you're walking out and back, turn around now.", and one question for the way home. The phone needs no app and no Wi-Fi once the file is on it. I set one rule for the design: the app has to be done with me before I reach the door. The only dark screen in the product is the phone's player, and it says "Pocket your phone." and little else.

Three things set it apart from "article to podcast". You bring the content, the thing you already meant to read. The length of your walk shapes it. And it stays faithful: the voice reads prose that fits as written, Gemma condenses only what doesn't fit, and a number guard checks every number in the rewrite against the source. Code blocks and tables are described rather than read, because a code block read aloud is noise.

Demo

Listen to two finished walks on the project page: my own DEV post, asked for 10:00 and measured 10:15, and part one of Thoreau's "Walking", asked for 20:00 and measured 19:39.

A note on the article in the video. It is "Every Software Developer Has Blamed…" by @sylwia-lask. I picked it as a real-world test, and about 20 seconds of the audio version made it into the video. I hope Sylwia doesn't mind me using her post as the example 😇😇😇

Go read the full post:

Relatable tech humor and shared grievances

Sylwia Laskowska

Oct 8

Every Software Developer Has Blamed…

#discuss

164

114

4 min read

Code

nazboyko / tabs-to-trails

Turn your reading backlog into a walk: a local Gemma 4 and Kokoro make an MP3 sized to your walk.

Tabs to Trails

Turn your reading backlog into a walk.

Save tabs now. Walk them later.

Tabs to Trails keeps what you mean to read, measured in walking minutes. When you have twenty minutes, pick 20 and it proposes what fits. Your computer turns that into one MP3 of that length: Gemma 4 rewrites the text for listening and the Kokoro voice reads it, both on your own machine. You scan a QR code, put the phone in your pocket and go.

The file holds everything the walk needs: a short intro, the reading, a chime and a cue at the halfway point so you know when to turn around, one question for the way home, and a sign-off. Its chapters let the phone's own player resume and skip, and an audiobook copy (.m4b) is one tap away. Once the file is on the phone, the walk needs nothing else.

…

View on GitHub

Node and TypeScript: a Hono server, a React front end, Gemma 4 through Ollama, Kokoro-82M through kokoro-js, ffmpeg for the MP3. Gemma 4 and Kokoro-82M are Apache-2.0; the full credits with licenses are in the README.

How I Built It

The pipeline:

link or text, saved to the list and read once
  -> picked by the walk's length
  -> plan: in full, or condensed to a word budget
  -> Gemma 4 rewrite per section, number guard
  -> Kokoro voice per sentence group
  -> measure, fit once, place the halfway cue
  -> MP3 + script + QR code

Every stage writes into one folder per walk, so a build can stop and pick up where it was. I tested that with kill -9 in the middle of the voice stage; on restart the server said "Picking up 1 unfinished walk" and carried on from the third section.

Twenty minutes is not twenty minutes

The length is the product, so I measure it instead of trusting a words-per-minute guess. That guess was wrong in two places.

The voice first. My calibration read a smooth 250-word passage at 188.7 words per minute, and then my own DEV post at 10 minutes came out at 10:42. Across that one post the same voice went from 130 to 174 words per minute per section, because numbers, colons and short paragraphs cost time, while characters per second stayed between 14.3 and 15.9. So the app now calibrates in characters per second, on a passage with numbers in it, and converts that into words per minute for each source.

Then the model. Gemma does not hold a word count on a mild cut: asked for 697 words of a 939-word section, it returned 1,027, longer than the source. Short targets went the other way: asked for 823 of 1,037 words of Thoreau, it wrote 450. So each section gets one guarded shorten or lengthen pass, and whatever it over- or undershoots carries into the next ones. At the end, a fit pass looks at the measured audio once: more than 5% over, it shortens the largest condensed section; more than 8% under, it gives time back to the section that left out the most.

The sample above took my DEV post from 1,726 words to 1,531, with 4.1 seconds of model time and 63.5 seconds of voice on an Apple M5 Max, for 10:15 of audio. Kokoro reads about nine times faster than real time here, so most of the wait is the voice. The app says "Lace up." while it works, and means it.

The number guard

The prompt tells Gemma to use only what is in the source. A small model adds a number from time to time. So after each rewrite, code compares every number in the output with the numbers in that section of the source, spelled-out ones included. A new number sends the section back once, naming it. If it comes back again, the script view draws a dashed outline around it: "Check this number."

The guard once flagged a number that was right: Wikipedia's "one-hundred and fifty percent" came back as "150 percent", and the guard read it as two numbers. It adds them up now. It also misses what it cannot see: "the kid screen got the time" (my evening, in other words) came back as "the kid screen showed the time", with no number involved. The script view's footer says to review anything important, and I mean that.

Read-along that lands on the word

Kokoro speaks in groups of a few sentences, and the app knows where each group starts. Inside a group, my first version spread the time over the sentences by their characters. Measured against the pauses in the audio, those starts were a median 0.3 seconds off, enough to mark the wrong sentence. Now each start moves to the nearest real pause in the voice, preferring longer ones. In the two samples, 231 of 232 sentence starts sit on a pause of at least a quarter second, 40 milliseconds before the voice is loud again.

What broke

Kokoro reads at most 510 phoneme tokens per call and drops the rest without a word. A 294-character chunk of money figures was 1,237 phonemes. Each chunk is now measured with the same phonemizer and split until it fits.
Wikipedia read its footnotes aloud: citation marks like [12] became "twelve". The app strips reference lists and footnotes now, and names what it left out.
The first run read an HTML comment. My own post ends with , and the voice said it.

I took it outside

I didn't film the walks; the video above is a screen recording with the real audio. The 10- and 20-minute walks went without a hitch. On a longer one, a phone call interrupted "Play it here" and I had to open the page and start again, so for long walks the downloaded MP3 or the audiobook file is the better way.

What I cut and what's next

I cut a model comparison with gemma4:e2b, because it wasn't on my laptop and I didn't want to download a model for one table. Next I'd try a pace setting per voice, and test the audiobook file and the reminder on more phones than mine.

Why Does Open Innovation Matter?

The documents I most want to walk with are the ones I can't put in a demo. With open weights on my own machine, the text goes from the clipboard to my disk and nowhere else, so the app works for anything I'm allowed to process on my own machine.

It also changes what a walk costs. There is no meter, so I can make one for a ten-minute errand and throw it away. Paste mode works with the network off once Ollama and the voice are installed.

And anyone can change it. The model is one setting (OLLAMA_MODEL), the prompts are plain text in the repository, and the voice is an Apache-2.0 model you can swap.

Prize Categories

Best Use of Gemma. Gemma 4 (gemma4:e4b through Ollama) does the language work: it condenses sections to a word target, describes code and tables for the ear, rates how much each section matters, and writes the closing question. The code around it keeps it honest: word budgets, the number guard, and a measured fit to the walk's length.

My Six-Year-Old Can't Do Five Things at Once, So His Screen Shows One

Nazar Boyko — Mon, 05 Oct 2026 03:30:12 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

My son is six and started kindergarten a month ago. A school morning asks him for five things: eat, brush teeth, get dressed, shoes and jacket, backpack. Breakfast is easy, because breakfast is one pancake with honey and he is very consistent about that. The rest is where it falls apart. He starts getting dressed, remembers his teeth, wants to play, and a few minutes later he is doing all three at once, which means none of them.

I noticed that he is fine with any single step. What he cannot hold is the list. So I built a screen for him that never shows a list.

One Thing is a small app for our home network. I type the routine in plain words. A Gemma 4 model running on my laptop turns it into a short mission with a theme (I went with rockets). I read every step and fix what I don't like. Only after I approve it does it reach the kid screen on the tablet, and there it shows exactly one step at a time: one big emoji, a few words, and one button.

Every rule on that screen comes from something I see on our mornings:

Rule	Why
One step on screen, never a list	The list is the problem.
Every step is read aloud	He is only starting to read.
The button has to be held, not tapped	A six-year-old will happily tap through eight steps in two seconds. Holding it takes a decision.
Brushing teeth is a timer he can't skip	"Until the timer ends" is easier to accept than "until Dad says so".
Nothing ever fails	No red, no "too slow", no points. If a timer runs out, the app asks once whether he is still on it.
The end is always visible	A row of dots with a small rocket on the current one. A routine with a visible end feels shorter.
I approve every mission first	He never talks to the model and never sees a word I have not read.

Demo

Try the kid screen yourself: nazboyko.github.io/one-thing/demo. It plays the built-in sample mission in your browser. Hold the amber button; a quick tap does nothing.

In the video (79 seconds) I type a routine for getting ready to go outside and give it the theme "space walk". Gemma writes the mission in 2.6 seconds. I scroll through the steps, approve it, and the kid screen plays the mission to the finale. The typing is sped up 2x and labeled. The kid screen runs at normal speed, and you can hear it say each step.

Where it stands. This is the first working version, built in one evening. My son has not used it yet. I wanted it finished and checked before it goes in front of him, and I wanted the first try to be a calm one, not one squeezed in before a deadline. Everything in this post is about the idea and how it is built, not about results.

Code

nazboyko / one-thing

A mission board that shows a kid exactly one step at a time. Runs offline on Gemma.

One Thing

A mission board that shows a kid exactly one step at a time. Runs offline on Gemma.

Try the kid screen in your browser: nazboyko.github.io/one-thing/demo (the built-in sample only; writing new missions needs Gemma on your own computer).

Why it exists

I built this for my six-year-old son. Routines with several steps are the hardest part of his day: on a school morning he wants to get dressed, brush his teeth and play all at once, and none of it gets done. A list does not help him, so this screen never shows one.

How it works

A parent describes a routine in plain words and picks a theme.
Gemma 4 runs on the laptop through Ollama and writes a short mission as JSON that has to match a schema. The server tidies it, checks every rule and asks the model once more if something is off.
The…

View on GitHub

How I Built It

The open-source AI at the center is Gemma 4, Google's open-weight model (gemma4:e4b, with thinking turned off). Ollama, an open-source runtime, runs it on my laptop. Around them sits one Go binary that uses only the standard library, with a React front end compiled into it. There is no database, no account and no cloud. Saved missions are JSON files in a folder, and the only network call the app makes is to Ollama on localhost.

parent's words ──> Go server ──> Ollama (Gemma 4, on the laptop)
                       │                    │
                       │   JSON that matches a schema
                       │<───────────────────┘
                 sanitize, validate, retry once
                       │
                 parent reads, edits, approves
                       │
                 tablet shows one step at a time

Getting a small model to return something I can trust. I don't want prose from the model. I want a mission my code can check. So the request to Ollama carries a JSON schema, and Gemma has to answer in that shape. A mission holds three to eight steps, and each step is described like this:

"items": {
  "type": "object",
  "required": ["emoji", "title", "say", "mode", "seconds"],
  "properties": {
    "emoji": { "type": "string" },
    "title": { "type": "string" },
    "say": { "type": "string" },
    "mode": { "type": "string", "enum": ["until_done", "for_duration"] },
    "seconds": { "type": "integer" }
  }
}

A schema guarantees the shape, not the sense. So every answer goes through two more functions. Sanitize fixes what is safe to fix: stray whitespace, Title Case in step titles, a timer outside the allowed range, an "emoji" that is not one. Validate returns plain field errors such as steps[2].title: too many words (at most 6). If any remain, the server sends them back to the model as a follow-up message and asks once more.

Here is what I typed:

Routine: School morning for a 6-year-old: breakfast, brush teeth, get dressed, shoes and jacket, backpack. Brushing teeth is the hardest part, split it into short pieces.

Theme: rocket launch

And this is the raw answer, with only the line breaks tidied:

{
  "title": "Ready for rocket launch",
  "intro": "Captain, it is time to prepare your rocket for today's mission!",
  "steps": [
    { "emoji": "🍳", "title": "Fuel up the rocket", "say": "Captain, eat your breakfast now. Keep fueling up!", "mode": "until_done", "seconds": 60 },
    { "emoji": "🦷", "title": "Polish top deck", "say": "Brush your top teeth. Make them shiny for blast off!", "mode": "for_duration", "seconds": 120 },
    { "emoji": "🦷", "title": "Polish bottom deck", "say": "Brush your bottom teeth. Mission control needs clean teeth!", "mode": "for_duration", "seconds": 120 },
    { "emoji": "👕", "title": "Suit up the rocket", "say": "Captain, get dressed now. Your flight suit is ready!", "mode": "until_done", "seconds": 60 },
    { "emoji": "🥾", "title": "Seal the landing gear", "say": "Put on your shoes and jacket. Time to secure your gear!", "mode": "until_done", "seconds": 60 },
    { "emoji": "🎒", "title": "Pack the rocket", "say": "Captain, pack your backpack. Make sure everything is inside!", "mode": "until_done", "seconds": 60 }
  ],
  "finale": "Mission accomplished, Captain! You are ready for launch!"
}

I would still change one line before approving it. "Keep fueling up!" sounds like "eat more", which the prompt tells the model never to say.

Numbers from my laptop (Apple M5 Max, 64 GB, Ollama 0.35, model already loaded):

Setting	Seconds per mission	Valid on the first try
Thinking off	2.4 on average (1.7 to 2.8)	22 of 22 runs
Thinking on (one run)	11.3	No: breakfast became a ten-minute timed step

The 22 runs went through the server while I tuned the prompt (school mornings, a bedtime, an after-school routine), and the time includes parsing and validation. The retry never fired; it is covered by tests against a fake Ollama. Thinking made Gemma several times slower and worse at this job, so it stays off.

The prompt needed real fixes. The first version returned valid JSON every time, and as a parent I would still have rejected half of it. Asked for "breakfast", it invented cereal. Asked to split tooth brushing because it is the hardest part, a bedtime run kept it as one two-minute step. So the prompt now says:

- Use only the actions and things the parent names. Do not invent foods,
  clothes or objects. If the parent says "breakfast", say "Eat your
  breakfast".
- If the parent says a part is hard or asks to split it, that part MUST become
  two or three separate steps. Brushing teeth becomes "top teeth" and then
  "bottom teeth", each its own timed step.

Brushing has been split in every run since. Two more fixes came from reading output the same way: one run said "eat your breakfast until done", and another made breakfast a two-minute timed step, which would have locked the button while he eats.

What did not work. In 3 of 8 morning runs that I read line by line, Gemma folded "shoes and jacket" into just "shoes". Four rounds of prompt changes fixed everything else I found, but not this. The screenshot below shows it happening again, unedited: step 5 has no jacket. This is why the parent reads every step before approving, and why I would not let a model talk to my son directly.

Small things that turned out to matter:

The hold button fires after 0.8 seconds, measured from timestamps, not animation frames. Quick taps do nothing, and letting go early drains the ring.
Step timers come from timestamps too, so a throttled tab stays correct. ?speed=20 in the address makes them twenty times faster, which is how the screen got tested without brushing anyone's teeth for a minute at a time.
Gemma once returned a colon as the "emoji" for both teeth steps, and my validator let it through: it only rejected letters and digits. Now any plain ASCII there is rejected and replaced with a star.
The first voice the app picked sounded robotic. It now uses only voices installed on the device, never a network one: Premium first, then Enhanced, then a short list of natural voices, and never the novelty voices macOS ships. On the parent screen I can pick another voice and test it.
If I set a time to leave, the last screen says how long is left: "You have 14 minutes to play before liftoff."

What I cut. A speed comparison with the smaller gemma4:e2b. It was not on the laptop, so I have no numbers for it. It was one evening, and the kid screen got the time.

What is not tested yet. It has run in a browser in tablet mode on my laptop, not on a real tablet, and not with the person it is for. Speech voices differ between devices: for a natural one on a Mac or iPad, you download a Premium or Enhanced English voice in Settings > Accessibility > Spoken Content (Read & Speak on newer macOS), and the app picks it by itself. I expect the timers to need tuning once a real six-year-old is holding the button.

Why Does Open Innovation Matter?

For this project it is not a nice extra. It decides whether I would use the thing at all.

The input is a description of where my child struggles. "Brushing teeth is the hardest part." "He only eats one thing for breakfast." That is what I type into the box. With open weights on my own laptop, those sentences go from my keyboard to my own memory and nowhere else. I did not have to read anyone's privacy policy to decide that this was fine.

It does not need the internet. The page, the Lexend font, the model and the saved missions all live on the laptop. A morning routine should not depend on somebody else's uptime.

It costs nothing, so I can be picky. I generated dozens of missions while tuning the prompt. There is no meter running, no key to protect, and no account to create for a tool that a six-year-old uses.

Anyone can change how it thinks. The system prompt is a text file in the repository, and the model is one line of configuration. If your kid is four, or ten, or needs steps cut even smaller, you edit a paragraph of English, not a product.

A hosted API would probably have written similar JSON. But I would be sending notes about my son to a third party every time, paying per call for something that runs a few seconds a week, and tying his morning to a service that can change or disappear. The weights are a file on my disk, and the whole point of this tool is that every day looks the same. For a family tool, local and open is simply the right shape.

Prize Categories

Best Use of Gemma. Gemma 4 runs locally through Ollama and writes every mission. It is used with schema-constrained output, a validation and retry loop, and a system prompt written for one specific job: turning a parent's description into single, physical, kid-sized steps.

Side Project Graveyard: a proper burial for dead repos

Nazar Boyko — Sun, 04 Oct 2026 17:27:41 +0000

This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange

What I Built

I have a folder of side projects that stopped at some point and never really came back. Some of them were useful for a while. Some made it into production. Some survived for two days, got a README, and then spent the next three years pretending they were merely "paused".

So instead of deleting them, I built them a cemetery. 😂😂😂

Each project gets a stone: its years, an epitaph, a cause of death, the stack, the last commit message, and the one thing it taught me. You can walk the yard, hover a cause of death to see which graves it took, read an obituary, and light a candle.

No stone has its own artwork. A stone's height comes from how long the project lived, its moss and cracks from how long ago it died, its marks from the cause of death, its brass and flowers from being retired with honour. A two-day todo app is a low marker with a wooden tag. A framework that never had a user is a mausoleum.

The home page opens with a register: 14 buried, 3 retired with honour, average lifespan 355 days, most common cause of death "Lost interest". Nobody typed those numbers. A grave points to its cause and its stack as Sanity documents, and Astro counts them during the build.

There are 18 graves. Five are public repos of mine, written up from their GitHub metadata and READMEs. The other 13 are invented, and you have met them before: the todo app that lived two days, the framework with a router, an ORM and no users, the newsletter with one subscriber and a 100% open rate.

Demo

Live site: side-project-graveyard.boyko-nazar.workers.dev

Three clicks worth making:

The register on the home page, then hover "Lost interest" in the legend and watch the other graves step back.
Sunday Letter, the newsletter tool. Read the last line of the obituary.
The candle on any grave. It counts in your browser and nowhere else, and the page says so. Go back to the yard afterwards: that grave is lit there too.

The animated tour at the top is a Playwright recording of the live site, converted to a GIF with ffmpeg.

Code

nazboyko / side-project-graveyard

Side Project Graveyard

Every repo deserves a proper burial.

I have a folder of side projects that stopped. This site gives each of them a stone: an epitaph, a cause of death, the stack it was built with, its last commit message, and the one thing it taught me. The content lives in Sanity, the site is Astro, and I built it for the DEV × Sanity Challenge by prompting Claude Code.

Live site: https://side-project-graveyard.boyko-nazar.workers.dev
Studio: https://side-project-graveyard.sanity.studio
Sanity project ID 20pcz8by, dataset production (public)
Build log, with every prompt and every failure: docs/BUILD_LOG.md

All six screenshots, at 1440, 768 and 390 pixels, are in docs/screenshots.

Content model

Four document types, defined in studio/schemaTypes/.

Type	What it is	Fields
`project`	A grave	name, slug, epitaph, status (buried, retired, undead), born and died dates, cause, stack, last commit, mood at death, lines of code, obituary, lesson, repository, and an

…

View on GitHub

studio/ is the Sanity Studio: four schema types, the desk structure, the seed content, the script that set the monument fields.
web/ is the Astro site: one file of GROQ queries, one file that turns a record into a monument, one of date and stats maths, all tested; five page templates; one stylesheet bundle; every drawing hand-written SVG; five generated images for the scene and the stone, in web/src/assets/scene/.
docs/DESIGN_BRIEF.md is the redesign plan, written from two outside reviews.
docs/visual-enhancement/ is the visual audit a second agent wrote before it touched the materials, and docs/image-prompts.md has the prompts for the five images.
docs/BUILD_LOG.md is the prompt log. Every prompt is in it word for word, and so is every failure.
CLAUDE.md holds the rules the session ran under.

My Build Process

I used two tools. Claude Code built the site and the redesign, in one session. Codex, a second agent, wrote a visual audit and implemented the material pass at the end. Claude Code then reviewed that pass and corrected it.

Before the session I wrote two things by hand. A plan: the concept, the schema, and one prompt for each of eight phases. And a rules file: one phase is one branch and one pull request, merge when CI is green, write every prompt and every failure into the build log, stop only when a step needs my browser. Then I typed one kickoff prompt and the model read the phase prompts from the plan.

The numbers: 16 pull requests, and CI never failed on one of them. The build took 8 phases and about 95 minutes of the model's work; the first five phases, from a bare Studio scaffold to 42 built pages, took 52. Then the session waited seven hours for me to click through a hosting dashboard. The redesign took five more pull requests and about 65 minutes, with two stops for my review. The material pass was one pull request by the second agent, and the review of it took Claude Code 66 minutes. A final check before publishing found twelve dependencies without a credit in the README; that fix was the sixteenth pull request. 25 messages from me in all.

The parts worth telling are the ones where the prompt and the result disagreed.

My kickoff was wrong in three places. It said my global git excludes would hide the tooling folder. They did not. It assumed a git identity existed on the machine. None did. It asked for a job-level if: hashFiles(...) in the CI workflow, which GitHub Actions does not allow. The model caught all three before anything failed: it ran git check-ignore before staging, looked up the author on my earlier public repos before the first commit, and moved the condition to the steps. The build log lists them under "what failed", because my prompt failed, even if no command did.

The schema got its real test from a broken file. The prompt asked for a date rule: a death date is required unless the project is undead, and it cannot come before the birth date. The model wrote 17 validation rules with messages in the voice of the graveyard keeper. Then it could not check them on screen, because the Studio stops at a login and it does not sign in to my accounts. So it wrote three broken graves into a file and ran sanity documents validate on it. Seven errors came back, among them "A project cannot die before it is born." and "Only the undead may go without a date of death."

astro add installed React into a site with a no-React rule. npx astro add @sanity/astro added react, react-dom, sanity and styled-components as direct dependencies. They are peers of the integration, for an embedded Studio this site does not have. The model removed them and tried to keep them off disk with legacy-peer-deps. That broke astro check, which then printed a misleading request to install @astrojs/check, a package that was already there. The cause was a pruned peer of an unrelated package. The model found it by importing the package by hand, dropped the setting, and let npm install the peers. Same phase: npm installed TypeScript 7, astro check wants 6. Three retries in 13 minutes, all in the log.

The screenshots looked right and the page was wrong. After building the pages the model took screenshots at three widths and they were fine. Then it read the text of the links in the browser and found "Previous graveEverything.js" and "Lost interest5graves". Two spans sat side by side with no space between them, so a screen reader would have read them as one word. No screenshot shows that. Lighthouse came out at 100 in all four categories after the fix, and I trust the number more because of what was found before it.

The plan said Cloudflare Pages. The dashboard gave me a Worker. "Connect to Git" now creates a Worker with static assets, built by Workers Builds. My plan, my rules file and the README the model had drafted all said Pages. I also told the model to continue before the hosting existed and gave it the URL I expected to get. It did not take my word for it. The name did not resolve, there was no .env, sanity hooks list was empty. It deployed the Studio, wrote the webhook test script, and stopped again with that evidence. When I came back with the real URL, the fix was an 11-line wrangler.jsonc and a reworded README. A publish in the Studio now reaches the live site within a minute. I measured it with a script that stamps the footer line and polls the page.

The review changed the order of the graves. The first version listed the newest death first. That put my five real repos in the top rows, with sober one-liners from their READMEs, and pushed the better epitaphs below the fold. The review phase flagged it. The graves are now ordered oldest first, which is how a cemetery grows: the old part is by the gate.

The redesign started from a working site that looked like a dashboard. Five tiles, a row of pills, eighteen identical cards. I had two outside design reviews done, and one of them proposed a map in TypeScript with a visual entry per project. That would have put content in code and broken for the next grave. The brief I wrote instead had one rule: the stone is computed from the record. The model added one field to the cause (motif) and one optional group to the grave (monument: shape, relic, inscription, figures), set them with one script, and wrote describeMonument(project, now), which knows no grave by name. A test runs it on the seed file and checks the brief's own counts: 4 ancient stones, 6 aged, 2 settled, 5 fresh, 1 disturbed.

The model was not allowed to ship anything it had not seen. Every visual branch went through at least three rounds of screenshots at three widths, and the model read every image. 19 drawings were redone because of what it saw. The sky had no warm band. The fence strip read as a barcode. Moss looked like polka dots. The smallest stone floated in the sky above the fence because the candle button was pinned to the ground instead of the stone. A shovel pushed a marker off its tag. Signpost, briefcase and crates were brown on brown ground and disappeared. None of these would have shown in a type check.

A second agent added the photographs, and the first one reviewed its work. The redesign was drawn in CSS and SVG and still looked flat. I generated five images in ChatGPT (image model Sol 5.6, effort set to medium, two candidates per image, and I kept the one with the better detail and the right amount of objects in the frame): a wide dusk cemetery, a portrait version for phones, a limestone tile, a soil tile and a strip of grass. Codex wrote an audit of the site first, then put the photographs behind the gate and the limestone on the stones, in one pull request, and reported Lighthouse accessibility 100. Claude Code reviewed that pull request from its own screenshots. It measured the pixels behind the tagline and got 2.65:1. Lighthouse cannot measure text over an image, so the 100 had not covered it. It also blocked the image to test the fallback and found half of the old fence in the dark, found a pale gate post floating in the sky of every grave page, and found that one of its own relics from the day before had been lying across "lived less than a day" the whole time, in a screenshot it had committed itself. Eleven fixes went in. Firefox would not start for the model on my machine, so I opened the preview in Firefox myself, and the log says the check was mine. The last fix came after that: the relics had always had an ink outline in Safari and none in Chrome, and now they are flat in both.

One of the six repos I had named as real graves turned out to be private. The prompt said to skip it in that case, and the model did. For the five real ones it left "mood at death" and "lines of code" empty. Its note in the log: they would have been guesses.

What I cut and why

A form where visitors bury their own projects. It needs accounts or moderation, and neither fits a weekend.
A candle count shared between visitors. It needs a write path, and the dataset is read-only from the site on purpose. The count is local and the page says so.
The Studio embedded in the Astro site. It needs server output, and this site is static files.
A library of photographed stones. The brief planned cutouts for every shape. Five generated images replaced it: two for the scene, three as materials. The stone shapes are still CSS masks, the words on them are still HTML, and the relics are still hand-written SVG.
A backdrop I can change from the Studio. The field exists and works, but one wide image cropped for a phone is not the portrait image, so it stays empty and the two local images are the default.
A gate that swings open on scroll, leaves, fireflies, a crow. One fog band and one cat stayed.
Every animation except the candle, the undead grave's light, the fog and a 3-pixel lift on hover.
The App SDK and Workflows bonus. I wanted one path done well.

What I would do differently

I would check the hosting dashboard before writing the plan. Seven hours of this build were me finding out that a product had been renamed.

I would also give the model a way to see the Studio. It tested the schema well without it, but I am the only one who has looked at the desk.

Sanity Project Details

Project ID: 20pcz8by
Dataset: production (public)
Studio: https://side-project-graveyard.sanity.studio
Schema: studio/schemaTypes/. Four types: project, cause, tech, siteSettings. The grave has an optional Monument group; the cause has a required mark.
Seed content: studio/seed/graveyard.ndjson, 41 documents.

The dataset answers without a token. This query returns each cause of death with its number of graves:

https://20pcz8by.api.sanity.io/v2026-09-01/data/query/production?query=*[_type=="cause"]{title,"graves":count(*[_type=="project"%26%26references(^._id)])}|order(graves desc)

The content model is small on purpose. Cause and stack are references, so the site can count them. The death date is validated against the birth date and the status. The epitaph is capped at 120 characters because that is what fits on the stone, the inscription at 28 ("The mason charges by the letter."), the figures at three ("A grave is not a dashboard."). The settings are one document that the Studio will not let you duplicate or delete.

Every part of a stone comes from these fields: height from the dates, weathering from the date of death, marks from the cause's motif, brass from the status, shape, relic and inscription from the optional monument. The cat sits on whichever grave was published last, so it moves when I publish.

Agent Session

The full agent transcript is not attached: it contains my local notes and paths that are not part of the project. Every prompt is in docs/BUILD_LOG.md instead, word for word: one entry per phase, with what came out, what failed, and what the model decided on its own. The material pass ran in a Codex session, and its prompts are in the same log.

Seed content is a mix of five real dead projects of mine and 13 invented ones. The stats are computed from all of them at build time.

When to Stop Asking the AI to Fix Its Own Fix?

Nazar Boyko — Thu, 01 Oct 2026 04:34:23 +0000

A few weeks ago I ran into one of those bugs that looked simple enough that I kept thinking the next fix would probably solve it. A small Node.js and TypeScript service was pulling jobs from several APIs, normalizing them and storing them in PostgreSQL. The background worker finished without errors and logged that the import had completed successfully, but when I checked the database, some of the jobs simply weren't there.

Running the same import again would often make more of them appear. Not all of them, just more, which made the problem look like some kind of timing issue. So I asked the AI to take a look. 😎

The first suggestion was to add retries around the database writes. That seemed reasonable, but it didn't help. Then came a delay, changes to the transaction boundaries, a higher retry count and eventually some extra error handling around individual inserts. Four rounds later, the symptom was exactly the same, while the diff had spread through the worker, the database layer and the tests.

The actual bug turned out to be an async callback inside a forEach. None of the suggested fixes had touched it.

I don't think the AI was being dumb here. I think I kept handing it the same information and asking for a different answer.

Look at the symptom from the AI's side for a second. Rows go missing and a rerun brings more of them back and nothing in the description says where they went, so it smells like timing, right? Every fix it suggested followed that smell from the first round to the last.

First it added retries around the database writes. Then came a delay, different transaction boundaries and a higher retry count. By the last round, it was catching individual insert errors so one bad record wouldn't affect the rest of the batch.

Those guesses weren't unreasonable. If all you know is that some rows go missing and a rerun brings some of them back, a timing issue is an obvious place to look. I probably would have started there too. 🙄

The funny part is that there really was a timing problem, just not the one we were trying to fix. The writes weren't happening too early or taking too long. The worker simply wasn't waiting for them to finish.

And that's where the debugging nightmare really started, because by that point neither the AI nor I seemed to understand the problem any better than when we began. 😕 By the fourth attempt, the suggestions had started circling back to the same ideas, just with slightly different settings. The last one went in another direction, but it still didn't solve the problem. If an insert fails and the code catches the error and continues, the row is still missing; now the failure is just quieter.

Here's what I think was going on. Every round the AI got the same clues (some rows are missing and a rerun brings back more). Unless a model gets logs or a way to run things, it works from the description and the code it can see, and "still missing" adds nothing to either of those. So it guessed again from the same clues, except that now the conversation also held every guess that had already failed, and every new answer had to work on top of the code the previous answers had left behind in the worker and the database layer.

At some point I realized we weren't really debugging anymore. We were just generating new guesses from the same two facts: some rows were missing, and running the import again brought some of them back.

And every failed fix made the next round a little messier. Now the AI wasn't only looking at the original code. It was also looking at retries, delays and transaction changes that had been added during the previous attempts. The code was changing, but my understanding of the bug wasn't.

Could a better prompt have helped? Maybe, but I'm not sure what I could have put in it. Everything I knew was already in the conversation. I could rewrite "some rows are missing" five different ways, but it was still the same piece of information.

What I actually needed wasn't a better way to describe the symptom. I needed one new fact about what the program was doing.

The Fact Was In The Order Of The Logs

So I stopped asking for another fix, reverted the changes and went back to the worker as it was before all of this started. This time I followed a single import through the logs from beginning to end, including the database writes.

That showed something off right away, just from the order of the lines. The worker logged "completed" before all of the inserts had finished. A job can't be done while its own writes are still running, unless nobody's waiting for them.

Here's the shape of the code. On a quick read it looks fine:

jobs.forEach(async (job) => {
  await saveJob(job);
});

console.log("Import completed");

forEach calls the callback once per job and ignores whatever the callback returns. An async callback hands back a promise as soon as it reaches its first await, so forEach ends up with one promise per job, drops every one of them on the floor and returns as if the work were done. MDN says it plainly: forEach() "expects a synchronous function" and "does not wait for promises." So the log line runs while the inserts are still in flight and the job gets marked complete with its writes still going in the background, and by the time some of those writes failed the worker had already reported the whole import as a success.

I think that's also why a rerun kept bringing more rows in. Every run got a few more of the inserts through.

The fix is to give the code something to wait on:

await Promise.all(
  jobs.map((job) => saveJob(job))
);

console.log("Import completed");

Now the log line waits for every insert and if one of them fails Promise.all rejects and the code after it never gets to say "completed". It does start all the inserts at once, though, and MDN notes that a rejection "does not cancel the remaining operations", so after one failure the rest keep running. If you want the result of every insert, Promise.allSettled waits for all of them. And if parallel inserts aren't wanted at all, a plain loop does one at a time:

for (const job of jobs) {
  await saveJob(job);
}

console.log("Import completed");

It's slower, but nothing's running behind your back. (There's also a lint rule for this exact mistake. typescript-eslint's no-misused-promises flags an async callback passed to forEach and it's switched on in the recommended-type-checked config, so a type-aware lint setup would have pointed straight at it.)

Anyway, once I saw the order in the logs, finding the actual bug took a few minutes.

After Two Failed Fixes, I Go Find A Fact

My rule now: if two AI fixes fail and I still haven't learned anything new about the bug, I stop asking for another fix. First I find one new fact: a repro, an error, a payload, a stack trace or just the real order of events like this time. Then the AI comes back in, with that fact. Not before.

What made me stop this time was the diff, honestly. It had spread into the worker and the database code and the retries and the tests while the symptom stayed exactly where it was, and on top of that one of the new suggestions was just a variation of something it had already tried. Those two together are a pretty reliable sign that the guessing's run out. I'd add one more: a fix that swallows errors has stopped looking for the cause.

I'm not saying AI is bad at debugging. I still use it for this all the time. But if I'm on the third fix and I still haven't learned anything new about the bug, I've probably stopped debugging and started guessing.

That's what happened here. A fifth fix would have been working with the same information as the first four. The logs were the first thing that actually changed what I knew.

How many failed fixes do you usually let an AI try before you stop and go back to investigating the bug yourself?

The AI Writes Better React than Vue

Nazar Boyko — Tue, 29 Sep 2026 13:41:23 +0000

In May 2025 a team at ByteDance published Web-Bench, a coding benchmark with an unusual detail tucked into its appendix. It gives the same tasks to four UI frameworks (React, Vue, Angular and Svelte) and checks every result with end-to-end tests. The model that led their overall results was Claude 3.7 Sonnet. With thinking turned off it passed 65% of the tasks in React. In Vue it passed 30%.

I also tried testing this on two projects, and sure enough, the AI is better trained or, I would say, has a better understanding of React projects. 🤷

Here's the whole table from the paper's appendix. The numbers are pass rates in percent, measured as pass@2 over five runs:

Model	React	Vue	Angular	Svelte
Claude 3.7 Sonnet (thinking)	60	40	50	55
Claude 3.7 Sonnet	65	30	40	25
Doubao 1.5 Pro (thinking)	50	40	25	40
Doubao 1.5 Pro	35	35	5	10
GPT-4o	35	30	5	20
DeepSeek-R1	40	30	30	40

It's a small sample. Each framework gets one project of twenty tasks so five points is roughly one task. The ranking isn't clean either, and Svelte beat Vue for two of the six models even though far fewer people use it. But React came out at or above Vue for every model on the list. And the authors' first explanation is the one anyone would guess: React "provides the largest dataset for LLM training."

It matches what I see in my own work. React from an assistant usually reads like React somebody wrote this just recently, whereas in Vue, deviations are more common! And these deviations often look as if someone used a Vue 2 template that no longer exists, or mixed two API styles within a single component. Nothing dramatic. Just more to check.

So there's a criterion that has quietly slipped into framework choice, one nobody likes to say out loud: the AI is better at it. Is that a legitimate reason to pick a framework? Noooo... It's a legitimate input and a bad deciding factor. Here's how I get there. I'll start with the case for yes because it's stronger than the people who dislike the question want it to be.

The model has just read a lot more React

If we look at some basic statistics from GitHub, for example, we can see that the number of stars on GitHub hardly reflects this difference. The paper lists React at 235k and Vue at 208k but stars measure attention and a model learns from the code people actually write and publish, so usage is where the gap lives.

In the 2025 Stack Overflow survey 44.7% of respondents used React and 17.6% used Vue. On npm React got about 203 million downloads in the week of September 21 to 27, 2026 and Vue got about 18 million. That's the same roughly 11x gap that showed up when I compared the two frameworks.

Vue also carries a history problem that React mostly doesn't. Vue 2 shipped in September 2016 and was supported until the last day of 2023, while Vue 3 only came out in September 2020 and removed a handful of things Vue 2 code leaned on (the $on event methods, filters, $set), so for four full years almost every new Vue tutorial, answer and public repo on the internet was written for Vue 2, and some of what they taught doesn't work anymore.

Vue 3 also has two official ways to write a component. There's the Options API and there's the Composition API, and both are fully supported (the docs even point out that the Options API is built on top of the Composition API). So the model has three dialects of Vue in its training data. Mixing them is what I'd expect from a model that has seen all three used side by side for years. That's my reading, to be clear. The benchmark didn't test why.

React has old dialects too. Class components are all over public code and the React team only deprecated Create React App in February 2025. The difference is proportion, I think. There's so much hooks-era React out there that the current idiom usually wins.

The case for yes is real

In the same survey the most common frustration with AI tools was "AI solutions that are almost right, but not quite" and 66% of developers picked it. And 45.2% said debugging AI-generated code takes longer. That's why if a project has only recently been updated to Vue 3 but some components or services still use the Vue 2 approach, then each such instance requires a code review. Each one costs a read and a re-prompt, and across a team and a year that adds up to real hours.

Onboarding is the other half. Someone new to a React codebase who leans on an assistant gets taught current React. The same person on a Vue codebase can get taught a blend of Vue 2 and Vue 3 with no way to tell which parts are which. For a junior that can be worse than no help at all, because the old idiom arrives with exactly the same confidence as the current one and nothing in the diff or the passing test says which of the two they just learned.

Honestly, the mixed-style component is the sneakier problem. It usually runs fine. It just makes every later reader's job harder and it's the kind of thing that gets merged because it works.

So if a team is choosing between two frameworks it could live with equally well and it'll write most of its code with an assistant, I don't think it's silly to pick the one the assistant writes better, since that's a cost like any other and costs belong in a decision like this. If the argument stopped there I'd have nothing to add.

Choosing by corpus feeds the corpus

Here's where I get off. The first problem is that picking a framework because the model's read the most of it is a loop. The popular option gets more code written in it. The next models train on that code and get better at it, and that's what pushes more people toward it.

Lovable's one of the AI app builders, and in February 2025 it explained why it generates React. The reason it gave is the loop in one sentence: models trained on code "can generate high-quality React code due to its dominance in online resources." So the apps a tool like that produces are React, and some of those apps get pushed to public repositories, and public repositories are exactly what the next round of models reads when its makers go looking for code to learn from, and round it goes. I don't blame Lovable, it's a sensible product call. That's exactly why it's a loop and not a conspiracy (every single step in it is reasonable on its own, and I'd probably have made the same call in their seat).

There's a second gear, and it's the one that worries me more. The public Q&A that taught models how people really use a framework is drying up. A study in PNAS Nexus found that activity on Stack Overflow dropped 25% within six months of ChatGPT's release, compared with Russian and Chinese Q&A sites where ChatGPT was hard to get. The authors' own conclusion is that "the decreased production of open data will limit the training of future models."

React built its mountain of public answers before that happened. The next framework has to build its pile in a world where people ask a chatbot instead of posting a question, and the chatbot answers in a private window, and nobody's around to write the better answer three comments down that the next model would've learned from. If everyone picks by corpus size, nothing new ever gets a corpus.

What I want is a Vue and a Svelte and whatever comes after them still pushing on React ten years from now, and a whole industry quietly picking by training data is how that stops happening.

Models change in months, frameworks stay for years

The second problem is timing. Look again at the model that led that benchmark. Its API name is claude-3-7-sonnet-20250219 and Anthropic's deprecation page lists it as retired on February 19, 2026. That's a year to the day after the date in its name. After that requests to it just fail.

Vue 2 got support from September 2016 to December 31, 2023. More than seven years. A framework picked this year will very likely still be in the codebase long after the models that made it look like the easy choice have been deprecated, retired and replaced a few times over, by which point the reason it was picked is one line in an old planning doc and the code is the only thing left.

The gap itself also moves, and the clearest sign of that comes from the React side. I use CLAUDE.md in my project, and it includes a block that next dev wrote on his own! And to be honest, I didn't even notice it! It opens with "This is NOT the Next.js you know" before warning the agent that APIs, conventions and file structure "may all differ from your training data" and telling it to read the docs bundled inside node_modules before it writes any code at all. Turns out even React's biggest framework tells the model not to trust what it learned, and that's the side with the biggest corpus. Vercel measured the fix too. In their evals the agent that had the version-matched Next.js docs in front of it hit a 100% pass rate against 79% for the best skill-based setup.

I'm not aware of a Vue measurement like that. There's a community project called vuejs-ai/skills, which calls itself an early experiment and lives outside the official Vue organization. Anyway, the point stands: a fluency gap is the kind of thing that can shrink in a release or two, and nobody revisits a framework choice that fast.

An input, not the decision

So I'd keep it on the list, just not at the top. The codebase that already exists comes first, then the team you have and the one you'll hire, then the meta-framework that fits the product. After that comes how well the assistants you use write it, as a real line in the cost column. Between two options that tie on everything else it's a fair tiebreaker.

And if the answer is Vue or Svelte or anything else with a smaller pile behind it, go in knowing the price. More review time per generated file. Output checked against the current docs, not the model's memory. Mixed API styles treated as a real review comment and not a nitpick. Putting the current docs in the model's context the way Next.js now does by default makes the gap smaller, though I'm not sure it ever gets to zero.

I'd still rather pay that in review hours than pick a framework for the one reason that'll be out of date first. If you've picked a stack partly because the assistant was better at it, I'd like to hear how that held up.

Thanks for reading! English isn't my first language, so I use AI to polish the grammar. Everything else here - the ideas, the code, the opinions - is mine.

Enjoyed this one? Let's stay in touch — I'm on LinkedIn, always happy to chat, swap ideas, or just say hi. 👋

React and Vue Are Turning Into the Same Framework

Nazar Boyko — Mon, 28 Sep 2026 14:26:49 +0000

Before diving into this article, I have to say that I haven't been a front-end developer for a very, very long time 😁 I just analyze architectures and enjoy listening to people who argue about what's best to use on the front end. So I might be wrong about some things. 🤷‍♂️🤷‍♂️🤷‍♂️ Please correct me if I'm wrong!

Recently, I came across a team that was rewriting a project from Vue to Ract, and their argument was that Vue runs slower. 😬 This made me wonder, why does Vue run slower? And it turned out that the Vue code had been generated but not optimized.

And while there were a lot of questions about the code generation itself in the Vue project, the team didn’t have any questions at all about the generated code in the React project because everything works well there. 🤔🤨 But I won’t go into that right now, I’d rather analyze everything in detail and describe it in another article.

I won't go into a detailed comparison either, since there's plenty of that online. I'll just list the three main popular aspects below. Some add a fourth about templates versus JSX. That one's taste, so I'll leave it alone.

	React	Vue
Virtual DOM	yes	yes
Memoization	by hand, with `memo`, `useMemo` and `useCallback`	automatic, through reactivity
What re-renders	the component and its children, unless you stop it	only what read the state that changed

Every row in that table is out of date or about to be. React now ships a compiler that writes the memoization for you, and Vue is finishing a compile mode that drops the virtual DOM for any component that opts in. The two of them started from opposite ends of the same old argument and ended up in roughly the same spot: a build step that works out what doesn't need to run.

That's why I think this is the first year the interesting React vs Vue question isn't a technical one. They aren't the same framework. There's a whole section below on where they still split, but the three talking points everyone reaches for are exactly the three that are dissolving.

React's Memoization Moved Into The Build

React's default is simple and a bit blunt. The memo docs say it in one line: "React normally re-renders a component whenever its parent re-renders." For years the fix was to tell React by hand what was safe to skip. Here's what that looks like in a small product list with a search box and rows you can pick:

ProductList.jsx (by hand, before the compiler)

import { memo, useCallback, useMemo, useState } from 'react'

const ProductRow = memo(function ProductRow({ product, onPick }) {
  return <li onClick={() => onPick(product.id)}>{product.name}</li>
})

export function ProductList({ products }) {
  const [query, setQuery] = useState('')
  const [picked, setPicked] = useState(null)

  const visible = useMemo(
    () => products.filter((p) => p.name.includes(query)),
    [products, query]
  )
  const onPick = useCallback((id) => setPicked(id), [])

  return (
    <>
      <input value={query} onChange={(e) => setQuery(e.target.value)} />
      <p>Picked: {picked ?? 'nothing'}</p>
      <ul>
        {visible.map((p) => (
          <ProductRow key={p.id} product={p} onPick={onPick} />
        ))}
      </ul>
    </>
  )
}

There are three tools here and two of them only work as a pair. memo lets a row skip rendering when its props look the same as last time. useCallback keeps onPick the same function between renders. That part matters. A fresh function counts as a changed prop and quietly defeats the memo. Forget the useCallback and the memo still compiles, still passes review, still looks perfectly responsible in the diff. It just skips nothing. useMemo is the odd one out. It keeps the filter from running again when the only thing that changed is picked.

The React team was blunter about all this than I'd be, and in the React Labs post from February 2024 they wrote that "manual memoization is a compromise. It clutters up our code, is easy to get wrong, and requires extra work to keep up to date."

React Compiler 1.0 shipped in October 2025 and works with React 17 and up. For new code the release post recommends "relying on the compiler for memoization and using useMemo/useCallback where needed to achieve precise control." Expo has had it on by default since SDK 54. Next.js 16 made the reactCompiler option stable but left it off by default while the team gathers build performance data (they also warn that builds get slower with it on, since the compiler runs through Babel, and the Rust port that runs inside Turbopack only showed up in Next.js 16.3 in August 2026 as an experimental flag). So "React memoizes for you now" is true, with a footnote: on the most popular React framework, somebody still has to flip a switch first.

What matters for this comparison is the component with the compiler on, next to the Vue version of the same thing:

ProductList.jsx (with React Compiler)

import { useState } from 'react'

function ProductRow({ product, onPick }) {
  return <li onClick={() => onPick(product.id)}>{product.name}</li>
}

export function ProductList({ products }) {
  const [query, setQuery] = useState('')
  const [picked, setPicked] = useState(null)

  const visible = products.filter((p) => p.name.includes(query))
  const onPick = (id) => setPicked(id)

  return (
    <>
      <input value={query} onChange={(e) => setQuery(e.target.value)} />
      <p>Picked: {picked ?? 'nothing'}</p>
      <ul>
        {visible.map((p) => (
          <ProductRow key={p.id} product={p} onPick={onPick} />
        ))}
      </ul>
    </>
  )
}

ProductList.vue

<script setup>
import { computed, ref } from 'vue'
import ProductRow from './ProductRow.vue'

const props = defineProps(['products'])
const query = ref('')
const picked = ref(null)

const visible = computed(() =>
  props.products.filter((p) => p.name.includes(query.value))
)
</script>

<template>
  <input v-model="query" />
  <p>Picked: {{ picked ?? 'nothing' }}</p>
  <ul>
    <ProductRow
      v-for="p in visible"
      :key="p.id"
      :product="p"
      @pick="picked = p.id"
    />
  </ul>
</template>

The React version's just the first one with every wrapper deleted. The Vue version never had wrappers to delete.

The Compiler Writes Your useCallback, Not Always Your useMemo

I ran that plain React file through babel-plugin-react-compiler 1.0.0, because I wanted to see what it actually produces rather than trust the diagrams, and the answer is a lot of bookkeeping: ProductList gets 21 cache slots, ProductRow gets 6 of its own, and every one of them is a plain array entry checked by an if. Here's the part of ProductList that matters, trimmed down:

ProductList.jsx after babel-plugin-react-compiler 1.0.0 (trimmed)

export function ProductList(t0) {
  const $ = _c(21);
  const {
    products
  } = t0;
  const [query, setQuery] = useState("");
  const [picked, setPicked] = useState(null);
  // ...
  if ($[0] !== picked || $[1] !== products || $[2] !== query) {
    // ...
    const visible = products.filter(t4);
    let t5;
    if ($[8] === Symbol.for("react.memo_cache_sentinel")) {
      t5 = id => setPicked(id);
      $[8] = t5;
    } else {
      t5 = $[8];
    }
    const onPick = t5;
    // ...
  }
  // ...
}

That Symbol.for("react.memo_cache_sentinel") check is the compiler's version of useCallback(fn, []). The first render stores the function in slot 8 and every render after that reads it back. Nobody wrote a dependency array.

The filter's where it gets interesting. My hand-written useMemo was keyed on products and query. The compiler put products.filter(...) inside a block that's also keyed on picked. So picking a row runs the filter again. With fifty products nobody will ever notice. If the filter were genuinely slow, this is the case the release post means when it says to keep useMemo for "precise control", because the compiler caches what flows into the output and its idea of a sensible cache boundary (one big block keyed on everything the JSX reads, as far as I can tell from this output) isn't always the one I'd have drawn by hand.

Vue Got The Same Result From Reactivity

None of this was ever a question in the Vue version. The reason is how Vue decides what to run. Its docs describe it plainly: "each component instance creates a reactive effect to render and update the DOM." The render reads query, picked and visible, Vue records those reads, and only a change to one of them re-runs this render. computed caches its value and only re-runs the filter when products or query changes, so picking a row doesn't re-filter and I never had to say so.

Children follow a matching rule. Vue's performance guide says "a child component only updates when at least one of its received props has changed."

Here's the detail I didn't know until I read the compiled output. In the normal virtual DOM build the inline @pick handler inside the v-for becomes a brand-new function on every render. That's exactly what useCallback exists to prevent in React. Vue doesn't care. The runtime function that decides whether a child updates is called shouldUpdateComponent, and in it a changed prop only counts if it isn't a declared event listener, so as long as ProductRow declares pick in defineEmits, a brand-new handler on every render doesn't make a single row update. React asked me to keep the function stable. Vue just stopped comparing it.

Vue isn't completely free either. "Never needed memoization" oversells it a little. The same performance guide has a section on props stability: pass activeId to every item in a list and every item updates when it changes, pass active (a boolean worked out in the parent) and only the items whose value actually flipped do. That's the same class of problem React's memo solves, except in Vue you fix it by shaping props instead of wrapping components.

Vue even has its own dependency array. v-memo, which arrived in 3.2, skips a whole subtree unless the values in its array change. The docs say it's "provided solely for micro optimizations in performance-critical scenarios and should be rarely needed." Rarely needed is the honest version of never.

Vue Is Compiling Its Virtual DOM Away

Vue's virtual DOM already isn't the purely runtime kind. The template compiler leaves hints for the runtime (patch flags that say which part of a node can change, cached static content, flattened blocks so the diff skips whatever can't change), and the Vue docs call this a "Compiler-Informed Virtual DOM" and contrast it with React's, where "the reconciliation algorithm cannot make any assumptions about the incoming virtual DOM tree."

Vapor Mode goes the rest of the way. A component that opts in compiles to direct DOM operations with no virtual DOM at all, and since this is the claim in here that's most likely to go stale, here's exactly where it stands:

Vapor first shipped in Vue 3.6.0-alpha.1 in July 2025.
The first beta landed in December 2025, with the team saying Vapor now had "feature parity with all stable features in Virtual DOM mode" (Suspense in a Vapor-only app being the exception).
3.6 went to release candidate in July 2026. The newest one as I write this is 3.6.0-rc.9, from September 18.
npm's latest tag for vue still points at 3.5.43. There's no stable Vue release with Vapor in it yet.

The RC release notes call Vapor "feature-complete" and "100% opt-in." For now they recommend it for two things: a performance-sensitive page inside an existing app or a small new app built entirely in Vapor. Opting in takes one attribute on the script tag, <script setup vapor>, and after that the only real decision is about the app: one created with createVaporApp() leaves the virtual DOM runtime out of the bundle entirely, while a normal createApp() app can mix Vapor components in through vaporInteropPlugin and keep everything else exactly as it was.

I compiled the Vue component from the tabs above with 3.6.0-rc.9 in both modes. The normal build returns a render function that builds vnodes, like Vue always has, while the Vapor build returns this:

ProductList.vue with script setup vapor, Vue 3.6.0-rc.9 (trimmed)

const t0 = _template("<input>")
const t1 = _template("<p> ")
const t2 = _template("<ul>")
// ...
  const n1 = t1()
  const x1 = _txt(n1)
  _renderEffect(() => _setText(x1, "Picked: " + _toDisplayString(picked.value ?? 'nothing')))
  // ...
  const n2 = _createFor(() => (visible.value), (_for_item0) => {
    const _on_pick = () => (picked.value = _for_item0.value.id)
    const n4 = _createComponent(ProductRow, {
      product: () => (_for_item0.value),
      onPick: () => _on_pick
    })
    return n4
  }, (p) => (p.id), 3 /* FAST_REMOVE, IS_COMPONENT */)

There's no render function here and no vnodes. The markup is turned into real DOM templates once and cloned from then on, the <p> gets exactly one _renderEffect, and when a row is picked that effect is the only thing in the whole component that runs: it sets the text of one text node, and that's it. Props go to the child as getter functions (product: () => (_for_item0.value)), so the child reads the current value itself instead of receiving a new props object. The component's setup runs once and never again. Turns out that's the Solid model, and Vue's own docs say so, describing Vapor as a "Solid-inspired compilation strategy."

The subset's real, though. Vapor components don't support the Options API, app.config.globalProperties or v-memo, and getCurrentInstance() returns null inside them, but the one I'd watch for in an existing app is events. Vapor delegates most listeners to document. The release notes spell out the catch: if any ancestor calls stopPropagation() "the delegated handler will not run." Mixing Vapor and virtual DOM components works for ordinary props, events and slots, but the notes still warn about "rough edges" with VDOM-based component libraries.

The Paths Met At The Compiler, Not At The Mental Model

Put the two compiled outputs side by side. The convergence is obvious. Both frameworks now ship a compiler that rewrites a component into code nobody would write by hand, and both compilers exist for the same reason: to skip work for things that didn't change.

The mechanism's where they still split, and honestly I think it's the most important difference left. React's compiled ProductList is still a function that runs on every single render and checks its 21 cache slots on the way through to reuse whatever it can, while Vapor's version runs once and then leaves individual DOM nodes to a handful of effects, so that component never renders a second time.

React chose that on purpose, and the same React Labs post from 2024 says so: "Our vision is for React to automatically re-render just the right parts of the UI when state changes, without compromising on React's core mental model." That core model is UI as a function of state, and signals would change it. The TC39 Signals proposal is still at Stage 1. Its README credits design input from the authors of thirteen named projects, Vue among them. React isn't one of them. Vue's docs say outright that "signals are the same kind of reactivity primitive as Vue refs." And 3.6 goes further: it rewrites the core of @vue/reactivity by porting alien-signals, a standalone signals library, for better speed and memory use, so a reactivity system that was always signal-shaped now literally has a port of one sitting at its center. (The state management landscape piece covers what signals look like when you add them to React from the outside.)

This one's the difference you feel every day, not just in benchmarks. In React I call setPicked(id) and the whole function runs again with new values and the props stay read-only snapshots the entire time, so what I reason about is renders, while in Vue I write picked.value = p.id and the state changes in place and whatever read it updates on its own. There I reason about dependencies. Someone fluent in one has to relearn habits in the other. No compiler touches that part.

The Server Moved Closer On Both Sides, Unevenly

The third shared direction is the server. It's the messiest one. React 19 made Server Components stable in December 2024, and in the Next.js App Router "layouts and pages are Server Components" by default, with 'use client' added only where a component needs state or event handlers. And there's nothing like that in Vue's core. Nuxt has server components: .server.vue files that render on the server as islands and add none of their code to the client bundle, but the Nuxt docs say they're "still marked experimental" and that on client-side navigation "each island on the destination page must be fetched from the server." That's a different shape from RSC, where server components are the default and a serialized payload carries the rendered server tree to the client. Nuxt's stronger server story is Nitro, the server engine that lets API routes live in the same project as the pages, and it's the part of Nuxt I'd point a React developer at first.

Moving work to the server isn't free on either side, and the Next.js 16.3 announcement says plainly that Server Components "made navigations feel slow." A big chunk of that release is tooling to fix it. So both camps agree the server should do more, they just don't agree on the unit: React made the component the unit of server work, while Nuxt works at the level of routes and server endpoints and keeps component islands experimental.

The Ecosystems Are Nowhere Near The Same Size

Here's the row that didn't converge at all. These are npm downloads for the week of September 20 to 26, 2026, pulled straight from the npm downloads API:

Package	Weekly downloads
`react`	203,498,378
`vue`	18,457,765
`next`	67,256,843
`nuxt`	2,364,072

Download counts measure installs, not people (every CI run counts, and so does every package that depends on these), but an 11x gap between the libraries and a 28x gap between the meta-frameworks isn't noise, and Stack Overflow's 2025 survey points the same way from the people side: 44.7% of respondents used React and 17.6% used Vue, 20.8% used Next.js and 4% used Nuxt.

One number from that same week made me look twice. babel-plugin-react-compiler got 17.8 million downloads, nearly as many as vue itself. That's not a typo. A big part of that is Expo. Its Babel preset depends on the plugin because Expo turns the compiler on by default, and babel-preset-expo alone got 10.9 million downloads in the same week. Still. A React build plugin now gets installed about as often as the entire Vue framework.

None of that makes Vue small. Eighteen million installs a week is a very alive framework. But size is what decides how easy hiring is and how many libraries work on day one and how many answers already exist for your strange edge case, and React has a lot more of it.

Where I'd Actually Make The Call

Okay, but Vapor benchmarks alongside Solid and Svelte 5. Isn't that exactly the kind of performance gap a React compiler can't close?

It's a real gap in the benchmark. I won't argue that. The Vue team cites the js-framework-benchmark for that claim, and a compiled React component that still re-runs on every render isn't going to match one that never re-runs. It just doesn't decide the choice for most products. Vapor is still a release candidate, it's opt-in per component, it supports a subset of Vue, and the Vue team itself recommends it for one hot page or a small new app. And in my view the diff is rarely what makes a product feel slow anyway (the network and the amount of JavaScript shipped usually are), so if one screen really is diff-bound that's a reason to try Vapor on that one screen and not a reason to pick a whole framework.

So here's how I'd choose, in order.

The codebase you already have. If there's a working React or Vue app, keep it. In 2026 a rewrite from one to the other buys almost nothing on performance. Turning on the React Compiler is far cheaper than a migration. So is trying Vapor on the one slow page.

The team you have and the one you'll hire. A team that knows Vue deeply will ship better Vue than it'd ship average React, and the reverse holds too. When people switch, it's the mental model from earlier that costs them. The APIs are the easy part. If you're hiring a lot, the survey numbers are the honest tiebreaker: the React pool is about two and a half times bigger.

The meta-framework that fits the product. This is the one I'd spend the most time on. It now decides more of the architecture than the UI library does. Next.js if the product wants server components as the default and the team is ready for the server and client boundary and its caching model. Nuxt if the product wants a full-stack Vue app with server routes next to the pages and a more gradual path to the server. Most of the differences between React and Vue that still matter in 2026 live one layer up, in these two.

If your team already knows one of them well, that's your answer. It probably always was, we just had more interesting things to argue about.

Thanks for reading! English isn't my first language, so I use AI to polish the grammar. Everything else here - the ideas, the code, the opinions - is mine.

Enjoyed this one? Let's stay in touch — I'm on LinkedIn, always happy to chat, swap ideas, or just say hi. 👋

Laravel Is Not As Heavy As You Think

Nazar Boyko — Tue, 22 Sep 2026 13:25:12 +0000

Recently I came across another discussion about Laravel's memory usage and I can't say that it was exactly new to me, I've worked with Laravel and Lumen for years and have seen how differently they can behave in terms of memory, but it made me curious about what actually creates that difference. Is Laravel itself really that expensive, is Lumen significantly lighter because of the framework, or are we mostly looking at the effects of PHP configuration, OPcache, bootstrapping, and the way the application loads data? 🤷‍♂️

So I decided to measure it properly and break down where the memory actually goes. The result was not what I expected.

A hello-world route in a fresh Laravel 13 app peaks approximately at 0.66MB of PHP memory. The framework's share of that is 316KB. That's everything that runs before my controller method does. Ten thousand Eloquent models loaded in the same app cost 17MB. I went in expecting the ratio to go the other way because the number everyone quotes for a Laravel request is "20MB, maybe 30" and the framework gets the blame for it.

And it turns out that this number is also accurate! It’s simply the value you get when OPcache is disabled, and OPcache is off in exactly the places people measure, which is php artisan tinker and the test suite and the dev container, so the number travels from there into the pm.max_children calculation and the memory_limit argument and the "Laravel is heavy" thread, and nobody checks it again. So this piece is the two numbers side by side, then a walk through the knobs everyone reaches for with a before and after for each (php artisan optimize, the Composer class map, deferred providers, OPcache itself), then the one thing that actually moved the number by a lot. Which was how the models got loaded.

The setup first so the numbers mean something. Laravel 13.31.0 on PHP 8.4.22, in the official php:8.4-fpm-alpine image on an Apple silicon Mac, with MySQL 8.4.11 in a second container, and every request going through real PHP-FPM, a static pool with a single worker, with cgi-fcgi sending the requests so nothing else touches the process. Every number below is the third request to a route, so the worker's warm and OPcache has compiled everything it's going to compile. And MB in this article means 1,048,576 bytes because that's what memory_limit counts in.

The measuring code is small. Two constants at the top of public/index.php before the autoloader loads:

public/index.php

define('LARAVEL_START', microtime(true));
define('MEM_INDEX_START', memory_get_usage());
define('MEM_INDEX_START_REAL', memory_get_usage(true));

And a controller method that takes a reading on entry and does the route's work and returns every counter I could think of as JSON:

app/Http/Controllers/MeasureController.php

public function modelsGet(Request $request)
{
    $n = (int) $request->query('n', 10000);
    $entry = memory_get_usage();

    $items = Item::query()->where('id', '<=', $n)->orderBy('id')->get();

    return response()->json([
        'index_start' => MEM_INDEX_START,
        'route_entry' => $entry,
        'after_hydrate' => memory_get_usage(),
        'peak' => memory_get_peak_usage(),
        'peak_real' => memory_get_peak_usage(true),
        'count' => $items->count(),
    ]);
}

The worker's resident memory comes from reading VmRSS out of /proc/self/status in the same method, which I left out of the listing. The items table has 100,000 rows. Its eight columns are the kind a product table has: a SKU, a name, a 120-character description, a price, a quantity, a flag and the two timestamps. It's boring on purpose, because I wanted the shape of a product table rather than a benchmark table.

memory_get_usage(true) Counts 2MB Chunks, And A Warm Worker Starts With Several

Before any Laravel numbers I want the two functions straight. The gap between them confuses people and honestly I had to go read the allocator to be sure I understood it myself.

memory_get_usage() is what the script has allocated right now through PHP's allocator. memory_get_usage(true) is what that allocator has taken from the operating system whether the script is using it or not. The manual says the second one is "the value that memory_limit is enforced against" and adds that the amount the operating system has given the process is a different and typically much larger number. So there are three numbers, what you use, what the allocator holds and what the process holds, and this article is mostly about the first with a stop at each of the others.

The allocator is the Zend Memory Manager (Zend/zend_alloc.c in php-src). It asks the OS for memory in chunks of exactly 2 * 1024 * 1024 bytes, the ZEND_MM_CHUNK_SIZE constant in zend_alloc_sizes.h, and it hands 4KB pages out of those chunks to the script. That's why memory_get_usage(true) only ever returns multiples of 2,097,152. Never anything else. Every "real" figure in my results is one of those: 2,097,152 for the hello route and 20,971,520 for 10,000 models and 186,654,720 for 100,000. Anything bigger than a chunk minus one page is a "huge" allocation and gets its own mmap() call. So the very large numbers aren't rounded quite as coarsely.

Here's the part I didn't know. On the third request for 10,000 models the worker had just served the first two. memory_get_usage(true) at the very top of index.php said 14,680,064. Seven chunks before a single line of Laravel ran. After two requests of 100,000 models the same line said 136,314,880. That's sixty-five chunks. The allocator doesn't hand chunks back at the end of a request. In zend_mm_shutdown it keeps a running average of how many chunks each request peaked at, holds that many in a cache for the next one, and resets the real counter to (cached_chunks_count + 1) * ZEND_MM_CHUNK_SIZE, so on a worker that has seen a heavy request the real number starts high and stays high for a while, even for a hello world, until enough small requests pull the average back down. That's not a leak, it's the allocator guessing that the next request will look like the last few.

Two practical consequences. memory_limit is enforced against the chunk count. A script whose memory_get_usage() never reached 128MB can still die with "Allowed memory size of 134217728 bytes exhausted", because the chunks behind it got there first. And if you log memory_get_peak_usage(true) from a long-lived worker as the cost of a request you're partly logging the previous request. For per-request work the non-real peak is the honest one. Since PHP 8.2 there's also memory_reset_peak_usage() for the Octane and queue-worker case where the process never ends.

Without OPcache The Bootstrap Is 15MB. With It, 316KB

Now Laravel. Same hello route and same worker in two configurations, and that's the whole experiment. The first is what laravel new leaves you with when OPcache isn't on: no config cache and no route cache and the plain PSR-4 autoloader. The second is what a deploy script should leave you with: php artisan optimize plus an optimized class map plus OPcache on.

Checkpoint	OPcache off, no caches	OPcache on, caches on
top of index.php	385,200	339,640
after vendor/autoload.php	2,007,888	360,608
after bootstrap/app.php	3,285,760	418,152
controller method entry	15,773,808	663,096
peak for the whole request	17,827,888	691,216
files included	460	400
classes declared	444	410
wall time	28.3ms	0.8ms

Bootstrap here means the difference between the top of index.php and the first line of the controller, and it's 15,388,608 bytes in the first column and 323,456 in the second. 14.7MB against 316KB for the same framework and the same 400-odd files and the same providers registered and booted. The 47x difference is where the compiled code lives.

This was one of those results where I reran the test a few times because the difference looked almost too large to be real. 😁😁😁

Without OPcache every one of those 460 files is read, tokenized, parsed and compiled on every request, and the result (the opcodes, the class tables, the constant arrays, the interned strings) is allocated in the request's own heap through the same allocator memory_get_usage() watches, and that's the 15MB. Laravel isn't doing anything with it. It's the cost of holding the compiled form of Laravel in memory once per request per worker and throwing it away at the end.

With OPcache on the compiled form lives in a shared memory segment. PHP-FPM's master process maps it once and every worker uses it. opcache_get_status() on the same hello request reported 412 cached scripts using 22,686,344 bytes of that segment out of the default 128MB (opcache.memory_consumption=128). So the 15MB didn't disappear, it became 21.6MB that's paid once per server instead of once per request, and it stopped showing up in memory_get_usage() entirely because OPcache's segment isn't the request heap.

An honesty note, since this is the part where a cheaper per-request number gets sold as a cheaper server. The FPM worker's resident memory for the hello route was 27.7MB with OPcache off and 30.7MB with it on. That's higher, not lower. The worker now has the shared segment's touched pages mapped in as well as its own heap. What OPcache buys isn't a smaller process. It's a process that doesn't grow by 15MB of compiled framework every time a request starts, and a request that takes 0.8ms instead of 28.

'php artisan optimize' And The Class Map Barely Move The Number

This is the section I expected to be the meat of the article, and it turned out to be the footnote. Every deploy guide says to run php artisan optimize (config:cache and event:cache and route:cache and view:cache in one command) and composer install --optimize-autoloader. Both are right. Neither's about memory.

Peak memory of the hello route in all eight combinations:

Autoloader	artisan optimize	OPcache	Entry	Peak
PSR-4	no	off	15.04MB	17.00MB
PSR-4	yes	off	14.33MB	16.40MB
class map	yes	off	15.53MB	17.60MB
authoritative class map	yes	off	15.53MB	17.60MB
PSR-4	no	on	0.77MB	0.80MB
class map	no	on	0.77MB	0.80MB
PSR-4	yes	on	0.63MB	0.66MB
class map	yes	on	0.63MB	0.66MB

php artisan optimize is worth 0.7MB per request without OPcache and 143KB with it, and that's the whole effect. You can see the mechanism in the file count: 460 included files without the caches and 400 with them. The config cache replaces reading .env plus every file in config/ with one require of a 20KB bootstrap/cache/config.php. The route cache replaces routes/web.php and all the registration calls with a single cached file. Those are real savings in time and syscalls (the docs describe config:cache as reducing "the number of trips the framework must make to the filesystem"), and they're tiny in memory, because reading thirty small PHP files and reading one bigger one produce roughly the same arrays in the end.

The class map is the more interesting row because it goes the wrong way. composer dump-autoload -o turns the PSR-4 rules into a flat array of 6,861 class-to-file entries (this app has 8,090 PHP files under vendor/) and that array has to exist in memory to be useful. Without OPcache it's built on every request, the "after autoload" checkpoint went from 2,007,888 bytes to 3,272,056, and the whole request got 1.2MB more expensive. With OPcache the array is a literal in a compiled file and OPcache stores literal arrays immutably in the shared segment and the per-request cost of the map is zero. The --classmap-authoritative flag, the one that stops Composer from checking the filesystem for classes missing from the map, changed nothing I could measure either way. Which is fine, because Composer's own docs sell the class map as a speed feature ("should always be enabled in production") and speed is what it delivers: fewer file_exists calls per class rather than fewer bytes.

So both knobs are worth turning and both are for CPU and disk rather than memory.

Deferred Providers Save Nothing Unless register() Does Work

Deferred providers come up in every Laravel performance thread so I tested them too. The framework already does this for itself: the compiled manifest in bootstrap/cache/services.php for this app lists 31 providers (30 from the framework plus AppServiceProvider), and 16 of them are eager and 15 are deferred. The question was what deferring my own provider would save.

Four providers added one at a time to bootstrap/providers.php, measured on the hello route with everything else in the production configuration:

A normal provider: three singleton() bindings in register(), nothing in boot(). The kind you write for a payment gateway or a search client.
The same provider, deferred: implements DeferrableProvider, with provides() listing the three bindings.
A heavy provider: register() does require on a 527KB PHP file that returns a 5,000-entry lookup array and binds it as an instance. The anti-pattern where "registering" a service means building it.
The same heavy provider, deferred: the require moves inside the singleton closure, so it runs only when something resolves the service.

Extra bytes at controller entry compared with no extra provider at all:

Provider	OPcache off	OPcache on
normal, eager	+8,168	+2,456
normal, deferred	+384	+0
heavy, eager	+3,373,528	+184
heavy, deferred	+176	+0

The normal provider costs eight kilobytes when it's loaded on every request and nothing when it's deferred. Eight kilobytes, for the whole provider, on every request. That's one file compiled and one object constructed. It's exactly what the docs say deferring saves ("it is not loaded from the filesystem on every request") and it's no more than that. If the app has forty providers like that then deferring all of them is worth about 300KB without OPcache and about 100KB with it. Rendering one small Blade page added about 200KB in the same runs.

The heavy provider is the row worth staring at. Without OPcache it costs 3.4MB per request because the whole 5,000-entry array gets built from source each time and deferring it takes that to zero. With OPcache it costs 184 bytes per request even when eager, because the array is a literal in a compiled file and OPcache keeps it as an immutable array in the shared segment, and I checked this twice since I didn't believe it: the segment's used_memory grew by 1.3MB when that provider was added and the request heap didn't move. require on a file that returns a constant array is close to free under OPcache. require on a file that computes an array or reads JSON or hits the network is not, and deferring is the fix for that whether OPcache is on or off.

So deferring's a real tool with a narrow target: providers whose register() actually does work. Marking a provider that only binds closures as deferred is correct and clean, and it won't show up on any graph.

Ten Thousand Models Cost 17MB. A Hundred Thousand Don't Fit

Everything so far was fractions of a megabyte in the production configuration. Here's what the route that loads data did on the same worker with the same OPcache and caches:

Route (10,000 rows)	Entry	Peak	Peak, real	Time
`Item::query()->...->get()`	0.64MB	18.44MB	20.0MB	40ms
`DB::table('items')->...->get()`	0.64MB	14.15MB	16.0MB	9ms
`->chunk(1000, fn)`	0.64MB	2.58MB	6.0MB	52ms
`->lazy(1000)`	0.64MB	4.25MB	6.0MB	52ms
`->cursor()`	0.64MB	3.17MB	4.0MB	122ms
`->cursor()`, unbuffered query	0.68MB	0.88MB	2.0MB	119ms

Ten thousand Eloquent models are 17,991,000 bytes on top of the entry point, which is 1,799 bytes per model for a row with eight columns. The same ten thousand rows through the query builder, as plain stdClass objects with no Eloquent around them, are 11,717,416 bytes or 1,172 per row, so the row itself (the strings and the numbers and the object that holds them) is about two thirds of the cost and Eloquent's $attributes array plus the $original copy it keeps for dirty checking plus the model object itself is the other third. Neither number is surprising once you know every PHP value carries a header and every array slot costs more than the value inside it. I think, the point is the ratio between them. One get() on ten thousand rows is fifty-five times the whole framework bootstrap and it's a line most codebases have somewhere, behind an export or a report or an admin page nobody paginated.

At 100,000 rows the get() route peaked at 183,961,728 bytes. That's 175MB, with the worker's resident memory at 208MB. Under the default memory_limit=128M it doesn't get that far:

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes)
  in /app/vendor/laravel/framework/src/Illuminate/Database/Connection.php on line 442

Then a second fatal 65,536 bytes later in ClassLoader.php, while Laravel tried to autoload the exception handler to report the first one, so the client got a 500 with an empty body, nothing reached laravel.log, and the only evidence of what happened was in the FPM error log.

The 50,000-row version fit at 88MB, and somewhere between those two numbers is the export that works in staging and dies on the first real customer. The fix isn't a bigger limit, it's the other four rows of the table, and they aren't equal.

chunk(1000) peaks at 2.58MB and stays there whether the table has 10,000 rows or 100,000 (2.65MB at 100k). It runs one LIMIT 1000 OFFSET n query per page, hands the page to the callback, and then (this is in BuildsQueries::chunk) calls unset($results) before fetching the next page, so there's one page in memory at a time, and the price is a hundred queries for a hundred thousand rows, 1,088ms in total against 407ms for the single get().

lazy(1000) peaks at 4.25MB. Higher than chunk, and I think that's because of how the generator's written. The loop is $results = $this->offset($offset)->limit($limit)->get() followed by a yield per row, so when page two is fetched page one is still sitting in $results until the assignment completes, which puts two pages at the peak instead of one, and it's still flat (4.32MB at 100k) and it's still the one I'd pick for a foreach, because 1.7MB isn't a reason to prefer chunk's callback style over a plain loop.

cursor() is the one people get wrong. I'd got it wrong too before I ran this. It runs a single query and yields one hydrated model at a time so it looks like it should be the smallest of the lot, and at 10,000 rows it's 3.17MB, and at 100,000 rows it's 24.28MB and climbing with the table. The Laravel docs say why in a sentence that's easy to skim past: it "will still eventually run out of memory" because of "PHP's PDO driver internally caching all raw query results in its buffer". A MySQL query is buffered by default, so mysqlnd pulls the entire result set into the PHP process before the loop sees the first row, and with mysqlnd that buffer counts against memory_limit. So cursor() saves you the hydrated models and nothing else. It doesn't save you the rows.

The last row of the table shows what happens when the buffer goes away. I set PDO::MYSQL_ATTR_USE_BUFFERED_QUERY to false on the connection before the same cursor() call and the 100,000-row loop peaked at 920,976 bytes. That's under a megabyte for the whole table in a single query. The manual's caveat is that an unbuffered result set owns the connection until it's fully read, so any query inside the loop on the same connection fails, and Laravel's own docs point you at lazy() instead for that reason, and I'd agree with them for anything that touches the database inside the loop. For a pure read-and-stream job an unbuffered cursor is the smallest thing PHP can do with a result set and honestly it's underused.

One more data point, because it changes the advice depending on the database. I repeated the cursor run against SQLite (a fresh Laravel install ships with it) and cursor() over 100,000 rows peaked at 847,088 bytes. The SQLite driver steps through rows as you ask for them with no client-side buffer. So the "cursor runs out of memory" warning's a MySQL fact rather than a PHP fact.

Okay, But My FPM Workers Show 35MB Each

That's the fair objection, and it's what makes people distrust the 0.66MB figure. ps on a production box shows php-fpm: pool www processes at 35MB and 60MB and 90MB and none of them are loading ten thousand models.

They're not lying, and neither is memory_get_peak_usage(), they're counting different things. Here's the same worker from the outside in three states with OPcache on:

Worker state	RSS
serving the hello route (measured inside the request)	30.7MB
serving the 10,000-model `get()` (inside the request)	52.1MB
idle, after the 10,000-model request has finished	36.3MB

The 30MB floor is the PHP binary and its extensions, plus the pages of the OPcache segment this worker has touched (shared with every other worker, but RSS counts them in each), plus the allocator's first chunk, and the 21MB on top of that during the model request is the heap from the previous section, and the 36MB after the request has finished is the allocator's chunk cache from two sections ago, the worker keeping some of the chunks it peaked at so that a worker that's served one heavy request stays bigger than one that hasn't until enough small requests pull the average back down. Multiply that by a pool where every worker eventually gets one heavy request and you've got the thing everyone observes on a dashboard, FPM memory that only goes up, with no leak anywhere in it.

Which is exactly why pm.max_children shouldn't be sized from memory_limit. The limit is a ceiling on one request's heap rather than a prediction of it, and dividing the box's RAM by 128MB gives you a pool less than half the size it could be for an app whose heaviest route peaks at 20MB. The manual describes pm.max_children as "the limit on the number of simultaneous requests that will be served". So the number to divide by is what one worker occupies while serving the heaviest route it will actually see. For this app on this box that's 52MB (the 10,000-model route measured from inside), so a 2GB budget for PHP gives about 39 workers, and if some route loads 100,000 models then it's 208MB per worker and 9 workers, and the right move there is to fix that route rather than buy the RAM, because the route that needs 208MB today is the route that'll need 400MB when the table doubles.

What I'd Actually Do

Measure the peak per route in production and keep the numbers. The cheapest version is a terminable middleware that logs the peak after the response has gone out:

app/Http/Middleware/LogPeakMemory.php

<?php

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Log;

class LogPeakMemory
{
    public function handle(Request $request, Closure $next)
    {
        if (function_exists('memory_reset_peak_usage')) {
            memory_reset_peak_usage(); // PHP 8.2+, matters under Octane
        }

        return $next($request);
    }

    public function terminate(Request $request, $response): void
    {
        Log::info('peak', [
            'route' => $request->route()?->uri(),
            'peak_mb' => round(memory_get_peak_usage() / 1048576, 2),
        ]);
    }
}

Append it globally in bootstrap/app.php and after a day you've got a histogram per route instead of a guess, and the routes at the top of it will be hydration, not bootstrap, so fix those first: paginate the admin page, lazy() the export, unbuffer the streaming job, and stop calling ->get() on a query with no LIMIT in it, because every one of those is worth more than all four bootstrap knobs combined, by a factor I measured at fifty-five.

Then turn the bootstrap knobs anyway, for time rather than memory. And make sure OPcache is on in every environment where someone is going to read a memory number, so the number they read is the real one.

Then size the pool from the log, not from memory_limit. That's it.

Octane changes the accounting but not the conclusion. It boots the application once per worker and keeps it in memory, so the 316KB is paid once and the per-request cost is only what the route itself allocates. But the worker never exits, and that's the catch. The model that leaks a reference or the static array that grows keeps growing, which is why Octane recycles a worker every 500 requests by default and why the memory_reset_peak_usage() line above stops being optional. If the Go version of this exercise is more your thing, I did the same measurement for goroutine stacks in I Spawned 1000000 Goroutines. Here's Where 13 GB of RAM Went. The shape of the answer was the same there: the number everyone quotes is true, it's just not the number that gets you paged.

The interesting part for me wasn't finding one magic Laravel setting that suddenly fixed memory usage. It was almost the opposite! Most of the framework-level optimizations changed far less than I expected, while one ordinary database call could outweigh the entire bootstrap dozens of times over. By the end of the tests, the framework overhead was almost the least interesting number. What the request loaded mattered far more.

Laravel costs 316KB a request. Your rows cost whatever you ask for.

Thanks for reading! English isn't my first language, so I use AI to polish the grammar. Everything else here - the ideas, the code, the opinions - is mine.

Enjoyed this one? Let's stay in touch — I'm on LinkedIn, always happy to chat, swap ideas, or just say hi. 👋

A Million Go Map Entries Take 38MB, Not 16MB

Nazar Boyko — Wed, 16 Sep 2026 14:47:35 +0000

A few months ago, I noticed an issue with the internal structure of the new Go map—specifically regarding empty slots! So I decided to figure out why a map[int64]int64 theoretically appears to be 16 bytes per element: 8 bytes for the key + 8 bytes for the value. But in Go 1.27.1, 1,000,000 elements take up approximately 37.8 MB, which is ~37.8 bytes per element. This made me wonder: where do those extra ~22 MB come from?! 🤔 And if you thought that Go simply adds some large header to each element, that’s not the case at all!

A Go map holding one int64 key and one int64 value takes 192 bytes of heap. A map[int64]int64 with a million entries takes 37.8MB. The napkin math for that second map is eight bytes of key plus eight bytes of value, sixteen bytes an entry, 16MB for the million and the gap between that and what the heap reports is what this whole piece is about. 🤷‍♂️

It's a follow-up to the goroutine stacks piece and it uses the same method, which boils down to taking something everybody in Go uses without thinking, making a lot of it and forcing a garbage collection to see what the runtime says is still live. The goroutine number held up until the goroutines called something. For maps it doesn't hold up at all. The cost per entry swings between 21 and 44 bytes depending on nothing but how many entries there are, and sets and deletes both behave differently on the current map than most of what's written about them says.

Everything below ran on Go 1.27.1 on an Apple M5 Max and I reran the byte counts on 1.26.4, which gave the same numbers apart from a little run-to-run noise right where tables split. MB means a million bytes throughout, since that's the unit the napkin math uses.

The Map Most Go Articles Describe Was Replaced In Go 1.24

Search for how Go maps work and most of what comes back is about buckets. A bucket holds up to 8 key/value pairs plus a few high bits of each key's hash, a ninth key that lands in a full bucket gets chained onto an overflow bucket, and once buckets average 6.5 entries the whole map doubles. Every bit of that was true, and it still sits in runtime/map.go in Go 1.23. There's a comment in there worth remembering. It says the bucket keeps all its keys together and all its values together because alternating them would need padding for something like map[int64]int8.

Go 1.24 replaced it with a map that doesn't have buckets at all. Go 1.24's release notes list "a new builtin map implementation based on Swiss Tables" among the runtime changes that cut CPU overhead by 2 to 3% on average, and Michael Pratt's post on the Go blog shows microbenchmarks where map operations got up to 60% faster than in 1.23. There aren't any overflow chains in the new map and there's no 6.5 either, so plenty of good writing about Go map memory describes a map that hasn't been the default since February 2025.

One Entry Costs 192 Bytes, A Million Cost 37.8MB

Here's the part of the harness that does the measuring. It reads HeapAlloc after a forced GC, fills the maps and reads it again after another one.

main.go

func liveHeap() uint64 {
    runtime.GC()
    var ms runtime.MemStats
    runtime.ReadMemStats(&ms)
    return ms.HeapAlloc
}

// bytesPerMap fills `copies` maps with n entries each and returns the live
// heap bytes per map. The keys exist before the first reading, so only the
// maps themselves are counted.
func bytesPerMap[K comparable, V any](n, copies int, keys []K, val V) float64 {
    maps := make([]map[K]V, copies)
    before := liveHeap()
    for c := range maps {
        m := make(map[K]V)
        for i := range n {
            m[keys[i]] = val
        }
        maps[c] = m
    }
    after := liveHeap()
    runtime.KeepAlive(maps)
    runtime.KeepAlive(keys) // or the GC can free the keys and subtract them
    return float64(after-before) / float64(copies)
}

Four details keep the numbers honest. runtime.GC() doesn't return until the collection and the sweep after it are done, so HeapAlloc right after it is live memory and not garbage waiting to be swept. Small maps get built many times over (as many copies as fit in two million entries) so a stray runtime allocation can't pass for a per-map cost. And the maps escape into a slice on purpose. A small map that provably never escapes can get its storage on the stack where HeapAlloc wouldn't ever see it. The last one's the KeepAlive(keys) line: a trimmed copy of this function that didn't have it reported 29.8 bytes per entry at a million, because when the call's the last place the keys slice gets used the second GC frees its 8MB and takes it off the total.

Here's map[int64]int64 at a handful of sizes.

# go1.27.1 darwin/arm64
     entries      bytes/map  bytes/entry
           1            192        192.0
           8            192         24.0
           9            376         41.8
          14            376         26.9
          15            664         44.3
         100           2392         23.9
         896          18519         20.7
         897          36991         41.2
        1000          36991         37.0
       10000         295585         29.6
      100000        2364444         23.6
     1000000       37812804         37.8
    10000000      302642440         30.3

One entry is 192 bytes and so are eight. The ninth entry nearly doubles the map and the fifteenth nearly doubles it again. At 896 entries each one costs 20.7 bytes, the closest a map[int64]int64 got to sixteen in any of my runs. Entry 897 pushes it straight to 41.2, and from there it keeps bouncing between the two with 37.0 at a thousand, 29.6 at ten thousand, 23.6 at a hundred thousand and 37.8 at a million. The keys and values don't change between rows. Only the count does.

Most Of The Extra Bytes Are Empty Slots

The new map's entries live in groups. A group is 8 slots plus an 8-byte control word with one byte per slot, and each control byte says whether its slot is empty, deleted or full, with the low 7 bits of the key's hash packed into it when the slot is full. That's what lets a lookup check all eight bytes against the hash in one go and only compare the keys whose bits already match. For map[int64]int64 that's a 16-byte slot and a group of 8 + 8*16 = 136 bytes.

A map with 8 or fewer entries is one group and nothing else (the source calls this the small map optimization), and the allocator doesn't have a 136-byte size, it rounds up to its 144-byte size class, while the Map header next to it is another 48 bytes. That's the 192.

The ninth entry turns that group into a real table with 16 slots, and from then on a table grows when it's 7/8 full (maxAvgGroupLoad = 7 in group.go, next to a comment saying it's "the same load factor used by Abseil"). Growing means building a new table twice the size and moving every entry into it. Right after a grow the table's only 7/16 full and more than half of it is empty, then it fills back up to 7/8 before the next doubling, and that's the whole shape of the table above: the cost per entry falls as a table fills and jumps every time it doubles, all the way up to entry 897.

Tables don't keep doubling past 1024 slots. That limit is maxTableCapacity in table.go and the comment above it has a TODO that says "Completely made up value", which I think is the most honest line in the runtime. A full table that size splits into two new 1024-slot tables and a small directory in front of them picks the right table from the hash's top bits. The blog post gives the reason: Go wants every insert to have "an upper bound on the amount of growth work it must do", and moving 896 entries is a small fixed amount of work no matter how big the whole map gets.

That's where the size-class rounding shows up again. A 1024-slot table is 128 groups or 17408 bytes and the allocator rounds that up to its 18432-byte class, so a table that's exactly as full as it's allowed to be (896 entries) costs 20.6 bytes per entry before any headers and a table that just split costs twice that. And since the hash spreads keys evenly, every table fills at about the same speed and splits at about the same moment, so the sawtooth doesn't smooth out as the map grows and its teeth just get wider. Around 110 thousand entries the map cost 21.4 bytes per entry and around 120 thousand it cost 39.3, and a million entries sits just past the split at 917,504, so that's the whole reason it comes out at 37.8.

I know this chart looks a bit like a heartbeat monitor... I promise it’s actually Go map memory usage. 😄

So the sixteen bytes are in there. They're the slot. What the napkin math doesn't count is everything around the slot and the biggest part of that is plain emptiness, because in any map past eight entries somewhere between 12.5% and 56% of the slots are empty by design.

A 129-Byte Value Costs Less Than A 128-Byte One

Everything so far used int64 keys and int64 values, and since the slot's the thing that repeats, key and value sizes move the whole number. Here's the same million entries with different types.

Map type	Slot size in bytes	Bytes per entry
`map[int32]int32`	8	19.5
`map[int64]int64`	16	37.8
`map[int32]int64`	16	37.8
`map[string]int64`	24	55.8
`map[int64][64]byte`	72	167.8
`map[int64][128]byte`	136	301.8
`map[int64][129]byte`	16, value stored separately	181.8

A slot is the key followed by the value, padded out to the alignment of the bigger one, so map[int32]int64 costs exactly what map[int64]int64 costs because 4 bytes of each of its slots are padding. There's a TODO in table.go that admits it: interleaving keys and values is good for locality "but it comes at the expense of wasted space for some types". That's the same padding the old bucket comment was avoiding.

A string key's 16-byte header goes in the slot (a pointer and a length) and the characters live in their own allocation, and since my keys were built before the first reading the 55.8 is the map alone, so a real map[string]int64 pays that plus whatever its strings cost.

The last two rows are the ones that don't make sense at first. Keys and values bigger than 128 bytes don't go in the slot at all: MapMaxKeyBytes and MapMaxElemBytes are both 128 in internal/abi and anything bigger gets its own allocation with a pointer in the slot. A [129]byte value costs a 16-byte slot plus a 144-byte object and a [128]byte value costs a 136-byte slot, so on paper the inline one should win. Even with one table as full as it can get (896 entries) the two only tie at 164.7 bytes each, since the inline version's groups array is over 32KB and anything that big gets rounded up to whole 8KB pages. At a million entries it's the 128-byte map that's 120 bytes per entry bigger. Turns out that's the empty slots again. An inline value takes all of its bytes in every slot, the empty ones included, while an empty slot in the pointer version holds just 16 bytes of key and pointer.

I wouldn't reshape a struct around the 128-byte line. But it explains how a big map of 100-byte structs ends up so much fatter than expected, since those 100 bytes get paid in every empty slot too, and map[K]*V does by hand what the runtime does past 128 bytes at the price of a pointer the garbage collector has to follow.

A struct{} Set Costs Exactly What A bool Set Costs

The standard advice for a set in Go is map[string]struct{} because struct{} doesn't take any bytes and bool takes one. On Go 1.23 that advice was right, by a little: I built the same harness with Go 1.23.12 (the last release line where the bucket map was the default) and a million-entry map[int64]struct{} came out at 22.3 bytes per entry against 24.6 for map[int64]bool, and that's because the bucket kept its 8 values in their own array where 8 zero-size values take zero bytes.

Here's how sets look on the three layouts I could build, all at a million entries.

Map type	Go 1.23.12 (buckets)	Go 1.27.1	Go 1.27.1 with mapsplitgroup
`map[int64]struct{}`	22.3	37.8	21.1
`map[int64]bool`	24.6	37.8	21.1
`map[string]struct{}`	40.1	55.9	39.0
`map[string]bool`	42.3	55.8	39.1
`map[int64]int64`	40.2	37.8	37.8

On the current default map the two set types cost the same (the string rows wobble by 0.1 between runs, in both directions) and both cost a lot more than they did on 1.23. It's the slot again. The slot's a struct with the key first and the value last. The compiler's rule is that any non-empty struct ending in a zero-size field gets one extra byte of padding, so that a pointer to that last field can't point past the end of the object (that rule goes back to issue 9401 from 2014). Alignment then rounds that one byte up to eight, and a bool is also one byte that gets rounded up to the same eight.

Three weeks before 1.24 shipped Michael Pratt opened issue 71368 about exactly this: "With swissmaps in 1.24, a map[int64]struct{} requires 16 bytes of space per slot, rather than the expected 8 bytes." Someone in the thread asked whether map[X]bool was just as bad and got a one-line answer: "Yes, both now allocate exactly the same amount of memory."

One map size can flatter one layout because 1.23 and 1.27 double at different points, so I reran the sets at a hundred thousand and five million entries too. The int64 set on 1.27.1 was 1.5 to 1.7 times its 1.23 size at all three sizes, while map[int64]int64 and map[string]int64 came out smaller on the new layout at all three (40.2 against 37.8 in the last row). Slots that need padding are where it's gone backwards, and the issue calls a set "the most extreme case" of that.

There's a fix already. Jake Bailey's change lays out a group as all 8 keys followed by all 8 values (KKKKVVVV instead of KVKVKVKV) and it was merged in March as GOEXPERIMENT=mapsplitgroup, but Go 1.27 ships with it switched off, so the last column is 1.27.1 with it switched on. With it on, sets drop just below their 1.23 size and map[int32]int64 goes from 37.8 to 27.9 while map[int64]int64 doesn't move because it never had padding to lose. On August 24 Michael Pratt's own change turned it on by default on the development branch and closed the issue under the Go 1.28 milestone. Even with split groups struct{} and bool still tie, though. Eight bool values fit in the same 8 bytes the padding would've taken.

make(map, n) Makes The Map Faster, Not Smaller

Preallocating is the other standard advice and the natural guess is that it makes the map smaller too, since a map built to size doesn't have to overshoot. Here's the same set of sizes built both ways.

# go1.27.1 darwin/arm64
   entries  grown bytes/ent make(n) bytes/ent
       100             23.9             23.9
      1000             37.0             37.0
     10000             29.6             29.6
     50000             23.6             23.6
    100000             23.6             23.6
    500000             37.8             37.8
   1000000             37.8             37.8
  10000000             30.3             30.3

Same numbers. A size hint asks for enough slots to hold n entries at 7/8 load and rounds the table and directory sizes up to powers of two, and that lands on the same layout growth reaches anyway because all the tables split together. Across the full sweep the two only disagreed right at split points, and not always in the hint's favor: at 897 entries the hinted map was 31.2 bytes per entry against 41.2 for the grown one, but at about 1.9 million it was 39.3 against 37.8.

The hint's payoff is in the work of getting there. Here's the testing.B side of the measurement.

fill_test.go

package main

import (
    "strconv"
    "testing"
)

var sizes = []int{1_000, 100_000, 1_000_000}

var sink map[int64]int64

func BenchmarkFill(b *testing.B) {
    for _, n := range sizes {
        b.Run("grow/"+strconv.Itoa(n), func(b *testing.B) {
            b.ReportAllocs()
            for b.Loop() {
                m := make(map[int64]int64)
                for i := range n {
                    m[int64(i)] = int64(i)
                }
                sink = m
            }
        })
        b.Run("make_n/"+strconv.Itoa(n), func(b *testing.B) {
            b.ReportAllocs()
            for b.Loop() {
                m := make(map[int64]int64, n)
                for i := range n {
                    m[int64(i)] = int64(i)
                }
                sink = m
            }
        })
    }
}

go test -run '^$' -bench BenchmarkFill -benchmem -count 3

BenchmarkFill/grow/1000-18             40568         27625 ns/op       74456 B/op         22 allocs/op
BenchmarkFill/make_n/1000-18          193857          6219 ns/op       36992 B/op          6 allocs/op
BenchmarkFill/grow/100000-18             478       2472747 ns/op     4729552 B/op        532 allocs/op
BenchmarkFill/make_n/100000-18          1441        838571 ns/op     2364600 B/op        258 allocs/op
BenchmarkFill/grow/1000000-18             25      42785217 ns/op    75605811 B/op       8209 allocs/op
BenchmarkFill/make_n/1000000-18           38      30394810 ns/op    37832752 B/op       4098 allocs/op

That's the first of the three runs, the other two were within about 5%. The B/op column is the cross-check against the heap numbers, and it holds up: a preallocated thousand-entry map allocated 36992 bytes and HeapAlloc said exactly 36992 bytes were live, while at a million entries the preallocated map's live bytes and its B/op differ by 1.5KB out of 37.8MB. A growing map allocates almost exactly twice its final size because each doubling throws the previous table away. On time, the hint made filling a thousand entries 4.4 times faster and a hundred thousand 2.9 times faster, but a million only 1.4 times. I'd guess that at a million most of the time goes into writing 38MB of memory the process has never touched, which both versions pay for equally. I didn't profile it to check though.

Deleting Every Key Gives Back Zero Bytes

Go issue 20135 ("runtime: shrink map as elements are deleted") was opened in April 2017 and it's still open, but everything in its thread was written about the bucket map, so deletes were the part worth checking again on the new one. The steps are in the labels below, and every line was read after a forced GC and measured against the heap from before the map existed.

# go1.27.1 darwin/arm64
filled                             len=1000000  heap=   37798.2 KB
deleted every key                  len=0        heap=   37801.2 KB
refilled with new keys             len=1000000  heap=   37838.2 KB
clear(m)                           len=0        heap=   37838.2 KB
refilled, deleted 99%              len=10000    heap=   37838.3 KB
copied survivors to a new map      len=10000    heap=     301.2 KB
m = nil                            len=0        heap=       5.6 KB

Deleting a million keys didn't free a byte. clear(m) freed nothing either. The map that went from a million entries down to ten thousand still held 37.8MB, nearly 3.8KB for each entry left in it, and the only line that moved at all is the one where the ten thousand survivors went into a fresh map and the old one got dropped.

The source says the same thing and it doesn't need any measuring. Clear walks every table and marks every slot empty and right after that loop sits a comment that just says TODO: shrink directory?, while Delete marks a slot empty or leaves a tombstone if its group is full, and nothing in internal/runtime/maps hands a table back while the map's alive. The old for k := range m { delete(m, k) } loop compiles into the same runtime call as clear(m) too. Brad Fitzpatrick pointed out in the same issue that the compiler rewrites that loop into runtime.mapclear.

Okay, but doesn't the garbage collector clean up after a delete? It cleans up what the deleted entry pointed to, and that's it. Keith Randall spelled out the split in that thread back in 2020: "the space for the keys and values themselves won't be reclaimed, as that space is part of the buckets. Only the things referenced by the keys and values will be collected." Swap buckets for groups and it describes the new map just as well. When a session gets deleted from a map[string]*Session the Session and the key's characters can be collected (if nothing else points at them) but the 24-byte slot stays where it is.

The map doesn't keep growing forever, though. Deleted slots get reused, which the "refilled with new keys" line shows well enough: a million new keys went into the emptied map and the heap moved by 37KB. I also ran a sliding window of a hundred thousand live keys where every insert deletes the oldest key, kept it going for twenty million inserts, and watched the map go from 2.36MB to 4.73MB by the two-million mark and then sit there for the other eighteen million. So a map with steady turnover settles at about twice its freshly built size, and a map that was once big stays as big as it ever got.

Josh Bleecher Snyder's first comment on the issue in 2017 is still the whole workaround: "The only available workaround is to make a new map and copy in elements from the old." It's cheaper than it sounds as long as it isn't done after every single delete. Someone in the thread asked about copying to a new map after O(n) deletes and Keith Randall's reply was "That would work fine."

What I'd Change In Real Code

Sets first. I'd still write map[string]struct{} because it tells the next reader the values mean nothing, but on Go 1.24 through 1.27 it doesn't save a single byte over bool, and honestly I wouldn't flip a GOEXPERIMENT in production just to get the split layout early. When the keys are small integers from a dense range the map is the wrong shape anyway, and the difference isn't small: a bitset for a million possible IDs (make([]uint64, 15625)) was 128KB of heap, the same million as a map[int64]struct{} was 37.8MB, and a plain []int64 indexed by the key took 8.0MB.

I'd preallocate whenever the size is known up front. The map ends up the same size but it gets there 1.4 to 4.4 times faster with half the garbage, and garbage is GC work later.

After a big delete I'd rebuild the map. That means copying what's left into make(map[K]V, len(old)) and dropping the old one, since nothing else gives the memory back.

And I'd measure the maps in the real service before rewriting any of them. A heap profile works, with one detail worth knowing before opening it: for a map made without a size hint, pprof puts the memory on the line that inserts into the map and not on the make line, because the tables get allocated as the map grows. My million-entry set showed up as 36.06MB on its assignment line, so pprof's MB is 1024 times 1024 bytes so that's the same 37.8MB.

The map with one int64 in it is still my favorite number from all of this. Sixteen bytes of entry, 176 bytes of map.

I tried to break all of this down in as much detail as possible and verify the numbers along the way. That said, this goes pretty deep into Go’s runtime and memory layout, so I may have missed something or made a mistake in one of the calculations. 🙄 If you spot anything that looks wrong, I’d genuinely appreciate a correction.

Thanks for reading! English isn't my first language, so I use AI to polish the grammar. Everything else here - the ideas, the code, the opinions - is mine.

Enjoyed this one? Let's stay in touch — I'm on LinkedIn, always happy to chat, swap ideas, or just say hi. 👋