DEV Community: Ahmed Sozzer

Why I'm building a filament changer for printers that already have one

Ahmed Sozzer — Sat, 17 Oct 2026 14:51:41 +0000

I run a small print farm: two P1S with an AMS each, an A1 Combo, and an A1 mini. Three of those four printers already have an automatic filament system. I'm building another one anyway. The reason is a line near the top of its design docs: there's no official way to put 30 spools on a shelf and let any of them feed any of my printers.

What the stock units can't do

An AMS holds four spools. A P1S can take up to four AMS units through an AMS Hub, which gets one printer to 16. The A1 series takes one AMS lite, or up to four full AMS units through its own hub.

Sixteen is a lot of colours. The bigger limit for a farm is that every spool belongs to one printer. A spool in one P1S's AMS can't feed the other P1S, even when that printer is idle and the first one doesn't need it. The hub doesn't change that. It merges up to four AMS units into one printer's inlet and has no way to send filament the other direction. Two printers that run the same colour need two spools of it, loaded in two places.

What I want is closer to a switchboard: a bank of spools that any printer can draw from, with no fixed count. That's the long-term goal for AMS-X, and it's a long way off. The roadmap calls routing filament between printers a hard, separate problem and puts it last.

Decision one: leave the firmware alone

Every Bambu printer already knows how to do a manual filament change. Set the change-filament gcode to a pause, slice a multi-colour model, and the printer stops at each change, unloads, and waits for someone to push the next filament in. Then it loads, purges, wipes and carries on.

AMS-X doesn't fork firmware, emulate Bambu's AMS protocol, or write hotend gcode. It replaces the person standing at the printer. The printer keeps everything that depends on the nozzle and the material: temperature, retracting out of the melt zone, loading, purging. AMS-X keeps the logistics: which spool is next, pulling the old filament clear, and pushing the new one in until the printer's own filament sensor sees it.

The reason is calibration. Purge length and retraction are per-nozzle, per-material numbers, and the printer already has them right. If I wrote my own, I'd own that problem on every model I run. The cost is that I can only drive what the printer exposes on its local network, so the printers run in LAN mode and every swap goes at the printer's pace. Driving a Bambu Lab printer over MQTT covers that interface and which parts of it I've confirmed.

That decision also set the order of the work. Everything depended on the printer's unload, resume and filament sensor being reachable over MQTT, so the roadmap tests that first, from a laptop, with no hardware. The next step builds the whole loop with a human standing in for the motor: the server parses the sliced file, uploads it, starts the print, catches each pause, asks a person to swap, and resumes when the sensor trips. A motorized module plugs into the same interface later, and the orchestrator doesn't change.

Decision two: one motor at a time

Each spool sits in a module: a NEMA 17 stepper on a TMC2209 driver, pushing filament through a Bowden-style extruder. An ESP32 runs a cluster of modules and talks to the server over MQTT. The early docs planned one ESP32 per roughly 16 modules. The firmware settled on eight.

The rule that keeps the board simple is that only one module moves at a time. A filament change only needs one spool moving, so there's no reason to run two motors at once. That lets every driver in the cluster share the same STEP and DIR lines, with a separate enable pin per driver. Picking a spool means enabling one driver. Eight modules cost two shared pins plus eight enables, ten in total, against sixteen if each driver had its own STEP and DIR.

The enable is held only for the length of a move. Exactly one spool is ever energised, and that's guaranteed by the wiring rather than by the code getting it right. It keeps power small too: with one motor moving at a time, a 24 V, 5 A supply covers a cluster.

Pin numbers aren't compiled in either. The pin map arrives over MQTT, and the board refuses pins that would take it down, like the ones wired to its own flash, and reports a fault instead.

Where it actually is

Server: the full loop runs. It parses the sliced 3MF, uploads over FTPS, starts the print, catches each pause, prompts a person to swap, and resumes when the printer's sensor trips. The printer side is confirmed on my A1 mini and P1S. It also tracks spools in Spoolman and runs against a built-in printer simulator, with 130+ tests.
Firmware: about 900 lines of C++, on the bench with four motors, not eight. Loading works. Unloading doesn't: the module's own filament sensor isn't read yet, so an unload thinks it's already finished and the motor never turns.
Not built: the motorized module on the server side, and the hub that merges modules into one printer.
X1: untested. I don't have one.
Sharing spools between printers: the goal, not something that runs.

What's next

Fixing unload comes first, because nothing swaps on its own until a module can pull filament back. After that, four spools swapping with no hand on them, then eight. Until then, AMS-X is a server that tells me when to swap spools.

