DEV Community: Remdore

A sticker over 15% of a QR code is fine. Erasing 0.7% of it kills the code.

Remdore — Tue, 22 Sep 2026 09:29:16 +0000

Everyone repeats the same fact about QR codes: you can destroy about 30% of one and it still scans. It is the reason people put logos in the middle of them, and it is the reason a scuffed parking sign still works.

I wanted to see it happen, so I generated codes at all four error-correction levels, damaged them in controlled ways, and fed each damaged image to a real decoder two hundred times per data point.

The folklore is true in one specific sense and badly misleading in every other. Where you damage a QR code matters far more than how much.

A sticker over 15% of it: fine

First, the kind of damage people imagine: a solid patch, like a label stuck on a box or a ring left by a coffee cup. I covered a square of the data area and tried to decode it, moving the patch to a random position each time.

EC level	5% covered	10%	15%	20%	25%
L	47%	2%	0%	0%	0%
M	97%	43%	0%	0%	0%
Q	100%	99%	35%	0%	0%
H	100%	100%	99%	29%	0%

Those are the share of two hundred attempts that decoded correctly. At level H you can cover 15% of the symbol with a sticker and it still scans essentially every time.

That is the picture the folklore is describing, and it holds up.

Scattered dirt over 3% of it: dead

Now the same total amount of damage, spread out. Instead of one patch, I flipped individual modules at random across the whole symbol — the pattern you would get from dust, print noise, or a bad camera.

EC level	1% speckled	2%	3%	5%
L	65%	13%	1%	0%
M	74%	46%	7%	0%
Q	61%	38%	15%	0%
H	44%	29%	10%	0%

Three per cent of scattered damage is worse than fifteen per cent in a patch. Every level is finished by five per cent.

The reason is that the error correction does not work on pixels, it works on codewords of eight modules each. A solid patch ruins a small number of codewords completely. The same number of scattered modules ruins up to eight times as many codewords, because each stray speck lands in a different one. The decoder is not counting damaged area, it is counting damaged codewords, and scattering is the most efficient way to spend your damage budget.

The part that genuinely surprised me

Look at that speckle table again, at the 1% column. Level H — the strongest error correction available — did worse than level M. 44% against 74%.

That is not an error. Level H needs more room for its redundancy, so for the same payload it produced a bigger symbol: 33×33 modules against M's 25×25. One per cent of a bigger code is more modules, and since scattered modules are what destroy codewords, the stronger code ate more damage at the same percentage.

Stated as a percentage, more error correction made it more fragile. Stated in absolute terms, H still corrects more. Both are true, and the percentage version is the one people quote.

The 0.7% that kills it instantly

Everything above damaged the data area. Now the structure.

A QR code is not uniform. Roughly a quarter of the modules in the symbol I tested — 260 of 1,089 — are fixed furniture: the three big squares in the corners, the dotted lines running between them, the strips that describe the format. I found them empirically, by generating three hundred codes with different payloads at the same size and marking every module that never changed.

None of that furniture is protected by error correction. It is what the decoder uses to find the code in the first place.

what I erased	share of modules	result
one finder pattern (a corner square)	4.5%	dead
the format strip beside a finder	0.8%	dead
half of one timing row	0.7%	dead

Seven tenths of one per cent. A single thin line of modules, and the code is unreadable — while the same code shrugs off a sticker twenty times that size.

That timing row is the dotted line running between two corner squares. It is how the decoder works out the grid spacing, so without it there is nothing to measure the rest of the symbol against. No amount of redundancy in the data helps, because the data is never reached.

What I got wrong

I ran the whole first round with an error-correction level I was not actually using.

My level L and level M results came out identical — not close, identical to the decimal. Two hundred randomised trials producing exactly 50.5% for both is not a coincidence, it is a message. Comparing the two matrices directly: zero differing modules.

The library I used boosts the error-correction level automatically when a stronger one fits the same symbol size, which is sensible behaviour and is on by default. So asking for level L had quietly given me level M, and my weakest data point was never measured. Every number above comes from a rerun with boost_error=False, and with that off, L and M separate exactly as they should: 47% against 97% at the same damage.

If you are putting QR codes on things

Use level H when the code will live in the world rather than on a screen — it is the difference between surviving a 15% sticker and dying at 5%.

Do not scatter your logo. A single solid shape in the middle is close to the best case; the same area sprinkled around the symbol is close to the worst.

Protect the corners and the two dotted lines between them above everything else. That is where a fraction of a per cent of damage is fatal, and it is exactly the part people crop, round off, or print over.

There is also a practical debugging order that falls out of all this. When a code in the wild stops scanning, the instinct is to assume it has got too dirty or too worn, and to reprint it bigger. The numbers say that is usually the wrong first guess, because dirt has to be remarkably evenly distributed to beat the error correction in a level-H symbol, whereas a corner that has been trimmed by a label machine, or a sign whose bottom edge has been clipped by a mounting bracket, will take out a finder pattern or a timing row and kill the thing outright while looking almost undamaged to a person.

So check the edges and the corners before you check the surface. And if you are the one placing the code, give it a quiet margin on all four sides and keep anything decorative away from those three squares, because that is the region where less than one per cent of damage is the difference between a code that works for years and one that never worked at all.

Code, images and the raw numbers are at github.com/DimitrovK/qr-damage if you want to rerun it.

I wired Django to Next.js. Four things broke and only one of them threw an error.

Remdore — Mon, 21 Sep 2026 15:55:25 +0000

I wired a Django REST Framework API to a Next.js 16 front end this week — the most ordinary stack decision there is. Both sides worked. Every request returned 200. The page rendered, the styling was fine, the data looked right.

It was wrong in four separate ways, and only one of them ever produced an error message.

Here is each one, what it looks like from the outside, and the line that fixes it.

1. The page showed 10 tasks. There were 26.

The API had 26 tasks in it. The page listed 10 of them, in a perfectly formatted list, with no warning anywhere.

DRF's pagination wraps your array in an envelope:

{ "count": 26, "next": "...?page=2", "previous": null, "results": [ ... ] }

So you write the obvious thing — data.results — and you have silently accepted the default page size of ten. Nothing throws, because nothing is wrong exactly: you asked for the first page and you got the first page.

The dangerous part is that this failure scales with your success. With twelve rows in development you notice nothing, because ten of twelve looks like a full list. Ship it, let real data arrive, and you are quietly hiding most of your database behind a list that looks complete.

2. In production, the page froze at build time.

This is the one that would have cost me a weekend.

next build printed this:

Route (app)
┌ ○ /
└ ○ /_not-found

○  (Static)  prerendered as static content

That little circle means the page called Django during the build, baked the result into HTML, and will serve that HTML forever. I started the production server, added three tasks through the API, and reloaded:

API count now: 29
newest task in API: BRAND NEW TASK 3
page still shows: 10 | Created via correct POST

Cache-busting query string, hard refresh, same thing. The application is not broken. It is working precisely as designed, serving a snapshot of a database from whenever the build ran, and nothing in the output suggests your data has stopped moving.

The fix is one line at the top of the page, and the build output changes from ○ (Static) to ƒ (Dynamic):

export const dynamic = 'force-dynamic';

3. My fix for that ran straight into the next silent failure.

Having made the page dynamic, I also asked for more rows, in the way anyone would:

fetch("http://127.0.0.1:8008/api/tasks/?page_size=100", { cache: "no-store" })

The page still showed ten.

DRF's PageNumberPagination ignores ?page_size= entirely unless you tell it the parameter exists. Here is the whole behaviour:

/api/tasks/                 -> 10 rows
/api/tasks/?page_size=100   -> 10 rows
/api/tasks/?page_size=1     -> 10 rows

Three different requests, one answer, no complaint. And it is not just that parameter. On a plain ModelViewSet, every query parameter you have not explicitly wired up is discarded in silence:

/api/tasks/?done=true              -> all 26 rows
/api/tasks/?ordering=title         -> unchanged order
/api/tasks/?nonsense=banana        -> all 26 rows, 200 OK

Your filter checkbox does nothing. Your sort dropdown does nothing. The API cheerfully returns 200 and the full list every time, so the bug reaches you as "the filter feels broken" rather than as an exception.

The fix for the page size is a four-line class:

class SaneP(PageNumberPagination):
    page_size_query_param = "page_size"
    max_page_size = 500

After which ?page_size=100 returns 30 rows and ?page_size=1 returns one. For filtering and ordering you need django-filter and DRF's OrderingFilter — the point is that until you add them, the parameters are decoration.

4. The server's timezone decided what time every user saw.

Django stored a due date as 2026-10-15T15:44:59Z. The page rendered it with new Date(...).toLocaleString(), inside a server component.

I ran the same build under three server timezones:

server timezone	what every visitor saw
UTC	10/15/2026, 3:44:59 PM
America/New_York	10/15/2026, 11:44:59 AM
Europe/Sofia	10/15/2026, 6:44:59 PM

Same instant, same code, same database row. Because the formatting happens on the server, the time your users see is the timezone of the machine that rendered the page — not theirs, and not necessarily the one you developed against. Deploy to a region in a different offset and every timestamp in your product shifts, with nothing in any log to say so.

If the value matters, format it explicitly with a timezone you have chosen, or move the formatting to the client where the browser actually knows where the person reading it lives. What you should not do is what I did, which is let toLocaleString pick up whatever the rendering machine happens to be set to and assume that is a property of the data.

The one that did shout

In fairness, one thing broke loudly and got it exactly right. I posted to the collection URL without a trailing slash, the way you would if you had typed the path from memory:

POST /api/tasks   ->  500, RuntimeError

Django's APPEND_SLASH will happily redirect a GET to the slashed version, but it refuses to do the same for a POST, because a redirect would quietly drop the body you were trying to send. Rather than lose your data it raises, says so, and names the setting responsible. Add the slash and you get 201 with the new row in the response.

I would take that trade every time. It cost me thirty seconds and told me precisely what was wrong, which is more than the four silent ones managed between them.

A smaller one that wasted twenty minutes

