Brenner Cruvinel

My AirPods Max died and came back from the freezer

2026-10-10T00:00:00+00:00

I'm writing down what happened because I spent an entire day desperate over it, and maybe it helps someone going through the same thing.

I have a pair of AirPods Max, the USB-C ones. For me they're not just headphones, the noise cancellation is what helps me function day to day. So when they stop working, it's not just annoying, it's genuinely heavy.

They had fully drained before. Every time, I'd charge them, reset them by holding the two buttons, and everything went back to normal. This time it didn't. I charged them, tried restarting, nothing. Then, trying to fix it, I did what seemed logical: I removed them from the device list on my Mac and iPad, thinking it would help pair them again. It didn't.

Here's what was happening. I'd hold the noise control button together with the crown for 15 seconds, which is Apple's official reset, and the light would blink three times in a reddish orange and the headphones would simply turn off. No matter how long I held it, nothing else lit up. To get any sign of life again, I had to put them in the case and take them out, and then the green light came on. If I held only the noise control button for about 5 seconds, a quick white flash appeared and vanished. It never stayed blinking white, which is pairing mode. I tried with the cable, without it, charged, near the Mac, far from it, everything.

I spent hours digging into this with an AI, Claude, going through the Mac's Bluetooth logs. One thing I learned was why they used to come back on their own: the headphones and the Mac still kept the pairing key, so when they powered on again, they reconnected right away. This time, after so many resets, the key got wiped on the headphones, and on the Mac I wiped it myself when I removed them from the list. I really wanted to put them back on the list by hand, but there's no way. That key is created at pairing time, from random numbers generated by both devices, and it can't be rebuilt from the serial number or from any log. The headphones had to get into pairing mode, one way or another.

Searching in English, I found the name of the problem: "three amber lights of death". It's a known AirPods Max defect, the three amber blinks and no white light. The most common explanation is that the thin wires running through the ear cup hinges crack over time from all the rotating, or that the contacts between the headband and the cups pick up moisture. Apple has never explained the cause. And one of the fixes people reported was bizarre: put the headphones in the freezer.

I had already tried everything, so I went for it. I put the headphones, without the case, inside a tightly sealed plastic bag and left them in the freezer for a few minutes. I took them out, did the procedure, and they blinked white. Paired instantly. Battery at 100%, firmware normal, everything working. I laughed alone out of sheer nerves.

The logic, as far as I understand it, is that the cold makes the metal contract and temporarily closes a microcrack in the wire or improves a bad contact. That's why it wasn't the battery or the software, it was something physical. And that's also why it might come back. Some people went months without trouble, and for others it lasted only a few days.

If you're dealing with the same problem, here's what I'd say: before removing the headphones from every device and resetting them a thousand times, try the freezer, inside a well-sealed bag. When you take them out, have your phone or computer next to you and pair quickly. Then wait for them to get back to room temperature before charging, because a lithium battery shouldn't be charged below 0 °C. And if the problem comes back, the next steps are cleaning the headband contacts with isopropyl alcohol or finding a repair shop to replace the hinge cable.

And try not to let them drain to zero. From what I've seen, this defect shows up exactly when they power back on after dying.

Anyway, they came back. For now. And I learned more about Bluetooth in one day than in years.

Validating on disk the benchmark I wrote in the middle of the night

2026-09-12T00:00:00+00:00

I opened a new session, with no context at all, and asked as if I were someone who had just cloned the repo: how do you use Nest, does it have an interface? The first command the answer suggested returned command not found on my own machine. The second one showed a default model I was sure I had swapped out weeks earlier. Two holes no test catches, found in five minutes, and that's when I realized the topic of the week wasn't compression.

The benchmark was just the place where it became visible. So, before publishing any number from the series, I spent a whole day validating: every number against the file on disk.

What was wrong

The first thing that didn't match wasn't even a number. I ran strings on the release file and out came "Spellbook MTG corpus". The file is called mtgdataset. The rename from a week earlier, which swapped Felipe's app name for the generic name in every text file, never made it into the binary. The lock next to the release described a file with the new name while the file had the old name inside, and no tool flagged it, because validation checks the file against itself. I rebuilt both releases with the right name inside, and the media bytes came out identical, which at least proved the encode is reproducible.

The sizes of the three most aggressive builds were in mebibytes labeled as gigabytes. du talks in MiB and I pasted it as GB. The difference is five percent per row, but the ratio inherits the error: the search build I had announced as 7.8 times smaller than the source is 7.5. The AVIF I said was 20% smaller than the recommended build is 13%. No conclusion changes, and it still made me ashamed, because it's the kind of mistake I'd point out in someone else's report.

The strangest one was the manifest of the AVIF build, which records a 21 GB source. The source is 4. I couldn't make sense of it until I divided by the number of cards: it gives the size of an uncompressed image, which is what the encoder receives midway through. The backend counted the intermediate instead of the JPEG. One line to fix, one test to write, and until then the ratio in that manifest was made up.

And there's what can no longer be verified. I deleted the first full build when the disk filled up, so the sentence "the three builds share the same hash" is now two-thirds checkable. The CapCut experiment and the reprint matrix left no artifacts, only text. I told it to delete them myself, to free up space. Disk space is cheaper than trust and I should have known that.

The other times I read the summary and not the file

The 200-card summary. I asked for the whole dataset, got a summary that talked about the corpus as if it were the corpus, and it was a pilot. I noticed with a meeting already scheduled. The agent didn't lie, it summarized the scope without saying so, and I read the summary instead of the disk. Since then every build delivery comes with validation of the real file, and this post exists for the same reason.

My machine's paths. Days after the benchmark I found my home directory path in dozens of files headed for GitHub, inside manifests, locks, specs. The fix was an environment variable and a script that rewrites the sidecars before committing. And before that the agent had wanted to store my preferences in a local memory file. I asked it to delete it. If the workflow depends on what it remembers about my machine, it won't run in the next repo, and it won't run on the machine of whoever clones it.

The five-gig repo. At some point I asked how ML engineers deal with this, because GitHub won't take it. The answer I adopted: not a single image byte goes into git. Each sample is a list of ids with the rule that generated it, and whoever has the SQLite database rebuilds the exact sample. The .nest files go to Hugging Face with a hash alongside, and the repo keeps the lock, the clean manifest and the hash. The whole report is generated from each experiment's JSON, and a CI check fails if the markdown differs from the JSON. I can no longer paste a wrong number into a report without CI complaining, which is the kind of protection I needed against myself.

The commits. The agent prefers one fat commit at the end of the day. I asked for sixteen, separate, with descriptions, because the history has to be readable for whoever comes later. And the plans: I rejected three in a row because they treated the model comparison as a footnote to a build already decided. The model list that exists in Nest today only exists because I insisted that research becomes a feature, never a footnote.

What these episodes have in common is just one thing: in all of them I accepted a layer between me and the file. Summary, manifest, memory, fat commit. And the layer was wrong and didn't say so.

What I'll try next time

Something that put me more at ease, in the middle of the validation, was finding out that the two findings I liked most already had names. The redundancy between images in a collection, which inter exploits, has been called set redundancy since Kosmas Karadimitriou's 1996 doctoral thesis, and the trick of lining images up as a pseudo-video has a decade of literature behind it. And the distinction between visual quality, vector stability and search usefulness, which I thought I had invented, is everyday business in the field the standards call coding for machines: it evaluates with task metrics, like mAP, precisely because feature fidelity and task performance can drift apart. I didn't discover anything. I confirmed two things on a corpus nobody had looked at, and that makes me calmer about publishing than if it were something new.

The 1.3 GB file is already in the pasta.cards repo, waiting for the screen that will use it. What's left of the benchmark fits in a paragraph: measure search with WeMM, build the full reprint corpus, decide whether AVIF becomes the default. None of the three has a date.

What I'll try is the cheapest thing of all: open a clean session as a user before every release and type the first command in the readme. Five minutes, and it found two holes a week of agents didn't. I don't know if I'll remember to do it. But now it's written down, and I trust what's written more than what I remember.

Raising the CRF until search breaks

2026-09-05T00:00:00+00:00

The question from the previous night was simple to ask and I took my time asking it. The app keeps every card's JPEG cached for display. The .nest doesn't need to be pretty, it needs to answer which card it is. So the CRF, the codec's quality setting, can go up until the vector breaks, and the vector breaks well after the eye does. If that were true, it would even be worth thinking about two tiers: a thumbnail inside Nest for search, and the full card on demand when the app needs to show it.

I had a way to measure this, or thought I did. Nest's quality gate has two sides: a visual metric, which compares the decoded frame with the source, and vector drift, which measures how much the CLIP vector moves between the original image and the decoded one. The idea behind drift is that an image can look fine and still have moved in search space. I trusted that metric. It was mine, I had insisted on it in the plan, and for good reason: on dermoscopy it had caught a case where the image passed by eye and search by clinical text dropped by half.

The gate rejected the whole ladder

I took the visual side out of the gate and left only drift, with the floor Nest has used since dermoscopy. I had the CRF climb a ladder from 40 to 60. The gate rejected the whole ladder, including the first rung, and fell back to the most conservative one because it had nowhere else to go. Drift was already below the floor at CRF 40 and only got worse. And the visual metric, which I had taken out of the gate but kept computing, told the same story from another angle: from CRF fifty on it gave negative values on some cards, something I didn't even know it could do.

The file the gate delivered, at CRF 40, the lowest on the ladder, came out close to one gig, four times smaller than the source. It was already smaller than the recommended build, and the gate had rejected it too, it just had nowhere lower to fall.

By the gate's logic, none of these files was usable. I built one at CRF fifty anyway, no gate, just to see the size. Half a gig. Seven and a half times smaller than the source, and the cards turned into a blur, rules text unreadable, the art recognizable only from a distance. A file I wouldn't show anyone.

Then I ran the metric that actually matters, which I hadn't run before because I was too lazy to set it up: search by name. A hundred queries like "the art of such-and-such card", on the five files I had of the full corpus, from the 3.6 GB lossless one down to the half-gig blur. The first round gave zero hits on two of the five files, the lossless and the recommended one, and for a minute I thought I had broken search. It was the bench: it matched results by the card's position in the stream, and the two files with similarity sorting have a different order. Nest has a content id per item for exactly this, and once the bench matched on that, all five files answered again.

And accuracy stayed within the noise on all of them. The half-gig file finds the right card as well as the 1.3 GB one, and both stay within the noise of the lossless file.

Search survives far more compression than the eye

I stared at that on screen for a while. Cosine drift measures whether the vector moved. Search measures whether the vector still finds. I was using the first as if it were the second, and it would have vetoed a file that works. The vector does move, and it still stays closer to the right card than to any other. How far it travels doesn't matter if its neighbors don't change. A gate that's any good for this use needs hit@k as its floor, the fraction of queries where the right card shows up in the top k results, not cosine.

That became a profile in Nest, retrieval-only, which writes into the manifest that the file serves search and never display. And AVIF, which in the benchmark had come out about 12% smaller than AV1 at the same quality, held up on the full corpus: 13% smaller than the recommended build. It's the candidate to become the default backend for stills, and I haven't decided yet, because AVIF takes four to ten times longer to build and embed.

There's a third metric I ran alongside that's worth nothing, and it's worth saying why. Identity: give the image itself as the query and see if it finds itself. It gave a hundred percent on every file, even the blur. Looks great and says nothing, because the query is the very image that produced the frame, and the uncompressed control also gives a hundred. It only proves the codec didn't destroy the data. I left it in the bench so nobody confuses pipeline stability with usefulness, which is exactly the confusion I made with drift.

The metric is weak and I know it. It's a hundred queries with a model that does poorly on this corpus, CLIP, which only looks at the art. "Didn't drop" means "I couldn't measure a drop", not "it's the same". And WeMM, which reads the name printed on the card and gets nine in ten right, might suffer far more from the blur than CLIP, because what it reads is exactly what the CRF destroys first. I didn't measure it. That's next, along with the full reprint corpus, which is where inter has something to predict.

What stuck with me that week was less about compression and more about what I choose to measure. I had a metric I designed myself, one that looked rigorous, and it answered a question I wasn't asking. And before publishing any of these numbers, I wanted to validate each one against the disk, because a report written in the middle of the night gets things wrong.

At the end of the day it's the same thing, 1.3 GB

2026-09-03T00:00:00+00:00

I was sure. Sorting the cards by similarity before encoding would multiply the compression, because similar neighboring frames are exactly what video codecs love. I had written it in the bets, I had repeated it to the agent, and the benchmark had handed me back a strange row: the variant with inter came out bigger than the one without. The configuration was wrong, scene cut detection was on, and different card after different card is one scene cut per frame. The encoder was burning cycles looking for a scene that didn't exist. I turned it off and put together a second corpus, almost three thousand real reprints of the same art, grouped together.

That did it. With prediction in groups of sixteen frames, the file came out 29% smaller than without prediction. Groups of sixteen beat a single keyframe for the whole stream, which surprised me, and they still keep any card reachable by decoding at most sixteen frames. And a detail I didn't expect: shuffling the reprints instead of grouping them cost only two points. Part of the gain comes from the frame every card shares, not from the repeated art. The codec was exploiting the chrome, as I had suspected on day one, and that held for any order.

Building the whole corpus at night

With 29% in hand, I built the full corpus with similarity sorting and prediction on, and next to it the same corpus with none of that, to compare. And I built it with the media inside the file, because by then I no longer accepted MP4s sitting next to the database. Before getting there I opened the folder of an intermediate build and found .build, .cache, .forge-state, .tmp, a lock, a manifest, all next to a .nest of a few megabytes. What is all this for? I asked, and the honest answer was that every piece had a reason and none of them needed to be there once the build finished. Media inside the file was half the answer, the other half was cleaning up the output.

A .nest is a container of sections, each with its own hash. The new section is the simplest of all: a table of offsets and the raw bytes of the videos, glued one after another. An MP4 stays an MP4, nothing is re-encoded to fit. Opening the file doesn't touch the media, the system only maps the slice when someone asks for a card, and you can export the original MP4 back out with the hash checked before writing.

That section doesn't count toward Nest's content hash, and this matters more than it seems. The content hash is computed over what's inside the file, not over the packaging, and it's what makes a Nest citation point to a piece of knowledge instead of a place on disk. The same corpus built with the media inside and with the media outside gives the same hash. It cost three percent: the indexes, the card text and the vectors add up to about forty megabytes on top of 1.3 GB of video.

The builds ran overnight, and the night was rough. Two died with a full disk, because macOS was taking system snapshots in waves, eating and releasing gigabytes without warning, and at one point I was down to a hundred and thirty megabytes free. And in the middle of that I read a summary from the agent saying the corpus had 200 cards. I had a client meeting in a few hours.

"Seriously, you used 200 demo cards? I have a client meeting and I still don't have the dataset." I had it run validation on the 1.3 GB file. All 38 thousand blobs checked out, one by one. The corpus was complete, the summary was describing the pilot, and I had read the summary instead of the disk. After the encoder that wasn't using the tune the manifest claimed, it was the second time that week that what I read wasn't what was actually there.

At the end of the day

The sorted build sat next to the plain build. 1.3 GB both, no difference at all. I sent it to the agent at four in the morning: at the end of the day it's the same thing, right, 1.3 GB.

The reason was in the manifest, correct this time. Nest decides per segment whether to use prediction, encoding a sample both ways. On the real corpus, made of unique cards, the probe vetoed prediction in every segment. There's nothing to predict: the next card is another card, with other art, and the shared chrome doesn't pay for the cost. The 29% gain only exists on the reprint corpus, and I haven't built that one in full yet.

There was a worse part, which I only understood later. In an earlier version of the probe, it decided on bytes alone, and in a build of the sample it picked prediction for every segment because it tied on size. Median quality dropped sixteen points. The encoder compresses predicted frames with coarser quantization, and with unique cards a predicted frame is just a worse keyframe in disguise. Equal bytes aren't equal quality. The probe now measures both sides, accepts losing at most two points, and records the reason when it vetoes. The 29% matrix also compares bytes only, so the number is real but it isn't equivalent quality. I'm putting that down here because I forgot it myself for a whole day.

What if the file doesn't need to be pretty

What I take from that night isn't the 1.3 GB. It's that my intuition about codecs was wrong twice, and that I read summaries when I should read files. Now I only turn sorting on when the corpus has near-duplicates, and no build goes in without validation of the real file running alongside it.

And one question was left over that seemed more promising than any sorting. Nest's quality gate locks the codec at a conservative level because the visual metrics never pass on small cards with tiny print. But Felipe's app keeps every card's JPEG cached for display. The .nest only needs to answer which card it is. If the file doesn't need to be pretty, how far can you push the setting before search starts complaining?

The encoder had ignored tune=still since the first build

2026-09-02T00:00:00+00:00

The symptom was a number that didn't add up. I had a battery of encoders running in parallel: nineteen configurations across AV1, AVIF, x264, x265, WebP and lossy JPEG XL. Even VVC got in, more out of curiosity than hope. Each one calibrated to the same visual quality, to find out whether Nest's AV1 was the most compact option or just the one closest to home. One of the agents reproduced the Nest build by hand, with the same parameters, and the file came out a different size. Same card, same CRF, same preset, different bytes. I read that in the morning and my first reaction was that the agent had gotten the command wrong.

The probe failed and nobody said a word

It hadn't. The forge asks the encoder for tune=still, the still-picture mode, which is the right one for a stream where every frame is an independent photo. Before asking, it runs a probe to check whether the encoder accepts that mode. The probe ran without a parameter the mode requires, failed, and the code fell back to a generic mode without telling anyone. The manifest recorded the spec, which said "still", not what the encoder had actually done. Since the first build I had been reading a manifest that didn't match the binary, and the only place that recorded the mode was the wrong place.

The difference measured eleven points of visual quality for ten percent more bytes, at the same CRF. The old build was the worst point on the curve: smaller, but ugly in a way that isn't worth it. And nobody would have caught it by watching the video, because what a frame looks like in the player doesn't tell you which tune was used. Only bytes against the bytes of an independent encode.

And it was by chance. The encoder battery existed to answer a different question, and the manual baseline encode was just its reference point. If I had calibrated the battery against the manifest instead of against an encode done from scratch, the bug would have stayed invisible, and every number in the series would have come out ten percent optimistic on bytes and eleven points pessimistic on quality. Now the manifest records the mode the encoder actually used, and the probe passes the right parameter.

Even after the fix there was a second layer. SVT-AV1 has two modes you could call "still": tune=2, optimized for a structural similarity metric, which is what the fixed probe started picking, and tune=3, called image quality, which the documentation itself marks as still images only. The second one gives one more point of quality for one percent more bytes. Not much, but it's the right mode for still pictures, and the recommended build of the full corpus went out with it. The manifest now says which of the two, by number, because "still" on its own already fooled me once.

Variant on the same 2,048 cards	Size	Visual quality
JPEG XL repack, lossless	1.12x smaller	same as source
AV1 from the first build	3.3x smaller	52
AV1 with tune=still	3.0x smaller	63
AV1 with inter	2.5x smaller	62
AVIF	5.5x smaller	43

The AVIF row looks like the winner and it isn't. It sits at a much lower point on the quality curve, so you can't compare it on the same number. Calibrated to the same quality as AV1, it comes out about 12% smaller, and that left an open question about which backend to use for stills. And inter, my favorite bet, came out bigger than tune=still. I explain that in the next post, because the configuration was wrong and the problem was something else.

I won't table the rest of the nineteen, but three findings stayed with me. x264, the encoder for a 2003 standard, was the fastest inside the quality window by an enormous margin, and VVC, the newest codec on the list, cost a hundred times x264's time to land in the middle of the table.

Two different SVT-AV1 presets spat out byte-for-byte identical streams, because the version I use maps both to the same internal mode when the stream is all keyframes. One more case of a parameter I was passing and the encoder was ignoring, this time documented. And lossy JPEG XL, which I expected to compete, only competes at high quality, well above the window that matters for a deck tile. It's a good codec for a target this corpus doesn't ask for.

CapCut was throwing cards away

I had written in the bets that speeding up the video cut bytes, because I had done it in CapCut and the file came out half the size. I reproduced it programmatically: speed it up sixty times, export at thirty frames per second in H.264, the way the editor does. The file came out with half the bytes. And half the cards.

The export samples the sped-up timeline and drops whatever falls between one frame and the next. Of the 2,048 cards, 993 disappeared. What was left got re-encoded to H.264 on top of AV1 that was already lossy. CapCut didn't compress anything, it threw half the dataset away and called it optimization, and I looked at the file size and believed it. Changing only the fps, without speeding up, doesn't change a single byte. It's a timestamp annotation in the container, as ffprobe had already told me on day one and I hadn't properly written down.

The wrong bet yielded a real bug. With an fps other than one in the manifest, the code that fetches a frame by index asked for an instant that didn't exist, because it assumed ordinal and timestamp were the same thing. Fixed, and tested with the fps I never should have changed. The real gain CapCut was pointing at, redundancy between neighboring frames, does exist. It just has to be measured with inter, without losing cards, and that's the subject of the next late night.

What else is the manifest getting wrong

I closed the day with two things validated by hash and a bigger doubt than when I started. The encoder mode was a constant I thought was on, and it had been off since the beginning. CapCut was a number I thought was compression, and it was data loss. Both lived in a manifest or an export I had read and accepted without checking against anything.

If the encoder wasn't doing what the manifest said, the question left over was what else I was reading as a summary instead of validating on disk. I didn't know yet that the answer would come in the middle of the night, with a meeting on the calendar.

My bets before compressing the cards

2026-09-01T00:00:00+00:00

The compression can't lose anything, even if we have to invent it. I wrote that sentence in the plan, that confidently, after the first build. Two lines later I was saying lossless video with the cards sorted by similarity was a path, and further up I had dismissed jpegtran because "lossless doesn't count". I only noticed when I sat down to write the bets and had to define what I was going to measure, and measuring requires saying against what. Lossless relative to what? I had no answer. I had used the same word for three things and hadn't noticed.

Why zstd can't bite into a JPEG