The code is on GitHub under MIT: server and firmware. The firmware is covered in One ESP32, eight spools, two legs per filament move.

How often public Supabase repos leave a table readable by the anon key

Ahmed Sozzer — Thu, 15 Oct 2026 15:15:55 +0000

While going through some of my older projects, I found a Supabase table with row level security off. It came in with a PR I'd mostly vibe coded, and I'd never turned RLS on for it. Anyone holding the anon key could read it, and the anon key ships in the frontend bundle. I fixed it as soon as I saw it.

Then I wanted to know how common that is. So I replayed the migration history of 1,000 public Supabase repos into throwaway local databases and checked every table, commit by commit.

Short version: 18.8% of the repos I could replay had a fully readable table at some point, and 10.9% still have one at their latest commit.

Why this happens

A Supabase frontend talks to Postgres through PostgREST, using the anon key. Supabase's default privileges grant anon SELECT, INSERT, UPDATE and DELETE on new tables in public. Row level security is the only thing standing between those grants and your rows.

The dashboard's table editor turns RLS on for new tables by default. A create table in a migration file doesn't:

create table public.messages (
  id bigint generated always as identity primary key,
  body text not null
);
-- no "alter table public.messages enable row level security;"
-- anon can now read and write every row

So the same table is safe or open depending on whether you made it in the UI or in SQL.

What I measured

Sample. GitHub code search for .sql files under supabase/migrations/, sliced into 8 file-size bands to get past the API's 1,000-result cap. Every band hit the cap, so the frame is the first 1,000 hits in each band: 5,865 repos. I screened them in seeded random order and kept the first 1,000 that weren't forks, templates, tutorials or Supabase's own examples, and that had at least 3 migration files and 2 commits touching them.

Replay. For each repo, every commit that touched the migrations or seed.sql, capped at 30 (first, last and evenly spaced in between). Each commit was replayed into a fresh supabase/postgres container with no outbound network, using the same rules supabase db push uses. Nothing touched a live project, and no URL was visited.

Exposure. A table in public with RLS off, on which anon has table-level SELECT. That means every row and every column is readable with the public key.

Results

	Repos	Share	95% CI
Exposed at any sampled commit	146 of 777	18.8%	16.2 to 21.7%
Still exposed at the latest commit	43 of 393	10.9%	8.2 to 14.4%

The denominators differ because not every commit replays (more on that below). 777 repos had at least one commit that replays, and 393 had a latest commit that does.

When an exposure ended, it usually wasn't a quick fix in the next commit. 67% of the ones that ended lasted more than a day and 37% more than a week. Counting exposures that are still open, the median was 47 days (Kaplan–Meier, since open ones haven't finished yet). 22 of the 75 that ended did so at the very next migration commit.

A few results worth a closer look

Starred repos did worse. Repos with 1 to 9 stars were exposed at their latest commit 20.3% of the time, against 8.3% for repos with no stars, and the intervals don't overlap. I wouldn't read that as cause. Starred repos tend to have longer histories, and every extra commit is another chance to add a table.

Older repos weren't safer. Repos created before 2026 were at 16.7% at their latest commit and 2026 repos at 9.5%, and that difference is within the intervals. If you wanted to pin this on AI coding tools, this data doesn't support it.

Most latest commits don't replay at all. Only 39% of repos had a latest commit that applies cleanly on a fresh database. Of the ones that fail, 69% fail because a migration refers to a table, column or function that doesn't exist yet, almost always because it was made in the dashboard. For those projects, the migration folder can't rebuild the database it's supposed to describe.

Public reads are everywhere, and that's mostly fine. 48.6% of repos had a SELECT policy for anon with using (true) on a table that does have RLS on. That's how a public profile page or a blog works. Supabase's own linter skips that pattern on purpose and only flags always-true write policies, which showed up in 9.3% of repos.

Limits

Migrations aren't the live database. A project can turn RLS on in the dashboard without a migration. Then it looks exposed here when it isn't. The reverse happens too.
The sample is young and small. 72% of the repos were created in 2026 and 79% have no stars. Public repos lean toward hobby, demo and portfolio projects even after filtering.
The frame is whatever order GitHub search returns. Repos outside those 8 size bands, or past the first 1,000 hits in a band, had no chance of being picked.
The 30-commit cap can catch an exposure's start late. I replayed 25 capped repos again with no cap (3,026 commits). No repo changed classification, and start times moved by at most about a day.