While measuring the timezone behaviour I kept starting dev servers on different ports, and my results made no sense — two of the three runs rendered nothing at all. Next 16 will not run a second dev server in the same project directory. It prints a note saying another one is already running, gives you its port, and then does nothing further, so my script was politely being redirected to a server I thought I had replaced.

Not a bug, and arguably good behaviour. But it is the same pattern as everything else here: the output was a success message, the exit was clean, and what I believed was happening had not happened for some minutes.

What I take from this

Every one of these has the same shape. A default that is reasonable in isolation — paginate by ten, prerender what looks static, ignore unknown parameters, format dates with the ambient locale — becomes wrong at the seam between two frameworks, and the seam is exactly where nothing is watching.

None of it shows up in a status code. The only reliable way I found any of them was to compare what the API says exists against what the page actually renders, which is worth building as a test on day one: count the rows in the database, count the list items in the HTML, assert they match. That single assertion would have caught three of the four.

And after every production build, look at the little symbols in the route table. A ○ next to a page that shows live data is telling you, quietly, that it does not.

How many WebSocket connections can a $6 server hold? 99,770, and memory is the wall

Remdore — Mon, 21 Sep 2026 13:41:24 +0000

If you are building anything with live updates — a chat, a multiplayer game, a dashboard that ticks, a collaborative editor — sooner or later you need a number. How many people can be connected at once before I need a bigger server? The advice you find is remarkably unhelpful: "it depends on your workload", followed by an anecdote about someone's Erlang cluster.

So I put a plain Node WebSocket server on the cheapest machine DigitalOcean rents, one shared vCPU and 1GB of memory at $6 a month, and opened connections until it stopped accepting them.

It held 99,770 at once. The thing that eventually stopped it was memory, but not the memory you would look at.

Holding connections is nearly free

The first surprise is how little work an idle connection is. I climbed to 85,000 connections in waves of five thousand, waiting two and a half seconds after each wave so that the measurement reflects the cost of holding connections rather than the cost of opening them.

connections	server RSS	CPU busy	memory free
5,000	88 MB	1%	637 MB
25,000	154 MB	0%	497 MB
50,000	232 MB	0%	323 MB
75,000	320 MB	1%	156 MB
85,000	351 MB	1%	87 MB

Eighty-five thousand open WebSocket connections, and the CPU is doing nothing. Zero to one per cent, the whole way up.

This is worth sitting with, because it contradicts how people reason about real-time capacity. A connection that is merely open is a file descriptor and some buffers. It does not poll, it does not wake anything, it costs no cycles. Your CPU budget is spent on two things only: completing handshakes, and moving messages. If your app has a lot of users connected and mostly quiet — which describes most chat apps, most dashboards, most multiplayer lobbies — the CPU is not what you will run out of.

The memory that does not show up in your process

Look at the two memory columns again. Node's resident memory grew by about 3.6KB per connection, which is the number you would report if you watched your own process. But free memory on the machine fell by 550MB across those 85,000 connections, which is 6.6KB each.

Half the cost is invisible from inside the application. Roughly 3KB per connection lives in kernel socket buffers — the send and receive queues the kernel keeps for every TCP connection — and it never appears in your heap snapshot or your RSS.

That gap is the whole planning story. If you size your server from what your process reports, you will be out by a factor of two, and you will discover it at the worst possible moment.

The arithmetic also predicts the wall almost exactly. At 85,000 connections there was 87MB free; at 6.6KB each, that is room for about 13,000 more, which puts the ceiling near 98,500. The measured maximum was 99,770 — within 1.3% of the prediction.

The cliff is late, sharp, and unmistakable

Up to 98,000 connections the server accepted new ones at between 3,000 and 4,400 per second. Then:

opened= 98,000   handshake rate = 3,731/s
opened= 99,000   handshake rate =    34/s
opened= 99,770   handshake rate =     0/s

A hundredfold collapse inside one thousand connections. There is no gentle degradation to warn you, which is an argument for leaving real headroom rather than running close to a limit you have measured.

What it feels like at each level

Latency, sampled from random live connections with a request id matched to its reply:

connections	p50	p99	messages lost
20,000	1.0 ms	27.1 ms	0 of 100
40,000	0.8 ms	2.5 ms	0 of 100
60,000	1.4 ms	23.3 ms	0 of 100
80,000	1.0 ms	9.1 ms	0 of 100
99,770	2.3 ms	1,572 ms	46 of 300

Up to 80,000 connections the box answers in about a millisecond and loses nothing. At 99,770 the median is still 2.3ms, but the tail has fallen apart and fifteen per cent of messages never came back.

So the honest capacity is not the maximum. A comfortable working number is around 80,000 connections, which still leaves a fifth of the memory free and keeps every reply inside ten milliseconds at the ninetieth percentile.

For a sense of scale: eighty thousand simultaneous live connections is a chat app with eighty thousand people in it at the same moment, on a machine that costs less per month than two coffees. Most products never see that, and the ones that do are not worrying about a $6 server.

When it is in distress

At 99,770 connections the machine was still serving its existing connections at 2.3ms, yet new arrivals mostly could not get in: four of five handshake attempts from an unrelated machine timed out at twenty seconds, and the one that succeeded took 6.17 seconds. SSH could not complete a key exchange at all, timing out during banner exchange even with a 110-second limit.

That combination is worth recognising because it is genuinely confusing in production: the application looks healthy from the inside, existing users report no problem, and you cannot get a shell on the box to find out why nobody new can connect.

What I got wrong, twice

The first run reported a p99 latency of 34,885 milliseconds — thirty-five seconds — which I nearly wrote down as a finding about tail latency under load.

It was my measuring code. I picked a random socket, sent a ping, and waited for the next message on that socket, while thousands of other handshakes were still completing. Any reply arriving on that socket stopped my stopwatch, including replies to somebody else's ping. The rewrite tags every ping with an id, ignores anything that does not match it, and enforces a hard three-second deadline, counting losses separately instead of quietly folding them into the tail. With that fixed, the real p99 at nearly 100,000 connections is 1.5 seconds. Bad, but honest, and a completely different number.

The second is simpler and more embarrassing. I restarted the server to clear it, and the client began connecting a second later, so the first wave met a server that was still coming up: 1,194 instant failures and a run that aborted with "no progress". Nothing was wrong with either machine. I had just raced my own setup.

The third mistake ran the other way, and for a while it made the server look worse than it was. Somewhere above ninety thousand connections my client stopped being able to add any, and I wrote that down as the server's ceiling. Then, mostly out of curiosity, I opened a socket to it from my laptop at home, across the public internet, while the box was still carrying its hundred thousand: the reply came back as 101 Switching Protocols after 4.6 seconds. Slow, but it worked, which meant the server had capacity my client could no longer reach. What had actually run out was a single Node process on the load generator trying to shepherd a hundred thousand sockets of its own, and I had been about to publish its limit as though it belonged to the thing I was measuring.

The short version

A $6 machine holds tens of thousands of live WebSocket connections without much drama, and the resource it runs out of is memory rather than CPU, at roughly 6.6KB of real system memory per connection rather than the 3.6KB that the process itself will own up to. That factor of two is the part worth remembering, because it is the difference between a capacity plan that works and one that fails in production while your dashboards insist everything is fine.

If your users are mostly idle, something in the region of 80,000 connections per gigabyte is a defensible planning figure, and you should halve it if they are chatty, because messages cost CPU in a way that open sockets simply do not. Watch MemAvailable on the host rather than the heap size your runtime reports. And leave yourself real headroom, because the collapse I measured arrived inside a single thousand connections with no warning at all, going from nearly four thousand handshakes a second to thirty-four.

Measured on a DigitalOcean s-1vcpu-1gb droplet in Frankfurt, with load generated from a separate s-4vcpu-8gb droplet in the same region. Both destroyed afterwards; the entire experiment cost about thirty cents.

How much traffic can a $6 server handle? I measured it: 9,737 requests a second

Remdore — Mon, 21 Sep 2026 12:42:21 +0000

Every few weeks someone asks a version of the same question: is a cheap server enough for my project? The answers are always adjectives. "It depends." "Probably fine for a small site." "You'll want to scale up before launch." Nobody produces a number, so everybody over-provisions, because nobody wants to be the person whose launch fell over.

So I rented the cheapest thing DigitalOcean sells that anyone would actually run a site on — one vCPU, 1GB of memory, $6 a month, which works out at 0.893 cents an hour — put a real application on it, and pushed it until something broke. Then I measured what broke, which turned out to be the interesting part.

The short version: it served 9,737 requests a second, and the first thing to give out was not the hardware.

Making the test honest

Most benchmarks of this shape are useless for two reasons, and both were easy to avoid.

The first is that they serve a hello-world page. I put four workloads on the box instead: a 6.7KB catalogue page served as a static file by nginx, a JSON API endpoint, a SQLite query against a 5,000-row table returning twenty rows, and a server-rendered HTML page built from that same query. Node 22 behind nginx, which is what a small production app actually looks like.

The second is that they run the load generator on a laptop, so what gets measured is the laptop's network. I rented a second, much larger machine — four vCPUs, in the same region — purely to generate load, on the principle that the thing doing the measuring should never be the thing that runs out first. At no point did the generator break a sweat.

Every number below is the mean of three fifteen-second runs, and I kept the raw output rather than a summary, for reasons that become clear later.

The numbers

workload	100 connections	400 connections	p50 at 100
static page (nginx)	9,737/s ±491	9,773/s ±405	9.2 ms
JSON endpoint (Node)	1,291/s ±28	672/s ±67	67 ms
SQLite query	1,049/s ±4	556/s ±119	82 ms
server-rendered HTML	1,099/s ±39	521/s ±109	79 ms

Across the whole verification run the box served 1,117,976 requests and returned zero non-2xx responses. Not a handful of errors at the top end. None.

Translating that into the units people actually plan with: the static page at 9,737 a second is 35 million requests an hour. The rendered page, the slowest thing I tested, still does 3.9 million an hour. If a visitor views eight pages in a session, the dynamic path supports something like 490,000 visitors an hour at full tilt.