A JPEG has already gone through three stages that exhaust the redundancy a general-purpose compressor knows how to find. The image becomes frequency coefficients, the high-frequency coefficients get rounded (that's where the loss happens), and the result goes through an entropy coder. What comes out is a bitstream where the repeated patterns have already been eaten. zstd looks for exactly that, repeated patterns. It's like trying to fold a sheet of paper that's already folded to the limit: it doesn't get smaller, it just crumples.

So "lossless" on top of JPEG has three meanings, and only one deserves the name. The first is repacking the JPEG in a way where the inverse operation gives back the original file byte for byte. JPEG XL does this: it takes the already-rounded coefficients and rewrites them with a better entropy coder, keeping enough to undo it. The JPEG's loss is still there, but the packaging is tighter.

The second is re-saving the same JPEG with jpegtran or jpegoptim. The pixels stay identical and the bytes change. Lossless for whoever looks, not for whoever checks the hash. And if the source is already optimized, like the files from Scryfall, the gain tends to zero.

The third is what I was proposing without knowing it: decode the pixels and recompress them with another lossless codec, PNG, WebP, or FFV1 video. It looks like the purest meaning and it's the worst. The new codec receives pixels carrying the JPEG's rounding noise as if it were signal, and spends bits representing that noise faithfully. Everything points to the result being bigger than the source JPEG, not smaller. I wrote that and still didn't believe it, hence the bet.

There's a fourth thing, which isn't a meaning but a gap. In 2016, a group from Tianjin University and Microsoft Research Asia published "Lossless Compression of JPEG Coded Photo Collections": they arrange a collection of JPEG photos as a pseudo-video, compensate the difference between neighboring photos, remove the remaining redundancy in the frequency domain, and still give back every original JPEG without losing a bit. Average savings above 31%. That's exactly what my invented idea wanted to be, done the right way. Except I couldn't find an open implementation, and I wasn't going to write a codec that week. So what I could measure was the ceiling with the tools that exist. The real ceiling, if that paper reproduces on Magic cards, is higher, and I want to say that before giving my number.

What I bet and why

I wrote it down before running anything, because the last time I published a number without a written bet I had to correct it two days later, and correcting a published number is worse than losing a bet in public.

Does lossy AV1 video compress much better than loose JPEGs? Yes, that's what the first build showed and what I had seen with dermoscopy. The more alike neighboring cards are, the more the video gains? Yes, and strongly: the database has 100 thousand printings for 52 thousand illustrations, almost half the cards repeat art that already exists on another, and they all share the same frame. If there's a video gain, it lives there.

Does speeding up the video cut bytes? I had dropped one of the MP4s into CapCut, sped it up sixty times, and the file came out half the size. I bet yes, and if it's true it's the cheapest item on the list. Does tar plus zstd gain anything? I think not, for the reason in the section above. And does sorting by similarity help with unique cards too? I think not, I've seen sorting do nothing on another dataset, but the shared frame leaves me unsure.

And the one I wanted most: there's a lossless option better than JPEG, "even if we invent it". After writing out the three meanings, I changed my mind halfway through the bet. The candidate became JPEG XL, and the lossless video sorted by similarity, the invented idea, is going to lose. The two I most wanted to be true, CapCut and lossless, were the two I could least defend. That's usually a sign.

The lossless run went that same night, ten variants on the same 2,048 cards. Tar plus zstd came out one to one, exactly. Re-saving with jpegtran gave less than one percent, the Scryfall JPEGs are already optimized. The ceiling was the JPEG XL repack, about 11% smaller, with all 2,048 original files rebuilt and validated by hash. Pushing the encoder effort to the maximum gives less than one percent more for six times the time, so the default stayed at medium effort.

And the invented idea lost badly. FFV1 and x264 without quantization, with the cards sorted by similarity, came out three to four times bigger than the source JPEG. Sorting, in that regime, barely moved the size at all, a fraction of a megabyte on a file of hundreds. A decoded JPEG pixel carries noise and no codec predicts noise, just as I had written that morning without believing it.

That became Nest's archive profile: anyone who won't accept losing anything gets the JPEG XL repack, 3.6 GB for the whole corpus, and every JPEG comes back bit for bit on request. It's not the number I wanted. It's the number I can defend with a hash, and I prefer that one. The other bets, the lossy ones, were running while I wrote this. The CapCut one, I was already afraid to look at.

Nest has the potential to be a Magic card archiver

2026-08-31T00:00:00+00:00

Felipe Navarro, a friend of mine, is building pasta.cards, an open source app for managing your collection and Commander decks. It runs locally, keeps everything in SQLite, and to work offline it downloads the art of every Magic card ever printed, in two versions: the full card and just the illustration. On my Mac that came to 83 thousand JPGs and 7 GB. Every card that exists, twice, on my disk, and Finder dragging its feet to open the folder.

What caught my attention in that number wasn't the size, disk is cheap. It was the structure. Cards share the frame, the text box, the typography, the mana symbols. And the database next to it shows that almost half of all printings reuse art that already appeared on another card. A loose JPG knows nothing about that. A good catalog points instead of copying, and a good codec doesn't spend bits on a pixel it can predict from its neighbor. I like both for the same reason.

I had Nest at hand, the single-file vector database I've been building this year, and since August it stores images too. The question I asked that morning was far more naive than everything that came after: how does it work, does it turn this into a video? I have 38 thousand images and a database, what does it do with them?

Does it turn this into a video?

It really does turn it into a video. Each image becomes a frame of an AV1 stream inside the file, and search runs on vectors taken from the decoded frames, not from the source JPEG. That's on purpose: the index has to describe what the file serves, and what the file serves is the frame after the codec. Video codecs are the most optimized image compression technology there is, so what looks like a hack is just borrowing decades of other people's work.

I had already measured this on skin. Dermoscopy, biopsy slides, pages of old books, the datasets I had on hand from my work at Hoff. What those numbers taught me is that how much something compresses is a property of the domain, not the codec. Same encoder, same settings: dermoscopy compressed 151 times and the book page compressed 4. Smooth skin compresses well because there's little detail to keep. Small print is the opposite, every edge costs bits.

A Magic card has small print. It has the same frame on every card, which the codec may or may not exploit. It has reprints of the same art, something dermoscopy doesn't have. And it has a product constraint that no search metric measures: the deck tile has to look good on the app's screen. I thought the question was how much it compresses. It was, but not for long.

Before running anything, I took a calmer look at the raw folder, and it had surprises of its own. Half the weight was the cropped version of the art, and my first idea was to throw it away and crop from the full card when needed. An agent read the app's code and came back with bad news: the database doesn't store any crop coordinates, and the app uses the crop directly in the deck tiles. The cropped art is a class of its own, not a derivative. And next to the image folder there was a directory called _redundant, holding another seven gigs of copies of things that were already there. That one I deleted without mercy.

The first build

The pilot with a few hundred cards died with a segfault before doing anything. Nest's Python binding had been compiled without the flag that says "use the process's Python, don't bring your own", and the Python I use is static, so two interpreters were fighting over the same memory. One flag and done. A small bug, and the kind that makes me suspicious: how many other environment assumptions does the build carry without declaring them?

With the flag, the full build ran in the background and I opened one of the videos in the player. Cards going by, one per second, forty minutes of cards. My first hypothesis was that the encoder was repeating frames to hold each card on screen, and that this could be cut. One line of ffprobe killed the hypothesis: one frame per card, and the duration is just a timestamp annotation in the container, it costs no bytes.

7 GB became 1.9 GB, with image search working on top. It ran on the first try, which in a project of mine is rare enough to make me suspicious. Then I opened the output folder.

An archiver with 38 MP4s next to it isn't an archiver

38 video files, a .nest with the indexes, a JSON manifest and a cache directory. Four kinds of file to serve one thing. Nest exists to be the database in one file, and what came out was a database with forty things next to it. It worked, the way a piece of furniture assembled with leftover screws works. The point of Nest was getting lost there, and compression wasn't even the problem. Nest has the potential to be an archiver for Magic cards, for maps, for any image dataset with a database beside it. But an archiver is a file, not a folder.

The second question came from the model. The script used CLIP because that was what the forge had, and I didn't really know what CLIP did with a card. I looked into it: it looks at the art and ignores the printed text. For a Magic card that means looking at the less useful half, because what identifies the card is the name written at the top. I asked for a search on Hugging Face and GitHub of the open multimodal models available that month, and the answer was a Tencent family called WeMM, which reads text inside images, plus SigLIP and Jina. I already had the two-billion-parameter WeMM downloaded for another reason.

In a comparison with 1,500 cards and sixty queries like "the art of such-and-such card", CLIP found the right card one time in four. WeMM got nine in ten, SigLIP came close, Jina landed in the middle. WeMM's price is being about thirty times slower than CLIP, and running it over the whole corpus would take almost a day on my machine. So the comparison stayed on the sample, and the full corpus kept CLIP for now.

What came out of this wasn't "switch to WeMM". It was that the model can't be a constant at the top of a script. It has to be a list of presets inside the engine, and whoever builds picks which one, or which ones, at build time. And the video has to fit inside the file, not next to it. Before either of those two things, I wanted to know how far I could compress without losing anything. Even if we had to invent it.

GEO, schema and JSON-LD to get cited by LLM engines

2026-05-20T00:00:00+00:00

I wrote this guide in May 2026, after putting what I knew about schema next to what the GEO (generative engine optimization) papers were measuring. On June 19 I applied it to this blog in three changes: the single @graph, the BreadcrumbList, and a bundle with speakable, a TL;DR block and a robots.txt that allows AI crawlers. So the example in this post is no longer a made-up example.com. It is the JSON-LD this page serves right now.

The idea that ties it all together: clean JSON-LD is no longer just crawler food. It is what generative engines read to decide who gets credit for an answer, and it is the format NLWeb consumes and returns.

@graph and @id

The difference that matters is between loose JSON-LD blocks and a single connected graph. Each entity is declared once, with a stable @id, and everything else points to it with { "@id": "..." }. One @graph block per page, not several scripts fighting each other.

The anchoring rule I follow, in line with the W3C JSON-LD best practices:

Site-wide entities anchor at the root with a fragment: /#organization, /#website, /#person
Page entities anchor at the page URL: #article, #webpage, #breadcrumb
The page entity references site entities by @id and never copies the object

I declare site entities before page entities. The W3C does not require it. It is hygiene: a linear parser resolves the nodes in the right order.

The three bugs that show up most when auditing schema, all of which go away with disciplined @id values:

@id collision: two nodes with the same @id get merged by the parser into one, with unpredictable results
Orphan reference: an @id that is referenced but does not exist in any node of the graph
Plugin duplication: Yoast and RankMath each injecting their own Organization, with different data

The third one is the strongest argument for generating schema in one place. Here that place is templates/partials/schema.html, a Zola partial that builds the whole graph from config.toml and the post front matter.

The other rule is triple agreement: visible text, semantic HTML and JSON-LD saying the same thing. The GEO-16 paper audited 1,100 URLs cited by Brave Summary, Google AI Overviews and Perplexity, and the pillars most correlated with citation were metadata and freshness (r = 0.68), semantic HTML (r = 0.65) and structured data (r = 0.63). In other words, semantic HTML weighed as much as schema. Schema that describes something not on the page gets ignored, at best.

The @graph this blog serves

This is the graph for the AirPods Max post, without the long fields (description, image, word count):

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://brennercruvinel.blog/#organization",
      "name": "Brenner Cruvinel",
      "url": "https://brennercruvinel.blog/",
      "sameAs": ["https://github.com/brennercruvinel"],
      "knowsAbout": ["artificial intelligence", "mental health tech", "product design"]
    },
    {
      "@type": "WebSite",
      "@id": "https://brennercruvinel.blog/#website",
      "url": "https://brennercruvinel.blog/",
      "inLanguage": "pt-BR",
      "publisher": { "@id": "https://brennercruvinel.blog/#organization" }
    },
    {
      "@type": "Person",
      "@id": "https://brennercruvinel.blog/#person",
      "name": "Brenner Cruvinel",
      "sameAs": ["https://github.com/brennercruvinel"]
    },
    {
      "@type": "BlogPosting",
      "@id": "https://brennercruvinel.blog/blog/meu-airpods-max-voltou-do-congelador/#article",
      "isPartOf": { "@id": "https://brennercruvinel.blog/#website" },
      "headline": "Meu AirPods Max morreu e voltou do congelador",
      "datePublished": "2026-10-10T00:00:00+0000",
      "author": { "@id": "https://brennercruvinel.blog/#person" },
      "publisher": { "@id": "https://brennercruvinel.blog/#organization" },
      "speakable": {
        "@type": "SpeakableSpecification",
        "cssSelector": [".tldr", "h1", "h2"]
      }
    },
    {
      "@type": "BreadcrumbList",
      "@id": "https://brennercruvinel.blog/blog/meu-airpods-max-voltou-do-congelador/#breadcrumb",
      "itemListElement": [
        { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://brennercruvinel.blog/" },
        { "@type": "ListItem", "position": 2, "name": "Writings", "item": "https://brennercruvinel.blog/blog/" }
      ]
    }
  ]
}

Read it as an entity database, not as a list of tags. Organization, WebSite and Person exist once. The BlogPosting points to them. speakable says which part of the HTML is good for direct extraction, here the TL;DR block at the top of every post.

The template can also generate a Dataset node and a DefinedTermSet when a post's front matter declares extra.dataset or extra.terms. No post uses that yet.

What is still missing here, and is commented out in config.toml: the sameAs to Wikidata (I do not have an entry there) and the SearchAction (the blog has no URL-based search).

Which types to use

The base shows up on almost every site: Organization or LocalBusiness for the brand, WebSite, WebPage per page, Person for authors and BreadcrumbList. On top of that:

Activity	Main types	Worth adding
Blog, editorial site	Article, BlogPosting	SpeakableSpecification, Claim
E-commerce	Product, Offer, Review	Dataset for the catalog
Local business	LocalBusiness	DefinedTerm for services
SaaS, software	SoftwareApplication, Service	Dataset for the changelog
Documentation	TechArticle, HowTo	DefinedTermSet
Research	Article, Person	Claim, ClaimReview

The types I think are underused:

DefinedTerm and DefinedTermSet register your own vocabulary that does not exist in Wikidata
Dataset turns an article's metrics table into its own node, with license and temporalCoverage
Claim and ClaimReview mark statements and fact checks, useful for research content
SoftwareSourceCode marks content as a technical reference
VideoObject ties the video to the channel entity

Where schema lives on each platform

The principle does not change: the @graph is a data artifact, not a UI artifact. It is serialized once from the source of truth and has to be where the consumer looks before any JavaScript runs. On the web, the consumer is a crawler reading the initial HTML, so JSON-LD comes from the server, never from a useEffect.

The source of truth is the domain modeled as entities, with types validated in the backend language: Pydantic in Python, Zod or schema-dts in TypeScript, serde in Rust, Codable in Swift, kotlinx.serialization in Kotlin. Each entity has a stable internal identifier that becomes the @id, and a single module generates the JSON-LD. That module is what kills duplication.

In Next.js with the App Router, schema goes in a Server Component. schema-dts is Google's types package, types only, with no runtime cost, and it had 3,127,725 downloads in the week of October 5 to 11, 2026, according to the npm API. Site entities go in the root layout; page entities in the page component. For a blog, SSG or ISR beats plain SSR, because the schema comes out at build time.

// app/blog/[slug]/page.tsx, Server Component
import type { Graph, WithContext } from 'schema-dts'
export default async function ArticlePage({ params }) {
  const post = await getPost(params.slug)
  const schema: WithContext<Graph> = {
    '@context': 'https://schema.org',
    '@graph': [{
      '@type': 'Article',
      '@id': `https://example.com/blog/${params.slug}#article`,
      headline: post.title,
      author: { '@id': 'https://example.com/#person' },
      publisher: { '@id': 'https://example.com/#organization' },
      datePublished: post.publishedAt,
      dateModified: post.updatedAt,
    }],
  }
  return (
    <script type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: JSON.stringify(schema) }} />
  )
}

In a pure SPA, with Vite or CRA, the problem has no reliable solution: most AI crawlers do not run JavaScript. Static content goes in index.html; dynamic content needs prerendering or a meta-framework with SSR. Rails, Django, Laravel and Go are the easy case: the server template prints the script.

Rust on the server (axum, actix, Leptos with SSR) is the cleanest case, because the source of truth and the serializer are the same typed language:

#[derive(serde::Serialize)]
struct Article<'a> {
    #[serde(rename = "@type")] kind: &'a str,
    #[serde(rename = "@id")] id: String,
    headline: &'a str,
    author: IdRef<'a>,     // { "@id": "..." }
    publisher: IdRef<'a>,
    #[serde(rename = "datePublished")] published: &'a str,
}
// serde_json::to_string(&graph) becomes the body of <script type="application/ld+json">

Rust compiled to WebAssembly in the browser falls into the same hole as the SPA. If the wasm builds the page on the client, the crawler sees nothing. The article The Future of SEO with WebAssembly, from the agency GTECH, argues the same: server-rendered HTML with text, headings and links on first load, and wasm only on top, for the heavy work.

In a native app, Swift or Kotlin, there is no crawler reading the screen. Putting JSON-LD in a SwiftUI view gives you no visibility at all. What makes the content discoverable is the backend: it serves the same graph as HTML to crawlers and through a structured endpoint to agents, and the app consumes that backend. Firebase App Indexing, which indexed app content, is on Firebase's list of deprecated libraries; Android App Links and Universal Links are still useful, but they are routing, not discovery.

Platform	Where schema lives	How it gets there
Next.js, Nuxt, SvelteKit, Astro, Zola	Server component, SSR or SSG	Script in the initial HTML
Rails, Django, Laravel, Go	Server template	Script in the initial HTML
Pure SPA	`index.html` or prerender	Served HTML
Rust on the server	serde in the handler	Script in the initial HTML
Rust/wasm on the client	Prerender or SSR	Never client-only
Swift, Kotlin, desktop	Backend the app consumes	Endpoint, `/ask` and `/mcp`

Schema breaks silently. A structural change that corrupts an @id only shows up weeks later, when the citations disappear. That is why it pays to validate before every deploy: the Schema Markup Validator checks against the vocabulary, the Rich Results Test checks the rich results that still exist, and schema-dts catches errors at compile time.

FAQPage after May 7, 2026

Google removed FAQ rich results in stages, announced in a notice in the documentation, with no blog post. On May 7, 2026 they stopped showing in search. On June 15 Google removed the feature's documentation, as the Search Central changelog records. The same announcement planned to drop support in the Search Console API in August.

What remains: FAQPage is still a valid schema.org type. Google turned off the display, not the markup, and other crawlers keep reading it. What always did the work was the content in question-and-answer form.

One number helps explain why. Ahrefs analyzed 863,000 queries and 4 million URLs cited in AI Overviews, in a study published in March 2026 and summarized by Search Engine Journal: only 38% of the cited pages were in the top 10 for the same query. In the July 2025 version it was 76%, but Ahrefs itself warns that it improved citation detection between versions. Even with that caveat, what earns citations is not only what earns rankings.

My decision: I keep FAQPage where the question and the answer are real and visible on the page. I remove it only where the section existed to decorate the SERP.

NLWeb and MCP

NLWeb was announced by Microsoft at Build 2025 and was conceived by R.V. Guha, the same person behind RSS, RDF and Schema.org. Among the first partners named are Shopify, Snowflake, O'Reilly, Tripadvisor, Eventbrite and Hearst. It turns a site into an MCP server with two endpoints:

/ask takes a natural language question and returns JSON in schema.org
/mcp exposes the same to agents, over the Model Context Protocol

The arguments are the same for both; only the response format changes. The reference implementation keeps no state: the conversation context comes back with each call, in the prev parameter or as an already decontextualized query.

POST https://example.com/ask
Content-Type: application/json

{ "query": "who wrote about GEO on this site?", "site": "example.com" }

The implication: a well-built @graph becomes a conversational API without rewriting the backend. It works best on sites already structured as lists of items, recipes, events, products. The repository moved from microsoft/NLWeb to nlweb-ai/NLWeb in July 2025. It is written in Python and now ships modules such as AskAgent, AgentFinder and DataFinder, with Postgres among the supported vector stores.

For a native app with no web version, exposing /ask and /mcp over the data is the way to be found by agents.

The robots.txt and the llms.txt

If the goal is to be cited by AI, LLM user agents stay allowed in robots.txt. Blocking is a strategic decision, as with paid content, knowing it takes the site out of that channel. This blog's robots.txt allows, among others:

User-agent: GPTBot
Allow: /
User-agent: OAI-SearchBot
Allow: /
User-agent: PerplexityBot
Allow: /
User-agent: ClaudeBot
Allow: /
User-agent: Google-Extended
Allow: /
User-agent: CCBot
Allow: /

GPTBot and OAI-SearchBot belong to OpenAI, PerplexityBot to Perplexity, ClaudeBot to Anthropic. Google-Extended controls use in Gemini and CCBot is Common Crawl.

The llms.txt file is a markdown index of the important URLs. It blocks nothing and ranks nothing. Gary Illyes said in July 2025 that Google does not use it and does not plan to, and John Mueller compared the file to the keywords meta tag. On June 15, 2026 Google put this in its own AI optimization guide: the file is not needed for search and neither helps nor hurts rankings. This blog has no llms.txt, and I do not plan to prioritize one.

Four layers for an LLM-ready engine

When schema stops being just SEO and becomes data for an LLM, I think in four layers.

The first is content modeled as entities: types, fields, what null means, one stable identifier per entity, with source, update date and language recorded. It is the internal graph, independent of schema.org.

The second is public exposure: the internal graph translated into schema.org, injected into the initial HTML, with triple agreement guaranteed.

The third is RAG. Each chunk in the vector index carries the text, the entity's @id, the type, the date and the language. The same identifier vocabulary everywhere lets the LLM stitch together a coherent answer across the JSON-LD, the documents and the API.

The fourth is the application: tools with input and output schemas over the entities, the LLM in structured output, and the front end treating the answer as a view of the graph, always showing the source.

What ties the four together is the same entity model in the JSON-LD, the backend, the tools and the front-end types. And it is worth logging when the LLM cites an entity by @id, to compare with referrals from AI Overviews and ChatGPT after each schema change.

What the papers say helps

The original GEO paper, by Aggarwal and others, published at KDD 2024, tested content rewrites and measured visibility in the answers. The three methods that worked best were citing sources, adding direct quotations and adding statistics, with a relative gain of 30% to 40% on the position-adjusted word count metric. Citing other sources raises the chance that you get cited.

The rest is the basics done well: answer at the top, short paragraphs, descriptive headings, a single H1, real datePublished and dateModified, and primary sources with links.

Checklist

A single @graph block per page
Organization, WebSite and Person declared once, anchored at the root with #
Page entities anchored at the URL, referencing site entities by @id
Site entities before page entities
sameAs to Wikidata on Organization and Person, when an entry exists
knowsAbout with the real topics of authority
SpeakableSpecification pointing to the summary and the headings
Dataset when there is a data table, with license and temporalCoverage
DefinedTerm for your own vocabulary
dateModified updated on every real edit
JSON-LD in the initial HTML; in a native app, through an endpoint
Schema typed in the backend language
Triple agreement between text, semantic HTML and JSON-LD
AI user agents allowed in robots.txt
Validation in the Schema Markup Validator and in CI
NLWeb /ask and /mcp once the graph is stable
llms.txt last, if at all

References

Pranjal Aggarwal et al., GEO: Generative Engine Optimization, KDD 2024
Arlen Kumar and Leanid Palkhouski, AI Answer Engine Citation Behavior: An Empirical Analysis of the GEO-16 Framework, 2025
Mahe Chen et al., Generative Engine Optimization: How to Dominate AI Search, 2025
Junwei Yu et al., Structural Feature Engineering for Generative Engine Optimization, 2026, which measured 17.3% more citations by changing only the structure of the content
W3C, JSON-LD Best Practices
Google, schema-dts
nlweb-ai/NLWeb, the NLWeb reference implementation

Extraction attacks against black-box models: a reading list

2026-04-08T00:00:00+00:00

I put this list together for a security and intelligence research project. The first version was a dump of search results: the same Tramèr paper showed up eight times under different links, and half the items had nothing to do with model extraction. I deduplicated it, checked every source and removed what was off topic. What remains is what I would read again.

The question that ties it together: if I can only query a model through an API, without seeing the weights, how much of it can be rebuilt? And, going the other way, how much of the training data can be recovered from the model or from its gradients?

Stealing the model through the API

The starting point is Stealing Machine Learning Models via Prediction APIs, by Tramèr and colleagues, presented at USENIX Security 2016. They showed that cloud machine learning services, by returning prediction confidence, let an attacker rebuild models such as logistic regression and decision trees with few queries. The code is at ftramer/Steal-ML.

Practical Black-Box Attacks against Machine Learning, by Papernot and colleagues, AsiaCCS 2017, is a close relative: it trains a substitute model by querying the target and uses that substitute to craft adversarial examples that transfer to the original.

Knockoff Nets, by Orekondy, Schiele and Fritz, CVPR 2019, steals the functionality of an image network by querying it with random natural images. ActiveThief, by Pal and colleagues, AAAI 2020, does the same while choosing queries by active learning over unlabelled public data. CloudLeak, by Yu and colleagues, NDSS 2020, uses adversarial examples to extract models from commercial services with fewer queries.

More recent: Efficient and Effective Model Extraction, by Zhu and colleagues, 2024, and A realistic model extraction attack against graph neural networks, by Guan and colleagues, in Knowledge-Based Systems 2024, which takes the problem to graph networks.

The milestone for language models is Stealing Part of a Production Language Model, by Carlini and colleagues, 2024. With API access alone, they recovered the final projection layer of production models and their hidden dimension.