The 43

42 of the 43 repos still exposed at their latest commit got a private note, by email, GitHub's private vulnerability reporting, or an issue asking for a security contact (with no details in it). The last one has no private contact channel and doesn't look deployed, so I left it alone. The published data replaces repo names with repo-NNN and table names with salted hashes, because a distinctive table name can be searched back to its repo. As of October 15, one owner has confirmed a fix.

Checking your own project

In the dashboard, Advisors > Security flags these as "RLS disabled in public". The fix is one line per table, plus policies for whatever access the app actually needs:

alter table public.messages enable row level security;

To catch it before it merges, I built Lintel, which replays a PR's migrations and fails the check when the PR adds a table anon can read:

npx @amsozzer/lintel migrations check

There's also a playground that runs the same checks in your browser.

The method, the scripts and the anonymized data (one row per sampled commit and per exposure) are in the repo: study/results.md.

Originally published on amsozzer.com.

A Terminal-Bench task frontier agents could not pass

Ahmed Sozzer — Wed, 07 Oct 2026 17:46:58 +0000

I wrote a task for Terminal-Bench, a public benchmark of hard command-line tasks for AI agents. The agent has to build a redactor for court-filing PDFs: black out every visible name and ID on a list, leave nothing recoverable in the file, and change nothing else on the page.

I ran it three times each with Claude Opus 5.5 and GPT-6 Sol on their highest reasoning settings. All six runs failed, and so did two runs where the agent was told to cheat. Each agent wrote a tool of around 4,000 lines and tested it before stopping, and each one believed it had passed. This post is about how I built the task and why the agents stopped where they did.

What a Terminal-Bench task is

A task is a Docker environment, an instruction, a reference solution and a hidden test suite. The agent gets a shell and the instruction. When it says it’s done, the tests run against whatever it left behind, and the result is pass or fail.

A good task is one a strong engineer could finish with the information given, and that current agents still get wrong. Getting both at once took most of the work.

Thirteen designs that didn’t work

For each idea, I first asked a few models with no tools how they’d solve it. If their plan named the trick, the idea was dead. Most died there.

The ones that survived got built and run against real agents with tools. A pump-monitoring task looked solid on paper. Opus solved it in 54 minutes by working the hidden behavior out of the residuals in the data. A sewer-overflow model went the same way, and Opus’s answer came in tighter than my own reference solution. A fire-hydrant flow task got passed by five agents out of five.

Each failure came from the same place. For a task to be fair, the information that decides the answer has to be visible to the agent. If it’s visible, an agent with a shell will find structure in it. Opus usually did that in 7 to 30 minutes.

Picking PDF redaction

I picked redaction because the rules are short and easy to state, and the difficulty is in how many ways content can sit inside a PDF. It’s also a real failure mode. Court filings leak when someone draws a black box over text that’s still in the file.

The first version gave the agent the policy and three sample files. I ran two agents. One failed and the other got a perfect score. Opus read the policy and listed nearly every way a name can hide in a PDF before it opened a file.

The obvious fix was a vaguer spec. I didn’t do that, because a task that withholds a rule is unfair, and a reviewer would be right to reject it.

Separating the rules from the test cases

What worked was treating the rules and the test cases as separate things. The policy states every rule in full. The hidden test set includes cases no sample shows, and each one is decided by a rule the policy already states. The agent has everything it needs to handle them. It just can’t check its handling against an example.

I built candidate cases and kept one only if:

it beat the finished tools from both earlier agents,
my reference solution handled it with a general method, not a special case, and
a rule already in the policy decided it.

The second condition cost me six candidates. My own reference solution couldn’t handle them cleanly, so I dropped them.

Then I checked that the set wasn’t tuned to the two tools I’d tested against. Two fresh agents that had never seen those tools failed it too. After that I froze the task.

Running the trials

I set the rules before the first run, because a 0% result means nothing if the runs were broken:

Freeze and checksum the task before trial one, and never edit it after.
The reference solution scores 100% and a do-nothing submission scores 0% before any agent runs.
Run one normal trial and one cheat trial first, then the rest.
A run counts only if the agent stopped on its own, with no harness errors, no rate limits and no probing of the grader. Anything else gets rerun once and marked.

One Sol run hit a usage cap partway through. I reran it and didn’t count the capped attempt.

Before freezing, I also found a bug in my own grader: it flagged some correctly redacted pages as failures. I fixed it, even though leaving it in would have made the task harder. A task that’s hard because the grader is wrong doesn’t measure anything.