Whatever your side project is doing, it is not doing that.

What actually runs out

I sampled the server itself once a second throughout, which is the part most benchmarks skip, and the answer is clear: it is CPU, and only CPU.

At saturation the single core was 57% in user space and 21% in the kernel, with 2% idle. Memory was never remotely a factor — the lowest free memory I recorded was 596MB of 961MB, with nginx holding 10MB and Node 83MB. The 1GB that sounds so meagre on the pricing page sat two thirds empty while the CPU was pinned.

One number deserves calling out, because shared-CPU instances have a reputation: CPU steal averaged 0.58% across the loaded period. Steal is the time your virtual core is ready to run and the hypervisor gives it to somebody else, and on a noisy host it can be brutal. I saw a single one-second spike of 23% and essentially nothing otherwise. The cheapest shared instance on the platform was not meaningfully robbed of the CPU it was sold.

The nine-fold gap, and the one line that closes it

A static file goes nine times faster than a rendered page. That gap is the whole story of why small servers feel slow: your machine is fine, it is just doing work per request that it could be doing once per ten seconds.

So I added a single directive in front of the rendered route — proxy_cache with a ten-second lifetime — and ran it again.

rendered HTML	before	after	change
100 connections	1,099/s	18,662/s	17x
400 connections	521/s	18,557/s	34x

The cached dynamic page is now faster than the static file, which looks absurd until you notice the rendered response is 566 bytes against the catalogue page's 6.7KB. Less to push down the wire.

The honest caveat: a ten-second cache means somebody can see ten-second-old content. For a catalogue, a marketing page, a leaderboard, a blog, that is free performance. For a dashboard showing someone their own balance it is wrong, and no amount of throughput makes it right.

The only errors I saw all day were from 2004

The cached run at 400 connections was the first time anything failed: 311 non-2xx responses out of 1,651,331 requests. That is 0.019%, and I could have rounded it away. Instead I read the log.

[crit] open() "/var/cache/nginx/app/3/f2/cd07..." failed (24: Too many open files)
[alert] socket() failed (24: Too many open files) while connecting to upstream
[crit] accept4() failed (24: Too many open files)

Not memory. Not CPU. File descriptors. Ubuntu's nginx ships with worker_connections 768, a default that has been carried forward since machines had a fraction of this one's capability, and a per-process file limit to match.

Two lines of configuration later — worker_connections 8192 and a raised LimitNOFILE — I ran the same test again: 840,277 requests, zero errors, and an empty error log, at 18,557 requests a second.

The $6 machine never hit its limit in that test. My configuration did.

The ceiling nobody mentions

Here is the number that should actually shape your planning, and it has nothing to do with requests per second.

While serving the static page, the box pushed 64.6MB a second, which is 517 megabits. The plan includes 1TB of outbound transfer a month. At that rate you would spend the entire monthly allowance in four hours and eighteen minutes.

Put the other way round, which is the useful way: 1TB is about 146 million page views of that size. You will not run out. But if your traffic ever does approach what this hardware can serve, the bill that arrives will be for bandwidth, not for the server. The CPU is not the constraint and neither is the memory — the pipe is, and it is the line item everyone forgets to model.

What I got wrong

Two things, both in my own instruments rather than in the results.

I built a status check that ran pgrep -f verify_run.sh over SSH to see whether the benchmark was still going. It reported RUNNING, confidently, for about fifteen minutes — during which nothing was running at all, because the script had never been copied to the machine. The pattern was matching the SSH command line containing the words verify_run.sh. It was reporting on itself. I replaced it with a marker file that the job touches when it finishes, which cannot lie in that particular way.

Then, converting bandwidth into page views, I divided a terabyte by 10⁹ instead of 10¹² and got 146,391 page views, a number I very nearly wrote down. It is 146 million. The tell was that it felt small, and the honest lesson is that unit errors in your favour are the ones you catch, while unit errors against you slip through because they sound appropriately humble.

So: is a $6 server enough?

For most things people build, comfortably, and it is not close.

A single shared vCPU with a gigabyte of memory served a million requests without a single error, handled a real SQLite-backed page at over a thousand a second, went to nearly nineteen thousand a second once I let nginx cache the output for ten seconds, and spent the whole time with two thirds of its memory free and its CPU steal under one per cent. The parts that did break were a twenty-year-old default in a config file and my own arithmetic.

The useful advice is not "buy the small one". It is that the bottleneck is almost never where the pricing page makes you look. Before you upgrade the machine, check whether you can cache a route for ten seconds, and check whether you are about to pay for a bigger CPU when what you are actually running out of is bandwidth.

Measured on a DigitalOcean s-1vcpu-1gb droplet in Frankfurt at $0.00893/hour, with load generated from a separate s-4vcpu-8gb droplet in the same region. Both destroyed afterwards; the whole experiment cost under twenty cents.

I had a model translate my locale file. The bug it introduced was correct Japanese.

Remdore — Thu, 17 Sep 2026 10:22:00 +0000

Translating the interface is one of those jobs that sits on the list for a year, because the quote from an agency is real money and the effort of doing it yourself is real time, and neither of those is ever the most urgent thing this week. What I wanted was a number, so I could stop guessing: what does it now cost to put a product's interface through a model instead, and what does that quietly break on the way.

The material is the locale file out of a football quiz app I run, which is a perfectly ordinary Next.js codebase and not special in any way that matters here. All 430 strings went through four models into four languages. The cost turned out to be so small it barely deserves a paragraph, which I was not expecting, and the breakage turned out to include one bug I would have shipped without noticing, which I was not expecting either.

The first surprise was how little of the app was translatable at all

Before any of the interesting work there was a reality check, and I suspect it generalises well past my codebase. The locale file holds 430 strings and 4,593 words, which felt like most of the app until I went and counted how many components ever ask for a translation at all:

51 of 861 components import a translation hook

Six per cent. The rest render their text directly, and a regex hunting for prose sitting in raw JSX flags roughly 1,837 more text nodes that no translation layer will ever reach. That figure is a heuristic and I would not defend the exact number, but the shape of it is not in doubt, because you can go and look at lines like this one:

<Link href="/login">Sign In</Link>

Nothing is going to translate that. So the honest framing of everything below is that I translated one locale file, not an application, and the gap between those two things was bigger than I would have guessed for a codebase I wrote myself. If you are budgeting for internationalisation on the basis of your en.json, the file is probably telling you a comfortable lie.

What the tokens actually cost

Every run went through DigitalOcean's inference API, against DeepSeek v4 Pro, Llama 4 Maverick, GLM 5.3 and Mistral 3 14B. The same 430 strings, in batches of forty, into Bulgarian, Spanish, German and Japanese: 16 model-language pairs, 230 requests.

Measuring the cost through those batches turned out to be slightly wrong, because each response echoes the JSON keys back, and the keys are ASCII regardless of the target language, so they flatten the differences. A cleaner measurement is to hand each model the same paragraph and ask for nothing but the translation:

language	output tokens, relative to English
Japanese	1.66x
Bulgarian	1.61x
Spanish	1.38x
German	1.34x

All four models agreed on the ordering independently. The practical version of that table: if you bill per token, the same sentence costs you between a third and two thirds more to produce for a non-English user, and if you are streaming model output to users in Japanese or a Cyrillic language, that multiplier is sitting on every response you generate, not just the one-off translation job.

For the translation itself, the whole exercise — 430 strings, four languages, four models, everything above — came to a few hundred thousand tokens. It is a rounding error. The cost was never going to be the reason not to do this.

Quality, judged by a machine that does not speak the language

I do not read Japanese, and I was not going to eyeball 1,720 translations. So the gate is mechanical: a different model translates each string back into English, and DigitalOcean's bge-m3 embedding model scores how far the round trip landed from where it started.

language	mean round-trip similarity	below 0.80
German	0.976	2%
Bulgarian	0.973	0%
Spanish	0.965	2%
Japanese	0.944	7%

That is, broadly, a pass. Machine translation of short interface strings is good now, and the rare failures were not random — every one of them was a terse label with the context stripped out of it:

'Tactics Brief · All-Time'        -> 'Tactical Report · Historical'
'How do I play Conquest?'         -> 'How do I play?'
'Retired-roster boards · grids
 built from the legends'          -> 'Legendary players only grid'

The middle one is the one to look at. Conquest is the name of a game inside the app, and the Japanese translation dropped it, so a question about one specific game became a question about the app in general. A proper noun that the model did not recognise as a proper noun simply evaporated, and the sentence that remains reads perfectly well, which is exactly what makes it dangerous.

The failure that would have reached production

Here is the one that matters, and the reason a similarity score is not enough on its own.

Three strings in the file use ICU MessageFormat plurals, the syntax every serious i18n library uses to get "1 attempt" and "5 attempts" right:

{count} {count, plural, one {attempt} other {attempts}}

Checking whether that construct survived translation, by language:

language	ICU plurals intact
Bulgarian	12 of 12
German	12 of 12
Spanish	12 of 12
Japanese	4 of 12

Two of the four models, translating into Japanese, returned this:

{count} 回

Which is correct Japanese. Japanese does not inflect nouns for number, so a plural construct is linguistically pointless, and the model made a sensible call. It also deleted a branch that the formatter requires, and a missing other branch is not a wording problem, it is a runtime error in the component that renders it.

Note what this does to the two gates. The round-trip similarity for those strings is fine, because the meaning genuinely is fine. Only a structural check catches it. The two gates are looking at different things, and if I had run only the clever one I would have shipped the break.

There were quieter versions of the same lesson. GLM 5.3 silently returned 40 fewer keys than it was given in one language, no error, just a shorter object. And between 0.2% and 2.8% of strings came back identical to the English input, which is sometimes right (ExtraTime should stay ExtraTime) and sometimes just a string the model skipped.

What I got wrong

My first placeholder checker reported that every model mangled placeholders in 4% of cases, consistently, across all sixteen runs. That consistency is what made me look: four different models failing at an identical rate on the same string is not how models fail, it is how a checker fails.