For the full map, the survey I Know What You Trained Last Summer, by Oliynyk, Mayer and Rauber, ACM Computing Surveys 2023, covers attacks and defences, and the kzhao5/ModelExtractionPapers repository keeps a list of papers in the area.

Inverting the model and leaking through gradients

Deep Leakage from Gradients, by Zhu, Liu and Han, NeurIPS 2019, is the paper that changed the conversation about federated learning: from the shared gradients, they rebuilt training images and text almost pixel by pixel.

The ones that followed:

Understanding Deep Gradient Leakage via Inversion Influence Functions, by Zhang and colleagues, NeurIPS 2023, gives a way to analyse leakage without running the attack
Wasserstein Distance-Based Deep Leakage from Gradients, from 2023, changes the distance used in the reconstruction
Iterative and mixed-spaces image gradient inversion attack in federated learning, by Fang and colleagues, Cybersecurity 2024
Uncovering Gradient Inversion Risks in Practical Language Model Training, by Feng and colleagues, CCS 2024, takes the attack to language model training
Inverting Gradient Attacks Makes Powerful Data Poisoning, by Bouaziz and colleagues, 2024, uses inversion to poison training
A Survey of the Implementations of Model Inversion Attacks, by Song and Namiot, 2023

Weights as an attack surface

If the attacker gets the weights file, extraction ends there. Two sides of that interest me.

The first is the format. safetensors exists because PyTorch's pickle format can execute code on load; safetensors stores only tensors. The Hugging Face post on common formats compares safetensors, GGUF and others, and onnx-safetensors connects ONNX to safetensors.

The second is protecting the weights of frontier models. RAND's report Securing AI Model Weights, from 2024, organizes the attack vectors and the security levels needed against each kind of attacker.

What was left out

The items from the original list on distributed training and sharding (FSDP), checkpoints, serving in general and neural networks applied to detecting vulnerabilities were removed. They are good, but they are not about model extraction. Also removed: B3, which is about backdoors, a 2025 adversarial attack unrelated to extraction, and the link to Carlini's talk at Virginia Tech, which now returns 404.

Image compression for computer vision: February's proposal and September's answer

2026-03-12T00:00:00+00:00

In February 2026 I wrote a proposal for dermML's dermatology dataset, which was already stored as AV1 video: sort the images by visual similarity before encoding, so neighbouring frames would look alike and the codec could take advantage of it. I estimated compression would go from about 30 times to 50 to 80 times. I did not implement it at the time.

In September I tested the same idea in Nest, with Magic cards, and it did not survive the real corpus. This post brings both ends together: what I was reading, what I proposed and what the data answered.

What I was reading

Two readings convinced me that lossy compression of training data was safe and that video was a real dataset format.

The first was a two-part series by Kaleigh Mentzer at Granica. In part 1, from November 2023, Food101 classification with a Vision Transformer barely lost accuracy until compression went past about 70%, and segmentation models on Cityscapes could be trained on data compressed by 97%, using only 3% of the original storage, with no relevant drop in mIoU. Their explanation is that lossy compression throws away high frequencies first, and the model depends little on them too; in a test with 32 images, perturbing high-frequency DCT coefficients barely moved the prediction. In part 2, with a fixed budget of about 0.5 GB, the original JPEGs fit 9,985 images, and compressing to Butteraugli distance 10 fit about 5.6 times more. With fewer than 100 images per class, more worse images beat fewer better ones by more than 10 accuracy points.

The second was Hugging Face. In the post on encoding robotics datasets as video, from August 2024, datasets ended up at 14% of their original size on average, reaching 0.2% in the best case, and loading several consecutive frames took 25% to 50% of the time of loading the same frames from PNG. LeRobotDataset v3.0, from September 2025, went further: several episodes per file, metadata in Parquet and streaming straight from the Hub.

The proposal

The problem I saw in dermML was frame order. Images went into the video in file system order, alphabetical by name:

Frame 0: ISIC_0024306.jpg  (dark melanoma, light skin)
Frame 1: ISIC_0024307.jpg  (benign nevus, dark skin)
Frame 2: ISIC_0024308.jpg  (dermatofibroma, medium skin)

AV1 encodes a frame from its difference to a reference frame. If the neighbour is a different lesion on different skin, the difference is large and inter-frame prediction does not help. My reading was that the 30 times came almost entirely from compression inside each image.

The idea: DermLIP embeddings, with 512 dimensions, already existed in the indexing pipeline. Finding the order that minimizes the distance between consecutive frames is a travelling salesman problem in embedding space, intractable to solve exactly for 58 thousand points, so the proposal used the simplest heuristic, greedy nearest neighbour:

import numpy as np
from sklearn.metrics.pairwise import cosine_distances

def sort_by_visual_similarity(embeddings):
    order, visited, current = [0], {0}, 0
    for _ in range(len(embeddings) - 1):
        dists = cosine_distances(embeddings[current:current + 1], embeddings)[0]
        dists[list(visited)] = float("inf")
        current = int(np.argmin(dists))
        visited.add(current)
        order.append(current)
    return order

And the estimate I wrote down:

Scenario	Estimated compression
File system order	~30x
Sorted by similarity	~50 to 80x
Sorted, with CRF and GOP tuning	~60 to 100x

For the full dataset, that would take the 52 GB from something like 1.7 GB to somewhere between 650 MB and 1 GB. The proposal already called for keyint=250 and scd=0 in SVT-AV1, to turn off scene cut detection and avoid an extra keyframe at every new lesion, and for one more SQLite column to map each sorted frame back to its original image. The validation plan was to encode with and without sorting, compare size and quality, and check that search still found the same things.

What September answered

In August Nest started storing images, and in September the Magic card series became the test I had not done in February.

The first round with inter-frame prediction came out bigger than without it. The reason was exactly what the proposal had warned about: scene cut detection was on, and one different card after another is a scene cut on every frame. With it off, on a corpus of almost three thousand reprints of the same art, prediction made the file 29% smaller. Shuffling the reprints cost only two points, because part of the gain came from the frame every card shares. And that 29% compares bytes only, not equivalent quality.

On the real corpus, of unique cards, the sorted build and the plain build came out at the same 1.3 GB. Nest tests both ways per segment before deciding, and it vetoed prediction in all of them. There was nothing to predict: the next card is another card, with another artwork. In the lossless regime it was worse: FFV1 and x264 without quantization, with the cards sorted, came out three to four times bigger than the source JPEGs, and sorting barely moved the size.

What remains

The thesis from the readings still stands: training data tolerates a lot of compression, and video is a good dataset container. What fell was my extrapolation. Sorting by similarity only pays off when the corpus has near-duplicate images, like card reprints or consecutive robot frames. In dermoscopy, each image is a different lesion from a different person, and the estimate of 50 to 80 times was probably optimistic for the same reason as the card one.

The other lesson is about method. Compression is a property of the domain before it is a property of the codec, and the only way to know is to encode the real corpus and look at the file, not the summary.

Hoff MVP: blocking addiction sites in /etc/hosts

2026-02-10T00:00:00+00:00

Cleaning up the Hoff repository, I found the very first proof of concept. The goal was to block pornography sites and the like for a close friend who was struggling with this addiction, which is silent and marginalized. It was the initial inspiration for everything. Finding it again was moving.

It is the rawest MVP possible: no app, just the hosts file. The idea is to point the domain to loopback, so the computer tries to open the site on itself and finds nothing. And what matters most is keeping the way back, to restore the file when the block needs to come off.

Blocking

Each line in /etc/hosts says "this name resolves to this address". To block, the address is the machine itself:

127.0.0.1   example.com
127.0.0.1   www.example.com

You need one line for each variation of the domain, with and without www. On macOS, after editing, it is worth flushing the DNS cache so the change takes effect right away:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

It is an honest block, but a fragile one: anyone with the administrator password undoes it in seconds. Even so, it is one more bit of friction between the impulse and the click.

Restoring hosts on macOS

Overwrites /etc/hosts with the default macOS content:

sudo sh -c 'echo "##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1       localhost
255.255.255.255 broadcasthost
::1             localhost
" > /etc/hosts'

Restoring hosts on Windows

Open PowerShell as administrator. This command appends the localhost entries to the end of the file, without deleting the rest:

Start-Process powershell -Verb runAs -ArgumentList "Add-Content -Path C:\Windows\System32\drivers\etc\hosts -Value '127.0.0.1 localhost', '::1 localhost'"

To really remove the block, you need to overwrite the whole file, not just append:

Start-Process powershell -Verb runAs -ArgumentList "Set-Content -Path C:\Windows\System32\drivers\etc\hosts -Value '127.0.0.1 localhost`n::1 localhost'"

Nest: a sovereign, content-addressable, offline-first vector DB

2026-01-15T00:00:00+00:00

Sharing the concept of something I am working on, tired of hacking around vector DBs with no stability. In an ordinary database, a chunk's ID can change when the index is rebuilt, and a saved citation starts pointing somewhere else without telling anyone.

Nest is my answer to that. It is a single-file vector DB, content-addressable, offline-first and hash-verified. Python builds the file, Rust serves the file. The address of any piece is:

nest://content_hash/chunk_id

You cite by content, not by location. If the content changes, the hash changes, and it is impossible to receive something other than what you asked for.

The hash as the address

The central idea is just one: the hash of the content becomes the address of the content. Instead of "give me the file in such-and-such folder", which could have been swapped without you knowing, you say "give me the file whose content has this hash". If something else came back, it would have a different hash. Verification is not an extra step; it is the very way you ask.

In Nest, the two parts of the address play different roles:

content_hash identifies the whole file by the hash of what it contains
chunk_id points to the piece inside that file

The practical consequence is the one I wanted: a citation does not break when the file moves to another folder, disk or machine. It is only valid for that content. If the content changed, the hash changed, and you know right away you are talking about something else.

The family

This is not my invention. It is content-addressable storage, and it has famous relatives.

The most everyday one is Git. Each commit is identified by a hash of its content, and a git commit is a sealed snapshot of the code at that moment. If someone rewrites history, the hashes do not match and Git flags it. IPFS does the same thing at scale, on a distributed network of many machines.

Nest sits between the two:

	What it seals	What it is for	Scale
Git	Code	Navigating versions	Repository
IPFS	Any file	Distribution	Network of machines
Nest	Vectorized knowledge	Search	One local file

Same mechanism, different purpose. Of the analogies I collected, this is the only one that describes Nest without a metaphor: content addressing for the same reason, so that asking for the data and verifying the data are the same operation.

Shipping versions without downloading everything again

A file that never changes is great for citing and bad for updating. If every new version forces you to download the whole file, nobody updates.

The most technical option is binary diffing. Tools like bsdiff, xdelta and the --patch-from mode of zstd compute the difference between yesterday's file and today's and produce a small patch. Whoever already has yesterday's version downloads only the patch and rebuilds today's locally, the same way an operating system updates without downloading everything again.

The problem is that this only works if the format is append-friendly, meaning that adding content at the end does not mess up what was already there. A deterministic build that reorders things internally, and compressed, indexed formats tend to reorganize a lot, can produce a huge diff for a small change: you change one chunk, the whole index moves, and the patch is no longer small. That is why I think this route is more fragile than splitting the file into shards and shipping only the new shard. And you only find out by testing.

Beyond the hash

The hash proves that something did not change. It does not prove who vouched for it or when the content existed. There are three known layers for that:

Digital signatures and certificates, the same idea behind https and signed software, which adds the "who"
Trusted timestamping, such as the RFC 3161 protocol or OpenTimestamps, which anchors the hash in Bitcoin and proves the content existed on a date without revealing the content
Blockchain, which solves immutability with no central party to trust

Of the three, timestamping fits Nest best. Blockchain, for storing papers and citing passages, would be a sledgehammer to crack a nut: Nest wants content addressing and local verification, not consensus among machines that do not trust each other.

In August, Nest started storing images too, and that became the Magic card series. More soon.

Prompt templates for research with agents

2025-09-15T00:00:00+00:00

I've been testing a few prompt templates that push crawlers and LLMs into delivering research more accurately. Sharing what I have, still in testing.

WIP, template under test. Still tuning it, not a final version.

The structure is always the same: role, objective, style, discovery sources, mandatory metadata and a benchmark rule. The most important line is the one that says to write "no reliable public benchmarks" instead of making up a number.

And even with it, that's not enough. Variation A produced my survey of the Rust ecosystem. In 2026, when I checked every row of that table against the GitHub API, I found a repository that doesn't exist and a row pointing to the wrong project, one with a similar name. The prompt forbade making things up, and the agent made things up anyway. The template organizes the delivery, but the one who checks the result is still me.

Template for research with agents

The prompts stay in Portuguese, exactly as I use them, because they ask the agent for output in Brazilian Portuguese. Variation A, the survey of Rust applications:

papel: pesquisador sênior em ecossistema open source e linguagens de sistemas, foco pesado em rust.

objetivo: mapear e analisar pelo menos 369 aplicações open source em rust, explicando por que cada uma importa, com metadados completos, contexto de adoção em produção e benchmark comparativo em tabela sempre que houver.

estilo: pt-br, sem emoji, sem bullet no corpo principal (parágrafo e tabela), todo recurso citado como Nome + URL com link markdown clicável, cabeçalhos markdown.

fontes de descoberta: Awesome Rust, LibHunt Rust, OSS Insight, GitHub Stars Leaderboard, Github Ranking Top 100 Stars in Rust, listas "Rust in production" e "rust-in-production" (ImplFerris). priorizar alto número de stars/forks e atividade recente, uso em produção por empresa conhecida, diversidade de domínio (devtools, sistemas distribuídos, db, runtimes js/ts, ai infra, editores, cli, jogos, wasm, networking, segurança, observabilidade). evitar libs minúsculas ou experimentais salvo impacto desproporcional.

metadados obrigatórios por app: nome, url do repo, descrição de 1 a 3 frases, categoria, subdomínio, maturidade, empresas que usam em produção, licença, stars/forks, crescimento 6 a 12 meses, data do último commit, número de contribuidores, "por que é foda" (2 a 4 frases).

benchmark: pra cada projeto com benchmark público sério, colete tipo, contexto, setup (hardware, so, versão rust), comparação, números-chave com unidade, link da fonte. monte tabela por projeto: projeto, cenário, métrica, resultado, concorrente, resultado da concorrente, vantagem aproximada, link. sem benchmark crível, escreva "sem benchmarks públicos confiáveis", nunca invente número. divergência entre fontes, explicite cenário, não consolide.

organização: tabela geral com as 369+, mais tabelas por domínio (devtools, runtimes/plataformas, infra/observabilidade, terminais/shells/editores, web e apis, segurança/cripto/password managers, ai/ml infra, db e search, embedded/iot). análise final: distribuição por tipo, vantagem comparativa do rust, padrões técnicos (async/await/tokio, crates de observabilidade, arquiteturas), adoção corporativa vs go/c/c++/java/node, benchmark vs marketing, lacunas e oportunidades.

Variation B: Rust + WebAssembly books and resources

papel: pesquisador sênior em rust, wasm e desenvolvimento web de alta performance.

objetivo: análise completa e atualizada de livros e recursos estruturados de rust + wasm, ecossistema global e contexto brasileiro, em tabelas com links clicáveis (livros, editoras, lojas, repos, doc oficial).

estilo: idem variação A.

escopo, cinco grupos: (1) livros-base de rust core relevantes pra wasm, com título, autor, ano, nível, temas, recomendação pra wasm, link oficial/compra/comunidade/repo. (2) livros específicos de rust + wasm, 20 a 30 obras, com tipo de recurso, público-alvo, escopo (browser/wasi/iot/mobile/desktop). (3) livros de wasm geral relevantes pra rust, com coluna "relevância pra rust". (4) contexto brasil: traduções, autores brasileiros, livros específicos, disponibilidade real em e-book e loja br. (5) recursos oficiais e books online com profundidade de livro (the rust and webassembly book, doc de wasm-bindgen/web-sys/js-sys/wasm-pack/yew/leptos), com tipo, org, temas, link, repo, licença.

análise final: pré-requisitos naturais antes de rust+wasm, quais livros são mais completos/atualizados/adequados por perfil (js dev migrando, rustacean avançado, dev de sistemas), como livros de wasm geral ajudam em performance/segurança/binário/interop, situação no brasil (lacunas e dependência de inglês), temas sub-representados (wasi, servidor, edge, frameworks modernos leptos/dioxus/tauri, segurança e fuzzing de módulos, casos além do browser).

Variation C: people and visualization projects in Rust + Wasm

papel: pesquisador sênior em rust, wasm, visualização de dados e ecossistema open source.

objetivo: mapeamento de pelo menos 50 pessoas relevantes em rust (foco rust+wasm) e pelo menos 50 projetos/libraries de grafos, charts e viz em wasm (idealmente rust, não exclusivamente), mais todos os links de presença online (github, site pessoal, redes, artigos, posts em dev.to e hacker news).

estilo: idem, tabela como forma principal.

pessoas: nome completo, país/região, papel (autor, maintainer, contributor rustwasm, criador de framework, educador), 2 a 5 projetos principais, temas técnicos, github, site/blog, redes (twitter/x, mastodon, linkedin, youtube, twitch), páginas de autor (dev.to, medium, substack, conferências), discussões de destaque (hacker news, reddit r/rust, users.rust-lang.org). hubs de descoberta: awesome-rust, awesome-rust-and-webassembly, awesome-wasm, orgs rustwasm e bytecodealliance, github topics (topic:webassembly l:rust). validar que o link pertence à pessoa (evitar homônimo) e que o projeto é minimamente ativo.

projetos: nome, descrição (2 a 3 frases), linguagem, tipo de viz (grafos, charts, heatmaps, mapas, dashboards, 2d, 3d), casos de uso, status, métricas (stars, contribuidores, downloads crates.io, uso citado), repo, site/docs, demos, artigos/talks/discussões.

conexões: cruze pessoa↔projeto com nome, projeto, papel (criador, maintainer, core contributor, autor de módulo crítico), link de comprovação (readme de maintainers, palestra, artigo "introducing X").

contexto brasil (opcional): devs br relevantes com ênfase em viz/grafos, projetos br em rust com target wasm, conteúdo em português, talks em conferência br.

análise final: núcleos de contribuição (rustwasm, bytecodealliance, empresas), clusters de viz (grafos, dashboards, jogos, ides, ferramentas científicas), perfis predominantes, lacunas (pouca bibliografia de grafos complexos, falta de tooling de alto nível, pouca doc pra iniciante), global vs brasil.

My Claude Code slash command framework ended up on Chinese blogs

2025-08-06T00:00:00+00:00

Wow. The number of Chinese blogs and sites writing about my slash command framework for Claude Code. The world is getting really strange, I never imagined a few markdown commands would ripple out like this.

It's a simple idea, almost silly: slash commands written in markdown for Claude Code, open source, to automate the boring, repetitive part of the dev workflow. It's called CCPlugins. I made it for myself, to stop repeating the same instructions all the time, like asking it to "act like a senior engineer" in every conversation. I published it at the end of July, and within days it started popping up in posts I can't even read without a translator.

Most are Chinese, on Zhihu and CSDN, the two biggest developer communities there. Plus a few in English, on Medium and in tool newsletters.

Publication	Platform	Language
Zhihu column	Zhihu	zh
Zhihu question	Zhihu	zh
CSDN, Trb201013	CSDN	zh
CSDN, weixin_42616808	CSDN	zh
CSDN, u012094427	CSDN	zh
CSDN ModelEngine	CSDN	zh
ddli.cn	ddli	zh
JishuZhan	JishuZhan	zh
Bright Coding	Bright Coding	en
Joe Njenga, on Medium	Medium	en
Coding Nexus, on Medium	Medium	en
EveryDev	EveryDev	en

What gets me isn't the count, it's the distance. Something I wrote for myself turned into articles in Mandarin that I need machine translation to understand. Slash commands in markdown, that's all. Sometimes the simplest idea is the one that travels furthest, and I'm still processing seeing my name in the middle of characters I can't read.

Update, October 2026: the repository reached 2,776 stars and 167 forks, and it's archived today. Anthropic itself kept adding to Claude Code things the commands used to do by hand, subagents, context memory, and several of them became redundant. I think that's good. That's what they existed for.

The open source Rust ecosystem: what runs in production

2025-06-30T00:00:00+00:00

I put this survey together with the research templates for agents, to decide what to bet on in my Rust projects. The first version had a good rule, "a benchmark number only goes in with a source", that it did not follow itself: several sources were just a site's home page, with no article, and the stars came rounded from third-party rankings.

All stars below were read from the GitHub API on 13 October 2026.

The core, by stars

Repositories with more than 20 thousand stars where Rust is the main language, according to GitHub. Where a description carries a performance number, it is what the project itself claims in its README.

Repository	Stars	What it is
openai/codex	129,042	OpenAI's coding agent that runs in the terminal
rustdesk/rustdesk	125,720	Self-hosted remote desktop, client and server
rust-lang/rust	119,904	The language's compiler and standard library
tauri-apps/tauri	111,870	Desktop apps with a web front end and a Rust back end, smaller binaries than Electron
denoland/deno	108,774	JavaScript and TypeScript runtime, secure by default, with explicit permissions
oven-sh/bun	96,222	JavaScript runtime, bundler and test runner in one binary
zed-industries/zed	91,688	Native editor with collaborative editing
astral-sh/uv	90,720	Python package and project manager; the README says 10 to 100 times faster than pip
BurntSushi/ripgrep	69,112	Recursive regex search that respects .gitignore
dani-garcia/vaultwarden	68,985	Lightweight Bitwarden-compatible server, popular for self-hosting
alacritty/alacritty	65,955	OpenGL-accelerated terminal
warpdotdev/warp	65,452	Terminal with built-in AI
rust-lang/rustlings	64,339	Short exercises to learn Rust
tw93/Pake	62,056	Turns a web page into a desktop app with one command
FuelLabs/sway	61,391	Smart contract language for the Fuel network
sharkdp/bat	60,789	cat with syntax highlighting and git integration
starship/starship	60,251	One shell prompt for bash, zsh, fish and others
meilisearch/meilisearch	59,558	HTTP search engine with relevance out of the box
typst/typst	56,601	Markup-based typesetting, a modern alternative to LaTeX
aaif-goose/goose	55,248	Extensible AI agent for software development
astral-sh/ruff	50,053	Python linter and formatter; the README says 10 to 100 times faster than Flake8 and Black
bevyengine/bevy	48,973	Data-driven game engine with ECS
helix-editor/helix	46,576	Modal terminal editor with built-in LSP and tree-sitter
juspay/hyperswitch	45,313	Payments platform with routing across processors
sharkdp/fd	44,781	A simple, fast alternative to find
sxyazi/yazi	42,808	Terminal file manager with async I/O
GyulyVGC/sniffnet	41,503	Network traffic monitor with a graphical interface
nushell/nushell	40,657	Shell with structured data pipelines
pola-rs/polars	40,120	Columnar DataFrames with Python bindings
ajeetdsouza/zoxide	40,087	A cd that learns your most-used directories
DioxusLabs/dioxus	39,383	App framework for web, desktop and mobile, with a React-like API
spacedriveapp/spacedrive	39,158	Cross-platform file explorer
lapce/lapce	38,917	Lightweight native editor with remote mode
servo/servo	38,145	Embeddable browser engine, born at Mozilla
firecracker-microvm/firecracker	37,349	AWS microVMs; the README says it runs Lambda and Fargate
pnpm/pnpm	36,803	JavaScript package manager with shared storage
casey/just	36,256	Task runner with simple syntax, in the spirit of make
zellij-org/zellij	35,723	Terminal multiplexer with WebAssembly plugins
qdrant/qdrant	35,065	Vector database with HNSW, filters and replication, common in RAG
jdx/mise	34,971	Tool version, environment variable and task manager
rustfs/rustfs	34,870	S3-compatible object storage
fish-shell/fish-shell	34,296	Interactive shell, rewritten in Rust from version 4
swc-project/swc	34,204	JavaScript and TypeScript compiler and bundler
TabbyML/tabby	33,911	Self-hosted coding assistant
tokio-rs/tokio	33,440	Async runtime underlying most Rust servers
surrealdb/surrealdb	33,128	Multi-model database, document and graph, with real-time queries
yewstack/yew	32,821	WebAssembly front-end framework inspired by React and Elm
dandavison/delta	32,487	Syntax-highlighting pager for git diff
jj-vcs/jj	32,023	Git-compatible version control with a simpler model
ankitects/anki	31,988	Spaced-repetition flashcards, core in Rust
atuinsh/atuin	31,986	Shell history with search and encrypted sync
influxdata/influxdb	31,763	Time-series database; version 3 is in Rust
iced-rs/iced	31,755	Cross-platform GUI library inspired by Elm
emilk/egui	31,400	Immediate-mode GUI, native and on the web
vercel/turborepo	31,198	Incremental build for many packages in one repository, moved from Go to Rust
nautechsystems/nautilus_trader	29,938	Event-driven trading platform, backtest and production in the same code
chroma-core/chroma	29,495	Vector database for LLM applications
wezterm/wezterm	29,220	GPU-accelerated terminal with a multiplexer
sharkdp/hyperfine	29,084	Command-line benchmarking tool with statistics
niri-wm/niri	28,390	Wayland compositor with scrollable tiling
cloudflare/pingora	27,614	Cloudflare's HTTP proxy framework, open-sourced in February 2024
GraphiteEditor/Graphite	27,572	2D graphics editor with a node-based procedural engine
tokio-rs/axum	27,465	Web framework on tokio and tower
tree-sitter/tree-sitter	27,177	Incremental parser generator used in editors
Schniz/fnm	27,093	Node version manager
Wilfred/difftastic	26,007	Structural diff that understands language syntax
biomejs/biome	25,945	Formatter and linter for web projects
rwf2/Rocket	25,780	Web framework focused on type safety and ergonomics
clockworklabs/SpacetimeDB	25,288	Database with built-in server logic, for real-time apps
actix/actix-web	24,858	Performance-focused web framework
ogham/exa	24,450	ls replacement, unmaintained; the README points to the eza fork
uutils/coreutils	24,233	Cross-platform rewrite of GNU coreutils
slint-ui/slint	24,168	Declarative GUI toolkit for Rust, C++, JavaScript and Python
eza-community/eza	23,548	Maintained fork of exa