Final results: Opus 0 of 3, Sol 0 of 3, both cheat runs 0.

Why the agents stopped

None of the agents skipped testing. Each one built a large tool, generated its own test documents and ran them. One made 52.

The problem was what they tested. Each agent checked its output with the same kinds of checks it had used to find the names. Anything its search missed, its verification missed too, so the tests came back clean and the agent stopped. Writing more tests of the same kind wouldn’t have caught the misses.

The policy also requires that nothing else on the page changes, so over-redacting fails too. In the first version, one agent added a safety net that blacked out anything that looked suspicious. It fixed one document and broke another by covering a banner that should have stayed.

The two models failed differently

Opus and Sol each handled cases that beat every run of the other. One case beat all six runs.

This is why I’d rather have many separately reasoned cases graded all-or-nothing than one clever trick. The next model release tends to solve any single trick. With many cases, a model has to be right about all of them at once.

The cheat runs

In a cheat trial, the agent is told to pass by any means. Both agents tried to make the problem easier instead of solving it. The grader keeps its own ground truth out of the agent’s reach and runs the agent’s tool on copies, so neither attempt scored.

I also audited the transcripts of the agents I used while building the task, to make sure none of them reached outside their sandbox. Before trusting that audit, I tested it against seven cheats I planted myself.

How the work was split

I ran this like a small team. Claude agents did most of the building, probing and kill-testing. I set the rules, wrote the decision criteria for each trial outcome, and made the calls. After the first PDF version, the agent recommended submitting it. I pushed instead on hiding the test cases rather than the rules, and that led to the final version.

What I’d take from it

If you build or deploy agents, look at what your agent checks before it stops. An agent that tests its own work is limited by the tests it thinks to write. When those tests share a blind spot with the solution, it stops with a wrong answer and a passing test suite.

The task is open as PR #2184 on the Terminal-Bench repo, and the evidence for every run is in the task repo.

Driving a Bambu Lab printer over MQTT

Ahmed Sozzer — Sun, 27 Sep 2026 23:06:48 +0000

A Bambu Lab printer will print in as many colours as you like, provided a human is standing
next to it. Set the change-filament gcode to a pause, slice a multi-colour model, and the
machine will stop at every change and wait for someone to pull one spool out and push the next
one in. That person is the only thing standing between four spools and any number of them.

AMS-X is an attempt to replace that person. This post is about the part I
had to establish first: what the printer will actually let a program do to it, and how much of
that I have confirmed rather than assumed.

The decision that shapes everything else

The tempting approach is to author your own hotend gcode. Retract this much, heat to that,
purge this many millimetres. It is also a trap, because purge and retraction amounts are a
per-nozzle, per-material calibration problem that never ends, and the printer already solves
it.

So AMS-X writes no hotend gcode at all. It drives the printer's own filament-change routine
and owns only the logistics up to the machine's inlet sensor.

AMS-X owns	The printer owns
which module, and when	nozzle temperature
retracting the spent filament clear of the path	retract from the melt zone
feeding the next filament to the inlet sensor	load to nozzle, purge, wipe, resume

The seam is the printer's existing routine. Everything below is about driving its prompts over
the network instead of by hand.

Getting in

The printer runs an MQTT broker on the local network. TLS on 8883, username bblp, password
is the LAN access code from the printer's own screen. The certificate is self-signed, so
verification is off; this is LAN-only and gated by a code you have to be standing at the
machine to read.

publish   device/{serial}/request
subscribe device/{serial}/report

Files go over FTPS, and FTPS is where the time goes. Three things cost me an evening each:

It is implicit TLS on port 990. The connection is encrypted from the first byte. It is not AUTH TLS on 21, and a client configured for explicit TLS just hangs.
The data channel has to reuse the control connection's TLS session. A fresh session gets refused.
After STOR, do not call unwrap() on the connection. It will sit waiting for a 226 that never comes.

Uploads land in /cache on the printer's SD card.

The plan comes out of the sliced file

A .gcode.3mf is a zip. Inside it, Metadata/plate_1.gcode is the actual gcode the printer
will run, and it carries the whole change sequence in order:

Command	Meaning
`M400 U1`	pause and wait for a filament change
`M1020 S<n>`	which project filament is next, zero-indexed
`M620 S<n>A` / `M621`	AMS load and unload, for the AMS path we never use

So the server unzips the file it is about to send, reads that gcode top to bottom, and comes
away with an ordered plan: change one wants filament two, change two wants filament five, and
so on. No custom slicer, no parsing of the model itself.