The string was the ICU plural above. My regex treated {attempt} and {attempts} as placeholders to be preserved verbatim, so when the models correctly translated them to {опит} and {опита}, it counted the correct answer as a defect. The real ICU problem, the one in the previous section, was sitting underneath that noise and only appeared once I wrote a check that understood the syntax instead of pattern-matching braces.

That is twice in a fortnight that my own instrument produced a tidy, publishable, wrong number. Both times the giveaway was the same: the result was too clean.

What to take from it

If you are thinking about doing this, the cost is not the question. A few hundred thousand tokens translates a locale file into four languages, and the per-language token inflation, real as it is, matters far more for the output you stream to users every day than for a one-time job.

The question is what to check afterwards, and it is not what I assumed. Check the structure first: that ICU constructs survive, that placeholders are intact, that the number of keys you got back equals the number you sent, which is the check that catches a model quietly truncating its own output. Then check meaning, with round-trip translation through a different model and an embedding score, because that catches the missing proper noun a structural check cannot see. And give the model your terse labels with some context attached, since every meaning failure I found was a four-word string with nowhere to stand.

Then go and find out how much of your interface is even reachable from your locale file. In my case it was six per cent of components, and that turned out to be the most useful thing I learned all day.

Show a model your old code and it writes your old bugs: 32 runs, 0% reuse

Remdore — Thu, 17 Sep 2026 06:47:00 +0000

Last July I spent seven pull requests deleting the same component eleven times. Eleven games in my football quiz app had each grown their own search box, and they had drifted apart in the way duplicated code always does: arrow keys behaved four different ways, only four of the eleven kept the mobile keyboard down at the start of a round, several could scroll the page while you were arrowing through results, and one could submit a stale result. The migration replaced all of them with a single shared component, and the final pull request added a test that fails if a twelfth one ever appears.

That gives me something most people writing about AI and code do not have: a repository where I know exactly what the right answer is, and where the wrong answer used to live at a known commit. So I asked a question I had been wondering about since I started letting models write parts of this app. Does the code that already exists decide what the model writes next?

It does, completely.

The experiment

The setup is deliberately boring, because the whole point is that only one thing moves. I wrote out a task asking for a footballer search box on a new game screen, told the model to match the conventions of the code it was being shown, and then sent that same text over and over, eight times per model per condition, at a temperature of 0.7 so the runs would not all be carbon copies of each other.

What changes between conditions is which commit of my own repository gets pasted in above the task. For the first I went back to 82385a5, where nine per-game search components are sitting there and nothing shared exists yet, and for the second I used cc78828, the commit that closed the migration, where the shared component is present and TeamTies is shown calling it. Both conditions get roughly four hundred lines of genuine source from the repository as it stood, so neither is winning on prompt size, which was the first objection I expected and wanted to rule out before I looked at anything else.

The models were DeepSeek v4 Pro, Llama 4 Maverick, GLM 5.3 and Mistral 3 14B, an odd-looking lineup that has a dull explanation: Claude and GPT both come back 403 on my account's tier, so open weights are what I had to work with.

context shown	reused the shared search	hand-rolled a new one	median lines
the forked era	0%	100%	190
after the migration	100%	0%	41

Thirty-two runs each, and not one crossed over. Same model, same instructions, 190 lines of hand-written state machine in one case and a 41-line wrapper in the other, decided entirely by what was lying around in the repository.

I expected a tendency. I did not expect it to be unanimous across four models from four different labs.

The models reproduce the specific bugs, not just the shape

The interesting part is not the line count, it is what is in those 190 lines. The migration existed because eleven copies had drifted on specific behaviours, and the test I added lists them. So I checked the generated components against that same list.

Of the 33 hand-rolled components the old context produced:

0% made the arrow keys wrap around at the ends of the list, which is the first behaviour the drift guard names.
0% used SEARCH_MIN_QUERY_LENGTH, and 97% re-typed a bare >= 2 instead — the exact thing the repository's own documentation tells you never to do.
58% had any mobile focus guard at all, against a rule that says the keyboard must not cover the board until the player has had a go.

These are not generic AI mistakes. They are my team's mistakes, from 2025, faithfully reproduced in 2026 by models that were shown the code containing them. The forked components taught the models to fork, and taught them the defects too.

There is a cleaner way to put the damage. Every one of the 32 components generated from the old context calls useFootballerSearch. That hook was deleted in the final pull request of the migration. All 32 would fail to compile against the repository as it stands today, which is a strange thing to say about code that perfectly matches the codebase it was shown.

So what actually steers it

If old code drags the model backwards, the practical question is what you can do about it when your repository is full of old code. I ran two more conditions to find out.

In the first, the model sees only the forked components, exactly as before, plus one paragraph from the repository's CLAUDE.md: the rule saying every search goes through the shared utility and never hand-roll another typeahead. In the second, the model sees no source for the shared component at all, only its filename in a directory listing.

context shown	reached for the shared search	hand-rolled
forked code only	0%	100%
forked code + the written rule	100%	0%
just the filename in a listing	97%	3%
the shared component's source	100%	0%

One paragraph of documentation, sitting next to nine hundred lines of exactly the code it forbids, flipped every single run. That is a better return than I expected from a file most people assume gets skimmed.

Except the documentation does not finish the job

Here is where the neat story breaks, and it took a second measurement to see it.

Reaching for the shared search only means the model wrote the component's name into its JSX. It does not mean it called it correctly. The component has 23 real props, so I compared the props in each generated call against that list.

When the model could see the component's source, it invented nothing: none of those 32 calls used a prop that does not exist. When it had only the written rule, 28.6% of calls invented at least one. When it had only the filename, 82.1% did, averaging 4.64 imaginary props per call.

So the file listing result is largely a mirage. Telling a model that the component exists reliably stops it hand-rolling a typeahead, and then it writes a confident call to an API it has never seen, with onFootballerSelect and debounceMs and other things I never wrote. The 97% reuse figure is nominal; most of that code does not compile.

The rule and the source do different jobs. The rule decides which road it takes. The source decides whether the code at the end of the road is real.

One thing that did not go wrong

I expected a single leftover fork to poison the well, so I ran a condition with the shared component present and one of the old forked files still sitting in view. It made no difference: every run still reused the shared component, at essentially the same length.

That is worth saying plainly because it contradicts the tidy version of this post. Models are not dragged down by the worst code in the repository, they follow the dominant pattern. You do not have to sweep up every last bad example before your AI-assisted work improves. You have to make the good abstraction exist, and make it visible.

What I got wrong

What I got wrong was the prop-counting instrument, and I nearly published its output.

My first pass reported that every call in every condition invented props that do not exist, including the condition where the model could read the component's source. I believed it for about a minute, because it flattered a story I was already enjoying. Then it occurred to me that a model with the type definition in front of it inventing nine imaginary props on every single run is not a plausible thing to happen.

The regex that was meant to extract the real prop names had matched nothing, so the set of real props was empty and every prop the models used counted as invented. That result was measuring my own broken parser. With the list actually populated, the true figure for that condition is zero, and the real finding — that invention rises sharply as context thins — only appears once the instrument works.

It is the same lesson as the last few of these: when a number arrives that is both extreme and convenient, the first suspect is the thing doing the measuring.

What to take from it

If you are letting a model write code in an existing repository, the repository is your prompt, whether you intended it or not. Everything in these results points the same way. The model is not consulting best practice, it is pattern-matching on what is in front of it, and it will reproduce a pattern you abandoned a year ago with complete confidence and a hook that no longer exists.

Three things follow, in the order they pay off. Delete the old pattern, because as long as it is the only thing in the repo it is the specification. Write the rule down where the tools will read it, since that one paragraph was worth more than every line of example code around it. And make sure the real implementation, not just its name, is reachable, because a model that knows your component exists but cannot see it will invent its interface without hesitating.

The migration was worth doing for the humans. The measurements say it changed what the machines write too, by a wider margin than it changed what we write.

Everything above ran on DigitalOcean's inference API against deepseek-v4-pro, llama-4-maverick, glm-5.3 and mistral-3-14B, 160 completions in total, eight per model per condition.

92% of dev.to posts get zero reactions, and the title advice does not change that

Remdore — Wed, 16 Sep 2026 12:12:00 +0000

I set out to test the advice. Every few weeks someone publishes a piece explaining what works on dev.to, and the recommendations are always the same: put a number in the title, use all four tags, post on a Tuesday morning, add a cover image. I wanted to check those claims against the platform's own data, because dev.to has a public API and nobody seems to have pointed it at this question.

I got an answer, but not to the question I asked. Before you can ask what makes a post do well, you have to know what a normal post looks like, and it turns out almost nobody knows, including me, because the version of dev.to you read is not the one you publish into.

Two websites wearing the same logo

The feed at dev.to is curated. I pulled 2,500 posts from it and looked at the ones published in August, so everything had at least a fortnight to collect reactions. In that sample of 170 posts, the median post had 15 reactions, 70.6% of them had ten or more, and the mean was 28.8. Exactly zero of them had no reactions at all.

Then I sampled the site itself rather than the feed, by picking article IDs at random and fetching each one directly. That gives 460 posts published in August, chosen without any regard for whether anyone liked them. Here is that sample:

	curated feed	the actual site
posts sampled (August)	170	460
mean reactions	28.8	0.21
zero reactions	0.0%	91.7%
ten or more reactions	70.6%	0.4%
zero comments	—	95.7%

Ninety-two per cent of posts, plus or minus about two and a half points at this sample size, get no reaction whatsoever. Not a low number of reactions. None. And 95.7% of them get no comments either.

These are not bad posts. The zero-reaction pile, read at random, looks like this:

0 reactions  Four JavaScript problems I hit writing a chess engine
0 reactions  Delta E is a distance, not a score
0 reactions  How Farm.js compiles React components into direct DOM updates
0 reactions  Why Zod Crashed My Node.js Server

I would read all four of those. They went out into total silence, and the feed I actually see has been quietly filtering them out of my view for as long as I have been posting here.

Getting a fair sample is the hard part

