10.10beanstalkd-rs: A Drop-in beanstalkd in Rust, with a Raft Cluster14 min read Operations per second, beanstalkd vs beanstalkd-rs Horizontal bar chart, higher is better. put-reserve-delete, 1 connection: beanstalkd 56,176, beanstalkd-rs 53,943 (0.96×); put-reserve-delete, 10 connections: beanstalkd 339,283, beanstalkd-rs 468,310 (1.38×); put-reserve-delete, 100 connections: beanstalkd 392,713, beanstalkd-rs 516,336 (1.31×); 100 connections, 4 KiB bodies: beanstalkd 362,247, beanstalkd-rs 463,416 (1.28×); 100 connections, 16 pipelined: beanstalkd 490,247, beanstalkd-rs 643,204 (1.31×); producers and consumers, 100 connections: beanstalkd 422,349, beanstalkd-rs 500,891 (1.19×); binlog (-b), 100 connections: beanstalkd 267,391, beanstalkd-rs 594,148 (2.22×). Operations per second (higher is better) 0.96× 1.38× 1.31× 1.28× 1.31× 1.19× 2.22× beanstalkd beanstalkd-rs beanstalkd-rs / beanstalkd 0 100k 200k 300k 400k 500k 600k 700k put-reserve-delete, 1 connection put-reserve-delete, 10 connections put-reserve-delete, 100 connections 100 connections, 4 KiB bodies 100 connections, 16 pipelined producers and consumers, 100 connections binlog (-b), 100 connections 56k 54k 339k 468k 393k 516k 362k 463k 490k 643k 422k 501k 267k 594k
08.22The Agent Runtime Problem: Four Things a while-Loop Doesn't Give You15 min read What a runtime owns that a framework does not Four quadrants, each naming a problem an agent runtime has to own. One, durable state: a crash between the tool and the push, answered by two commits around one uncertain call. Two, session ownership: the terminal dies with the agent, answered by a daemon that reports working or blocked. Three, the orchestration loop: the author reviews its own diff, answered by splitting the context window rather than the model. Four, identity and money: no name to present and no way to pay, answered by HTTP 402 plus a delegation boundary. The four are independent, and no project has all four. What a runtime owns that a framework does not four independent problems — no project on this list has all four 1. durable state crash between the tool and the push→ two commits per uncertain effect 2. session ownership the terminal dies with the agent→ a daemon that owns the session 3. the orchestration loop the author reviews its own diff→ split the context, not the model 4. identity and money no name to present, no way to pay→ HTTP 402 plus a delegation boundary a framework gives you a while-loop and tool plumbing a runtime owns what survives the process
08.20gpui and the Mail Client Problem: A Text Field Costs 778 Lines28 min read The same event, two boundaries Two columns on a shared five-row grid, tracing the same event — a message landing in the mailbox while the user scrolls the thread list. Left column, Tauri or Electron: a sync task in the Rust core owns the store and the socket; the envelope is serialised to JSON, which is the only wire format the event system offers; the payload crosses into the WebView as evaluated JavaScript; a listener rebuilds the row, producing a second copy of the same data on the JavaScript heap; and a virtual list finally writes it into the DOM of WebView2, WKWebView or WebKitGTK depending on the user's operating system. Right column, gpui: the sync task runs on the background executor inside the same crate and the same address space; cx.spawn hops back to the main thread with an AsyncApp held across the await; store.update leases the state out, mutates it and returns it; cx.notify queues an effect that is flushed after the update completes; and the uniform list paints only the visible range on the next GPU frame. The left path buys a serialiser and a runtime you do not own, but gets a text field, a table and accessibility for free. The right path is a function call, and a design system you now maintain yourself. The same event, two boundaries a message lands in the mailbox while the user is scrolling the thread list Tauri / Electron sync task, Rust core owns the store and the socket serialise the envelope JSON — the only wire formatevents "are always JSON strings" cross into the WebView payload arrives as evaluated JS listener rebuilds the row a second copy on the JS heap virtual list, then DOM WebView2 / WKWebView / WebKitGTK gpui sync task, background executor same crate, same address space cx.spawn back to the main thread AsyncApp held across the await store.update(cx, ..) state leased out, mutated, returned cx.notify() effect queued, flushed after update uniform_list, next frame visible range only, painted by the GPU left: a serialiser, and a runtime you do not own right: a function call, and a design system you now maintain the left column ships a text field today; the right one charges 778 lines
08.17X's Phoenix Ranker: A Transformer That Cannot See Its Own Batch33 min read One sequence, three regions Three stacked bands, one per region of the Phoenix ranking model's input sequence. First, the user prefix at positions 0 to 1: two hashed identifier lookups and two hashed IP lookups, plus country, language, latitude and longitude, gender, age and installed apps; it attends to the user prefix and the history. Second, the history at positions 2 to 1023: post hashes, author hashes, semantic ID, the action taken, dwell time, timezone, local hour, product surface and post age; it attends to the user prefix and the history, bidirectionally rather than causally. Third, the candidates at positions 1024 to 1087: post hashes, author hashes, semantic ID and context, but no action and no dwell, because those are what the model predicts; a candidate attends to the user prefix, the history and itself, and nothing else. Right-anchored rotary position embedding puts the newest history event at position 1023 whatever the history length, and every candidate receives position 1024. A candidate's score therefore depends on the viewer and that candidate only, never on which other candidates share its batch. One sequence, three regions the Phoenix ranker reads 1088 positions in a single non-causal pass user — positions 0…1 two hashed id lookups, two hashed IP lookupscountry · language · lat/lon · gender · age · installed appsattends to: user + history history — positions 2…1023 post hashes · author hashes · semantic ID · action takendwell time · timezone · local hour · surface · post ageattends to: user + history — bidirectional, not causal candidates — positions 1024…1087 post hashes · author hashes · semantic ID · contextno action, no dwell — those are what the model predictsattends to: user + history + itself, and nothing else right-anchored RoPE puts the newest history event at 1023 whatever the history length every candidate gets position 1024 a candidate score depends on the viewer and that candidate alone never on which candidates share its batch
08.11Pi's Durable AgentHarness: An Agent Loop That Survives kill -918 min read Three stores, one invariant Three stacked bands, one per durable store in a Pi AgentHarness session. First, entries — the conversation itself: messages, compaction summaries and branch summaries, written once, never edited or deleted, belonging to no lane. Second, registers — current mutable state: the lane leaf, the lane configuration, operation metadata and the total operation state, plus facts; a register is overwritten or deleted and keeps no write history, and the operation-state register is the program counter recovery reads. Third, the usage ledger — one append-only row per settled attempt, never edited or deleted, never in the tree. All three share one monotonic sequence number. A transaction is the only write primitive. Recovery reads the operation-state register; it does not replay a journal or infer state from what is missing. Three stores, one invariant every durable payload is an entry, a register, or a ledger row entries — the conversation messages, compaction summaries, branch summarieswrite-once · never edited · never deleted · belongs to no lane registers — current mutable state lane.leaf · lane.config · op.meta · op.state · factsoverwrite or delete · no write history · this is the program counter usage ledger — cost history one row per settled attempt · token and cost eventsappend-only · never edited · never deleted · not in the tree all three share one monotonic seq — a transaction is the only write primitive recovery reads op.state; it does not replay a journal or infer from what is missing
08.07Bun's Zig→Rust Rewrite in 11 Days: The Loop, Not the 64 Claudes23 min read Bun’s port loop: split the context window A four-stage loop running top to bottom. At the top, the binding spec: PORTING.md and LIFETIMES.tsv, holding the Zig-to-Rust pattern rules and a proposed lifetime for every struct field in the codebase. It binds all four stages below it. Next, one implementer, which sees the Zig source, the spec, and its own reasoning, and writes the port. Its diff — and nothing else — goes to two adversarial reviewers, each instructed to assume the code is wrong; neither sees the implementer's reasoning. Their findings go to one fixer, which applies every finding before the code lands. Sixteen such loops ran per git worktree across four worktrees, roughly sixty-four Claude instances at peak, and the same loop shape drove all three phases: translating 1,448 files, clearing about 16,000 compiler errors, and fixing every failing test. Bun’s port loop: split the context window the reviewer gets the diff and nothing else — never the implementer’s reasoning binds all four diff only findings PORTING.md + LIFETIMES.tsv the binding spec · Zig→Rust patterns, a lifetime per struct field 1 implementer sees the Zig source, the spec, and its own reasoning adversarial reviewer adversarial reviewer 1 fixer applies every finding — only then does the code land sees the diff only · instructed to assume the code is wrong 16 loops per worktree · 4 git worktrees · ~64 Claudes at peak the same loop drove all three phases: translation, compiler errors, failing tests
08.07herdr Joins Y Combinator: A Rust Agent Runtime, Not Another tmux14 min read herdr: the agent runtime Three layers. On top, clients: Claude Code, Codex, opencode and a human. Each attaches to the herdr daemon. The daemon owns every terminal session, persists agent state, and is reachable from anywhere through the bundled TUI (herdr --remote self-installs in seconds). Below, the sessions it spawns, one per agent, marked working, blocked or idle, each surviving agent restarts. A terminal pane belongs to an agent; a pane belongs to a tab; tabs belong to a project. herdr: the agent runtime agents attach to a daemon that owns every session and tracks its state attach spawns · owns Claude Code Codex opencode Human herdr daemon owns every session · persists agent state terminal session terminal session terminal session working blocked idle state detected per pane · sessions survive agent restart a terminal pane belongs to an agent · a pane belongs to a tab tabs belong to a project · run them anywhere, keep them running herdr --remote self-installs in seconds
08.05Cloudflare Wallets and cloudflare.pay: Identity and Payments for AI Agents18 min read Cloudflare Wallets delegation tree Four layers of authority. A human account owner funds an Account Wallet holding the stablecoin balance. The Account Wallet delegates capped authority to three Virtual Wallets, each carrying its own weekly budget, per-call ceiling and merchant allowlist. Each Virtual Wallet issues an API key to one agent, which spends without per-transaction human approval. No agent can exceed the limits set above it. Delegated spending authority who is allowed to spend what funds · sets the ceiling delegates capped authority API key Human account owner a Cloudflare account, not a keypair Account Wallet stablecoin balance · on-ramp / off-ramp Virtual Wallet Virtual Wallet Virtual Wallet research agent ETL agent reader agent inference · $100 / wk max $2 per call data feeds · $20 / wk allowlist: 4 hosts web content · $5 / wk allowlist: 12 hosts research.acme etl.acme reader.acme no human approval per call · every child is bounded by its parent handles resolve under <name>.cloudflare.pay
08.05x402 Native Payments: HTTP 402 Protocol for AI Agents20 min read x402 UML sequence diagram Twelve numbered steps across four lifelines. Solid arrows are requests, dashed arrows are responses, and self-messages are local work. An alt fragment splits the flow after verification: the invalid branch returns another 402 and stops, the valid branch settles the payment on-chain and returns the resource. x402 payment sequence solid = request · dashed = response · self-message = local work Client Resource Server Facilitator Blockchain alt [invalid] [valid] discover authorize verify settle & respond 1 · GET /weather 2 · 402 Payment Required PAYMENT-REQUIREDprice · tokennetwork · payTo 3 · Sign authorization EIP-3009 · signed locally 4 · Retry + signature PAYMENT-SIGNATURE 5 · POST /verify 6 · VerificationResponse isValid 402 + PAYMENT-REQUIRED client re-signs or aborts 7 · Fulfill resource prepare the paid work 8 · POST /settle 9 · Execute payment transferWithAuthorization 10 · Confirmed 11 · SettlementResponse success · tx hash 12 · 200 OK + data PAYMENT-RESPONSE Client Resource Server Facilitator Blockchain
08.05simpleconf: A Go Config Service for When etcd Is Too Much11 min read simpleconf write path in Raft mode Four stages from an incoming PUT to the append-only log, with the alternative outcome at each stage on the right. One write, Raft mode reads never take this path — they are served locally from memory PUT /db/product.name 1 · am I the leader? no → re-issue to leader http_addr forward: false → 409 not leader 2 · raft.Apply(cmd) quorum commit across peers no quorum → error 3 · every FSM applies sjson.Set on the in-memory string client sees 200 here 4 · append to data.aof separate goroutine · no fsync after the response Steps 3 and 4 are decoupled: the acknowledgement means “applied in memory”, not “on disk”.
08.05svelte-router: Svelte 3–5 SPA Routing Without SvelteKit8 min read svelte-router candidate merge Four candidate sources each expose their next match with its declaration order; the matcher repeatedly takes the lowest order until one matches. Lowest declaration order wins each source offers its next candidate; the matcher merges them by array index static Map get(path) order 0 keyed dynamic segs 2 · users order 3 fallback dyn. :param first order 5 wildcard * /^.*$/ order 9 take the lowest order that still matches a regex only runs when its route is the current front-runner { component, params } Dashed: early exit — when the static hit already outranks every dynamic route, no bucket is consulted and no regex runs at all.
08.05alpinejs-router: HTML-first Client-side Routing for Alpine.js7 min read alpinejs-router path resolution Five stages from an incoming path to route params, with the fallback at each stage noted on the right. Resolving one path each stage falls through to the next; the right column is what happens on a miss /teams/42/projects/9 1 · staticRoutes.has(path) a Set — paths with no “:” never compile hit → {} params 2 · dynamicRoutes[depth] bucket by segment count — here 4 no bucket → notfound 3 · keyed["teams"] + wildcard Map on first segment, then “:param” first both lists may run 4 · RegExp test, score order static 3 · regex param 2 · bare param 1 all miss → notfound 5 · named groups → params $router.params.projectId Declaration order is not consulted — specificity decides. is() and notfound() walk the same index.