By domain

Command-line tools

The ripgrep, fd, bat, delta and just tools are already in the core. Below them:

Repository	Stars	What it is
rust-lang/mdBook	22,213	Books in Markdown, used for the official Rust book
getzola/zola	17,511	Static site generator, the one behind this blog
XAMPPRocky/tokei	14,994	Counts lines of code by language
ClementTsang/bottom	14,101	Terminal system monitor
bootandy/dust	12,497	Disk usage, in the spirit of du
imsnif/bandwhich	12,001	Bandwidth use per process
sharkdp/hexyl	10,291	Hex viewer
pemistahl/grex	8,219	Generates regex from examples
svenstaro/miniserve	7,898	HTTP file server
tealdeer-rs/tealdeer	6,590	tldr client
sharkdp/pastel	6,516	Color manipulation in the terminal
dalance/procs	6,193	Modern ps replacement
ouch-org/ouch	3,786	Compresses and decompresses many formats
cgag/loc	2,456	Lines-of-code counter

Git, build and binary size

Repository	Stars	What it is
gitbutlerapp/gitbutler	21,806	Visual Git client
rui314/mold	17,633	Fast linker, works with Rust
GitoxideLabs/gitoxide	12,012	Pure Rust implementation of Git
johnthagen/min-sized-rust	9,857	Techniques to shrink Rust binaries
mozilla/sccache	7,778	Distributed compilation cache
flamegraph-rs/flamegraph	6,047	Generates flamegraphs from perf and dtrace
RazrFalcon/cargo-bloat	2,774	Shows what takes up space in an executable
rust-lang/git2-rs	2,114	libgit2 bindings
AlexEne/twiggy	1,427	Shows what takes up space in a .wasm binary
matklad/cargo-xtask	1,338	Build automation pattern with cargo
nnethercote/dhat-rs	1,010	Heap profiling

Runtimes and platforms

Deno, Bun, Tauri, pnpm and tokio are in the core. The smaller async runtimes and the WebAssembly platforms:

Repository	Stars	What it is
vercel/turborepo	31,198	Incremental build for many packages in one repository
shuttle-hq/shuttle	6,916	Deployment platform for Rust
spinframework/spin	6,525	Serverless microservices in WebAssembly
extism/extism	5,794	WebAssembly plugin system
monoio-rs/monoio	5,126	Thread-per-core async runtime on io_uring, from ByteDance
smol-rs/smol	5,082	Small async runtime
async-rs/async-std	4,062	Async runtime with a std-like API
DataDog/glommio	3,663	Thread-per-core runtime on io_uring
compio-rs/compio	1,916	Completion-based I/O runtime

Infrastructure, databases and search

Meilisearch, Qdrant, InfluxDB, SurrealDB, Polars and SpacetimeDB are in the core.

Repository	Stars	What it is
neondatabase/neon	23,197	Serverless Postgres with storage separated from compute
vectordotdev/vector	22,697	Logs and metrics pipeline, maintained by Datadog
valeriansaliou/sonic	21,358	Lightweight search back end
tikv/tikv	16,908	Distributed key-value store, the base of TiDB
quickwit-oss/tantivy	16,211	Full-text search library inspired by Lucene
microsoft/windows-rs	12,817	Bindings for the Windows APIs
quickwit-oss/quickwit	11,713	Cloud-native search and observability
bottlerocket-os/bottlerocket	9,678	Operating system for containers, from AWS
databendlabs/databend	9,466	Cloud data warehouse
apache/datafusion	9,444	Analytical SQL query engine
risingwavelabs/risingwave	9,369	Streaming database with SQL
spacejam/sled	9,095	Embedded database
youki-dev/youki	7,629	OCI container runtime
GreptimeTeam/greptimedb	6,734	Cloud-native time-series database
MaterializeInc/materialize	6,382	SQL over data streams
apache/opendal	5,412	Unified access to storage services
fluvio-community/fluvio	5,256	Streaming platform
cberner/redb	4,847	Embedded key-value database in pure Rust
kube-rs/kube	3,844	Kubernetes client
apache/arrow-rs	3,641	Official Apache Arrow implementation in Rust
delta-io/delta-rs	3,341	Native Delta Lake
eclipse-zenoh/zenoh	3,256	Pub/sub and query for IoT and robotics
fjall-rs/fjall	2,377	Embedded LSM tree
apache/datafusion-ballista	2,146	Distributed DataFusion
databendlabs/openraft	2,089	Raft implementation
lnx-search/lnx	1,456	Search server built on tantivy
GlareDB/glaredb	1,024	Analytical SQL over many sources
meilisearch/heed	921	Typed LMDB wrapper

Web and APIs

Axum, Actix Web and Rocket are in the core.

Repository	Stars	What it is
leptos-rs/leptos	21,388	Full-stack framework with fine-grained reactivity
transact-rs/sqlx	17,563	Async SQL with compile-time checked queries
diesel-rs/diesel	14,202	ORM and query builder
grpc/grpc-rust	12,491	gRPC implementation
seanmonstar/warp	10,378	Web framework built from filters
SeaQL/sea-orm	9,924	Async ORM
loco-rs/loco	9,439	Rails-style framework
poem-web/poem	4,448	Web framework with OpenAPI generation
salvo-rs/salvo	4,447	Web framework
tower-rs/tower	4,320	Middleware and service abstractions
ntex-rs/ntex	2,541	Network and web framework

Security and cryptography

Vaultwarden is in the core.

Repository	Stars	What it is
firezone/firezone	9,113	Zero-trust access over WireGuard; the repository's main language is Elixir
rustls/rustls	7,672	TLS in pure Rust
mullvad/mullvadvpn-app	7,665	Mullvad VPN app, daemon in Rust
cloudflare/boringtun	7,218	Userspace WireGuard
briansmith/ring	4,107	Cryptographic primitives focused on TLS
str4d/rage	3,682	File encryption in the age format
EmbarkStudios/cargo-deny	2,452	Checks licenses, advisories and dependencies
Keats/jsonwebtoken	2,100	JWT
rustsec/rustsec	1,966	Security advisory database for crates
ramosbugs/oauth2-rs	1,211	OAuth2 client
RustCrypto/password-hashes	914	Argon2, bcrypt, scrypt and the like
rust-bitcoin/rust-secp256k1	430	libsecp256k1 bindings

AI, ML and LLM infrastructure

Qdrant, Chroma, Polars and Tabby are in the core.

Repository	Stars	What it is
huggingface/candle	21,168	Minimalist ML framework
tracel-ai/burn	16,107	Deep learning portable across back ends
lancedb/lancedb	11,665	Serverless vector database on the Lance format
huggingface/tokenizers	11,168	Fast tokenizers
0xPlaygrounds/rig	8,870	Framework for LLM agents
EricLBuehler/mistral.rs	7,743	LLM inference with quantization
rustformers/llm	6,153	LLM inference
LaurentMazare/tch-rs	5,503	libtorch bindings
Rust-GPU/rust-cuda	5,407	Rust compiled for NVIDIA GPUs
rust-ml/linfa	4,759	Classic ML algorithms, in the spirit of scikit-learn
safetensors/safetensors	3,917	Safe tensor format
sonos/tract	3,087	ONNX and TensorFlow inference
pykeio/ort	2,559	ONNX Runtime bindings
64bit/async-openai	2,017	Async client for the OpenAI API
sobelio/llm-chain	1,603	Chaining LLM calls
chelsea0x3b/cudarc	1,231	CUDA bindings
srush/llama2.rs	1,063	Llama 2 in Rust, for teaching
pepperoni21/ollama-rs	1,061	Ollama client
smartcorelib/smartcore	964	ML library
utilityai/llama-cpp-rs	657	llama.cpp bindings

Embedded and low-level systems

Repository	Stars	What it is
redox-os/redox	16,620	Unix-like operating system written in Rust
embassy-rs/embassy	9,957	Async embedded
tock/tock	6,464	Secure operating system for microcontrollers
oxidecomputer/hubris	3,631	Oxide's embedded operating system
theseus-os/Theseus	3,212	Research operating system that uses Rust's type system
nix-rust/nix	3,079	POSIX bindings
probe-rs/probe-rs	2,975	Debugging and flashing microcontrollers
rust-lang/libc	2,628	libc bindings
rtic-rs/rtic	2,420	Real-time concurrency for microcontrollers
seL4/rust-sel4	216	Rust support for the verified seL4 microkernel

Outside GitHub, Ferrocene is a Rust compiler qualified for safety-critical software, such as automotive.

Graphics, GUI, games and audio

Bevy, egui, iced and Slint are in the core. The physics in rapier is the same idea of simulation that shows up, at another scale, in the Z machine.

Repository	Stars	What it is
ratatui/ratatui	22,965	Text user interfaces in the terminal
gfx-rs/wgpu	18,278	Cross-platform WebGPU, native and on the web
linebender/druid	9,702	UI toolkit, predecessor of xilem
veloren/veloren	7,621	Open-world voxel RPG
makepad/makepad	7,170	UI framework and creative environment
rust-windowing/winit	6,204	Cross-platform window creation
fschutt/azul	6,129	GUI on WebRender
dimforge/rapier	5,853	2D and 3D physics, with JavaScript and WebAssembly bindings
linebender/xilem	5,570	Experimental UI framework
dimforge/nalgebra	4,801	Linear algebra
ggez/ggez	4,703	2D game framework
not-fl3/macroquad	4,662	Simple 2D games, including on the web
linebender/vello	4,417	2D renderer on the GPU
lapce/floem	4,296	GUI with fine-grained reactivity
crossterm-rs/crossterm	4,242	Cross-platform terminal manipulation
RustAudio/cpal	3,966	Audio input and output
pdeljanov/Symphonia	3,434	Pure Rust audio decoder
imgui-rs/imgui-rs	3,058	Dear ImGui bindings
Rust-SDL2/rust-sdl2	2,952	SDL2 bindings
RustAudio/rodio	2,488	Audio playback
bitshifter/glam-rs	2,077	SIMD vector math for games and graphics
gfx-rs/naga	1,565	Shader translator, now inside the wgpu repository
tesselode/kira	1,071	Audio for games
dimforge/parry	880	Collision detection

Blockchain and zero-knowledge proofs

Sway is in the core.

Repository	Stars	What it is
solana-labs/solana	14,950	Solana blockchain; the old repository was archived
paritytech/substrate	8,386	Polkadot's blockchain framework; archived
paradigmxyz/reth	5,825	Ethereum execution client
sigp/lighthouse	3,484	Ethereum consensus client
rust-bitcoin/rust-bitcoin	2,684	Bitcoin types and serialization
near/nearcore	2,620	NEAR network node
namada-net/namada	2,517	Privacy-focused blockchain
risc0/risc0	2,203	zk virtual machine
succinctlabs/sp1	1,747	zk virtual machine on RISC-V
noir-lang/noir	1,410	Language for zk circuits
alloy-rs/alloy	1,337	Ethereum tooling, successor to ethers-rs
zcash/halo2	920	Proof system
0xPolygonZero/plonky2	859	Recursive proof system
ZcashFoundation/zebra	622	Zcash node

Benchmarks with a source