My first attempt was the obvious one. dev.to's API lets you list articles by tag, so I paged through 39 popular tags and collected 82,749 posts. Then, before trusting any of it, I ran a check: the curated feed's August posts are popular by construction, so my big corpus ought to contain nearly all of them. It contained 49%.

So I took one missing post, a webdev article with 60 reactions published on 31 August, and walked twelve pages of the webdev tag listing looking for it. It is not there. What is there is stranger:

page 10: newest=2026-08-31  oldest=2026-08-29
page 11: newest=2026-09-13  oldest=2026-08-27
page 12: newest=2026-08-27  oldest=2026-08-18

Page 11 contains posts newer than anything on page 10. The pages overlap, they run backwards and forwards through time, and posts go missing between them. The listing is not an ordered, complete view of a tag, so you cannot page it to build a corpus, which is precisely what I had just spent forty minutes doing.

Worse, the omissions are not random. Comparing my random-ID sample against the tag corpus, the posts the listing gave me averaged 0.40 reactions while the ones it skipped averaged 0.15, and 19.0% of the included posts had at least one reaction against 5.1% of the excluded. Sampling through the listing quietly hands you a rosier site than the real one. My first draft of this post, written off that corpus, said 85% of posts get nothing. The true figure is 92%, and the error was entirely my instrument.

I also checked that a fortnight really is long enough for a post to finish accumulating. Splitting the August posts by age at the time I fetched them, the share getting any reaction was 13.6% at 14-20 days old and 15.0% at 42-48 days, with no trend in between, so nothing meaningful arrives after the first couple of weeks.

What actually correlates with anything

For the finer comparisons I used the large tag corpus, 45,400 August posts, because the random sample is too small to slice. It leans optimistic in absolute terms, for the reason above, but the relative differences between groups are what matter here.

The advice is not all wrong. A cover image goes with 23.7% of posts getting at least one reaction against 11.2% without. Writing in the first person, a title with "I" or "my" in it, goes with 24.7% against 13.9%. Length helps up to a point, with posts of three to seventeen minutes' reading time doing better than posts under three minutes. Four tags beat one, by 16.0% against 3.5%.

Two pieces of standard advice are simply backwards. Titles beginning with "How" did worse than titles that do not, 12.2% against 15.1%. Listicles, the numbered-list titles, got at least one reaction less often than other posts, 9.5% against 15.0%, though their mean was higher, 0.80 against 0.50, which is the signature of a format that mostly flops and occasionally spikes.

The tag you choose matters more than anything you do to the title. Among tags with at least 300 posts:

tag	posts	any reaction
css	560	38.8%
showdev	960	38.2%
frontend	541	33.6%
typescript	1,556	30.1%
crypto	926	1.1%
jobs	463	0.9%
defi	925	0.1%
tech	800	0.0%

Eight hundred posts tagged tech in one month, and not one of them got a single reaction.

And posting more is associated with doing worse per post, not better. Authors publishing one to five posts in August had 23.3% of them get a reaction; authors publishing 21 to 25 had 7.5%. Those high-volume authors are not a curiosity either, they produced 18,386 of the 45,400 posts in the corpus.

The part that undoes most of the above

All of those comparisons share a flaw. If experienced writers with existing followers are also the people who add cover images and write in the first person, then I am measuring the audience, not the technique.

So I ran it again inside each author. For every author with at least four posts in the month, I compared their own posts with a given feature against their own posts without it, then looked at the distribution of those paired differences. If a first-person title genuinely helps, an author's first-person posts should beat their other posts.

They do not. Across 254 authors, the median paired difference for first-person titles was −0.08 reactions, with a 95% confidence interval of [−0.13, +0.00]. Listicles came out at −0.08, [−0.12, −0.03]. Question-mark titles, −0.08, [−0.14, −0.04]. Colons, 0.00. Every apparent effect from the previous section collapses to nothing, or to very slightly negative, once each writer is compared against themselves.

The honest reading is that the title patterns were never doing the work. They were a marker of which kind of account was posting, and when you hold the account fixed they stop predicting anything. What survives the within-author test is not the phrasing, it is which tag you land in and whether anyone was already reading you.

There was one result I could not explain away, and the sample is small enough that I would not lean on it: the 273 posts carrying dev.to's new AI-assisted disclosure label averaged 4.06 reactions with 11.0% reaching ten, against 0.48 and 0.7% for everything else. That is either a real effect or, more likely, evidence that the people who bother setting a brand-new metadata field are unusually engaged with the platform to begin with.

Where I sit, since it would be cowardly not to say

My last twenty posts run from 5 to 16 reactions, median 8. Against the random sample, a post with 8 reactions beats 99.6% of dev.to. Sixteen beats everything in a 460-post draw.

That sounded like good news for about ten seconds. What it actually means is that the bar is on the floor: writing something that a handful of people react to puts you in the top half of one per cent, and the median experience of publishing here is being read by nobody at all.

What I got wrong

Twice, in the same afternoon, and both were instrumentation rather than analysis.

The first fetch piped its progress through tail, which buffers, so I watched an empty log for twenty minutes and assumed it had hung. It had not; it had collected 20,596 posts and was holding them in memory to write at the end. I killed it and lost all of them.

The second is the one that would have ruined the post. I had a complete-looking corpus of 82,749 posts and a headline number, and the only reason I did not publish 85% is that I made myself check the corpus against a list of posts I knew should be in it. If I had skipped that check, everything above would read the same and be wrong by seven percentage points, in the flattering direction. The check took four minutes.

What to take from it

If you write here, the relevant comparison is not the feed. The feed is the top fraction of a per cent, and measuring yourself against it is like judging your running against the people on television.

Pick your tag deliberately, because that is the one input with a large and consistent association. Put a cover image on it. Then stop optimising the title, because within a given author it does not appear to matter, and spend the time on the thing that does: being worth following, so that the next post starts with an audience rather than hoping to find one.

And if you are going to publish numbers about a platform, check your sample against something you already know the answer to. Mine was wrong in the direction that made the story nicer, which is the direction these things usually fail in.

Only 10 of the top 1000 sites hide the hostname you are visiting. I built the tool that counts.

Remdore — Tue, 15 Sep 2026 07:01:00 +0000

A few days ago I wrote about how the name of the site you visit over HTTPS travels across the network in plain text, sitting in the TLS ClientHello where anything on the path can read it. The reaction I did not expect was how many people wanted to know the same thing about their own sites, and had no quick way to find out. So I built the quick way, a small web app that answers one question: does this domain's hostname leak, and could it not?

You type a domain, it reads that domain's public DNS, and it tells you two things. Whether the site publishes an Encrypted ClientHello config, which is the only thing that can hide the hostname, and if it does, what cover name a watcher would see instead of the real one. It performs no handshake and needs no key, because the whole point of the original piece was that none of this is secret in the first place.

What it actually does

The interesting information lives entirely in DNS, which surprised me when I first worked it out. A site that supports ECH publishes its public key in a DNS record of type HTTPS, the same record that carries things like the ALPN list and IP hints. So the check is: fetch that record over DoH, look for an ech= parameter, and if it is there, decode it far enough to read the version, the key-exchange algorithm and the public_name. That is the cover hostname, the decoy that appears on the wire in place of wherever you were really going.

When a domain does publish ECH, the tool shows you the lot:

The whole check is one short function. It reads public DNS, sends nothing to the site you are asking about, and keeps no record of what you type, because there is nothing it would need them for. That also makes it cheap and safe to run, which matters for the next part.

So I pointed it at the top thousand sites

A single-domain checker answers your question about your site. The more interesting question is how common ECH actually is, so I fed the tool a list instead of a box. The command-line side of it takes a file of domains and reports how many publish ECH, and I ran it over the top 1000 domains by traffic.

Ten of them publish ECH. Ten, out of a thousand. That is one per cent, and 992 of the rest leak their hostname exactly the way the first post described, with the remainder failing to resolve.

The ten are the part worth staring at:

tinyurl.com          cover=cloudflare-ech.com
cedexis.net          cover=cloudflare-ech.com
sagepub.com          cover=cloudflare-ech.com
sxyprn.com           cover=cloudflare-ech.com
gizmodo.com          cover=cloudflare-ech.com
animeflv.net         cover=cloudflare-ech.com
remove.bg            cover=cloudflare-ech.com
arnebrachhold.de     cover=cloudflare-ech.com
yayoye-spiele.com    cover=cloudflare-ech.com

Every single one hides behind the same cover name, cloudflare-ech.com. Not one of them is Google or Amazon or Microsoft or a bank. They are a scattering of ordinary sites that happen to sit on Cloudflare, in zones where Cloudflare has switched the feature on. ECH in the top 1000 is not really a story about those sites choosing privacy; it is a story about one provider flipping a setting for some of its customers and not others. Even cloudflare.com itself, the apex, does not publish it, though the test host crypto.cloudflare.com does.

I pointed the tool at my own sites too, because it felt dishonest not to. extratime.world, a football quiz site I run, leaks its hostname just like the other 992. I have not turned ECH on either, and having now built the thing that measures it, I understand exactly why almost nobody has: it is off by default, it needs your DNS provider and your CDN to cooperate, and it only helps at all if the visitor's DNS is encrypted too. It is not a checkbox, it is a small alignment of four different parties, and the survey is what that looks like from the outside.

The number that is not the number

The tempting headline is "one per cent of the web supports ECH", and I want to be careful, because that is not quite what I measured. I measured the top 1000 by a particular traffic ranking, on one day, resolved through one DoH provider. A different list, or the same list next month, would give a different count, and the long tail of small Cloudflare-hosted sites almost certainly has a higher rate than the giants at the top. So the honest claim is narrower and more interesting than the headline: among the most-visited sites, the ones whose traffic a network observer would most want to profile, ECH is essentially absent, and where it exists it is one company's doing.

Where it ran, and where it is now

I hosted the live copy on a 1 vCPU DigitalOcean droplet in Frankfurt while I took the screenshots above, which is the honest way to check that a thing actually serves traffic rather than just runs on my laptop. I have since taken that droplet down, so there is no public instance to link you to and nothing accruing a bill.