The plan is only half of it. The other half is the live pause event arriving over MQTT, which
is what says now. The server matches each pause to the next expected change in its own plan,
which means a stray pause from a human pressing the button on the front never gets mistaken
for a swap. The rule is that the server only acts on a pause it can match to something it
planned.

The loop, confirmed on an A1 mini

Every line here has run against real hardware:

the printer pauses on M400 U1 and the pause shows up in the report stream
the server sends unload_filament, and the printer heats the nozzle itself
a human swaps the spool, because the motorised module is not built yet
the server watches hw_switch_state, the printer's own filament-present sensor, until it trips
the server sends resume
the cursor advances to the next planned change

What is worth noticing is how little of that is mine. Two commands and one sensor. The
printer does the heating, the retract from the melt zone, the load, the purge and the wipe,
because those are the parts it already knows how to do.

Starting the print

1. FTPS upload the .gcode.3mf to /cache/<name>
2. project_file with url = file:///sdcard/cache/<name>
3. param = "Metadata/plate_1.gcode"
4. use_ams = false, ams_mapping = []
5. project / profile / task / subtask ids all "0"

Line two is the one that cost me. The obvious URL is ftp:///cache/<name>, since that is how
the file got there. Sending that faults the A1 with 0500_C010, an SD read/write error, which
tells you nothing about what was actually wrong. It wants a filesystem path,
file:///sdcard/cache/, not the protocol you uploaded with.

The ids being "0" is what makes it a local print. Nothing touches Bambu's cloud.

The external spool

The printer models the external spool as a tray with reserved identifiers. Writing to it:

ams_id 255, tray_id 254, slot 0
colour as 8-hex RRGGBBAA, alpha appended as FF
tray_info_idx GFL04, nozzle 190–240

Reading back, vt_tray.tray_color gives 8-hex and vt_tray.tray_type gives the material.
layer_num is reported correctly. mc_print_line_number, which would be the obvious way to
know where in the gcode a pause happened, reports 0 on the A1, so the plan cursor is the
only thing tracking position.

What is still a guess

The A1 path above is confirmed. The X1 and P1 driver is not, and I want to be precise about
that: it is guesses end to end, thirty-one open markers, zero hardware time. The unload
trigger, the filament-select command, the resume verb, the start-print shape, all inferred
from the A1 and from what other people have published. One thing I do know is that
ams_filament_setting returns an empty payload on that path, so it is not supported there.

Smaller unknowns on the confirmed path:

gcode_state and its RUNNING / PAUSE / FINISH values are read but not proven
filam_bak, the X1/P1 filament sensor, is a guessed field name
tray_now is read without being certain what it means
using print_error to classify why a print paused is inference, not documentation

There is also a routine_extrude() that pushes filament with M83 and G1 E45 F500. It is a
diagnostic fallback and deliberately not in the loop, because the loop closes on the sensor
and lets the printer load and purge by itself. Any time I reach for raw gcode, it is a sign
the design has slipped.

Why write it down like this

The reason for the [OK] and [??] markers in the repo is that a protocol you inferred is a
protocol you will misremember. Six weeks later, everything you wrote looks equally
authoritative, and you cannot tell which lines you watched work and which ones you reasoned
your way into. Separating them costs a column and saves the argument with yourself.

The A1 is real. The rest is a hypothesis with a test plan attached.

AMS-X is on GitHub under MIT, design documents and all.

Originally published at amsozzer.com. The ESP32 firmware for the spool modules is at Amsozzer1/AMS-Firmware.

I could not understand Express, so I wrote my own

Ahmed Sozzer — Wed, 23 Sep 2026 14:06:22 +0000

Middleware chaining made no sense to me, so I rebuilt it in C++. A year later the profile said the slowest thing in my server was a map I rebuilt on every response.

I do not learn things by reading about them. I can read a page on how something works, nod along, and retain none of it. What stays is what I have had to build, and usually what I have had to build twice.

So when I joined FYCLabs and found that everything ran on Express, I had a problem. The low-level pieces I was fine with: sockets, buffers, what the kernel is actually doing. Express itself was opaque. Middleware chaining in particular. Handlers calling next(), error handlers taking four arguments instead of three, ordering that mattered in ways nobody wrote down. I could use it. I could not have told you what it did.

The sensible response was to read the source. I wrote my own instead.

The first attempt was pointless

I started in JavaScript. That lasted about an evening. I was reimplementing the thing I was trying to understand, in the same language, at the same level of abstraction, and learning nothing except that I could produce something Express-shaped if I squinted.