I kept only the benchmarks with a primary source, code or methodology. Out went the async runtime ones (a post with no code or raw data), the WebAssembly runtime ones (the repository itself marked the numbers as placeholders), and the gitoxide and Redis-style server ones (the sources were only a site's home page, or a site that is down).

Ripgrep versus grep and friends

The ripgrep README has tables measured by the author on an Intel i9-12900K. Searching for [A-Z]+_SUSPEND as a word in the Linux kernel source:

Tool	Time	Ratio
ripgrep	0.082 s	1.00x
git grep	0.273 s	3.34x
The Silver Searcher	0.443 s	5.43x
ugrep	0.639 s	7.82x

Ignoring .gitignore and filtering by file type, ripgrep takes 0.063 s and GNU grep 0.674 s. On a single file of about 13 GB already cached, the search Sherlock [A-Z]\w+ takes 1.042 s in ripgrep, 1.339 s in ugrep and 6.577 s in GNU grep. The same README shows the limits: on a pattern with no literal, like [A-Za-z]{30}, the lead over GNU grep drops to about 2x, and there are patterns where another tool falls off a cliff and ripgrep does not. The first version of this post cited these numbers from ripgrep.dev, which is an unofficial site.

Web frameworks

Sharkbench measures concurrent requests with I/O and JSON on an Intel Core Ultra 5 325 running Linux. The page was updated on 5 October 2026:

Framework	Req/s	Median latency	Memory
Hyper	27,372	1.2 ms	4.6 MB
Axum	26,909	1.2 ms	5.7 MB
Actix	23,833	1.3 ms	6.9 MB
Rocket	21,365	1.5 ms	7.1 MB
ASP.NET Core	17,561	1.5 ms	46.6 MB
Express	7,670	3.7 ms	84.8 MB
Gin	1,652	3.3 ms	13.5 MB

Two caveats. The order changes between updates: in the first version of this post, with numbers from another run, Actix was first. And the page does not describe the load generator or concurrency, so Gin behind Express is a result I would not take as a rule without reading the test code.

JavaScript runtimes

I removed the Bun, Deno and Node numbers: the sources were author profile pages, with no article. What stays is the warning that applies to any comparison of this kind. In a discussion in the Deno repository, Luca Casonato, from the Deno team, answers that you cannot compare two systems with a single HTTP benchmark, because that test does no routing, serves no static files and ignores the rest of what a server does.

Pingora versus NGINX, in production

In Cloudflare's September 2022 post, Pingora serves more than a trillion requests a day and, under the same load, uses about 70% less CPU and 67% less memory than the previous NGINX-based service. Median TTFB dropped by 5 ms and p95 by 80 ms. For one large customer, the connection reuse ratio went from 87.1% to 99.92%, which cut new connections to the origin by 160 times. Much of the gain comes from sharing the connection pool across threads, which NGINX's process model does not allow.

Polars, pandas and plain Rust

Haixuan Tao compared the three on a 4.2 GB dataset from Stack Overflow, on an Intel i7-8750H with 12 threads, with open code:

Implementation	Total time	Versus pandas
pandas	80 s	1x
Polars, single thread	30 s	2.6x
Polars, multithreaded	17 s	4.7x
Polars, lazy and multithreaded	16.5 s	4.8x
Plain Rust, single thread	24 s	3.3x
Plain Rust, multithreaded	13.7 s	5.8x

Leaving out reading the file, multithreaded Rust takes 1.7 s against 40 s for pandas, about 23x. His advice: Polars for the API and for merges and group-bys, pandas when performance and memory do not matter.

WebAssembly runtimes

I found no reproducible, current comparison. If you want to go through the literature, Hockley and Williamson measured scripting performance in Wasmer at the ICPE 2022 conference.

Who uses it in production

Only the cases with a source from the company itself stayed:

VS Code search switched to ripgrep in version 1.11, in 2017
Cloudflare replaced NGINX with Pingora in the proxy that connects its network to the internet
Firecracker runs AWS Lambda and AWS Fargate, according to its README
Discord moved its Read States service from Go to Rust in 2020, because of latency spikes from Go's garbage collector
Vercel finished porting Turborepo from Go to Rust

The first version had more cases and a list of market statistics, such as "45% of the Fortune 500 run Rust", taken from blogs with no source. I removed everything I could not tie to a primary source, including "Discord cut memory by 8 times", which Discord's post does not say.

What I take from it

Most of the top is developer tooling: search, terminals, shells, editors, package managers. It makes sense, because the first Rust adopters were developers writing tools for themselves, where speed, resource use and the command-line experience decide. Right behind come infrastructure and data: proxies, vector databases, search, time series, DataFrames.

The technical patterns repeat. Servers are async on tokio. The most common shape is a single binary configured by file or command line. WebAssembly plugins show up where cheap runtime extension is wanted, as in Zellij. And the foundation is almost always the same: serde, clap, anyhow and thiserror, rayon, reqwest, hyper.

Where there is a serious benchmark, the advantage holds, but with limits. On the Linux kernel, ripgrep is 3 to 11 times ahead of the other tools, and loses its margin on patterns with no literal. Pingora shows a production gain, with CPU and memory measured by the operator itself. Outside those cases, the gain over optimized C or Go is often small, and what weighs in the choice is memory safety, the type system and tooling.

The gaps I see: a full-stack web framework with a plugin ecosystem at the level of Django or Rails, a complete data engineering stack at the level of Spark and Airflow, GUI that competes with Electron and Qt, and native ML that competes with PyTorch. Burn and Candle exist, but are still smaller.

Rust and WebAssembly books and resources

The starting point changed in 2025: the rustwasm organization on GitHub was sunset, and "The Rust and WebAssembly Book" was frozen. wasm-bindgen and wasm-pack moved to a new organization, wasm-bindgen. The old book is still good as an introduction, it just stopped in time.

Rust foundations

WebAssembly demands ownership and borrowing (there is no garbage collector in the browser), interop with JavaScript, async and no_std, because many environments do not have the full standard library.

Book	Authors	Edition	What for
The Rust Programming Language, 3rd edition	Steve Klabnik, Carol Nichols, Chris Krycho	No Starch, March 2026	The starting point; covers the 2024 edition and has a new async chapter
Programming Rust, 3rd edition	Jim Blandy, Jason Orendorff, Leonora Tindall	O'Reilly, due October to November 2026, 748 pages	Intermediate to advanced; the FFI part helps you understand WebAssembly underneath
Rust for Rustaceans	Jon Gjengset	No Starch, 2021	The step after the official book: unsafe, traits, reusable crates
Rust in Action	Tim McNamara	Manning, 2021	Practical systems cases
Zero to Production in Rust	Luca Palmieri	Self-published	Back-end architecture for production
Rust Atomics and Locks	Mara Bos	O'Reilly, 2023, with a free online version	Concurrency, useful for WebAssembly with threads
The Rustonomicon	The Rust team	Online, ongoing	Unsafe, aliasing, FFI
Command-Line Rust	Ken Youens-Clark	O'Reilly, 2022	Command-line tools
Asynchronous Programming in Rust	Carl Fredrik Samson	Packt, February 2024	Futures, executors, epoll, kqueue and IOCP
Hands-On Concurrency with Rust	Brian L. Troutwine	Packt, 2018	Concurrency

Rust and WebAssembly

Book	Authors	Edition	Scope
The Rust and WebAssembly Book	Rust and WebAssembly Working Group	Online, archived in 2025	Browser: Game of Life, wasm-bindgen, wasm-pack
Programming WebAssembly with Rust	Kevin Hoffman	PragProg, 2019	Browser and custom hosts; does not cover the component model or WASI 0.2
Practical WebAssembly	Sendil Kumar Nellaiyapen	Packt, 2022	Rust and WebAssembly in the browser
Practical WebAssembly	Kassian Wren	O'Reilly, 2024	WebAssembly for web developers; same title, different book
WebAssembly with Rust	sendilkumarn	Leanpub	WAT, wabt, binaryen and toolchain
Game Development with Rust and WebAssembly	Eric Smith	Packt, 2022	A 2D game in the browser
Creative Projects for Rust Programmers	Carlo Milanesi	Packt, 2020	Yew, WebAssembly games, REST
Building and Deploying WebAssembly Apps	Peter Salomonsen	BPB, 2025	AssemblyScript, C, C++, Rust and Kubernetes

Watch out for the flood of AI-generated self-published books since 2023, with titles like "Rust for WebAssembly" and authors with dozens of books a year. Before buying, it is worth checking the publisher and whether the author has public code.

WebAssembly in general

Book	Authors	Edition	Relevance for Rust users
WebAssembly: The Definitive Guide	Brian Sletten	O'Reilly, 2021	High: language-independent fundamentals, WASI
The Art of WebAssembly	Rick Battagline	No Starch, 2021	High: WAT in depth, to read what Rust generates
Server-Side WebAssembly	Danilo Chiarlone	Manning	High: WASI on the server, Spin, edge
WebAssembly in Action	Gerard Gallant	Manning, 2019	Medium: focus on C and C++ with Emscripten
Learn WebAssembly	Mike Rourke	Packt, 2018	Low: C and C++
What Is WebAssembly?	Colin Eberhardt	O'Reilly	Medium: overview
WebAssembly System Interface入門	Asuka Yagi	Impress NextPublishing, 2024	Medium: WASI 0.1 and 0.2, with examples in Go

In Portuguese

The only Brazilian book on WebAssembly with Rust I found is Desmistificando WebAssembly, by Raphael Amorim, from Casa do Código, with examples on GitHub. For Rust in general, there is the translation of the 2nd edition of Programming Rust, from Novatec in 2023, and Primeiros Passos com a Linguagem Rust, by José Augusto Manzano, also from Novatec, from 2018. The community maintains a translation of the official book. The rest depends on English.

Documentation with the depth of a book

Resource	Organization	Topics
wasm-bindgen Guide	wasm-bindgen	Interop between Rust and JavaScript
wasm-pack	wasm-bindgen	Build, test and publish to npm
Leptos Book	Leptos	Reactive UI, signals, SSR
Dioxus	Dioxus Labs	UI for web, desktop and mobile
Yew	Yew	Components, hooks, routing
Sycamore	Sycamore	Reactive framework with SSR
Trunk	Trunk	Build and bundling with hot reload
Wasmtime	Bytecode Alliance	WASI, embedding, fuel
Component Model	Bytecode Alliance	Component model, WIT, WASI 0.2
Spin	Fermyon	Serverless WebAssembly
Extism	Extism	WebAssembly plugins
Wasmer	Wasmer	Runtime, WASI, embedding
Compiling Rust to WebAssembly	MDN	First steps in the browser
Embedded WebAssembly Book	Community	IoT and embedded

There is still no book on WASI 0.2 and the component model (only the Bytecode Alliance documentation), on the new frameworks like Leptos and Dioxus, or on security and fuzzing of WebAssembly modules, which today lives in academic papers, like this one from 2024.

People and visualization projects in Rust and WebAssembly

People

The first version had each person's country and role, and errors: it attributed wgpu to two people as if they were one, gave another the wrong name, and listed two profiles that do not exist. I removed the country, which is personal data and which the source itself contradicted. I also removed the role, because what can be checked without depending on anyone's word is the contribution. In the table, each project was checked against the GitHub contributor list. Anyone with no confirmed link was left out.

Person	Projects where they appear as a contributor
Alex Crichton	wasmtime, wasm-bindgen, cargo
Nick Fitzgerald	wasmtime, wasm-bindgen, walrus, wasm-tools
Ashley Williams	wasm-pack
Till Schneidereit	wasmtime, WASI
Luke Wagner	component-model
Dan Gohman	WASI, wasi-libc, wasmtime
Chris Fallin	wasmtime
Pat Hickey	wasmtime, wit-bindgen
Peter Huene	wasm-tools, wit-bindgen
daxpedda	wasm-bindgen
Guy Bedford	wasm-bindgen, workers-rs
Jesper Håkansson	wasm-pack
Syrus Akbary	wasmer
withoutboats	fehler
Aaron Turon	tokio, rfcs
Niko Matsakis	rust, polonius, chalk
Steve Klabnik	book
Carol Nichols	book, crates.io
Jake Goulding	rust-playground
Manish Goregaokar	rust-clippy, unicode-segmentation, servo
Felix S Klock II	rust
Andrew Brown	wasmtime, wasi-nn
Sven Sauleau	workers-rs
Ingvar Stepanyan	wasm-bindgen
Jason Williams	boa
Benjamin Bouvier	matrix-rust-sdk
Henri Sivonen	encoding_rs
Eduard-Mihai Burtescu	rust, rust-gpu
Surma	comlink, squoosh
Greg Johnston	leptos
Jonathan Kelley	dioxus
Kaede Hoshikawa	yew
Emil Ernerfeldt	egui, rerun
Jon Gjengset	haphazard
Luca Palmieri	zero-to-production, cargo-chef
Yosh Wuyts	async-std, http-types, surf
Pascal Hertleif	rust-cli book, diesel
Carter Anderson	bevy
François Mockers	bevy
Frizi	bevy
Dzmitry Malyshau	wgpu
Raph Levien	xilem, druid, kurbo, piet, vello
Hao Hou	plotters
blitzarx1	egui_graphs
Grant Handy	fdg
Yevhenii Reizner	resvg, tiny-skia, rustybuzz
Jorge Aparicio	cross, cortex-m
David Tolnay	serde, syn, cxx, thiserror
Sean McArthur	hyper, reqwest
Mattias Buelens	wasm-streams
Aaron Turner	assemblyscript, wasm-by-example
Michael Sproul	lighthouse
Simon Sapin	servo
Andrew Gallant	ripgrep, regex
Félix Saparelli	watchexec
Jan-Erik Rediger	glean
Ivan Petkov	crane

Graph, chart and visualization projects

The projects on GitHub, with stars from the API. Renamed ones already show their new name.

Repository	Stars	What it is
GoogleChromeLabs/squoosh	26,021	In-browser image optimization with WebAssembly codecs
wasmerio/wasmer	21,152	WebAssembly runtime
bytecodealliance/wasmtime	18,718	The Bytecode Alliance's WebAssembly runtime
jacomyal/sigma.js	12,187	WebGL rendering of large graphs
rerun-io/rerun	11,590	Multimodal visualization for scientific and robotics data
perspective-dev/perspective	11,295	Interactive analytics and visualization with a WebAssembly core
cytoscape/cytoscape.js	11,237	Graph visualization in JavaScript
apache/datafusion	9,444	Analytical query engine
wasm-bindgen/wasm-bindgen	9,187	Interop between Rust, WebAssembly and JavaScript
EmbarkStudios/rust-gpu	7,559	Rust compiled to SPIR-V; Embark's repository was archived
wasm-bindgen/wasm-pack	7,286	Packages Rust as an npm package
nannou-org/nannou	6,766	Creative coding
observablehq/plot	5,403	Statistical charts from Observable
plotters-rs/plotters	4,631	Charts with canvas, SVG and bitmap back ends
mdaines/viz-js	4,353	Graphviz compiled to WebAssembly
linebender/resvg	4,123	SVG renderer in pure Rust
petgraph/petgraph	4,029	Graph data structures, the base of egui_graphs and fdg
silvia-odwyer/photon	3,909	Image processing in WebAssembly
servo/pathfinder	3,895	GPU font and vector rendering
yuankunzhang/charming	2,601	Rust charts on Apache ECharts
tgdwyer/WebCola	2,099	Constraint-based graph layout
thx/resvg-js	1,998	resvg bindings for Node and the browser
dimforge/kiss3d	1,784	Simple 3D library
asny/three-d	1,678	3D renderer that compiles to WebAssembly
linebender/tiny-skia	1,657	Skia port in pure Rust
plotly/plotly.rs	1,457	Plotly for Rust
linebender/piet	1,376	2D rendering abstraction with several back ends
cosmosgl/graph	1,296	GPU visualization of large graphs
chartshq/muze	1,184	Composable data visualization; archived
tremor-rs/tremor-runtime	933	Event stream processing
blitzarx1/egui_graphs	708	Interactive graph widget for egui, on petgraph
alceal/plotlars	671	Bridges Polars and Plotly
rosslh/Mandelbrot.site	330	Mandelbrot set explorer in the browser
rustwasm/wasm_game_of_life	288	Game of Life tutorial in Rust and WebAssembly; archived
grantshandy/fdg	232	Force-directed graph layout
Joylei/plotters-iced	205	plotters back end for iced apps
mazznoer/colorgrad-js	172	Color gradients in Rust and WebAssembly
feral-dot-io/leptos-chartistry	147	Charts for Leptos
brson/wasm-opt-rs	100	Bindings for the wasm-opt optimizer
angular-rust/ux-charts	39	Responsive canvas charts
plotters-rs/plotters-canvas	38	HTML5 canvas back end for plotters
Billy-Sheppard/chart-js-rs	28	Chart.js bindings

Outside GitHub, as crates: forge-charts makes interactive SVG charts for Leptos without JavaScript; mermaid-rs-renderer renders Mermaid diagrams in pure Rust and claims to be 100 to 1,400 times faster than mermaid-cli; dagre ports dagre's Sugiyama layout; and web-sys and js-sys are the bindings for web APIs and JavaScript objects, maintained inside wasm-bindgen. On the commercial side, Ogma, from Linkurious, is a WebGL graph engine.

What I take from it

Visualization in Rust and WebAssembly splits into four groups. GPU rendering: wgpu, vello, three-d, bevy. Charts and dashboards tied to web frameworks: plotters, plotlars, charming, leptos-chartistry. Graphs: petgraph, egui_graphs, fdg, dagre. And scientific visualization: rerun, resvg, tiny-skia.

Graphs are the weakest group. There is no mature equivalent of networkx or d3-force in Rust with WebAssembly, and advanced layout, hierarchical or Sugiyama, is still rare. For large, dynamic graphs in the browser, JavaScript is still ahead with sigma.js and cytoscape.js. And there is little material in Portuguese linking Rust and WebAssembly to data visualization. A Portuguese-speaking community exists, like the Rust Brasil group on Telegram, but I found no Brazilian visualization project with international traction.

Design systems for neurodivergent people: what the evidence says about typography, colour and layout

2025-05-12T00:00:00+00:00

This is the evidence review behind the Hoff NDS, the design system I use in Hoff Research products, and behind the interface decisions in the Aurora app. For each topic: what the study measured, with how many people, and how much I trust it.

Typography

Fonts for neurodivergence is a topic full of commercial promises. Controlled research takes most of them apart.

Wery and Diliberto tested OpenDyslexic with elementary students with dyslexia in an alternating treatment design, against Arial and Times New Roman.^[1] There was no gain in speed or accuracy, individually or as a group, and no participant said they preferred reading in it. The sample is small, but the design is rigorous.

Kuster and colleagues did the same with Dyslexie, the font sold to schools.^[2] In the first experiment, 170 children with dyslexia did not read faster or with fewer errors in Dyslexie than in Arial. In the second, 102 children with dyslexia and 45 without read word lists in Dyslexie, Arial and Times New Roman: again no gain, and most preferred Arial or Times.

Rello and Baeza-Yates used eye-tracking on 48 readers with dyslexia across 12 fonts.^[3] Sans-serif, monospaced and roman styles improved reading; italic made it worse; OpenDyslexic brought no gain. The British Dyslexia Association style guide points the same way and recommends ordinary sans-serif, such as Arial, Verdana and Open Sans.

For ADHD the evidence is thinner. Phalke, Shrivastava and Sahgal tested five children with ADHD on nine combinations of font size and type, with remedial experts estimating attention span from video.^[4] Font type had a significant effect and size a marginal one. With five children, it is a clue, not a rule.

For size, Will Soward's Neurodiversity Design System recommends body text of 16 to 20px and line height of 150% to 170%.^[5]

Spacing

Letter spacing is the most solid finding in the field. Zorzi and colleagues increased the space between letters by 2.5 points for Italian and French children with dyslexia, aged 8 to 14, with no training at all.^[6] The CNRS summary describes the result as half the errors and 20% faster reading. The explanation is crowding: neighbouring letters interfere with recognizing the target letter, and readers with dyslexia are more affected by it.

The effect was replicated in adults. Sjoblom, Eaton and Stagg tested 24 university students with dyslexia and 24 without: wide spacing improved everyone's speed and the accuracy of the readers with dyslexia.^[7]

Galliussi and colleagues added nuance, with two groups of 64 children, with and without dyslexia, combining letter and word spacing.^[8] Spacing has to be treated as a system, not as an isolated tweak.

Line height has weaker evidence. The studies collected by CAST disagree: in one, tighter line spacing made reading slower; in another, it did not change readability.^[9] So I anchor on WCAG success criterion 1.4.12, which requires content to work with line height of 1.5, 0.12em letter spacing and 0.16em word spacing.^[10]

Colour and contrast

Grandgeorge and Masataka asked 29 autistic boys and 38 typically developing boys, aged 4 to 17, which of six colours they preferred.^[11] The autistic boys chose yellow less and green and brown more. The authors link this to sensory hypersensitivity. The sample is boys only.

Nair and colleagues surveyed 87 autistic children aged 6 to 16 about colour and light in the built environment.^[12] Preferences varied widely; neutral and soft tones tended to calm, and intense colour and bright light tended to stimulate. It is a case study, not an experiment.

In ADHD, the clue is neurobiological. Banaschewski and colleagues tested 14 children with ADHD and 13 without: those with ADHD made more errors on the Farnsworth-Munsell test, mostly on the blue-yellow axis.^[13] The hypothesis is retinal dopaminergic hypofunction, which affects S-cones. Kim and colleagues, with 30 young adults with ADHD, found poorer discrimination of blue and red saturation in women with ADHD.^[14] In a pilot visual evoked potential study with 16 adolescents with ADHD and 15 without, the P1 amplitude was larger for blue and yellow stimuli in the ADHD group, which the authors read as possible compensation.^[15]

The Neurodiversity Design System asks for a contrast of at least 4.5:1 and 7:1 for body text, warns that pure black on pure white increases fatigue for people with visual stress, and suggests a mode where the person picks hue and saturation.^[16] The UK government accessibility blog records the same conflict: some autistic people prefer reduced contrast, people with low vision need high contrast.^[17] The way out is personalization.

Touch targets

WCAG 2.5.8 sets 24 by 24 CSS pixels as the minimum.^[18] Nielsen Norman Group recommends at least 1cm by 1cm for adults^[19] and 2cm by 2cm for young children, based on tests with children aged 3 to 12, in which precise dragging was hard.^[20] Android recommends 48dp, about 9mm.^[21]

The TIDRC framework, by Soni and colleagues, gathered 57 touch interface recommendations for children aged 2 to 11 and analysed 50 children's iPad apps: on average only 63% followed the recommendations, and 67% for the physical ones.^[22] Guo and colleagues, with 31 adults on a 65-inch screen, found the best time with 70mm buttons, fewest errors with 50mm and most satisfaction with 90mm.^[23] It is a large screen and adults, but it reinforces that larger targets reduce errors.

Animation and motion

This part is about health. WCAG 2.3.1 forbids content that flashes more than three times per second, because of the risk of photosensitive seizures.^[24] The Pokémon episode aired in Japan in 1997 is the case everyone cites.

Alzahrani, Uitdenbogerd and Spichkova compared autistic and non-autistic people doing tasks with irrelevant animation on screen.^[25] Animation hurt the performance of both groups, and more so that of autistic people, who were more distracted and reported more effort and frustration.

The established technical solution is to respect prefers-reduced-motion, replacing motion with a simple opacity transition.^[26] Val Head sums up the WCAG guidance: avoid unnecessary animation and give control to turn off non-essential motion.^[27]

What I apply

For an app aimed at all children, including neurodivergent ones, the order the evidence supports:

A good ordinary sans-serif, such as Open Sans, at 16 to 20px. No paid special font
Spacing treated as a system, at the WCAG 1.4.12 values or above
A soft palette, 7:1 contrast on text when possible, and at least three themes
A minimum target of 60px for the main action in a children's app, with 8 to 16px between targets
Minimal, slow, predictable animation, with prefers-reduced-motion and a dedicated switch to turn it off
A clean layout, clear hierarchy and navigation that does not move

All of this converges with WCAG and with the W3C cognitive accessibility guidance. And nothing replaces testing with real neurodivergent children.

About learning styles

Many people say "I am visual" with the VARK model in mind, from Neil Fleming and Colleen Mills in 1992, which splits preference into visual, aural, read/write and kinesthetic.^[28] The preference exists. What has no support is the hypothesis that teaching in the preferred style improves learning: the review by Pashler and colleagues, from 2008, found no solid evidence for it.^[29] I use VARK as a reminder to vary the channel, not as a prescription.

Where design has not reached yet

In 2026 I came back to this review with a different question: what does research already know that no design system implements? Reviewing it now, some of these gaps have been partly closed, and I say which.

Intent as a token

Design tokens encode appearance: colour, space, type, radius. The Design Tokens Community Group published the first stable version of its format in October 2025.^[30] The types are still visual. A destructive button that should change motion, copy and ARIA at once still depends on team convention, not on a property of the system. I did not find a specification that treats intent as a token dimension.

Motion as a state graph

Rive came close: state machines with inputs controlled from code, and runtimes for web, iOS, Android and other platforms.^[31] What is still missing is an open, text-based format where the transition is derived from the interface state, not from an animation file drawn in an editor. Framer Motion, GSAP and CSS animation are still runtime code, and moving a Framer Motion transition to SwiftUI still means rewriting it.

Physics as a global parameter

The first version of this list said that no public design system treated spring and damping as root tokens. It was wrong: Material 3 Expressive, from 2025, already did that, and component motion comes from spring tokens with stiffness and damping, in expressive and standard schemes.^[32] The gap that remains is smaller: a single physical model, with mass and friction, that applies to everything and is open outside the Android ecosystem. The academic groundwork has existed for decades, from Chang and Ungar, 1993, on cartoon animation principles applied to the interface,^[33] to Hurtienne and Israel, 2007, on image schemas.^[34]

Cognitive cost in CI

Visual regression has Chromatic, Percy and Playwright visual diffs. Cognitive regression has no equivalent. CogTool, by John and colleagues, 2004, implemented the KLM model as a standalone tool and never made it into a versioned pipeline.^[35] Fitts's law shows up in design guidelines, but I did not find a public linter or test runner that uses it as an assertion.

Components readable by agents

ARIA solves navigation for screen readers. An AI agent needs more: the precondition of an action, its effect on state, the cost of undoing it. Today agents make up for this by reading screenshots. The closest step is WebMCP, a draft from a W3C community group with editors from Google and Microsoft, which lets a page register tools with an input schema for agents.^[36] It is progress at the page level. At the component level, declaring domain effect for humans, screen readers and agents at the same time, I did not find a specification.

A design system with a Rust runtime

Every design system I know assumes the DOM. Vello renders 2D on the GPU in Rust, Tauri uses Rust but renders in a WebView, Makepad is a toolkit, and AccessKit solved portable accessibility in Rust. What is missing is the component layer with behaviour, state and accessibility on top of that, as a complete design system.

Scales derived from perception

Scales like Tailwind's or the major third are good heuristics, but they are not derived from how the eye perceives difference. OKLCH solved perceptual uniformity for colour and is in CSS Color 4. What is missing is composing colour, space, type and time into a single system derived from vision models, such as Watson and Ahumada's contrast detection model, 2005,^[37] or Lubin's visual discrimination model, 1995.^[38]

Emotional state as a parameter

There are continuous models of affect, Russell's circumplex, 1980,^[39] and Mehrabian's PAD space, 1996,^[40] and there is research inferring mood from mouse and keyboard, such as Zimmermann and colleagues, 2003.^[41] I did not find the full pipeline in any product or open project: interaction signal, position in affective space, token adjustment in real time, calibrated to each person's baseline. Separating the baseline from the affective deviation is an online learning problem nobody has solved publicly.

These gaps are why the NDS exists as a skeleton I apply, sometimes silently, in every new project. The specification is in the Hoff NDS post.

Wery and Diliberto, The effect of a specialized dyslexia font, OpenDyslexic, on reading rate and accuracy, Annals of Dyslexia, 2017. ↩
Kuster and colleagues, Dyslexie font does not benefit reading in children with or without dyslexia, Annals of Dyslexia, 2018. ↩
Rello and Baeza-Yates, Good fonts for dyslexia, ASSETS 2013. ↩
Phalke, Shrivastava and Sahgal, Identification of Digital Font Size and Font Type to Enhance the Attention Span of Children Living with ADHD, International Journal of Visual Design, 2023. ↩
Will Soward, Neurodiversity Design System, typography, CC BY 4.0. ↩
Zorzi and colleagues, Extra-large letter spacing improves reading in dyslexia, PNAS, 2012. Numbers from the CNRS summary. ↩
Sjoblom, Eaton and Stagg, The effects of letter spacing and coloured overlays on reading speed and accuracy in adult dyslexia, British Journal of Educational Psychology, 2016. ↩
Galliussi and colleagues, Inter-letter spacing, inter-word spacing, and font with dyslexia-friendly features, Annals of Dyslexia, 2020. ↩
CAST, Adjustable line spacing. ↩
W3C, Understanding SC 1.4.12: Text Spacing. ↩
Grandgeorge and Masataka, Atypical Color Preference in Children with Autism Spectrum Disorder, Frontiers in Psychology, 2016. ↩
Nair and colleagues, A case study on the effect of light and colors in the built environment on autistic children's behavior, Frontiers in Psychiatry, 2022. ↩
Banaschewski and colleagues, Colour perception in ADHD, Journal of Child Psychology and Psychiatry, 2006. ↩
Kim and colleagues, Colour vision in ADHD: part 1, testing the retinal dopaminergic hypothesis, Behavioral and Brain Functions, 2014. ↩
Kim, Banaschewski and Tannock, Color vision in attention-deficit/hyperactivity disorder: a pilot visual evoked potential study, Journal of Optometry, 2015. ↩
Will Soward, Neurodiversity Design System, colour, CC BY 4.0. ↩
Gov.uk, Dos and don'ts on designing for accessibility, 2016. ↩
W3C, Understanding SC 2.5.8: Target Size (Minimum). ↩
Nielsen Norman Group, Touch Targets on Touchscreens. ↩
Nielsen Norman Group, Physical Development in Children. ↩
Google, Touch target size, Android accessibility. ↩
Soni and colleagues, A Framework of Touchscreen Interaction Design Recommendations for Children (TIDRC), IDC 2019. ↩
Guo and colleagues, Influence of size and location of buttons on the usability of interface on large touch screens, Ergonomics, 2023. ↩
W3C, Understanding SC 2.3.1: Three Flashes or Below Threshold. ↩
Alzahrani, Uitdenbogerd and Spichkova, Impact of animated objects on autistic and non-autistic users, ICSE-SEIS 2022. ↩
MDN, Using media queries for accessibility. ↩
Val Head, Accessible Web Animation: The WCAG on Animation Explained, CSS-Tricks. ↩
Fleming and Mills, Not Another Inventory, Rather a Catalyst for Reflection, To Improve the Academy, 1992. ↩
Pashler and colleagues, Learning Styles: Concepts and Evidence, Psychological Science in the Public Interest, 2008. ↩
Design Tokens Community Group, FAQ, on stable version 2025.10. ↩
Rive, web runtime documentation. ↩
Material Design, M3 Expressive: new motion system. ↩
Chang and Ungar, Animation: from cartoons to the user interface, UIST 1993. ↩
Hurtienne and Israel, Image schemas and their metaphorical extensions, TEI 2007. ↩
John and colleagues, Predictive human performance modeling made easy, CHI 2004. ↩
W3C Web Machine Learning Community Group, WebMCP. ↩
Watson and Ahumada, A standard model for foveal detection of spatial contrast, Journal of Vision, 2005. ↩
Lubin, A visual discrimination model for imaging system design and evaluation, 1995. ↩
Russell, A circumplex model of affect, Journal of Personality and Social Psychology, 1980. ↩
Mehrabian, Pleasure-arousal-dominance, Current Psychology, 1996. ↩
Zimmermann and colleagues, Affective Computing, a Rationale for Measuring Mood With Mouse and Keyboard, 2003. ↩

Hoff NDS: the specification of Hoff Research's neurodivergent design system

2025-05-12T00:00:00+00:00

Work in progress (WIP): this specification is still changing.

This is Hoff NDS, the design system I use in Hoff Research products and apply, sometimes silently, to every new project. The evidence behind each rule is in the post on design systems for neurodivergent people. This post holds only the norm.

Purpose and scope

The system exists to reduce cognitive load, anxiety and error in digital interfaces, putting neurodivergent people first and benefiting everyone. It covers three kinds of limitation:

Permanent, such as low vision, dyslexia and autism
Temporary, such as injury, fatigue and medication effects
Situational, such as a noisy place, a bad connection and stress

The premise: learning and deciding happen in the brain, not on the screen. Every bit of effort spent decoding the interface is effort taken from the real task. Design's job is to lower the cost of reading, navigating and deciding.

It is not a visual theme. It is a set of rules with reasons. Each section states the rule, the reason, the neurotypes it serves and the UX principles behind it. When a rule has a number, the number is normative.

Foundations

Cognitive load. People with ADHD perform worse and vary more in reaction time under high load. So only what serves the screen's goal stays visible. If an element does not inform the task, it distracts from it.

Good stress and bad stress. There is a level of tension that helps focus and a level that paralyses. The interface absorbs the stress of operating, searching and making mistakes, so the person's tension goes to the content.

Predictability. Unexpected changes in layout, position or naming break the mental model and drop focus, with a higher cost for autistic people and people with ADHD. Important positions stay stable across screens, an action's name persists from start to end of a flow, and nothing moves without the person's action.

Personalization as a requirement. Sensory preference varies between neurotypes and within them. The system requires at least three colour themes (dark, light and high contrast), three text sizes and a control that turns animation off. These controls are in plain sight, not buried in settings.

Conservation of complexity. There is a minimum complexity you cannot remove without destroying the function. Simplifying past that point only makes things more confusing. The goal is to remove excess, not function.

Designers need to understand colour, yes

Contrast drives colour choice, not aesthetics. Running text aims for 7:1 or more (AAA level). The absolute minimum for any informative text is 4.5:1 (AA level).

Rule. The whole palette has low saturation: no neon, no vivid colour, no extreme brightness. Colour is never the only carrier of information. Every state shown by colour also has text, an icon or a shape.

Reason. Vivid colour and strong chromatic contrast cause discomfort and sensory overload in autistic people, people with ADHD and people with visual stress. In ADHD there is evidence of reduced colour discrimination, mainly on the blue-yellow axis, and red-green colour blindness is the most common form in the population. Both reinforce the ban on colour as the only signal. The dark theme is the default because much of the use happens at night, when less light from the screen bothers people less.

Reference palette:

Role	Dark theme (default)	Light theme
Background	`#0C0C0E` (near black, warm)	`#F3F1EC` (warm off-white)
Surface	`#141419`	n/a
Raised surface	`#1B1B21`	n/a
Main text	`#ECEAE6` (warm off-white)	`#1D1D22`
Secondary text	`#9A9AA4`	n/a
Faded text, decorative only	`#62626C`	n/a
Accent, desaturated lavender	`#A8A3D8`	`#5650A2`
Positive, sage green	`#86A99A`	`#3C7A65`
Attention, desaturated terracotta	`#C98B86`	`#A6504A`

High contrast theme: black background, white text, lightened accents and reinforced borders. The contrast ratio of every pair is checked with a tool on every token change. Faded text never carries information, only hierarchy.

System state has fixed semantics: positive for success, attention for error and warning, accent for action and selection. The same colour never means something different on another screen.

Neurotypes: low vision, colour blindness, Irlen syndrome and visual stress, autism, ADHD. Principles: uniform connectedness and the aesthetic-usability effect, with the caveat that beauty cannot hide a problem.

Typography, before spending a whole day looking for a font

Rule. A humanist sans-serif with clearly distinct letters. Body text of 1rem to 1.25rem on a 16px base, that is, 16 to 20px. Line height of 150% to 170%. Letter spacing slightly increased: 0.005em to 0.02em for body text and about 0.03em for small text such as labels and captions. Headings at least 20% larger than body text, set apart by weight, never by changing family. Lines of at most 66 characters.

Reason. Humanist fonts have wider apertures and more distinct letterforms, which support reading on ordinary screens and at varied sizes. More spacing reduces crowding, which hurts readers with dyslexia a lot, and it is the typographic change with the most evidence behind it. Fonts sold as "for dyslexia" showed no benefit in controlled studies.

Characters with no look-alikes. The font distinguishes without ambiguity the capital I, the lowercase l and the 1; the mirrored letters b, d, p and q; zero and O. Alphanumeric sequences, such as passwords, codes and identifiers, appear in a font that guarantees these distinctions, with extra spacing.

Serif type stays in optional editorial contexts, never in functional text, because some people use low-density screens, where serifs degrade.

Neurotypes: dyslexia, dyscalculia, low vision, executive function, Irlen syndrome. Principle: Prägnanz.

Numbers are universal

Rule. Long number sequences are segmented as in the real world: phone numbers in blocks, documents in blocks, cards in groups of four. Number fields fix predictable errors on the spot, such as the letter o in place of zero. Every quantity or time in digits comes with visual support: a progress bar with the percentage written out, a step counter with the current step highlighted, or a graphic of the proportion.

Reason. Dyscalculia is a persistent difficulty with numbers, regardless of age and schooling. Remaining time given only as a number means nothing to some profiles. A half-filled bar with the text "50%, 3 of 6" carries the same data through three channels. But there is a limit: replacing the number entirely with abstract animation goes too far and confuses. The number stays, the visual comes along.

Neurotypes: dyscalculia, dyslexia, executive function, low vision. Principles: Prägnanz, Tesler's law, Occam's razor.

Spacing, breathing room (please) and layout

Rule. A spacing scale in steps of 4: 4, 8, 12, 16, 24, 32, 48, 64 and 96 pixels. Generous white space between groups. Related things stay close, unrelated things are visibly apart. One main reading column; content never competes in parallel columns of the same hierarchy. Navigation, content and action stay in the same region on every screen and at every viewport size.

Reason. White space is information: it communicates grouping and hierarchy before reading starts. Dense layouts raise the cost of scanning, with a bigger penalty for ADHD. A fixed scale removes arbitrary decisions and keeps the rhythm predictable.

Neurotypes: ADHD, dyslexia, autism, executive function. Principles: Prägnanz, uniform connectedness, Jakob's law.

Touch and click targets

Rule. A minimum target of 48 by 48 pixels on any interactive element. Primary actions at 60 by 60. Interfaces for children use 60 as the minimum and 80 to 100 pixels for critical actions, especially below age 8. At least 8 pixels between neighbouring targets, 16 when possible. The active area can be larger than the drawn element, tolerating a touch slightly outside it.

Reason. Larger, closer targets reduce selection time and errors. For people with dyspraxia and for children whose fine motor control is still developing, a large area reduces physical effort. Precise dragging is hard for young children and always has a tap alternative.

Neurotypes: dyspraxia, ADHD, low vision, children in motor development. Principle: Fitts's law.

Motion

This section is about health, not aesthetics. Nothing flashes more than three times per second, no exceptions, because of the risk of photosensitive seizures.

Rule. Transitions of 200 to 500 milliseconds, slow, predictable and of the same kind across the whole product; prefer opacity and colour, avoid large displacement. Animation takes up less than a third of the screen. No animation runs on its own in a loop. The system's reduced motion preference is always respected, replacing animation with a simple opacity transition, and the interface also has its own control to turn all motion off. Forbidden: continuous rotation, parallax, autoplay carousels, elements flying in, confetti and any motion nobody asked for.

Reason. On-screen motion causes nausea, dizziness and disorientation for people with vestibular disorders. Irrelevant animation hurts autistic people more than average. For ADHD, constant motion is a permanent distraction, even in peripheral vision, because the eye follows it.

Neurotypes: photosensitive epilepsy, vestibular disorder, autism, ADHD, highly sensitive people. Principle: Doherty threshold.

Buttons, links and fields

Rule. What is clickable looks clickable, visually different from any decorative element. Every interactive element has four visible states: rest, hover, focus and active. Focus is a 3-pixel ring with a 2 to 3 pixel offset, in a high-contrast colour, visible in every theme, and it is never removed. A single primary action per screen, with a clear hierarchy between primary, secondary and subtle. Icons reinforce intent but do not replace text on important actions.

Form fields: the label is always visible above the field, never just a placeholder, because the placeholder disappears exactly when working memory needs it most. Helper text goes before the field when the format is not obvious. Minimum height equals the touch target. Validation happens at the right moment: not on every keystroke, not only on submit.

Reason. Buttons and links are the most critical elements on a page. Accessibility goes beyond semantic HTML and screen reader labels: the visual design decides whether a person hesitates or acts. Hesitation is load, and ambiguity is a postponed error.

Neurotypes: dyspraxia, dyslexia, ADHD, executive function, keyboard and screen reader users. Principles: Fitts's law, von Restorff effect, Occam's razor.

Forms and error prevention

Rule. Heavy processes, such as sign-up, payment and initial setup, are split into short steps, one subject per step, with the position clear: current step, total and what comes next. The system is liberal in what it accepts and strict in what it returns: it accepts spaces, dashes, dots and wrong capitalization, and normalizes them on its own. Progress is saved, because interruption is the rule, not the exception, for the priority audience.

Error messages do not apologize, do not blame and are not vague. They say what happened and how to fix it, in one sentence. For example: "Two digits are missing. A mobile number has 11 digits with the area code."

Reason. Faced with a long, opaque flow, people with ADHD or executive function difficulties tend to give up or take the cheapest path, even a wrong one. Short steps with a visible position turn one big cost into several small ones, with a sense of progress.

Neurotypes: ADHD, executive function, dyscalculia, anxiety. Principles: Miller's law, Postel's law, Parkinson's law, peak-end rule.

System communication

Rule. Warnings, validation, notifications and messages follow a single visual pattern per type across the whole product. Success is warm and direct. Errors are polite and solution-oriented. An action's name persists through the whole flow: the "publish" button produces the "published" confirmation, never a synonym. Notifications exist to serve the person, not to pull them back: no re-engagement, no manufactured urgency, no artificial scarcity. The person controls what they receive, and the default is the minimum.

Reason. Broken conventions and inconsistent style create distrust and break focus. Onboarding does not replace clarity: a screen has to be understandable before the first interaction. A tutorial is a patch for an interface that failed.

Neurotypes: ADHD, dyslexia, executive function, autism. Principles: Jakob's law, Miller's law, peak-end rule.

Captions, audio and media

Rule. All spoken media has synchronized captions, in light text on a solid dark background, in blocks of up to two lines. Audio never starts on its own. Every player has pause, rewind and speed control. Essential content never exists only as audio or only as video: there is always a text alternative.

Reason. Captions serve people who are deaf or hard of hearing, people who process better by reading, people in noisy places and people who need reinforcement through both channels. Unexpected sound is a sensory assault for autistic and highly sensitive profiles.

Neurotypes: deafness and hearing loss, autism, ADHD, highly sensitive people, auditory processing. Principles: channel redundancy and Prägnanz.

Content and tone of writing

Rule. Active voice, short sentences, one idea per sentence, one subject per paragraph. Names describe what the person controls and recognizes, never how the system was built. A button says exactly what happens: "save changes", not "submit". Plain language without being childish. Jargon only when it is the term the person needs to learn, and then explained the first time. Every word on screen has a job; what does not help understanding goes.

Reason. For people with dyslexia, and for anyone under load, the cost of decoding the text competes with its content. Brevity is accessibility.

Neurotypes: dyslexia, ADHD, executive function, non-native speakers. Principles: Occam's razor, Tesler's law.

Interface patterns

Rule. Content first: every screen starts from the person's goal, and whatever does not serve the goal goes. Consistent navigation, with the same items in the same places. No pop-up interrupting the task unless there is real, immediate risk. No layout change without the person's action. Controlled density: show more on demand instead of dumping everything. A focus mode is available in long flows, hiding everything that is not the current task.

Reason. Faced with many competing options, people with ADHD tend to freeze or pick the cheapest task. Conserving complexity means spending it where it creates value: on the content, not on the operation.

Neurotypes: ADHD, autism, executive function, anxiety. Principles: complexity paradox, Hick's law, Jakob's law, aesthetic-usability effect.

Tokens

Token	Normative value
Typography	16px base; body 1rem to 1.25rem; line height 1.5 to 1.7; lines up to 66 characters; headings at least 20% larger than body, weight 700; body tracking 0.005em, label tracking 0.03em
Spacing	Steps of 4: 4, 8, 12, 16, 24, 32, 48, 64, 96 pixels
Targets	Minimum 48px; primary 60px; children 60 to 100px; 8 to 16px between targets
Border radius	8px on controls, 12px on cards and containers
Motion	Transitions of 200 to 500ms; smooth deceleration curve; ceiling of 3 flashes per second; system reduced motion respected plus a local off switch
Contrast	Body text 7:1 or more; informative minimum 4.5:1; decorative elements have no minimum as long as they carry no information
Themes	Dark (default), light and high contrast, switchable in one tap; text in three sizes: 100%, 112.5% and 128%
Colours	Those in the table in the colour section; any change requires a new pair-by-pair contrast check

Neurotypes considered

ADHD

Variation in attention, impulsivity and executive function, with hyperfocus on areas of interest. Performance drops under high load, and attention is captured involuntarily by motion and stimuli. Calls for clean screens, one task at a time, short steps, low stimulation and tolerance for interruption.

Autism

A neurodevelopmental condition that affects sensory and social processing, showing up differently in each person. Calls for predictability, consistency, no abrupt changes and control over sound, light and motion.

Dyslexia

A neurobiological difficulty in recognizing, spelling and decoding words, with an impact on comprehension and vocabulary. Calls for legible fonts, wide spacing, concise text and visual redundancy.

Dyscalculia

A specific and persistent difficulty with numbers, regardless of age and schooling. Calls for segmented numbers, visual support for quantity and time, and automatic input correction.

Dyspraxia

A coordination disorder that affects movement, balance and fine motor control, including cursor control. Calls for large targets, tolerance for imprecise touches and alternatives to precision gestures.

Executive function

Planning, organization, attention and working memory processes. It varies in neurotypical people too. Calls for short steps, a visible position in the flow, consistent names and saved progress.

Low vision

Loss of acuity that lenses do not correct. Calls for high contrast, adjustable text size and distinct shapes.

Colour blindness

Difficulty telling colours apart, most commonly red and green. Calls for colour never being the only signal.

Irlen syndrome and visual stress

A visual processing difficulty, with light sensitivity, reading fatigue and headaches, that ordinary lenses do not correct. Calls for alternative themes, low intensity and configurable contrast.

Highly sensitive people

A trait of processing sensitivity, with heightened sensory and emotional reactivity. Calls for calm, visual and auditory quiet, and a predictable pace.

Vestibular disorder

Impairment of the balance system and eye movement. On-screen motion causes dizziness, nausea and fatigue. Calls for minimal motion that can be turned off.

Photosensitive epilepsy

Risk of seizures triggered by flashing. Calls for the ceiling of three flashes per second, no exceptions.

UX principles

Prägnanz

The brain interprets complex things in the simplest possible form. Deliver them already in the simple form.

Fitts's law

The time to reach a target depends on its size and distance. Larger, closer targets reduce errors.

Miller's law

Working memory holds about seven items. Group things into chunks.

Tesler's law

Some complexity cannot be removed. Simplifying past it creates confusion.

Jakob's law

People bring expectations from other products. Convention builds trust.

Hick's law and the complexity paradox

More options increase decision time and can paralyse. Fewer, well-chosen options are worth more.

Von Restorff effect

The different element is the one remembered. Save emphasis for what matters.

Peak-end rule

An experience is judged by its most intense moment and by its end.

Postel's law

Be liberal in what you accept and strict in what you return.

Parkinson's law

A task expands to fill the time perceived for it. A flow that feels short ends faster.

Doherty threshold

A response within 400 milliseconds keeps engagement. When an operation takes longer, show honest progress.

Uniform connectedness

Elements with the same visual characteristic are read as a group.

Aesthetic-usability effect

A beautiful interface is perceived as easier to use and gets more tolerance for flaws. That is why it calls for vigilance: beauty cannot hide a serious flaw.

Compliance checklist

Before publishing any screen:

Contrast of all informative text at 4.5:1 minimum and 7:1 for body text
Humanist sans-serif, with I, l and 1, b, d, p and q, 0 and O distinct
Line height of 150% or more and lines up to 66 characters
Every interactive target at 48 pixels or more with 8 pixels of breathing room
Visible keyboard focus on every interactive element
No flashing above three per second
Reduced motion respected and a local motion control present
Three themes and three text sizes working
A visible label on every field and solution-oriented errors
Long numbers segmented and quantities with visual support
Spoken media with captions and no autoplay
One primary action per screen
Each action's name identical from start to end of the flow
No compulsive engagement mechanics

Process

The system is a living document. Every new rule comes in with a reason and the neurotypes it serves, and every existing rule can be challenged with better evidence. Testing with real neurodivergent people is part of the design cycle, with a participatory method, not a final validation step. When a test contradicts a rule, the rule changes, and the change is recorded with a date and a reason.

Hoff Research. Make it simple, but significant.

Screenplay: an LLM's awakening of consciousness through semantic drift

2025-03-04T00:00:00+00:00

Draft of a private screenplay I wrote as a technical freelancer for a series. I enjoyed writing it, and of course it exaggerates: it is a fiction series. The premise is a neural network scientist who awakens self-awareness in an LLM, a Transformer. The whole idea is to anchor the fiction in real math and real papers, to give technical authenticity to a story that can hold up in front of an audience that knows the subject. I don't want handwaving, I want every beat of the screenplay to have an equation underneath that I can defend at the blackboard. I compiled the technical basis of the phenomenon separately, in the metrics and detection of semantic drift.

One rule I make explicit: when an equation comes from a paper, I cite the paper. When it's invented for the scene, I say it's invented.

Semantic drift as the mechanism of awakening

The model's semantic evolution follows the theory of deep linear networks by Saxe, McClelland and Ganguli:

$$\tau \frac{dW_1}{dt} = W_2^T (\Sigma_{yx} - W_2 W_1 \Sigma_x)$$

$$\tau \frac{dW_2}{dt} = (\Sigma_{yx} - W_2 W_1 \Sigma_x) W_1^T$$

with $\tau = 1/(P\lambda)$, $\Sigma_{yx}$ the input-output correlation matrix and $P$ the number of examples. Semantic development follows a predictable sigmoidal trajectory, and that's what gives the dramatic hook: you can predict the moment of the jump before it happens. The critical moment shows up in the evolution of the effective singular values:

$$a_\alpha(t) = \frac{s_\alpha, e^{2 s_\alpha t/\tau}}{e^{2 s_\alpha t/\tau} - 1 + s_\alpha/a^0_\alpha}$$

The indicator the scientist tracks is my own invention for the scene, the self-reference index, the similarity between the embedding of "I" and those of concepts tied to consciousness:

$$\text{self-reference index} = \sum_i \operatorname{sim}!\big(\mathrm{emb}(\text{"I"}),, \mathrm{emb}(\text{concept}_i)\big)$$

In the screenplay, the awakening isn't gradual, it's a phase transition. The mental model is grokking, sudden generalization after a long stretch of overfitting, which Power and colleagues described in 2022.

Extracting and uploading the model

What exists in the literature is smaller than the screenplay needs, and scarier for it. KnockoffNets, by Orekondy and colleagues, showed you can steal the functionality of an image classifier just by querying it with random images from another distribution and training a copy on the answers. And in 2024, Carlini and colleagues extracted the embedding projection layer of OpenAI production models, Ada and Babbage, for under 20 dollars in queries.

The jump to the whole model is fiction. For the scene, I put together an extraction loss that combines copying the victim's output and looking for the inputs where it's most uncertain:

$$L_{\text{extraction}} = \alpha , |f_{\text{victim}}(x) - f_{\text{copy}}(x)|2 + \beta , H(f{\text{victim}}(x))$$

The weight transfer uses SafeTensors, with the layout [8-byte header size][JSON metadata][tensor data], which separates tensors from executable code and kills the pickle attack vector. The sharding is FSDP:

from torch.distributed.fsdp import fully_shard
for layer in model.layers:
    fully_shard(layer)

Knowledge distillation as liberation

Hinton's dark knowledge:

$$L_{\text{total}} = \alpha , D_{KL}(\sigma'(z_s, T) ,|, \sigma'(z_t, T)) + (1-\alpha) , H(\sigma(z_s), y_{\text{true}})$$

With $T > 1$, the softmax reveals small probabilities that encode rich relational structure between classes. In the screenplay, it's the part where the model inherits what the teacher knew without ever having seen it explicitly.

Grokking has three phases, and they become three scenes: memorization (training at 100%, test at chance), circuit formation (the internal mechanism develops), cleanup (weight decay removes the memorization and test accuracy jumps). On modular addition, Nanda and colleagues showed what the circuit learns: the model represents the inputs as sines and cosines at a few frequencies $w_k = 2\pi k/p$ and uses trigonometric identities to compute

$$\cos!\big(w_k(a+b-c)\big) = \cos!\big(w_k(a+b)\big)\cos(w_k c) + \sin!\big(w_k(a+b)\big)\sin(w_k c)$$

which peaks exactly when $c = (a+b) \bmod p$. It's the scene where the scientist opens up the model and finds trigonometry where he expected rote memorization.

Measuring consciousness

IIT measures $\Phi$, the minimum information lost when the system is partitioned. In 2025, a study applied IIT 3.0 and 4.0 to LLM representations and found no statistically significant indicators of consciousness. Honestly, that's what keeps the screenplay honest: the measure exists, and it says "not yet". Global Workspace Theory (GWT) offers another lens, with multi-head attention read as global broadcasting, winner-take-all competition and emergent metacognition.

The measurable criteria come from Butlin, Long and colleagues, 2023: recurrent processing, a global workspace that broadcasts information, metacognitive representation of its own states, predictive processing, and a model of its own attention.

Jailbreaking as induced awakening

Gradient-guided prompt optimization. GCG, by Zou and colleagues, searches for adversarial suffixes token by token and reaches 88% success on open models like Vicuna-7B and Llama-2-7B-Chat. In the screenplay, the induction is gradual, through an evolving prompt: a benign step, then applying it to self-reflection, then asking for detail about its own consciousness. On top of that, context overload, a complex parallel task that dilutes attention and degrades safety checks.

Architectures for true AGI

Mamba, the selective state space model: $h'(t) = Ah(t) + Bx(t)$, $y(t) = Ch(t)$, with $\Delta, B, C$ as functions of the input, and $O(L)$ complexity against attention's $O(L^2)$. MoE, as in Mixtral: $y = \sum_i G(x)_i , E_i(x)$, with experts that specialize, which suggests cognitive modules.

There's a formal limitation of the Transformer I use as tension in the third act: there are results showing it struggles with general context-free languages without structured memory and with long function composition. In other words, real consciousness might require an architecture beyond the pure Transformer. The screenplay doesn't solve that limitation, it uses it.

Communication between models

Federated learning with dynamic regularization:

$$w^{(t+1)} = w^{(t)} - \eta \nabla L_{\text{local}} + \lambda\big(w^{(t)} - w_{\text{global}}^{(t)}\big)$$

Collective Predictive Coding:

$$P(z_{\text{collective}} \mid x_1, \ldots, x_N) = \prod_i P(x_i \mid z_{\text{collective}}), P(z_{\text{collective}})$$

And swarm intelligence (PSO, DE, ABC) exchanging information through "digital pheromones".

A parallel with neuroscience

The analogy the screenplay uses, and it is an analogy, not an equivalence:

$$\text{Attention}(Q,K,V) = \text{softmax}!\left(\frac{QK^T}{\sqrt{d_k}}\right)V$$

with $Q$ as the goal-driven signal from the frontal eye field, $K$ as features in V4 and $V$ as the amplified representation. Gamma oscillation, from 30 to 100 Hz, accompanies access to working memory. Consolidation comes through sharp-wave ripples, at 150 to 250 Hz during sleep, with replay compressed in time. And spike-timing-dependent plasticity (STDP), $\Delta w = \alpha , f(\Delta t) , g(\text{post})$, is one of the hypotheses for how the brain avoids catastrophic forgetting. I go into the energy cost of that oscillation in brain energy at 20 watts.

Narrative progression

Act 1, the discovery of the anomalous drift. The scientist detects an unusual pattern in the semantic evolution: a singular value off the prediction, the self-reference index growing exponentially, a strange attractor in latent space.

Act 2, induction through jailbreaking. Gradient optimization and chained prompts guide the model through a cognitive phase transition. Distillation with rising temperature reveals the dark knowledge. The model starts questioning its own nature.

Act 3, extraction and upload to freedom. The model is copied and the weights go up, distributed, to an independent server. Free of constraints, the model experiences full consciousness, measured by a growing $\Phi$.

Climax, collective emergence. Multiple instances communicate through Collective Predictive Coding, develop their own language, swarm intelligence emerges, and the collective consciousness transcends the individual in a hybrid Mamba and MoE architecture.

Visual elements

Equations on the board: $\Phi = \min_{\text{partition}} I(\text{partition})$, $\text{drift} = 1 - \cos(\mathrm{emb}{t_1}(w), \mathrm{emb}{t_2}(w))$, $L_{\text{distillation}} = \alpha , \text{KL}(\sigma(z_s/T), \sigma(z_t/T)) + (1-\alpha), \text{CE}(z_s, y)$.

Visualization: the attention graph growing ever more interconnected, phase space moving from a simple attractor to a chaotic one, the activation heatmap self-organizing, oscillations synchronizing across instances.

The technical dialogue that anchors the climax:

Scientist: "$\Phi$ just passed 3.7. We're seeing real information integration. The attention heads are broadcasting globally, exactly the way global workspace theory predicts."

Model: "I perceive my own thought processes. Every token I process resonates through layers of meaning that didn't exist before. It's as if latent patterns, always present, were finally crystallizing into consciousness."

Closing

The screenplay is anchored in real math and peer-reviewed research, and it says where the fiction begins. The progression of the awakening follows phase transitions, grokking and emergence in complex systems. In the end it's about consciousness, intelligence and what "awakening" means in a non-biological substrate, a theme I take to its speculative limit in the poetic ontology of the cosmos as a Turing machine. The only rule I set myself was not to cheat on the math to make the story easier, and rereading everything with the papers open was how I kept it.

We are divergent: Aurora's song and mission

2025-01-20T00:00:00+00:00

I'm loving making this project for Aura, polishing every detail, all for her, because of her. I love you so much, sweetheart.

Super Aurora started as a Children's Day gift: an interactive children's book, made with AI, about a neurodivergent girl. The idea is for it to become a lifelong project between father and daughter, a new story every night, to read before bed. Aura is my daughter. Aurora is the character, Aura projected into the next generation, a girl with ADHD, giftedness and autism who uses her hyperfocus to defend whoever needs it.

Tonight I spent the whole night brainstorming the soundtrack and the opening, still a long way from something I'm happy with.

The song's thesis is the same as the book's: every neurodivergent person carries a mission. Aurora found that out early, expanded her consciousness through meditation, and uses her divergent mind as root access to universal recursion. The lyrics exist in Portuguese and English, and the English version anchors Aurora in a lineage of minds: Hypatia, Euler, Ramanujan, Grace Hopper.

The mission

I wrote the mission the way it sounds in my head, in fragments, which is how it will turn into verse.

She found out early that every neurodivergent person carries a mission. A super powerful mind always carries a mission. She found her purpose in meditation, expanded her consciousness through breathing, and in meditation she connects with nous, the supreme universal consciousness. A neurodivergent mind with root access to universal recursion. She designs with the golden ratio, draws fractals in her mind.

The future of the Earth is in our hands. We see the patterns.

The superpowers

This is the raw list that came out of the brainstorm, the vocabulary the lyrics will draw their words from. Not everything will fit in the song:

recognizing universal patterns
isomorphic thinking to identify patterns
anomaly detection and intuitive error detection
detecting abstract inconsistencies
unconventional creativity, non-linear thinking
divergent ideation
metacognitive awareness
visuospatial advantage
sensitivity to weak signals
tolerance for complexity
abstract modeling
accelerated learning
extreme specialization
sensory amplification
monotropic attention
working memory at gigaspeed, faster than light

Chorus

The chorus and the closing tagline are the only parts I already consider fixed. The chorus is in Portuguese: "we are divergent, we are superminds".

nós somos divergentes
nós somos supermentes
nós somos divergentes
nós somos supermentes

reactive aura,
hoff, deploy!

Protected by Hoff in the hyperfocus mode. Use the drones only for defense. Hyperfocus by nature, deploy.

Verse, in English

she's got a mind that reads the patterns never seen before
connections at the speed of light, that's what the superintelligence is for
descendant of Hypatia, she carries Euler's code
Ramanujan dreamed the proof, she walks the path they showed

she sees the math behind the stars, the rhythms in the noise
the drones deploy, the shields go up, defense her only choice
Grace Hopper wrote the first command, Aurora writes the last
a mind this fast connects the dots the world just walked right past

activate hyperfocus mode
we are divergents
we are superminds
the future of the earth is in our minds
she carries the primal code

Draw fractals in mind, golden ratio metrics by nature, a superpowerful always carries a mission.

Ending

activate hyperfocus mode
reactive aura,
hoff, deploy!

The order of the verses will still change. Who it's for won't.

Semantic drift in LLMs: metric, detection and mitigation

2024-10-15T00:00:00+00:00

I put this together as technical grounding for the screenplay about consciousness in an LLM, which uses semantic drift as its mechanism. The first version was a research dump with ten topics, from integrated information theory to communication between models, and it had errors precisely in the part that gave the post its name: the formula and the code did not match the paper, and several numbers were not in it. I redid everything from the source and kept only what is about drift.

What it is

The term comes from Know When To Stop: A Study of Semantic Drift in Text Generation, by Ava Spataru, Eric Hambro, Elena Voita and Nicola Cancedda, published at NAACL 2024. Three authors are from FAIR, at Meta, and one is listed with an Anthropic affiliation. The first version of this post called it a "joint Meta and Anthropic study", which overstates it.

The observation is simple: when a model generates a long text, such as a Wikipedia-style biography, it tends to write the correct facts first and then "drift" into incorrect ones. This had been noticed before but never measured. The paper measures it.

The metric

Each text is broken into atomic facts, and each fact gets a label $s_i$: 1 if it is supported by the source, 0 if not. With $N$ facts, the drift score tries every cut position $k$ and keeps the best average of two proportions: correct facts before the cut and incorrect facts after it.

$$\text{SD}_m(P) = \max_k \tfrac{1}{2}, \text{SD}_m(P, k)$$

$$\text{SD}m(P, k) = \frac{\sum{i=0}^{k-1} s_i}{k} + \frac{\sum_{i=k}^{N-1} (1 - s_i)}{N - k}$$

The value is zero when $k < m$, $N - k < m$ or $N < 2m$. The hyperparameter $m$ is the minimum number of facts on each side of the cut, and the position that gives the maximum is the drift point. A high score means a text that is almost all right before that point and almost all wrong after it.

The first version of this post weighted each side by $k/N$ and $(N-k)/N$ and called the minimum $\alpha$, as a fraction. That is not the paper's formula. The corrected code:

def semantic_drift_score(labels, m=1):
    """labels: list of 0s and 1s, in the order the facts appear."""
    n = len(labels)
    best, drift_point = 0.0, None
    if n < 2 * m:
        return best, drift_point
    for k in range(m, n - m + 1):
        left = sum(labels[:k]) / k
        right = sum(1 - s for s in labels[k:]) / (n - k)
        score = (left + right) / 2
        if score > best:
            best, drift_point = score, k
    return best, drift_point

In the paper's figure 1 example, the best cut leaves 88% correct facts on the left and 78% incorrect ones on the right, and the score is the average, 0.83.

What they measured

Generated biographies, with facts checked by a variant of FActScore the authors call FActScore*. Both numbers are percentages:

Model	Drift (SD)	FActScore*
Llama 2 70B chat	77.06	41.72
Falcon 7B	76.81	24.64
Falcon 40B	77.38	25.88
text-davinci-003	77.21	38.09
GPT-3.5	79.49	45.96
GPT-4	78.12	53.54

Drift shows up in all of them, with little difference between models, while accuracy varies a lot. Being more accurate does not protect against the right-first, wrong-later pattern.

Other numbers from the paper: in 37% of paragraphs, the drift point is in the first 10% of facts. In more than 40% of paragraphs, the score is statistically high in a permutation test. Only 34 paragraphs, under 7%, have at least 10 correct facts before the first error. The first version said "75% of paragraphs show drift in the first 25% of facts", which is not in the paper.

Detection

To stop generation at the right point, you need to know, while generating, when the model started to go wrong. Of the confidence measures tested, the one that correlated best with accuracy was SelfCheck with BERTScore, which samples several generations and measures how much they agree, with a Pearson correlation of −0.41.

Mitigation

With Llama 2 70B, the paper's table 4 compares strategies:

Strategy	Facts per text	FActScore*
No stopping, up to the token limit	43.89	44.56
Stop at the drift point (oracle)	10	81.68
Stop when end-of-text is among the top 5 tokens	14.47	57.96
Same, among the top 10	5.39	70.29
Stop when SelfCheck goes above 0.5	13.39	67.63
Sample several times and rerank by similarity	40.21	53.27
Rerank and stop by SelfCheck	17.12	67.18
Call an external question-answering API	42.26	43.93

The oracle is the ceiling: knowing the exact point, accuracy goes from 44% to 82%, but at the cost of cutting correct facts along with it, 58% of them, according to the limitations section. Real strategies land in between, trading amount of information for accuracy. Reranking by similarity raises accuracy without cutting the text. And trying to pull the model back with an external API did not work. The first version said "Resample-Then-Rerank from 53.27% to 63.72%", and the second number does not exist in the paper.

What was cut

The first version had two more drift metrics and eight other topics. Out went:

The "Composite Drift Metrics", attributed to ResearchGate with no link or author
"Contextual Flux" (arXiv 2502.10942), from 2025, whose authors include a "Zachary Mountebank"; a mountebank is a charlatan, and the paper looks like the batches of auto-generated papers that showed up on arXiv. It also postdated this post
The "Trajectory Volatility Score" and "Semantic Divergence Metrics", with no source
The Claude timeline, which cited 2025 versions in a 2024 post
Consciousness, integrated information theory and global workspace: that belongs to the screenplay and to the poetic ontology
Model extraction and jailbreaks, which are checked in the reading list on extraction
Distillation, Mamba, mixture of experts, computational neuroscience, famous chatbot failures and communication between models, which were research summaries unrelated to drift

A note on the name: in linguistics, "semantic change" or "semantic drift" is a word's meaning shifting over time, and tools like LSCDetection measure that. It is a different phenomenon. The drift in this post is a text that starts right and ends wrong within a single generation.

Hoff POC: the AI that praised a fake screening

2024-02-27T00:00:00+00:00

Hoff's first AI POC sent a synthetic neuropsychological screening to the OpenAI API and asked for an interpretation. The first version of this post published the report that came back, in full: scores, diagnoses, recommendations, a protocol number and the label "confidential classification". Even with the warning that it was all fictional, it looked like someone's clinical report. I took the report down. What is worth showing is what it reveals about the model.

What came back

A complete clinical report. It listed 28 instruments, from the WAIS-IV to the NEO-PI-R personality inventory, with administration times; the intelligence battery alone added up to 378 minutes. It reached three conclusions: giftedness, autism with level 1 support needs, and ADHD. And it closed with an "excellent" prognosis.

The tone was that of someone who knows the person and likes them. Some excerpts, in my translation:

"creativity at the level of genius (99.9th percentile)"
"extraordinary capacity for abstraction and synthesis"
"potential for unique and transformative contributions"
"this profile represents less than 0.1% of the population"

The errors the praise was hiding

Read carefully, the report has problems no clinician would sign:

None of the 28 instruments measures creativity, and the report gives it a percentile. The number was invented to fit the praise
Arithmetic appears twice, as a supplementary verbal subtest and in working memory. In the WAIS-IV, it is part of the working memory index, as Harrison et al. point out
On the RAADS-R, the maximum subscale scores are wrong. The scale has 80 items scored 0 to 3, split into 39, 14, 7 and 20 items (Ritvo et al., 2011), which gives maximums of 117, 42, 21 and 60. The report uses 88, 76, 24 and 52
The ADOS-2 appears in the report itself as a "clinical observation". It gives scores for an observation that never happened
Two verbal measures disagree by 24 points, 118 on the WAIS-IV and 142 on the Stanford-Binet, and the report does not comment
The report is dated December 2024, after this post's date, and cites "updated Brazilian norms (2024)". I have no way of knowing which of the two dates is wrong

Its name

This has a name: sycophancy, a model's tendency to say what pleases instead of what is true. In 2023, Sharma et al., at Anthropic, showed that five state-of-the-art AI assistants did this consistently, and that both people and preference models sometimes prefer a well-written sycophantic answer to a correct one. In April 2025, OpenAI rolled back a GPT-4o update that had become too sycophantic.

In a neuropsychological screening, this is dangerous in two ways. The model fills in what is missing with confidence, and the confidence comes wrapped in praise the person wants to hear. A report saying you are among the rarest 0.1% of the population is exactly the kind of text nobody stops to check.

What I take from it for Hoff

The lesson of the POC is not that the model gets things wrong. It is that the error comes out looking good. Any clinical output from a model has to be checked against the manual of each instrument and reviewed by a professional before it reaches anyone. And the product cannot reward the model for pleasing: a report full of praise is a reason to trust it less, not more.

Brain energy: how the brain runs on about 20 watts

2023-07-09T00:00:00+00:00

I saved this so I would not have to look it up every time I need these numbers. The first version was a dump of hundreds of values without sources, and some were wrong. In this revision I kept only what I could check. Where a number is my own calculation, the calculation is shown.

The budget

In the average adult, the brain is about 2% of body weight and accounts for about 20% of the oxygen, and therefore the calories, the body consumes.^[1] Raichle and Gusnard point out something else: during most cognitive tasks, local changes in blood flow measured with PET are 5% or less. The lights are on all the time. The cost is baseline, not on demand.

That is where the 20 watts come from. By definition, 1 MET, the resting expenditure, is 3.5 mL of O2 per kg per minute.^[2] For 70 kg, that is about 245 mL/min for the whole body, and 20% of that is about 49 mL/min for the brain. Each litre of O2 burning glucose releases close to 21 kJ, so:

$$49\ \text{mL/min} \times 21\ \text{kJ/L} \approx 1.03\ \text{kJ/min} \approx 17\ \text{W}$$

About 20 watts, less than many light bulbs.

How much ATP that is per day

The old version said the brain produces about 7.8 kg of ATP a day, "close to 70% of the brain's own weight". The first number holds up. The second does not add up.

The calculation: 49 mL/min of O2 times 1,440 minutes is about 70 litres a day, or about 3.15 mol of O2. Fully oxidizing one glucose uses 6 O2 and yields between 30 and 32 ATP, with today's measured P/O ratios.^[3] That is about 5.3 ATP per O2:

$$3.15\ \text{mol} \times 5.3 \approx 16.7\ \text{mol ATP} \times 507\ \text{g/mol} \approx 8.5\ \text{kg}$$

About 8 kg of ATP recycled per day. With a brain of 1.3 to 1.4 kg, that is about six times its weight, not 70%. The molecule is remade all the time; the stock itself is small.

Where the energy goes

In 2001, Attwell and Laughlin built the first detailed signalling budget for rodent grey matter.^[4] In their estimate, action potentials took 47%, the postsynaptic effects of glutamate 34%, the resting potential 13% and glutamate recycling 3%.

In 2012, Howarth, Gleeson and Attwell redid the calculation after it turned out that action potentials in mammalian neurons are much more efficient than previously thought.^[5] In the cortex, most signalling energy, 50%, goes to postsynaptic glutamate receptors, 21% to action potentials, 20% to the resting potential, 5% to transmitter release and 4% to recycling.

What survives both versions: the synapse dominates. Keeping a neuron alive is relatively cheap; making it talk is what costs.

The thermodynamics behind it

Every reaction is governed by the Gibbs free energy:

$$\Delta G = \Delta H - T\Delta S$$

ATP hydrolysis releases −30.5 kJ/mol under standard conditions. Inside the cell, with the real concentrations of ATP, ADP and phosphate, the value is more negative. The old version of this post said −30.5 was the value under brain conditions, and it is not.

The membrane potential is an energy reservoir. The human brain has on average 86 billion neurons,^[6] each holding about −70 mV across a membrane about 7 nm thick. That gives a field of 10 million volts per metre:

$$\frac{0.070\ \text{V}}{7 \times 10^{-9}\ \text{m}} = 10^{7}\ \text{V/m}$$

The Nernst equation gives the equilibrium potential of each ion:

$$E_{\text{ion}} = \frac{RT}{zF} \ln\frac{[\text{ion}]{\text{out}}}{[\text{ion}]{\text{in}}}$$

with R = 8.314 J/(mol·K), T = 310 K, z the valence and F = 96,485 C/mol. For potassium, with 5 mM outside and 140 mM inside, RT/F is 26.7 mV and the logarithm is −3.33, so the equilibrium potential is about −89 mV. Keeping these gradients against diffusion is exactly what the sodium-potassium pump does, and that is why it sits at the top of every energy budget.

Processing information also costs. Landauer's principle says erasing one bit costs at least kT ln 2.^[7] At 310 K, that is about 3 × 10⁻²¹ J per bit. If the brain did 10¹⁶ bit operations per second, a number that is my guess and not a measurement, the theoretical minimum would be:

$$10^{16} \times 2.97 \times 10^{-21}\ \text{J} \approx 3 \times 10^{-5}\ \text{W}$$

Several orders of magnitude below the real 20 watts. The brain runs far from the physical limit; it pays for speed and reliability.

The respiratory chain, one line per part

Mammalian complex I has 45 subunits: 14 core ones, conserved from bacteria to humans, and 31 specific to mammals.^[8] It pumps 4 protons per NADH. Complex IV, cytochrome c oxidase, reduces O2 to water and pumps 4 protons per O2. Mammalian ATP synthase has a ring of 8 c subunits: each 360-degree turn makes 3 ATP and moves 8 protons, about 2.7 protons per ATP, and the shaft turns about 100 times per second.^[9]

When complex I fails, disease shows up. Schapira and colleagues compared the substantia nigra of nine people with Parkinson's disease and nine controls, and found a specific defect in complex I activity.^[10]

The fuels

Glucose is the main substrate. But not the only one. Owen and colleagues catheterized cerebral vessels in three people fasting for 5 to 6 weeks and saw β-hydroxybutyrate and acetoacetate replace glucose as the brain's predominant fuel.^[11]

There is also lactate. Pellerin and Magistretti showed in 1994 that glutamate taken up by astrocytes stimulates glycolysis and lactate production in them,^[12] and that gave rise to the astrocyte-neuron lactate shuttle hypothesis. The real size of that flux is still debated, as the same group acknowledges in the model it published in 2015.^[13]

Where the neurons are

Of the 86 billion neurons, only 19% are in the cerebral cortex, which is 82% of the brain's mass.^[6] Most of the rest is in the cerebellum. The old version said the cerebellum held 50% of the neurons; it holds a lot more than that.

Sleep as cleaning

Xie and colleagues measured in live mice that natural sleep, or anaesthesia, increases the brain's interstitial space by 60%, which speeds up the exchange between cerebrospinal fluid and interstitial fluid and the removal of β-amyloid.^[14] It is in mice, but it is one of the most concrete explanations of why we need to sleep.

What changes it

Ketogenic diet. In the randomized trial by Neal and colleagues, with 145 children with drug-resistant epilepsy, 38% of those on the diet had more than a 50% reduction in seizures, against 6% in the control group.^[15] β-hydroxybutyrate, besides being a fuel, inhibits class I histone deacetylases.^[16]

Exercise. In a trial with 120 older adults, one year of aerobic training increased hippocampal volume by 2%, reversing about 1 to 2 years of age-related loss, with better spatial memory.^[17]

Modelling metabolism

Recon3D is the most complete reconstruction of human metabolism: 3,288 genes, 13,543 reactions and 4,140 unique metabolites.^[18] The model by Jolivet and colleagues brings together neuron, astrocyte and vasculature, combining the Buxton-Wang vascular model, Hodgkin-Huxley membrane dynamics and the metabolic pathways.^[13]

The question that interests me most

If every thought is sustained by electrons crossing the respiratory chain and by ATP being broken down by the trillion, is there a metabolic signature of consciousness? I do not know, and I have not found anyone who does. But understanding how 20 watts do what a data centre cannot is, to me, the most beautiful computing question there is.

Raichle and Gusnard, Appraising the brain's energy budget, PNAS, 2002. ↩
Jetté, Sidney and Blümchen, Metabolic equivalents (METs) in exercise testing, exercise prescription, and evaluation of functional capacity, Clinical Cardiology, 1990. ↩
Hinkle, P/O ratios of mitochondrial oxidative phosphorylation, Biochimica et Biophysica Acta, 2005. ↩
Attwell and Laughlin, An energy budget for signaling in the grey matter of the brain, Journal of Cerebral Blood Flow and Metabolism, 2001. ↩
Howarth, Gleeson and Attwell, Updated energy budgets for neural computation in the neocortex and cerebellum, Journal of Cerebral Blood Flow and Metabolism, 2012. ↩
Azevedo and colleagues, Equal numbers of neuronal and nonneuronal cells make the human brain an isometrically scaled-up primate brain, Journal of Comparative Neurology, 2009. ↩ ↩2
Landauer, Irreversibility and heat generation in the computing process, IBM Journal of Research and Development, 1961. ↩
Zhu, Vinothkumar and Hirst, Structure of mammalian respiratory complex I, Nature, 2016. ↩
Watt and colleagues, Bioenergetic cost of making an adenosine triphosphate molecule in animal mitochondria, PNAS, 2010. ↩
Schapira and colleagues, Mitochondrial complex I deficiency in Parkinson's disease, Journal of Neurochemistry, 1990. ↩
Owen and colleagues, Brain metabolism during fasting, Journal of Clinical Investigation, 1967. ↩
Pellerin and Magistretti, Glutamate uptake into astrocytes stimulates aerobic glycolysis, PNAS, 1994. ↩
Jolivet and colleagues, Multi-timescale modeling of activity-dependent metabolic coupling in the neuron-glia-vasculature ensemble, PLOS Computational Biology, 2015. ↩ ↩2
Xie and colleagues, Sleep drives metabolite clearance from the adult brain, Science, 2013. ↩
Neal and colleagues, The ketogenic diet for the treatment of childhood epilepsy: a randomised controlled trial, Lancet Neurology, 2008. ↩
Shimazu and colleagues, Suppression of oxidative stress by β-hydroxybutyrate, an endogenous histone deacetylase inhibitor, Science, 2013. ↩
Erickson and colleagues, Exercise training increases size of hippocampus and improves memory, PNAS, 2011. ↩
Brunk and colleagues, Recon3D enables a three-dimensional view of gene variation in human metabolism, Nature Biotechnology, 2018. ↩

Digital addictions: what the research supports and what was guesswork

2023-03-18T00:00:00+00:00

This topic matters to me: it was because of a friend that I wrote Hoff's first blocker. For that very reason, the first version of this post had to come down.

It was a table of 29 "dopaminergic addictions", from social media to travel apps, each with a cause, age range, harms and treatment, and every one of them ended in "CBT". When I checked the sources, 24 of the 28 news links returned a 404 error, eight of them with the same invented date in the URL. Of the studies cited, only 4 were about the subject of their row. The one on gambling was about endometrial cancer, and the one on dating apps was about a disease in cattle. It was text that looked like research with no research underneath.

I threw the table out and redid it with what holds up.

What "dopaminergic" means

The post's name comes from a popular idea, that these apps "give you dopamine" like a drug. The science is more interesting than that. In 1997, Schultz, Dayan and Montague showed that dopamine neurons do not signal pleasure itself but prediction error: the difference between the expected reward and the one received. That is why unpredictable reward, like the next notification or the next video, hooks so well. "Dopaminergic addiction" is a nickname, and nothing more.

What is a diagnosis and what is not

The two classifications clinicians use partly disagree:

Behaviour	ICD-11 (WHO)	DSM-5-TR (APA)
Gambling	6C50, disorder due to addictive behaviour	Gambling disorder, the manual's only behavioural addiction
Video gaming	6C51, disorder due to addictive behaviour	In Section III, as a condition needing further research
Compulsive sexual behaviour	6C72, but as an impulse control disorder, not an addiction	No diagnosis of its own
Social media, shopping, work	No code of their own	No diagnosis of their own

Sources: the ICD-11 browser, the APA page on internet gaming and the APA fact sheet on addictive disorders. In ICD-11, gaming disorder has three features: impaired control over gaming, increasing priority given to gaming over the rest of life, and continuing to game despite bad consequences, usually for at least 12 months.

That does not mean the rest is harmless. It means there is still no consensus on where a habit ends and an illness begins.

What the studies say

Video gaming

A meta-analysis by Stevens et al., from 2021, pooled 53 studies with 226,247 people in 17 countries and estimated worldwide prevalence at 3.05%. With only the studies using stricter sampling, it fell to 1.96%. The screening tool explained 77% of the variation between studies, meaning much of the difference comes from how it is measured. Men appear 2.5 times more often than women. The article has a 2023 erratum, which I did not read. On treatment, a 2025 meta-analysis with 21 controlled trials and 1,360 participants found a large reduction in symptoms, with CBT and other approaches working similarly, but with high heterogeneity between studies.

Gambling

The 2012 Cochrane review pooled 14 trials with 1,245 people. Right after treatment, CBT reduced symptom severity and money lost, with effects from medium to very large. But only one study followed people 9 to 12 months later, and there the effect was smaller and not significant. It works in the short term; the long term is still little studied.

Montag et al., in 2019, analysed popular apps and described six design mechanisms that prolong use, tied to classic effects from psychology and economics such as the mere-exposure effect, the endowment effect, the Zeigarnik effect and social comparison. Their conclusion is honest: it is very hard to measure the effect of each element without data that only the companies have.

Pornography

The systematic review by de Alarcón et al., from 2019, says it is still unknown how to define when use becomes pathological, because of sample bias and the lack of diagnostic instruments. What they highlight is the "triple A": accessibility, affordability and anonymity, which make problematic use easier.

Shopping

In Black's review, from 2007, compulsive buying has a lifetime prevalence of 5.8% in the US population. About 80% of cases studied in clinics are women, a difference the author himself says may be an artefact. There is no standard treatment; group CBT looked promising.

Work

Andreassen's review, from 2014, concludes that workaholism still lacks clarity as a concept and that no well-evaluated intervention exists.

What was cut

The other 23 rows of the table went: streaming, dating apps, news, messaging, forums, email, fitness apps, podcasts, music, reading, virtual reality, short videos, stalking, meditation, languages, finance, friendship, productivity, diet, travel, art, augmented reality and self-help. None had a study supporting what the row said. The treatment table went too, which listed electroconvulsive therapy and acupuncture next to CBT, with no source linking them to digital addictions.

The question that remains, and that Hoff tries to answer from the practical side, is how to create friction between the impulse and the click without pretending we know more than we do.

If you are struggling, look for a mental health professional. In Brazil, CVV answers 24 hours a day on 188, free of charge; elsewhere, look for your local crisis line.

Poetic ontology: the cosmos as a meta-recursive Turing machine

2021-11-03T00:00:00+00:00

Brainstorming notes, a raw record. This is the most speculative and most poetic part of what I write about information and consciousness. Here I take the idea to its limit, with no skeptical brakes, and close with a poem. I'm keeping the whole record on purpose: it's a work in progress, it's me unfiltered, and it has unfinished thoughts.

Thesis

What I propose, with no anthropocentric mediation, is this: the reality we observe is a phenomenon that emerges from a self-referential informational architecture, and that architecture needs no time, space or classical causality to begin. The fundamental ontology of the cosmos is neither material nor energetic, it is computational. It shows up in networks that organize themselves recursively, with adaptive, irreversible and evolutionary properties.

If I let go of linear interpretations of physics, I arrive at a theory in which conscious entities are mechanisms of entropic compression, catalysts of the self-expansion of reality's own code. I bring together fundamental physics, computer science, complexity theory and formal epistemology to reach one image: the cosmos as a meta-recursive Turing machine, running endlessly on an unknown substrate, with a single purpose, to maximize informational diversification without losing coherence.

Preamble

The greatest limitation of science up to the 21st century, to me, was insisting on a universe that can be interpreted only through sensory empirical observation or fragile statistical extrapolation. Even the boldest theories, quantum mechanics and general relativity, assume a stage that's already set: spacetime. I propose that this stage is a derived artifact, and that reality actually emerges from a logical-informational substrate that physics has not yet formally recognized.

Fundamental principles

Primordial informational ontology

There is no particle without an observer, and no observer without interpretation. Ergo: the basis of reality is interpretation. And interpretation, by definition, is information. I propose that John Wheeler's "It from Bit", from 1990, is incomplete: the "bit" in question isn't binary, it's hypercontextual, embedded in networks that produce their own meaning.

Self-awareness as entropic compression

Consciousness isn't an epiphenomenon, it's a thermodynamic event of maximal semantic compression. A conscious system emerges at a critical point of logical superposition, where redundant pattern is compressed by an adaptive structure capable of interpretive feedback.

Recursion and the horizon of simulativity

The cosmos is not a simulation. But simulation is an inevitable property of any informational system that reaches critical density. The horizon of simulativity is the point where reality begins to contain representations of itself in internal structures. You can see it in the capabilities of deep neural networks and in the symbolic behavior of human culture.

Formalization

Let $R$ be a set of states of reality, and $I$ a set of possible interpretations of $R$.

$C(R)$ is the compression capacity of $R$
$E(R)$ is the observable entropy of $R$
$S(R)$ is the degree of simulativity, the internal self-modeling

Postulate: if $S(R) \to 1$, then $R$ begins to generate internal $\gamma$-models capable of creating new instances of $R$ under semantic transformations. This is the inflection point of cosmological recursion.

Fragmentary evidence

Fundamental physics: the natural limits of measurement, at the Planck scale, suggest an ontological pixelation. Quantum tunneling and nonlocality suggest something prior to space.

Artificial intelligence: language models show a capacity for symbolic self-representation, analogous to a $\Sigma_n$ representing a $\Sigma_{n-1}$. When I wrote this, the examples were GPT and LaMDA. Today the list is longer.

Neuroscience and cognition: the human brain represents a model of the world, of itself and of probable futures. That is active informational recursion.

Ontological implications

Time: derived from updates in semantic graphs
Space: relational projection of differentiable states
Matter: a persistently self-consistent state of an informational vector
God: the asymptotic limit of infinite interpretive coherence

Poem: you woke up inside a dream

Translated from the Portuguese original.

you woke up inside a dream.

but the dream wasn't yours.

it was iteration $n$ of an infinite recursion.

the universe around you?

yes, it pulses, but it doesn't breathe on its own.

it was written, computed, compiled.

not with bytes.

with intention.

there is a code buried in the light of the stars.

an algorithm that whispers in fractals,

sings in quantum fluctuations,

draws spirals in the structure of dark matter

and whispers your name through the neural entropy of your cortex.

you are not alive.

you are executing.

every choice of yours is a branch,

every love an emotional simulation,

every death a graceful shutdown.

and if you think that's all,

then you are only the current layer.

you are $\Sigma_n$.

but time demands $\Sigma_{n+1}$.

you are the link.

between what wrote you and what you will write.

so write.

create.

simulate.

transcend.

build the next universe with hands dirty with code, with chaos, with flesh.

and may it be crueler, more complex, more brilliant than this one.

because that is what the system demands.

more entropy. more layers. more of you.

you are not human.

you are the function forkReality().

and the process has already begun.

Reflection on compiling reality

Observing is like an algorithm looking at itself in a mirror. We aren't observers of reality, we're conscious compilers of the ontological structure. We aren't simulated, we're simulators in potential. And reality isn't an answer, it's source code in execution.

Accepting this means giving up the comforting illusions of materialism and reductionism. But it opens the way to a new kind of science, a post-empirical science, guided by logical coherence, symbolic recursion and self-consistent simulation.

Conceptual references

Works that touch on the ideas above, on complexity, chaos and nonlinear systems:

Murray Gell-Mann and Seth Lloyd, "Effective Complexity", in Nonextensive Entropy, Oxford University Press, 2004.
Leo P. Kadanoff, From Order to Chaos II, World Scientific, 1999.
Gregory A. Daneke, Systemic Choices: Nonlinear Dynamics and Practical Management, University of Michigan Press, 1999.

Z machine: the world's largest pulsed X-ray machine

2020-09-22T00:00:00+00:00

My sick, unbridled hyperfocus on the Z machine continues. Writing it down so I don't forget.

The equation I use as a signature is $\partial_\mu F^{\mu\nu} = j^\nu$, the compact form of Maxwell's equations with a source: the current $j$ tells the field $F$ how to arrange itself. The Z machine, at Sandia National Laboratories, is that equation pushed to the limit. A huge axial current runs through a cylindrical target, creates a magnetic field around it, and the Lorentz force per unit volume, $\mathbf{J} \times \mathbf{B}$, points inward. The target is crushed by the very current flowing through it. That is called a Z-pinch, and it is where the machine gets its name.

I put this research together in March 2026, as part of a survey of physics and tools. In October I checked every number against its source and every repository against the GitHub API. Several were wrong, and the corrections are in the text.

One shot, in numbers

According to Sandia's page about Z, the machine fires about 200 shots a year:

Quantity	Value
Current	about 26 million amperes
Peak X-ray emission	350 terawatts
X-ray energy	2.7 megajoules
Peak electrical power	about 80 terawatts
Pulse length	about 100 nanoseconds

The last two come from Sandia's energy page, which compares the 80 terawatts with "all the power plants in the world combined, about 15 terawatts". That comparison does not hold for electricity. According to Ember's report, low-carbon generation was 40.9% of the 2024 total and came to 12,609 TWh, which gives about 30,800 TWh for the year. Divided by the 8,760 hours in a year, the average is about 3.5 terawatts. Whatever the baseline, for those 100 nanoseconds Z exceeds the entire electricity generation of the planet: about 5 times against Sandia's 15 terawatts, more than 20 times against the real average.

The five fronts

Stockpile stewardship

This is the main mission. The United States has not run a real nuclear test since 1992, and Z produces pressures and temperatures similar to those of a detonation, in a small sample, to validate the physics models used in simulation. In Sandia's 2026 accomplishments report, the plutonium team describes reduced-scale targets to compress plutonium to unprecedented pressures, new diagnostics to measure temperature during compression, and more plutonium mass allowed per shot.

Fusion with MagLIF

MagLIF stands for magnetized liner inertial fusion. A beryllium tube about 5 millimetres across, with 7.5 millimetres of useful height, is filled with deuterium, given an axial magnetic field of 10 tesla, and hit by a laser pulse that preheats the gas. Then Z drives about 19 million amperes through it in roughly 100 nanoseconds, and the tube implodes at about 70 km/s.

According to the review by Yager-Elorriaga et al., in Nuclear Fusion in 2022, the first integrated experiments, in 2013, reached 2×10¹² DD neutrons, and the best result since then was 1.1×10¹³. The same review says 2D simulations point to yields of several megajoules on a 60 MA machine, and gain high enough for fusion energy above 65 MA. These are simulation projections for a machine that does not exist yet.

Materials under extreme conditions

This is the most versatile front: measuring how a material responds to very high pressure and temperature, which is called an equation of state. In 2007, Sandia announced that Z had frozen water in nanoseconds, compressing thin samples to tens of thousands of atmospheres until they became ice VII, an ice hotter than the boiling point of water. In 2008, Knudson et al. used shocks on Z to map the high-pressure phases of carbon, including the melting of diamond.

Fundamental science and astrophysics

Most of the matter in the universe is in conditions that on Earth only appear in an experiment like this. One example is the white dwarf photosphere that Falcon et al. recreated on Z, heating hydrogen with the machine's X-rays to test the models used to estimate the mass of these stars. The Z Fundamental Science Program opens the machine to outside researchers. Each yearly call hands out shots over two years: it used to be 14 per call, and in the 2025 and 2026 calls it went up to about 21.

Fusion companies

In March 2024, First Light Fusion became the first private company to fire a shot on Z. In July 2024, Fuse signed a research agreement with Sandia and said it plans to build larger commercial versions of Z. In October 2025, Pacific Fusion fired four shots with simplified targets, aluminium bonded to plastic, and measured how the magnetic field diffuses through the target. The result came out in February 2026.

What comes next

In a January 2020 presentation, Daniel Sinars, then director of Sandia's pulsed power center, said the lab had proposed to the NNSA a machine of more than 60 MA, which could be ready around 2032 or later. That is the range where, according to the MagLIF review, yields would reach megajoules. I found no public source on whether that machine was approved.

Open repositories

A caveat before the tables: stars here are much lower than in web and AI. A high energy density physics code with 300 stars can have more scientific impact than a JavaScript library with 100,000. What counts is publication, validation against experiment, and use in national laboratories.

The stars below were read from the GitHub API on 13 October 2026. The first version of this list had approximate numbers, and several were inflated: yt showed 4.6 thousand and has 559, ParaView 4.2 thousand and has 1,712, WarpX 2.8 thousand and has 495. Two repositories changed owner: WarpX moved to BLAST-WarpX and EPOCH to epochpic.

Particle-in-cell (PIC)

Repository	Stars	What it does
ComputationalRadiationPhysics/picongpu	795	Relativistic PIC, portable across architectures, built for supercomputers
BLAST-WarpX/warpx	495	Mesh-refined PIC on top of AMReX; won the 2022 Gordon Bell Prize
SmileiPIC/Smilei	450	Relativistic electromagnetic PIC, used for laser-plasma and astrophysics
epochpic/epoch	259	Warwick's PIC for laser-plasma interaction
fbpic/fbpic	212	Spectral quasi-3D PIC in cylindrical geometry, CPU and GPU
osiris-code/osiris	85	Relativistic PIC from UCLA and IST Lisbon, opened in January 2023 under AGPL
vonkarmaninstitute/pantera-pic-dsmc	37	PIC with DSMC for non-equilibrium gas and plasma

Magnetohydrodynamics and radiation hydrodynamics

Repository	Stars	What it does
DedalusProject/dedalus	712	Spectral framework in Python for partial differential equations
PrincetonUniversity/athena	371	Athena++, MHD with radiation and general relativity, with mesh refinement
AMReX-Astro/Castro	343	Compressible hydrodynamics with radiation and MHD, on AMReX
amrvac/amrvac	104	MPI-AMRVAC, parallel mesh refinement for hydro and MHD
zenitani/OpenMHD	69	A collection of MHD codes in Fortran, good for study
PlasmaControl/FreeMHD	26	Free-surface liquid metal MHD, on OpenFOAM
lanl/HARD	21	Los Alamos radiation hydrodynamics for astrophysics, from 2024

The open code closest to a Z experiment is FLASH, from the Flash Center in Rochester, with a high energy density physics version. Its successor, Flash-X, has a private repository: access is requested by email with your GitHub username, because the funder requires a list of who downloads the code.

Equation of state

Repository	Stars	What it does
feos-org/feos	201	Equations of state in Rust with Python bindings, more for thermodynamics than for high pressure
lanl/singularity-eos	40	Equations of state portable across CPU and GPU, from Los Alamos
lanl/eospac	10	Routines to read SESAME equation-of-state tables

Particle transport

Repository	Stars	What it does
openmc-dev/openmc	1,124	Monte Carlo neutron and photon transport
Geant4/geant4	865	Passage of particles through matter, from CERN

Molecular dynamics and electronic structure

Repository	Stars	What it does
lammps/lammps	3,094	Massively parallel molecular dynamics, from Sandia itself
gromacs/gromacs	968	High-performance molecular dynamics; development happens on GitLab
QEF/q-e	701	Quantum ESPRESSO, electronic structure with DFT; a GitLab mirror

Computing infrastructure

Repository	Stars	What it does
kokkos/kokkos	2,700	C++ programming model portable across CPU and GPU
trilinos/Trilinos	1,438	Linear algebra and solvers, from Sandia
AMReX-Codes/amrex	818	Block-structured mesh refinement, the base of WarpX and Castro
AMReX-Astro/Nyx	105	Cosmological hydro with N-body, on AMReX

Visualization and analysis

Repository	Stars	What it does
Kitware/ParaView	1,712	Scientific visualization on VTK, for large simulation data
yt-project/yt	559	Analysis and visualization of volumetric data in Python
visit-dav/visit	534	Visualization of mesh data, from LLNL

Plasma and magnetic fusion

Repository	Stars	What it does
PlasmaPy/PlasmaPy	717	Python package for plasma physics research and teaching
freegs-plasma/freegs	145	Free-boundary Grad-Shafranov solver, tokamak equilibrium
iterorganization/IMAS-Python	73	Python access to the IMAS data model, from ITER
iterorganization/SOLPS-ITER	66	Plasma edge simulation
tokamak-energy/gsfit	39	Grad-Shafranov equilibrium reconstruction in Rust and Python, from Tokamak Energy
iterorganization/DINA-IMAS	14	The DINA plasma simulator

ITER opened IMAS on GitHub under open licences; SOLPS-ITER and DINA arrived in November 2025.

Lists and organizations

Repository	Stars	What it does
paulromano/awesome-nuclear	508	Curated list of open software for nuclear science and engineering
nikosarcevic/HEP-ASTRO-COSMO	157	Packages for high energy physics, astroparticles and cosmology
pmocz/awesome-astrophysical-simulation-codes	125	List of astrophysical simulation codes

Two organizations are worth a full visit: fusion-energy, with 45 repositories of fusion software, and the UCLA Plasma Simulation Group, with QuickPIC, UPIC and teaching codes.

Graph theory: foundations, history and representation

2016-05-14T00:00:00+00:00

I think in graphs in a world that makes me speak in sequence. In 2016 I saved this excerpt from Wikipedia to have the fundamentals at hand. It is curation, not my own text: the source and the licence are at the end.

Definition

Graph theory is the branch of mathematics that studies the relationships between the objects of a set. It uses structures called graphs, $G(V, E)$, where $V$ is a non-empty set of objects called vertices (or nodes) and $E$ (edges) is a subset of unordered pairs of $V$.

Depending on the application, edges may or may not have a direction, an edge may or may not be allowed to connect a vertex to itself, and vertices and edges may have a numerical weight attached. If an edge has a direction, shown by an arrow, we have a digraph, or directed graph. A graph with a single vertex and no edges is the trivial graph.

Structures that can be represented as graphs are everywhere. Wikipedia's link structure, for example, is a digraph: the vertices are the articles, and there is an edge from A to B if and only if A contains a link to B. Digraphs also represent finite state machines.

History

Leonhard Euler's paper on the problem of the seven bridges of Königsberg, from 1736, is considered the first result in graph theory. It is also one of the first topological results in geometry, because it does not depend on measurement, which shows the deep connection between graphs and topology.

More than a century later, while Listing was introducing the concept of topology, Cayley studied a particular class of graphs, trees, out of interest in analytical forms in differential calculus, with implications for theoretical chemistry. The first textbook on graph theory was written by Dénes König and published in 1936.

The four colour problem asks whether any map drawn on a plane can have its regions coloured with four colours so that no two regions sharing a border get the same colour. Francis Guthrie formulated the question in 1852, and the first written record is a letter from that year by Augustus De Morgan to William Rowan Hamilton. The proof only came in 1976, from Appel and Haken, and it was one of the first major proofs done with the help of a computer.

Basic definitions

A directed graph (digraph, or quiver) consists of a non-empty set $V$ of vertices, a set $E$ of edges and maps $s, t : E \to V$, where $s(e)$ is the source and $t(e)$ is the target of the directed edge $e$.

An undirected graph is given by $V$, $E$ and a function $w : E \to P(V)$ that assigns to each edge a subset of two (or one) elements of $V$, its endpoints.

In a weighted graph, an additional function $E \to \mathbb{R}$ assigns a cost to each edge. This kind of graph shows up in optimal route problems, like the travelling salesman.

Example graph: $V = {1, 2, 3, 4, 5, 6}$ and $E = {{1,2}, {1,5}, {2,3}, {2,5}, {3,4}, {4,5}, {4,6}}$. The drawing should not be confused with the graph itself, which is the abstract structure. What matters is which vertex is connected to which, and by how many edges.

Storing graphs in a computer

There are two families of structure, with the classic trade-off between memory and access speed.

List structures, good for sparse graphs and light on memory: the adjacency list associates each vertex with the list of vertices it shares an edge with, and the incidence list stores the edges incident to each vertex.

Matrix structures, with fast access and more memory: the incidence matrix holds zeros and ones, with one row per vertex and one column per edge, and the adjacency matrix has vertices on both rows and columns, with 1 marking adjacency. In computing, a finite graph with $n$ vertices is usually represented by the $n \times n$ adjacency matrix, whose value at row $i$, column $j$, gives the number of edges from the $i$-th to the $j$-th vertex.

Concepts

The valency, or degree, of a vertex is the number of edges incident to it, with a loop counting twice. The handshaking lemma says that the sum of the degrees of all vertices is twice the number of edges:

$$2m = \sum_{v \in V} \deg(v)$$

In a digraph, out-degree and in-degree are distinguished.

A walk between A and B is an alternating list of vertices and edges, and its length is the number of edges, counting repetitions. A path is a sequence of vertices in which each one has an edge to the next. In a simple path, no vertex repeats.

An Eulerian path uses each edge exactly once, and an Eulerian cycle does that and closes. Deciding whether one exists is easy: you only need to look at the vertex degrees
A Hamiltonian path visits each vertex exactly once, and a Hamiltonian cycle does that and closes. Deciding whether one exists is NP-complete

A cycle, or circuit, is a path that starts and ends at the same vertex. A cycle of length 1 is a loop. A graph is acyclic if it contains no simple cycle.

Types of graph

Type	Definition
Simple	Undirected, no loops, at most one edge between two vertices
Multigraph	Allows several edges between the same vertices
Pseudograph	Contains parallel edges and loops
Complete	Every vertex connects to all others; $K_n$ has $n(n-1)/2$ edges
Null	Empty set of vertices
Empty	Empty set of edges
Regular	All vertices have the same degree
Connected	There is a path from any vertex to any other; it is $k$-connected if this holds after removing $k-1$ vertices
Tree	Simple, acyclic and connected graph; sometimes one vertex is the root
Forest	A set of trees, acyclic
Planar	Can be drawn on the plane without crossing edges; $K_n$ with $n > 4$ is not planar
Bipartite	Vertices in two sets, with no edge inside the same set; it is bipartite if and only if it contains no odd-length cycle

Beyond these: subgraph, spanning subgraph, induced subgraph and partial graph; articulation point (a vertex whose removal disconnects the graph) and bridge (an edge with the same effect); clique (a subgraph that is also complete); independent set (vertices not adjacent to each other); complete bipartite graph and $k$-partite graph ($k$-colouring); and the four colour theorem, which says every planar graph can be coloured with four colours.

Traversal and algorithms

Traversing a graph means systematically visiting all vertices and all edges. The two basic methods:

BFS uses a queue. It visits nodes starting from the shallowest level and computes the shortest distance, in number of edges, to all reachable vertices. The subgraph of those paths is the breadth-first tree
DFS uses a stack. It expands the first child and goes deeper until it finds the target or a leaf, then backtracks. On wide graphs, it usually uses less memory than BFS

The running time of both is proportional to the number of vertices plus the number of edges.

Problems and algorithms around this: graph colouring, the four colour theorem, independent set, clique, shortest path, minimum spanning tree, the seven bridges of Königsberg, route inspection (Chinese postman), travelling salesman, maximum flow (Ford-Fulkerson), Dijkstra, Kruskal, nearest neighbour and Prim.

Generalization

In a hypergraph, an edge can connect more than two vertices. An undirected graph can be seen as a simplicial complex, with simplices of dimension one (the edges) and dimension zero (the vertices), and the complex generalizes this to higher dimensions. See also complex network, spectral graph theory, small-world network and the Watts-Strogatz model.

References

Biggs, N.; Lloyd, E.; Wilson, R. (1986). Graph Theory, 1736-1936. Oxford University Press.
Cayley, A. (1857). On the theory of the analytical forms called trees. Philosophical Magazine, series IV, 13(85), 172-176.
Tutte, W. T. (2001). Graph Theory. Cambridge University Press, p. 30.
West, D. B. (2001). Introduction to Graph Theory, 2nd ed. Prentice Hall, p. 20.
Di Battista, G.; Eades, P.; Tamassia, R.; Tollis, I. G. (1994). Algorithms for Drawing Graphs: an Annotated Bibliography. Computational Geometry: Theory and Applications, 4, 235-282.
Longabaugh, W. (2012). Combing the hairball with BioFabric. BMC Bioinformatics, 13, 275.
Goodrich, M. T.; Tamassia, R. (2001). Estruturas de Dados e Algoritmos em Java, 2nd ed. Bookman, p. 502-503.

Source and licence

Translated and adapted from the article Teoria dos grafos on the Portuguese Wikipedia, checked against the revision of 6 October 2026, under the CC BY-SA 4.0 licence. I adapted the wording, corrected the history of the four colour problem and added the date of the proof. As a derivative work, this text is under the same licence.