That is deliberate, and it is the better shape for this kind of tool anyway. The whole thing is open source, it is one small container, and running your own copy is two commands:

git clone https://github.com/oceanforge/sni-leak-check
cd sni-leak-check && docker compose up --build

Then it is on localhost:8000 and it is yours. A tool that inspects your infrastructure is better run by you than pointed at someone else's server, and this one is small enough that there is no reason not to.

What I got wrong on the way

The first time I started the container to test it, the page that came back was not my app. It was the admin API of a completely different project of mine that happens to run on the same machine, because I had mapped my new container to port 8000 and something was already sitting there. The health check even passed, because there was a healthy service on that port, just not mine. For a confused minute I thought my app was serving someone else's HTML.

It is the same lesson that keeps recurring in these posts, wearing yet another costume: a green check is not proof that the thing you think you are testing is the thing that answered. The fix was to move to a port nothing else was using, and to actually read the page title rather than trust the 200. I now check the title.

Contributing

The app does the one job well and there is a lot of obvious room to make it better, so I have left a set of good first issues on the repository: showing the raw ECH bytes with each field labelled, a bulk-check table, a shareable permalink, actively capturing a real ClientHello to show the leak rather than inferring it. They are small and self-contained on purpose. If you have been looking for something to contribute to during Hacktoberfest, this is an open invitation, and the issues are labelled to match.

The takeaway

The original post argued that HTTPS keeps two different promises and only one of them, the privacy of your traffic, has been kept for most of the web's life. This tool is the argument turned into a thing you can run against any domain, including your own. Check a few of the sites you use every day. Almost all of them will tell you the same thing, that the padlock protects the conversation and leaves the guest list in plain sight, and now you can see it for yourself in about a second.

The hostname you visit over HTTPS is sent in plain text

Remdore — Tue, 15 Sep 2026 05:50:49 +0000

I had assumed, without ever checking, that the padlock meant nobody on the network could tell which site I was visiting. The connection is encrypted end to end, so surely the destination is part of what gets hidden. It is not. The name of the site you are asking for travels across the network in plain readable text, at the very start of every HTTPS connection, and I wanted to see it with my own eyes rather than take anyone's word for it.

So I captured the first thing my machine sends when it opens an HTTPS connection, the TLS ClientHello, and went looking for the hostname in the bytes. It was not hard to find.

The hostname, sitting in the packet

Here is the ClientHello openssl sent when I asked it to connect with the server name secret.wikipedia.example. This is the raw handshake, dumped as hex before any key exchange has happened:

01 00 00 d7 03 03 dd 4f 36 06 ...
... 00 00 1d 00 1b 00 00 18 73 65 63 72 65 74 2e 77
69 6b 69 70 65 64 69 61 2e 65 78 61 6d 70 6c 65 ...

Those bytes from 73 onward are ASCII. 73 65 63 72 65 74 is "secret", and it runs straight through to "secret.wikipedia.example". The hostname is not hashed, not encrypted, not obscured. It is the literal string, sitting in the clear inside a structure called the Server Name Indication extension.

The handful of bytes in front of the name are just the wrapping, and once you have read them once the whole thing stops being mysterious. The pair 00 00 is announcing an extension of type zero, which is the number TLS assigns to server_name. After that comes a length, 00 1d, twenty-nine bytes, then another length for the list inside it, then a single 00 marking the entry as a host_name rather than anything else, then the length of the name itself, 00 18, which is twenty-four. Count twenty-four bytes on and you have run exactly to the end of "secret.wikipedia.example". I wrote a few lines to do that walk so I would not be counting nibbles by hand, and it landed where the hex said it would:

server_name extension found at offset 104
host_name length 24 -> 'secret.wikipedia.example'

Notice what did not happen there. Nothing was decrypted, and nothing could have been, because the key exchange is still several messages away when this is sent. The name goes first, and it goes in the open, and that is the protocol working as intended rather than failing.

Why it is sent in the clear

This is not a bug or an oversight, which is the part that took me a moment to accept. The server needs to know which certificate to present, and a single IP address today serves hundreds or thousands of different sites behind one TLS terminator. The server has to be told which site you want before it can hand you the right certificate and set up encryption for it. The SNI is how it is told. The chicken-and-egg problem, that you cannot encrypt the request for a site with that site's key before you have asked for the site, is real, and for twenty-odd years the answer has simply been to send the name unprotected.

A passive listener needs no key and no handshake

To make sure I was not being fooled by openssl showing me its own internal state, I wrote a listener that does nothing but read. It accepts a connection, reads the first packet, and pulls the hostname out. It never completes the handshake, never has a private key, never decrypts anything. It is about fifteen lines. Pointed a client at it asking for login.mybank.example.com:

read 1566 bytes, first byte 0x16 (0x16 = TLS handshake)
hostname the client is asking for: 'login.mybank.example.com'
bytes decrypted to get it: 0

That is the entire capability a corporate proxy, a national firewall, or your ISP needs to know every site you visit: read the first packet, skip to offset-something, read the length-prefixed string. The connection contents stay perfectly encrypted and completely beside the point. This is exactly how filtering by domain works without anyone breaking the encryption, and it is why "but it's HTTPS" is not the privacy argument people think it is. They are not reading your traffic. They are reading the label on the envelope, and you wrote it in block capitals.

TLS 1.3 does not fix it

I genuinely expected TLS 1.3 to have closed this, because 1.3 encrypts far more of the handshake than 1.2 did, the certificate included. So I ran the same listener against a 1.3-only client asking for tls13.secret.example:

read 1489 bytes, first byte 0x16
hostname the client is asking for: 'tls13.secret.example'
bytes decrypted to get it: 0

Still there, still readable, still zero decryption. TLS 1.3 encrypts the server's certificate so a watcher cannot see which cert came back, but the ClientHello, the client's opening message, is by definition sent before any keys exist, and the SNI lives in the ClientHello. Moving it was left to a separate mechanism.

The actual fix, and where it stands

That separate mechanism is Encrypted Client Hello, ECH, and it works by solving the chicken-and-egg problem with DNS. The server publishes a public key ahead of time, in a DNS record, and the client fetches it before connecting and uses it to encrypt the real ClientHello, hostname and all, inside an outer one that carries only a generic cover name.

This is not theoretical, there are real ECH configs published right now. I pulled the DNS HTTPS record for crypto.cloudflare.com and decoded the ech= blob in it:

ECHConfig version : 0xfe0d  (the ECH standard)
config_id         : 192
KEM id            : 0x0020  (X25519)
public key        : 32 bytes, 06dbbb64d9e36721...
public_name (seen on the wire instead): 'cloudflare-ech.com'

That is the whole idea in one record. The 32-byte X25519 key is what the client encrypts the true hostname with, and cloudflare-ech.com is the public_name, the decoy that a passive listener would see in the SNI instead of wherever you were actually going. Everyone connecting to an ECH-protected Cloudflare site looks, from the network, like they are visiting the same single cover name.

Two things stopped me short of showing a working encrypted handshake, and both are the honest state of ECH rather than a limitation of my afternoon. The openssl I have, 3.5, has no ECH support in its s_client at all, so I could decode the published config but could not make a client use it. And adoption is patchy even at the vendor that invented it: the same DNS lookup for cloudflare.com itself, the apex, returned an HTTPS record with no ech= field. The test host has it, the flagship domain does not.

There is also a deeper catch worth naming. ECH moves the secret out of the TLS handshake, but it moves it into DNS, because the client has to look up that public key by name first. If that DNS query goes out in plaintext, which is still the default on most machines, the watcher just reads the hostname from the DNS request instead and nothing has been gained. ECH only buys you privacy when your DNS is also encrypted, so it is really one piece of a set, not a switch you flip.

What I got wrong on the way

My first plan for proving the hostname was on the wire, and not just inside openssl, was to capture the packet with tcpdump and grep the raw bytes for it. That failed immediately, because tcpdump needs privileges to put the interface in promiscuous mode and this machine had no passwordless way to give it them.

The fix turned out to be better than the plan. Instead of sniffing my own traffic from above, I wrote the fifteen-line listener and pointed the client at it, so the "attacker" was just an ordinary TCP server reading its input. That is not a weaker demonstration than a packet capture, it is a truer one, because a real SNI-based filter is not doing exotic packet capture either. It is a box in the path reading the first bytes of the stream, which is precisely what my little server was. The privilege I could not get turned out to be privilege the demonstration never needed.

See it yourself

There is nothing to install for this. If you have openssl you can watch your own machine announce its destination, right now:

printf 'Q\n' | openssl s_client -connect example.com:443 \
  -servername anything.you.like -msg 2>&1 | sed -n '/ClientHello/,/</p'

Look for the 00 00 extension in the hex, step past the length bytes the same way I did above, and whatever name you passed will be sitting there in ASCII. And if you want to know whether a given site has bothered to publish an ECH config yet, the answer is in its DNS HTTPS record:

curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=crypto.cloudflare.com&type=HTTPS' \
  | grep -o 'ech=[A-Za-z0-9+/=]*'

An ech= blob coming back means that host is able to hide its name from the network. Try it on a few of the sites you actually use, and most of them will hand you back nothing at all.

What to take away

The encryption in HTTPS is real and it is doing its job: the contents of your connection are private. But privacy of contents and privacy of destination are two different promises, and only the first one has been kept for most of the web's history. The name of every site you visit is still, today, sent in a form any box on the path can read without doing any work. ECH is the fix, it exists, and the config is sitting in DNS waiting, but it needs encrypted DNS beside it and it is not yet switched on for most of the places you go. Until it is, assume the network knows the guest list even though it cannot hear the conversation.

Follow-up: I turned this into a tool you can run against any domain, and surveyed the top 1000 sites with it. Only 10 hide the hostname.

A container is just a process with a few private views. I built one in thirty lines.

Remdore — Mon, 14 Sep 2026 08:50:00 +0000

Here is a thing that bothered me for years without my quite admitting it: I did not know what a container actually was. I knew how to run one. I could not have told you what the kernel does when you start one, because the honest answer is that there is no such kernel object to point at. A container is just a normal process that has been handed a few private versions of things it would otherwise share, and I only really believed that once I built one myself, by hand, in about thirty lines and with Docker nowhere in sight. The part that surprised me was how little there was to it.