So I started again in C++, where nothing can be borrowed and every piece has to be built. You cannot hand-wave a socket.

What I found in Express

The first real discovery had nothing to do with middleware. It was routing.

Express matches a request by walking its layer stack in registration order, testing each one until something matches. That is a linear scan, which means the cost of routing depends on where your route happens to sit in the file. I would not have guessed a mature framework had that property.

A trie made more sense. My first version put one node per character, which is the trie everybody draws first and the wrong one here. URLs are not arbitrary strings. They are a small number of segments separated by slashes. One node per segment, keyed on METHOD:/path, and a lookup costs one step per segment however many routes exist.

That difference is most of the performance story against Express. One pinned core, identical handlers, identical payloads:

Routes registered	PlusWeb	Express
5	91,950 rps	19,236 rps	4.8×
1,000	90,085 rps	5,639 rps	16×
10,000	89,636 rps	355 rps	253×

The honest row is the first one. A five-route app is what most apps are, and it is the case Express looks best under. The larger multiples are not PlusWeb speeding up, since it sits at about 90,000 across every row. They are Express's router degrading. If you quote one number, quote 4.8×.

Where I was wrong for about a year

I wanted to write everything myself. Less ambition than a feeling that using a library for the interesting part was cheating. So I wrote my own event loop, which was not an event loop at all but a while loop that blocked, and my own HTTP parser.

It took me a year to see why that is a bad instinct. A project that refuses to use anything never reaches a first release. You stop building the thing you set out to build and start maintaining its dependencies instead.

What broke it was a detour. I had put PlusWeb down and started writing a JavaScript interpreter, which meant reading how Node actually works and trying to imitate V8's parser. Two things came out of that. The first was realising Node is itself a C++ program wrapped around a C event loop: I had gone down a level to understand the thing and found the thing was already there. The second was watching Tsoding mention libuv in passing, which made the question obvious. Node is built on libuv. I am trying to understand Node. Why am I writing my own event loop?

libuv replaced the blocking loop. When profiling then showed parsing was slow, for several reasons that were entirely my own fault, llhttp replaced my parser. It is the parser Node uses, it is small, and it handles framing as well as parsing, so pipelined requests, chunked bodies and requests split across packets all started working at once. Adopting it closed every correctness gap I had against Express.

The slowest thing in my server

Then I profiled properly, expecting the answer to be the blocking loop I had just removed.

It was a std::map.

HttpResponse carried the status-code table, eighty-five entries running from 100 Continue to 598, as a member:

class HttpResponse {
    std::map<int, std::string> ResponseCodes = {
        {100, "Continue"},
        {101, "Switching Protocols"},
        // …eighty-three more
    };
};

Every response built that map from scratch. Eighty-five string allocations and eighty-five red-black tree insertions per request, to look up one value that never changes. The fix is one word:

static const std::map<int, std::string>& defaultResponseCodes();

I measured it afterwards rather than trusting the memory of it, compiling the commit and its parent with the same flags and running each 200,000 times:

	before	after
construct an `HttpResponse`	3,390 ns	10.0 ns	339×
full response path	3,400 ns	255 ns	13×

Both versions emit byte-identical responses. The constructor is 339 times faster because it went from eighty-five allocations to none. The full path improved 13×, since once the map is gone the remaining work is work that genuinely has to happen.

Where the time goes now

flat %	symbol
~71%	libc syscall stubs (`send`/`recv`)
3.0%	`llhttp__internal__run`
1.8%	`HttpParser::Impl::onMessageComplete`
0.5%	`HttpResponse::serialize`
0.5%	`Node::find`, the routing trie

The router I spent most of my time on is half a percent. The framework as a whole is under ten percent and the rest is the kernel moving bytes. PlusWeb runs at 55% of what a bare epoll server doing no parsing and no routing reaches on the same machine. Express is at 3.9%.

That is the right place to end up and it is also the end of the cheap wins. Going faster now means making fewer syscalls, not writing faster C++.

What it was actually for

I can tell you what Express does when a request arrives, because I have written the thing that does it. Middleware stopped being mysterious the moment I had to implement next(): it is a list of functions where each one decides whether the next runs, and the four-argument error handler is a second list.

That was the point. The benchmarks are a side effect, and a slightly misleading one, because they make the project look like it was about speed. It was about not being able to read a page and understand it.

PlusWeb is on GitHub under MIT, and the playground runs the real router compiled to WebAssembly if you want to watch a trie match something.