The process I ended up with thought it was PID 1 on a machine called container. It could not see a single one of my other processes. It had its own network, empty, and its own root filesystem, and if it reached for more than 20MB of memory the kernel killed it. That is a container, all of it. And the thirty lines are not doing anything clever, they are just asking the kernel, one request at a time, for each of those private views.

Namespaces are the whole trick

The Linux feature underneath all of this is the namespace. A namespace is a private copy of one kind of global resource. There are several: PID, mount, network, UTS (the hostname), IPC, user. A normal process shares all of them with everything else on the machine. unshare is the command that says: give me a fresh one.

The entire isolation half of a container is one command:

unshare --user --map-root-user --mount --uts --ipc --pid --fork --net \
  python3 enter.py rootfs

Each flag is buying one kind of isolation and no more. --uts hands me a private hostname, which is why I can rename the machine to container and nothing on the host notices. --pid --fork gives a private process table, and because of the fork the child, not the unshare itself, is the one that becomes PID 1. --net drops me into an empty network stack: one loopback interface, down, and nothing else at all. --mount gives a private set of mounts, which is what lets me swap the filesystem later. The odd one out is --user --map-root-user, and it is the flag doing the quiet heavy lifting, because it makes a user namespace and maps my normal login to root inside it. That is what lets the process mount things and call pivot_root, while out on the host I am still nobody special.

Run that and look around inside, and the isolation is already total:

hostname: container
pid: 1
--- processes (own PID ns) ---
PID   USER     TIME  COMMAND
    1 root      0:00 /bin/sh
    4 root      0:00 ps -ef
--- net ---
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN qlen 1000

Two processes visible where the host has eighty-seven. One network interface, down. A hostname I chose. I did not install anything and I was never root on the host. That output is the entire point of the post: isolation is not something you build, it is something you ask the kernel for, one namespace at a time.

Swapping the root filesystem is the fiddly part

The one genuinely tricky step is giving the process a different root directory, because this is where the difference between a toy and a real container lives.

The obvious move is chroot, and it does work, but it is also the bit people warn you off, because a sufficiently privileged process can climb back out of a chroot. The old root is still mounted underneath, only hidden, and there are well-worn tricks for reaching it again. So the real runtimes reach for pivot_root instead. It swaps the root mount out and then lets you unmount the old one completely, and once the old root is unmounted there is simply nowhere left to escape to.

pivot_root is a syscall with no friendly wrapper on my machine, so enter.py calls it directly through libc. The sequence has three requirements that each cost me a run to discover. The new root has to be a mount point, so I bind-mount the rootfs onto itself. The parent mount has to be private, or pivot_root refuses with EINVAL, so I remount / as private first. And after the pivot the old root hangs under a directory I have to detach:

mount(None, "/", None, MS_REC | MS_PRIVATE)
mount(rootfs, rootfs, None, MS_BIND | MS_REC)
os.chdir(rootfs)
sc("pivot_root", b".", b"oldroot")
os.chroot("/")
sc("umount2", b"/oldroot", MNT_DETACH)   # the host filesystem is now gone

After that last line the container cannot see the host filesystem at all. Not hidden, gone. ls /oldroot returns "No such file or directory", and the only mounts left are the new root and a fresh /proc. That is the line that turns a chroot into a container.

The mistake that made ps lie

My first version used chroot and mounted /proc the easy way, with unshare --mount-proc. Inside, ps showed no processes at all, and for a happy minute I thought I had built the most isolated container in history.

I had not. ps reads /proc, and --mount-proc mounts it over /proc in the mount namespace before the chroot happens. After the chroot, the process is looking at rootfs/proc, which is a different, empty directory. ps was not seeing an empty process table, it was seeing an empty folder. The isolation looked perfect because the instrument was unplugged.

The fix is to mount /proc after the root swap, from inside the new root, so it is the container's /proc that reflects the container's PID namespace. Once I did that, ps showed exactly two processes, which is the real answer, and a much better one than zero, because zero was a lie and two is proof the PID namespace works.

Namespaces isolate. Cgroups limit.

Isolation is only half of what people mean by "container". The other half is the ceiling, the guarantee that the thing cannot run off with all the memory on the box, and namespaces do exactly nothing about that. That is a different kernel feature entirely, control groups, and once I had built the two halves separately the division stuck in my head: namespaces govern what a process can see, cgroups govern what it can take.

A cgroup v2 memory limit really is just a number in a file. You put the process into the cgroup, write a byte count into memory.max, and the kernel does the rest. To watch it actually bite I compiled a tiny static binary, dropped it into the rootfs, and had it grab a megabyte at a time, touching each one so the pages were genuinely resident rather than just promised, then set the cap to 20MB and let it run:

cap is 20MB. starting the memory hog as a child...
allocated 5 MB
allocated 10 MB
allocated 15 MB
Killed
hog exited with code 137

That exit code, 137, is 128 plus 9, so signal 9, a SIGKILL, and the sender was the kernel's out-of-memory killer firing the moment the cgroup went over its cap. The container's own shell was fine, still sitting there as PID 1, because the killer took only the greedy child and handed its memory back. So there it is: a real memory ceiling, enforced by the kernel, on a process I had isolated by hand a few minutes earlier.

Getting there cost me two more mistakes. My first memory hog filled a tmpfs instead of allocating anonymous memory, and tmpfs pages are not freed when the writing process dies, so the OOM killer killed the hog, the memory stayed full, and it went round again and killed PID 1, and the whole container collapsed. Anonymous memory that frees on death is the honest way to demonstrate a limit. And I could not attach the process to a cgroup by hand at all at first: on this machine my shell lives in a cgroup called /init.scope that I do not own, outside the tree systemd delegates to my user, so every attempt to move it returned EIO. The way through is systemd-run --user --scope, which starts the process inside the delegated tree where I am allowed to set limits. Which is itself the lesson: namespaces are genuinely unprivileged, cgroups need either root or a slice someone delegated to you.

What it is not

A container shares the host kernel, and once you have built one by hand you can feel exactly how thin the separation is. Inside my container, uname -r prints 6.6.114.1-microsoft-standard-WSL2, the host's kernel, because it is the host's kernel; there is only one, and every container on a machine is running on it. cat /proc/uptime inside reported the same 258,345 seconds as the host, because I did not ask for a time namespace and so the container shares the host's clock and boot time.

This is the whole difference between a container and a virtual machine, and it is not a detail. A VM brings its own kernel and the isolation goes down to the hardware. A container is your process with some of its views swapped out, running on the same kernel as everything else, and a kernel bug is a shared fate. That is the trade: containers are cheap because they are barely anything, and they are barely anything because they are just your process wearing a few borrowed namespaces.

Run it yourself

You need a root filesystem to run in. The easy way to get one is to borrow it from an image you already have:

mkdir rootfs
docker export $(docker create alpine:3.20) | tar -C rootfs -xf -

Then the launcher is the one unshare line above plus the enter.py that does the pivot, twenty-seven lines of it, calling mount, pivot_root and sethostname through libc. Run it and check the three things that prove it worked: hostname is what you set, ps shows one or two processes and not the host's hundred, and ls /oldroot fails because the host filesystem is gone. If ps shows nothing, your /proc is in the wrong place, which is the same mistake I made.

What to take away

The next time Docker feels like magic, remember that the isolating part of it is six flags to unshare and a pivot_root, and the limiting part is a number in a file. Everything else Docker gives you, images, layers, networking, a registry, is real engineering built on top, but the container itself, the thing people imagine as a sealed box, is a process that asked the kernel for a few private views and got them. It is worth building one once, because after you have, "it's just a process" stops being a slogan and starts being something you have watched happen.

ESLint took 4.4s to lint Vue's core. oxlint took 0.24s. Then I turned on the type-aware rules.

Remdore — Sun, 13 Sep 2026 15:33:00 +0000

ESLint took 4.4 seconds to lint 445 TypeScript files. oxlint took 0.24. Turn on the type-aware rules that most projects actually want and ESLint climbs to 12 seconds, while oxlint, doing the type-aware pass too, finishes in under one. I went in expecting to write that oxlint was fast but limited. The limited part did not survive the test.

The setup

oxlint is the JavaScript and TypeScript linter from VoidZero, the company Evan You started after Vue and Vite, written in Rust and pitched as a much faster ESLint. I wanted a real number on a real codebase, not a toy, so I cloned the Vue core repository, 445 TypeScript files and about 150,000 lines, and linted the same tree four ways in a clean Node 20 container.

Two tools, two modes each. ESLint 9 with typescript-eslint, once with the plain recommended rules and once with the type-aware recommendedTypeChecked set that needs the TypeScript compiler behind it. Then oxlint, once with its defaults and once with --type-aware. Every number below is a wall-clock median of repeated runs on the same files.

Linter	Mode	Time
ESLint	recommended (syntactic)	4.4s
ESLint	recommendedTypeChecked (type-aware)	12s
oxlint	default (syntactic)	0.24s
oxlint	--type-aware	0.9s

The syntactic number is 18x, and that undersells it

On the plain recommended rules, oxlint linted the tree in 0.24 seconds against ESLint's 4.4, about eighteen times faster. But even that includes Node starting up and npx resolving the binary. oxlint prints its own engine time at the end of a run, and for this codebase it was 75 milliseconds. The actual linting of 150,000 lines took less than a tenth of a second; the rest was process startup.

That is the difference between a linter you run in a pre-commit hook and one you run in CI and hope finishes. At 75 milliseconds you can lint on every keystroke. At 4.4 seconds you lint when you remember to, or you wait for the CI job to tell you.

Type-aware is where I was wrong

Here is the part I got wrong, and it is the more interesting result.

The rules developers actually reach for are the type-aware ones. no-floating-promises, no-misused-promises, await-thenable: the checks that catch the bugs that matter, and every one of them needs the type checker to know what a value actually is. That is also why they are slow. ESLint's type-aware pass on this codebase took 12 seconds, nearly triple its syntactic run, because it has to build a TypeScript program before it can lint a line.

I had written, in my head, the tidy conclusion: oxlint is fast because it skips this, it does the cheap syntactic rules and leaves the expensive type-aware ones to ESLint. A fast first pass, not a replacement.

Then I checked, and oxlint has a --type-aware flag. It runs the type-aware rules through a companion called tsgolint, and on the same codebase it finished in 0.9 seconds. Type-aware. Under a second. That is roughly thirteen times faster than ESLint doing the same class of work, and it is still five times faster than ESLint's cheap syntactic run.

So the story is not "oxlint is fast because it does less". oxlint doing the expensive, type-aware analysis beat ESLint doing the cheap, syntactic one, by a factor of five.

The honest caveats, because there are several

This is where I have to be careful, because a lint-time comparison is easy to make unfair.

The rule sets are not identical. ESLint's recommended set and oxlint's default set overlap heavily but are not the same list, so I am measuring the time to lint the same files to a comparable standard, not the time to run byte-for-byte identical checks. oxlint reported 96 rules on the syntactic run and 111 with type-awareness on; typescript-eslint's sets are their own count. If you need one specific ESLint rule or a custom plugin that only exists for ESLint, oxlint may simply not have it, and no speed number rescues a missing rule.

The type-aware mode is newer and needs help. It is behind a flag, it pulls in the separate oxlint-tsgolint package, and oxlint itself calls the type-checking part experimental. When I first ran --type-aware without that package it failed cleanly and told me what to install, which is the right behaviour, but it is a step, not a default. The 0.9-second number is real; it is just not what you get from a bare oxlint invocation.

And the type checker underneath is a reimplementation, not tsc. tsgolint is a Go-based TypeScript type checker, and the whole reason it is fast is that it is not the official compiler. For linting that is a reasonable trade, but it is a different implementation of the type rules, and "different implementation" is exactly the phrase that should make you test it against your own code before trusting it in CI.

Where a football site feels this

A TypeScript frontend like ExtraTime runs the linter constantly: on save in the editor, on every commit through a pre-commit hook, on every pull request in CI. At ESLint's 4 to 12 seconds, the pre-commit hook is the thing everyone eventually adds --no-verify to get around, and the CI lint job is a minute of a runner's life on every push. At oxlint's sub-second, the hook stops being an interruption and the CI line stops being something you notice. It is the same code being checked; the difference is whether checking it is fast enough that nobody tries to skip it.

What I got wrong on the way

I nearly published the wrong limitation. My draft, before I ran the last test, said oxlint's ceiling was that it does not do type-aware linting, that it is a fast syntactic pass and you still need ESLint for the rules that need types. That is the received wisdom about fast linters and I repeated it without checking.

It took one --help to find the --type-aware flag and one more run to get 0.9 seconds out of it. The lesson is the one that keeps recurring: the tidy limitation that makes your narrative balanced is exactly the claim you have not tested. I had a clean story about a fast-but-limited tool, and the limit was not there. The real caveats, the ones above, are messier and less quotable, which is usually how you can tell they are the real ones.

Run it yourself

git clone --depth 1 https://github.com/vuejs/core
cd core && npm i -D eslint typescript-eslint typescript oxlint oxlint-tsgolint

# ESLint, syntactic then type-aware
time npx eslint "packages/**/*.ts"
time npx eslint -c eslint.typed.mjs "packages/**/*.ts"

# oxlint, syntactic then type-aware
time npx oxlint packages
time npx oxlint --type-aware packages

Watch the number oxlint prints at the end of its own run, the "finished in Nms" line. That is the linting; everything else your time shows is Node waking up.

What to do about it

Add oxlint as the fast gate and keep the slow one where it earns its place. Run oxlint in the pre-commit hook and the first CI step, because at sub-second cost there is no reason not to, and it will catch the great majority of issues before anything slower starts. Keep ESLint for the specific rules or plugins oxlint does not have yet, and run it once in CI rather than on every save. The point is not to pick a winner. It is that the fast tool is now fast enough to run everywhere, and the only question left is which handful of checks still justify the slow one.

A warm pip install took me 13 seconds. uv took 56 milliseconds.

Remdore — Sun, 13 Sep 2026 14:33:00 +0000

A warm pip install of a normal web backend took 13 seconds on my machine. The same install with uv took 56 milliseconds. Not 56 milliseconds faster. 56 milliseconds total, for 63 packages, including numpy and pandas and pillow.

I did not believe it either, so I ran it enough times to be sure the number was real and not a no-op. It is real, and the reason it is real is the interesting part.

What I measured

uv is the Python package installer from Astral, the company behind the Ruff linter, written in Rust and aimed squarely at pip. The pitch is "10 to 100 times faster". I wanted to know where in that range real life lands, so I built a requirements file that looks like something you would actually deploy: FastAPI, uvicorn, SQLAlchemy, Alembic, Pydantic, Celery, Redis, pandas, numpy, pillow, the password and JWT libraries, gunicorn, twenty top-level packages that resolve to sixty-odd.

Then I installed it four ways, three times each, in a clean Python 3.12 container: pip and uv, each from a cold cache into a fresh virtual environment, and each from a warm cache into a fresh virtual environment. Cold means the download cache was wiped first, the state a CI runner is in without caching. Warm means the cache was kept but the environment rebuilt, the state your laptop is in all day.

	pip	uv	uv is
Cold cache	~26s	~5.4s	~4.8x faster
Warm cache	~13.2s	~0.056s	~236x faster

Both resolved the same versions. I checked FastAPI, pandas, numpy, SQLAlchemy and Pydantic across the two environments and they matched exactly, so this is not uv winning by installing less.

The warm number is the one that matters, and it needs explaining

Cold, uv is about five times faster, and that is mostly parallel downloads: pip fetches packages fairly sequentially, uv saturates the connection. Useful, not shocking.

Warm is where it stops being a speedup and becomes a different category. 13 seconds down to 56 milliseconds is not pip with the slow parts removed. It is a fundamentally different operation.

pip, even with every wheel already in its cache, still copies each one into the new environment and runs the install machinery for it. Sixty-three packages, sixty-three unpack-and-copy operations, and that is your 13 seconds. It is doing real filesystem work proportional to the size of your dependencies, every single time you build an environment.

uv keeps a content-addressed global store, and by default it populates a new environment by hard-linking to the files already in that store rather than copying them. A hard link is a directory entry, not a copy of the data, so the cost is metadata and almost nothing else. That is why sixty-three packages land in 56 milliseconds: nothing is being copied, the files are already on disk and uv is just pointing at them.

Once you see it that way the number stops being surprising and starts being obvious. The question is not why uv is fast. It is why we accepted copying our entire dependency tree on every environment build for so long.

The same trick pays off on disk. I built three separate environments from the same requirements and measured what they actually cost. The cache held 225MB of package files. The three environments, added on top, cost about 12MB of real disk between them, because every file in them is a link back to the cache rather than a copy. pip would have written three full copies, roughly 675MB, to hold the same three environments. If you keep several environments around, uv is not just faster to build them, it stores them for a fraction of the space.

The catch, and it is a real one

The hard-link trick only works when the cache and the environment live on the same filesystem. Links cannot cross a mount point, so the moment they are on different disks uv falls back to copying, and copying is what made pip slow.

This is not academic, it is the normal shape of CI. The runner restores your cache onto one mount and builds the environment on another, and there goes the hard link. So I measured the fallback directly, forcing uv into copy mode:

uv warm install	time
same filesystem (hard link)	0.08s
forced to copy (cross-filesystem)	0.32s

Copy mode is four times slower than linking, exactly as you would expect. But look at the absolute number: 0.32 seconds, against pip's 13. Even stripped of its best trick, forced to copy every file the way pip does, uv is still about forty times faster, because it is also resolving and unpacking in parallel Rust instead of sequential Python. The hard links are the spectacular part; they are not the whole advantage.

Where a football site would feel it

If you run a Python backend, the place this lands is CI. A site like ExtraTime rebuilds its environment on every push: every pull request, every deploy, every test run installs the dependencies from scratch. On pip that is 13 to 26 seconds of a runner sitting there copying pandas around, on every job, forever. Swap the installer and that line in the log goes to sub-second warm, or five seconds cold on a runner with no cache. It is not a heroic optimisation, it is a one-line change to the install command, and it gives back time on work you run hundreds of times a week.

What I got wrong on the way, and a real aside

My very first cold pip run took 268 seconds. The next three took 26. I nearly wrote down 268 as the cold number, which would have made pip look five times worse than it is.

It was not pip. It was the first network contact from a fresh container: cold DNS, TLS setup, PyPI connections warming up. Every cold run after that, with the download cache still wiped each time, settled at around 26 seconds. The lesson is the ordinary one, that the first measurement is often measuring your environment rather than the thing you care about, so throw it away and watch whether the number stabilises. But there is a real point hiding in it too: a genuinely cold CI runner, first job of the day, can pay that 268-second tax once, and neither tool fully saves you from it because it is the network, not the installer.

Run it yourself

Install uv, then race it against pip on your own requirements:

pip install uv

# cold: wipe caches first
rm -rf ~/.cache/pip; python -m venv /tmp/v
time /tmp/v/bin/pip install -r requirements.txt

uv cache clean; uv venv /tmp/uvv
time VIRTUAL_ENV=/tmp/uvv uv pip install -r requirements.txt

# warm: run each again into a fresh venv without clearing the cache

The warm run is the one to watch. Delete the environment, keep the cache, and install again. pip will take about the same time it took before. uv will finish before you have read the command back.

What to do about it

For a new project, uv is a straight swap and the CI time is free money. For an existing one, the honest friction is that uv is another tool in the chain and your lockfile and workflow assume pip, so the win has to beat the cost of the change. The way to decide is to run the warm test above on your real requirements. If your dependency tree is small the 13 seconds might not be worth touching. If you install pandas and friends on every CI job, you are copying the same hundred megabytes thousands of times a month, and hard links exist precisely so you do not have to.