DEV Community: Low Key Builds

Urdu voice notes to text on a free tier: Whisper pinned to Urdu, Roman Urdu without drift, and an honest error rate

Low Key Builds — Tue, 20 Oct 2026 18:16:54 +0000

Pakistan runs on WhatsApp voice notes. WhatsApp now writes transcripts for some languages, but Urdu is not in any list of supported languages I could find, and a Hindi transcript of Urdu speech comes out in Devanagari, which most Pakistanis do not read.

So I built Sunlo, a free web app: drop in a voice note, get Urdu script, Roman Urdu (the way people actually type on WhatsApp) and an English translation. Disclosure: I made it, and this post is how it works, including what it gets wrong.

The constraints: no budget, no audio stored anywhere, and a cheap Android phone as the main client.

1. Whisper on Workers AI, language pinned to Urdu

Cloudflare Workers AI hosts whisper-large-v3-turbo. The one setting that matters is language: 'ur'. Left to auto-detect, Whisper often decides Urdu speech is Hindi (the spoken languages are close) and writes Devanagari.

const w = await env.AI.run('@cf/openai/whisper-large-v3-turbo', {
  audio: base64Audio,      // WhatsApp .opus works as-is
  language: 'ur',          // never auto-detect for Urdu
  task: 'transcribe',
  vad_filter: true,        // skips silence in voice notes
});

WhatsApp's .opus files go straight in; no ffmpeg needed on the server.

2. A hard daily cap, enforced before the model runs

The free Workers AI allocation is 10,000 "neurons" a day. Whisper turbo costs about 46 neurons per audio minute ($0.00051/min at $0.011 per 1k neurons). The Worker keeps a per-day counter in D1 and reserves the estimated cost before calling the model, so parallel requests cannot overshoot, then corrects it with the real duration afterwards:

const est = seconds / 60 * 46.4 + 40;
const b = await env.DB.prepare('SELECT neurons FROM budget WHERE day=?').bind(day).first();
if ((b?.neurons || 0) + est > 8000) return json({ error: 'daily_cap' }, 503);
await env.DB.prepare(`INSERT INTO budget (day, neurons) VALUES (?, ?)
  ON CONFLICT(day) DO UPDATE SET neurons = neurons + excluded.neurons`).bind(day, est).run();

Per-visitor limits use a salted daily hash of the IP, so nothing identifying is kept. Audio and text are never written anywhere; D1 only holds counts, durations and timings.

3. Roman Urdu: transliterate, do not translate

Roman Urdu and English come from one call to Llama 4 Scout (about 11 neurons for a short note). The first prompt said "write it in Roman Urdu" and the model drifted into English words ("patient ko dusre se alag karna include hai"). Saying TRANSLITERATE, with two examples of how people type, fixed it:

"roman": TRANSLITERATE, do not translate. Write every Urdu word as the same
Urdu word in Latin letters, the way Pakistanis type on WhatsApp
(for example "main kal aaunga, aap fikar na karein").

Llama 3.1 8B was cheaper but changed words ("aaj", today, became "kal"). Scout, Llama 3.3 70B and gpt-oss-120b were all fine on clean text.

4. Long recordings: cut at silence, in the browser

Lectures and interviews are longer than one request should be. The browser decodes the file with AudioContext({ sampleRate: 16000 }), which also resamples to what Whisper wants, then cuts it into ~150-second pieces. Each cut goes at the quietest 50 ms window in the last quarter of the piece, so words are not split:

for (let w0 = lo; w0 < hi; w0 += win) {
  let e = 0;
  for (let j = w0; j < w0 + win; j++) e += mix[j] * mix[j];
  if (e < bestE) { bestE = e; best = w0 + (win >> 1); }
}

Pieces are transcribed one by one, joined, and then translated in a single pass, because translating fragments separately produced nonsense at the seams.

5. Share target: one tap from WhatsApp

On Android, an installed PWA can appear in WhatsApp's Share sheet. The manifest declares a share_target with a multipart POST; the service worker catches it, stashes the file in Cache Storage and redirects to the page, which picks it up:

"share_target": { "action": "/share-target", "method": "POST",
  "enctype": "multipart/form-data",
  "params": { "files": [{ "name": "audio", "accept": ["audio/*", ".opus", ".ogg"] }] } }

How accurate is it?

I ran the first 30 clips of the FLEURS Urdu test set (28 downloaded) through the live API, encoded as Opus like a WhatsApp note:

Condition	Word error rate	Character error rate
Clean	20.8%	8.5%
White noise at 15 dB SNR	23.0%	9.3%

That counts spelling variants and "70" against "ستر" as errors, so the text reads better than one wrong word in five suggests. Real voice notes are harder than read sentences.

The failure I worry about most: in a noisy test, "jald rihaa" (released quickly) was heard as "jal raha" (burning), and every model I tried, including the 70B and 120B ones, then translated the sentence as hostages being set on fire. A recognition slip becomes an alarming English sentence. The prompt now tells the model not to invent dramatic meanings, but the honest fix is in the interface: every result says it is a machine transcript and to check money, medicine, addresses and times against the audio. The method and examples are on the accuracy page.

Try it

sunlo.appin60.com is free, needs no account, and handles notes up to 10 minutes. If you speak Urdu, I would like to hear where it goes wrong: sunlo@appin60.com.

The 201st unit: modelling Pakistan's 2026 electricity slab tariff from a scanned SRO

Low Key Builds — Tue, 20 Oct 2026 17:43:19 +0000

Pakistan's household electricity tariff has a cliff in it. If a home stays at 200 units (kWh) or less in each of the last six months, it is billed as protected. Use 201 units once and the home is non-protected for the next six bills, even if usage drops again.

I wanted to know what that one unit actually costs, so I modelled the tariff from the government notification and built a free calculator in Urdu around it. Disclosure: I built the tool linked at the end. This post is about the modelling, which was more interesting than I expected.

1. Find the real source, even when it is a scan

Search results for "LESCO bill calculator" are full of calculators that disagree. I found per-unit rates of 10.54, 13.99, 7.74 and 10.06 quoted for the same "protected 101-200" band, plus tools still adding a 1.5% electricity duty and a Rs 35 TV fee that were dropped from bills in July 2025, or using 17% GST.

The binding document is S.R.O. 279(I)/2026 (Ministry of Energy, 12 February 2026), which notifies NEPRA's decision on "rationalization of tariff of XWDISCOs and K-Electric". NEPRA hosts it as a 54-page scanned PDF with no text layer, on a server slow enough that I had to resume the download several times:

curl -sL -C - -o sro279.pdf "https://nepra.org.pk/tariff/Tariff/Notifications/2026/02%20Feb/S.R.O.%20279(1)2026%20dated%2012-02-2026.pdf"
pdftoppm -r 60 -png sro279.pdf t   # thumbnails, to find the tables
pdftoppm -r 200 -png -f 15 -l 15 sro279.pdf z   # Annex A-1 at reading resolution

Contact sheets of the thumbnails found the residential schedule (Annex A-1) and the K-Electric schedule (Annex C) quickly. Both carry the same consumer-end rates, so one table serves all eleven distribution companies plus K-Electric.

2. The table

Slab (units/month)	Rs/kWh	Fixed Rs/kW/month
Lifeline up to 50	3.95	0
Lifeline 51-100	7.74	0
Protected 1-100	10.54	200
Protected 101-200	13.01	300
1-100	22.44	275
101-200	28.91	300
201-300	33.10	350
301-400	36.46	400
401-500	38.95	500
501-600 / 601-700 / 700+	40.22 / 41.85 / 47.20	675

New in 2026: a fixed charge per kW of sanctioned load, by slab.

3. The rules hide in the footnotes

Three lines under Annex A-1 decide the arithmetic:

"Only protected residential consumers will be given the benefit of one previous slab." 150 protected units = 100 x 10.54 + 50 x 13.01.
Lifeline consumers get no slab benefit.
Everyone else pays the rate of the slab their total lands in, on every unit. 201 units = 201 x 33.10.

function bill(units, status, kw) {
  if (status === "protected" && units > 200) status = "unprotected";
  if (status === "protected") {
    return units <= 100
      ? { energy: units * 10.54, fixed: 200 * kw }
      : { energy: 1054 + (units - 100) * 13.01, fixed: 300 * kw };
  }
  const slabs = [[100, 22.44, 275], [200, 28.91, 300], [300, 33.10, 350], [400, 36.46, 400],
                 [500, 38.95, 500], [600, 40.22, 675], [700, 41.85, 675], [Infinity, 47.20, 675]];
  const [, rate, fixed] = slabs.find(([top]) => units <= top);
  return { energy: units * rate, fixed: fixed * kw };
}

4. What the 201st unit costs

At 1 kW sanctioned load, adding the FC surcharge (Rs 3.23/unit, Rs 1.43 for protected users, per NEPRA's 2023 decision) and 18% GST, but not the monthly fuel adjustment:

200 units, protected: about Rs 3,470
201 units, non-protected: about Rs 9,030

The six-month rule makes it worse. If the next five months sit at 180 units, each is billed at the non-protected rate (about Rs 7,181 instead of Rs 3,130). The single extra unit costs roughly Rs 25,800 across six bills.

The six-month window is a sliding check over bill history, which turns into a one-liner: if the most recent month above 200 sits at index i (0 = oldest of six), the household gets i + 1 more non-protected bills, counting the current one.

5. Calibrate against a real bill

My first estimate came out about 10% low. An open-source LESCO estimator on GitHub that its author tuned to their own real bills includes the FC surcharge line, which the SRO does not mention because it was notified separately in 2023. Adding it brought my 153-unit example within a few percent of their recorded bill; the remaining gap is the monthly fuel price adjustment.

The tool and the data

BijliHisab (free, unofficial, in Urdu): https://bijlihisab.appin60.com. Enter today's meter reading and the reading date from your bill; it tells you how many of your 200 units are left, the daily budget to stay under, and the date you will cross 200 at your current pace. It also writes a printable Urdu application to the SDO for a wrong or late reading. Everything runs in the browser and nothing is collected.
The tariff as JSON (CC0, with the billing rules): https://github.com/lowkey-studio/pakistan-electricity-tariff

If you spot a rate that differs from your bill, open an issue with the bill line (no reference numbers, please) and the source.

Printing Urdu worksheets in Nastaliq from the browser: joined letter forms with ZWJ and print-to-PDF

Low Key Builds — Tue, 20 Oct 2026 17:33:51 +0000

Urdu letters change shape when they join. ب on its own, at the start of a word, in the middle and at the end are four different shapes, and a child who only practises the first one cannot read بلی (cat). Most free Urdu worksheets online are the same few scanned PDFs mirrored on spam pages, and almost none show the joined forms.

I built Takhti, a free worksheet maker that prints them correctly, with the child's name on the sheet. Everything runs in the browser. Here are the three tricks that made it work without a server or a PDF library.

1. Ask the font for a joined form with ZWJ

You do not need a table of presentation-form code points. Put a ZERO WIDTH JOINER (U+200D) on the side where the letter should connect, and the shaping engine (HarfBuzz in Chrome, CoreText in Safari) picks the right glyph:

const ZWJ = "‍";
function forms(letter, joins) {
  if (joins === "both") return [letter, letter + ZWJ, ZWJ + letter + ZWJ, ZWJ + letter]; // alone, start, middle, end
  if (joins === "right") return [letter, ZWJ + letter];  // ا د ڈ ذ ر ڑ ز ژ و ے: two shapes only
  return [letter];                                       // ء never joins
}

The ten right-joining letters are the part teachers notice when a sheet gets them wrong: ر has no "start" or "middle" form, so a sheet that shows four shapes for it is teaching a mistake.

The same trick builds a "missing first letter" exercise. Remove the first letter of پتنگ and you get تنگ, which renders with ت in its initial form. Prefix the rest with ZWJ and ت shows its middle form, the way it looks inside the real word. If the removed letter is one of the right-joiners (ریل without ر), skip the ZWJ, because the next letter really does start fresh.

2. Nastaliq needs room, and a real font

Noto Nastaliq Urdu is SIL OFL, so it can be self-hosted. The variable TTF from google/fonts converts to a 260 KB WOFF2 with fontTools. Two things to know:

Nastaliq has tall ascenders and deep descenders. A line height under about 1.8 clips dots and the tails of ے and ی.
The glyphs are small for their em size compared with Latin text, so Urdu needs a bigger font size next to English to look balanced.

I also offer Noto Naskh Arabic as an option, since many teachers start small children on the simpler Naskh shapes.

3. Print to PDF is the PDF engine

Most client-side PDF libraries draw text glyph by glyph and do not run the shaping engine, so Nastaliq comes out as disconnected letters. The browser's own print path does shape it, and on Android and desktop Chrome "Save as PDF" is in the print dialog. So each sheet is a fixed-size element:

.sheet { width: 210mm; height: 297mm; padding: 11mm 12mm 9mm; box-sizing: border-box; overflow: hidden; }
.letter .sheet { width: 215.9mm; height: 279.4mm; }   /* US Letter for families abroad */
@media print {
  body > :not(#print-root) { display: none !important; }
  .sheet { break-after: page; }
}

On print, the script copies the sheets into #print-root, injects @page { size: A4; margin: 0 } (or letter), waits for document.fonts.ready, then calls window.print(). Headless Chrome's --print-to-pdf gives the same output, which made it easy to test every sheet type: the fonts embed as Type 3 glyphs with the joins intact.

For the on-screen preview on a 390 px phone, the same A4 element is scaled with CSS zoom set to the container width divided by 794 (A4 width in CSS pixels), so what you see is exactly what prints.

What it makes

Letter tracing in all joined forms, the whole alphabet, the child's own name (common names are converted from Roman spelling, and there is a tap keyboard for the rest), letter and picture matching, missing letter, joining letters into words, ginti 1 to 10, opposites, wahid jama and muzakkar muannas, and short graded stories with a Roman Urdu and an English line under each Urdu line for parents abroad who do not read the script.

Every sheet carries the site address in its footer, since worksheets get photocopied and passed around classes. It is free, with no signup: https://takhti.appin60.com

If you teach Urdu, or have children learning it, I would like to hear which sheet is missing: takhti@appin60.com.

A .docx file in 60 lines of browser JavaScript, and other lessons from a Nikah Nama translation tool

Low Key Builds — Tue, 20 Oct 2026 17:11:34 +0000

Disclosure: I built the tool this post is about, NikahDraft. It has a free preview and a $9 unlock.

Pakistani couples applying for US, UK or Canadian spouse visas need an English translation of their Nikah Nama, the marriage contract. It is a printed Urdu form with 25 numbered columns, filled in by hand. People search for "nikah nama in english word format" because they want something they can fill in themselves and open in Word.

The documents are personal: names, parents, addresses, dower amounts. So the constraint I set was that nothing typed into the tool leaves the browser. That ruled out the easy routes (server-side PDF rendering, a docx library on a backend) and led to a few small techniques worth sharing.

1. A valid .docx needs three files and a zip writer with no compression

A .docx is a zip with XML inside. Word opens a package with only:

[Content_Types].xml
_rels/.rels
word/document.xml

Zip's "stored" method (no compression) is simple to write by hand: a local header per file, the bytes, a central directory and an end record. The only real work is CRC-32:

const CRC = Array.from({ length: 256 }, (_, n) => {
  let c = n;
  for (let k = 0; k < 8; k++) c = c & 1 ? 0xEDB88320 ^ (c >>> 1) : c >>> 1;
  return c >>> 0;
});
const crc32 = (b) => {
  let c = 0xFFFFFFFF;
  for (const x of b) c = CRC[(c ^ x) & 255] ^ (c >>> 8);
  return (c ^ 0xFFFFFFFF) >>> 0;
};

Then each file is a 30-byte local header (signature PK\x03\x04, version 20, method 0, the CRC, sizes, name length), the name, and the body; the central directory repeats that with an offset; the end-of-central-directory record closes it. With a Blob of those Uint8Array chunks you have a download. I check the output with python-docx in a test: it opens, and the table has 26 rows (header plus 25 columns).

In document.xml, a three-column bordered table is a w:tbl with w:tblBorders and fixed w:gridCol widths in twentieths of a point. Line breaks inside a cell are w:br elements between runs, not \n.

2. Watermarks that survive "Save as PDF"

The free tier prints with a "DRAFT PREVIEW" watermark. A CSS background image does not work: Chrome drops backgrounds when printing unless the user ticks "Background graphics". What does work is a real element, position: fixed inside @media print, which Chrome repeats on every printed page:

@media print {
  .wm { position: fixed; inset: 0; }
  .wm span { transform: rotate(-28deg); color: rgb(155 63 102 / .16); }
}

3. Nastaliq needs room

Urdu headings help users match columns on their paper form, and they have to be in Nastaliq, the script style Urdu readers expect, not the Naskh-style Arabic fallback a system font gives you. Noto Nastaliq Urdu (SIL OFL) is about 690 KB as TTF and 268 KB as WOFF2 after fontTools conversion. Two things bit me:

Nastaliq's descenders are deep and its stacking is tall: line-height under about 2 clips glyphs. I use 2.3 for body text.
A heading font set on h1 by the design system overrides inheritance from <html lang="ur">, so the Urdu page title fell back to a system Arabic font until I added an explicit html[lang="ur"] h1 rule.

4. Amounts in words, the Pakistani way

Pakistani documents group digits in lakhs (5,00,000) and write "Rupees five hundred thousand only". A small words() function plus a regex does the grouping:

const lakh = (n) => {
  const s = String(Math.floor(n));
  if (s.length <= 3) return s;
  return s.slice(0, -3).replace(/\B(?=(\d{2})+(?!\d))/g, ",") + "," + s.slice(-3);
};

Gold dower is in tola, so the tool adds grams (1 tola = 11.6638 g).

5. A paid unlock without accounts

The paid step is a one-time card payment through Whop. After checkout Whop redirects to /unlock/?payment_id=.... A Cloudflare Pages worker looks the payment up with the Whop API, checks it is paid, for this product and not refunded, and returns payment_id + "." + HMAC(secret, payment_id). The browser stores that token; on load it asks the worker to verify it again, so a refund removes the unlock. The worker never sees the form contents, only the payment id.

What it does not do

It does not read the handwriting. A person who reads Urdu types each entry, and the tool does the layout, the printed column text in English, the translator's notes for struck-out columns, and the translator's statement worded to the USCIS rule (8 CFR 103.2(b)(3)). It is not a certified translation, and for UK and Canadian files a professional translator still signs.

If you work on tools for languages other than English, I would like to hear what broke for you in print and PDF.

Confirming cash-on-delivery orders on WhatsApp without the API, in the browser

Low Key Builds — Tue, 20 Oct 2026 16:32:15 +0000

Most online orders in Pakistan are cash on delivery. Sellers who run ads get a steady stream of fake or careless orders, and every refused parcel costs two-way courier charges. So most small stores do one manual step before booking the courier: they message each customer on WhatsApp and ask them to confirm.

The paid fix is a Shopify app on the WhatsApp Business API (there are several, from about $3 to $10 a month plus Meta's per-message fees). I wanted to see how far a free, static, browser-only tool could go for the sellers who do not have Shopify or do not want the API: WooCommerce stores, and Instagram and Facebook sellers who keep orders in a Google Sheet.

The result is ConfirmKaro, which I built. Here is what was interesting to build.

1. `wa.me` links do the sending

WhatsApp has a public click-to-chat URL: https://wa.me/<number>?text=<urlencoded message>. On a phone it opens the chat in the WhatsApp app with the message typed; on desktop it opens WhatsApp Web. The seller presses send. No API, no number registration, no template approval, and the message comes from the shop's normal WhatsApp, which customers already recognise.

The cost is one tap per order, which is fine up to a few dozen orders a day.

2. Pakistani phone numbers in the wild

wa.me wants the international format with no +, no spaces and no leading zero: 923001234567. Order exports contain everything else:

0300 1234567      -> 923001234567
+92 321 7654321   -> 923217654321
0333-5556667      -> 923335556667
3001234567        -> 923001234567   (leading zero lost by Excel)
00923001234567    -> 923001234567
03451234          -> invalid (too short)

function normPhone(raw) {
  const s = String(raw || '').trim();
  const plus = s.startsWith('+');
  let d = s.replace(/\D/g, '');
  if (d.startsWith('0092')) d = d.slice(2);
  if (d.length === 11 && d.startsWith('03')) d = '92' + d.slice(1);
  else if (d.length === 10 && d.startsWith('3')) d = '92' + d;
  if (d.length === 12 && d.startsWith('923')) return { ok: true, wa: d, pk: true };
  if (plus && d.length >= 10 && d.length <= 15) return { ok: true, wa: d, pk: false };
  return { ok: false, wa: d };
}

The Excel case matters more than it looks: when a sheet stores the number as a number, the leading zero disappears, so a 10-digit value starting with 3 is almost certainly a Pakistani mobile.

3. Shopify exports one row per line item

Shopify's orders CSV repeats the order Name (#1041) on one row per item, and only the first row has the total and shipping details. Merging by order number and appending item rows gives one message per order. WooCommerce export plugins use different headers (Billing Phone, Order Total Amount), so columns are matched by a ranked list of header tests, and the user can override any column.

4. Fake-order flags without any server

All local heuristics: invalid number, the same number on several orders in the batch, an address under 12 characters ("abc"), a name with digits or fewer than three letters, and a total over four times the batch median. None of these prove fraud; they decide who gets confirmed most carefully.

5. Urdu in Nastaliq, and Roman Urdu

Most sellers write to customers in Roman Urdu ("Order confirm karne ke liye 1 likh kar bhejein"), some in Urdu script, some in English. The templates come in all three. The page self-hosts Noto Nastaliq Urdu (SIL OFL) as a 160 KB woff2 converted with fontTools, sets lang="ur" dir="rtl", and needs a line height above 2 because Nastaliq stacks vertically. WhatsApp renders the Urdu text itself with the phone's font, so the font only matters on the page.

6. Nothing leaves the browser

The CSV is read with FileReader, statuses (pending, confirmed, no reply, cancelled) live in localStorage, and the confirmed orders download as a CSV for courier bulk booking. Customer names and phone numbers never touch a server, which is the main reason a seller can trust a tool from someone they do not know.

What I would like to know

If you build stores for Pakistani (or Indian, Bangladeshi, Egyptian, Moroccan) COD sellers: how do your clients confirm orders today, and what format does their courier's bulk booking want? Replies at confirmkaro@appin60.com or in the comments shape what gets added next.

Disclosure: I built ConfirmKaro. It is free and has no paid tier.

I measured the 402 header of every x402 seller in the Coinbase Bazaar. 156 can't be read by aiohttp, 4 break Node

Low Key Builds — Wed, 14 Oct 2026 09:52:18 +0000

Your x402 endpoint can be listed, indexed and priced correctly, and still be impossible to pay from half the agent stack. On 2026-10-14 I sent unpaid requests to every origin in the Coinbase CDP Bazaar and measured one thing most sellers never look at: the size of the PAYMENT-REQUIRED header.

The short version

2,332 origins in the Bazaar (34,705 resources). 2,127 answered a probe with HTTP 402.
156 of those 402s carry a PAYMENT-REQUIRED header longer than 8,190 bytes. Python's aiohttp rejects any header line that long by default, so an aiohttp-based agent gets ClientResponseError: 400, message='Got more than 8190 bytes when reading' and never sees your price.
4 send more than 16 KB of headers. Node's built-in fetch (undici), and therefore @x402/fetch, fails with UND_ERR_HEADERS_OVERFLOW. The largest was 55 KB.
55 more sit between 12 KB and 16 KB, one bigger example away from the Node limit.
requests and httpx (the official Python SDK's client) read 32 KB headers without complaint, which is why sellers testing with curl or Python never notice.

Per-origin data and the method are public: x402doctor-data/HEADER-SIZES.md.

Why the header gets so big

In x402 v2 the whole PaymentRequired object travels base64-encoded in one header. That includes the Bazaar discovery extension: your input example, your output example, and the JSON schema. Sellers reasonably paste a full, realistic response as the output example. On the 55 KB endpoint, the output example alone was 29 KB (a complete vulnerability report) and the schema another 12 KB, while accepts was 1.2 KB.

The other common cause is accepts itself. One operator offers 14 payment options per route (several networks and stablecoins); that alone is about 4 KB of JSON before base64.

Base64 adds a third on top of the JSON, so a 6 KB challenge is already an 8 KB header.

Check yours

curl -s -D - -o /dev/null https://your-api.example.com/paid-route | grep -i '^payment-required' | wc -c

Over 8,190: aiohttp users can't read it. Over about 16,000 (all headers together): Node users can't either.

Or run the free origin audit I built, which reads your OpenAPI like the indexers do, probes each paid route with your own examples, reports header size, and lists which routes the CDP Bazaar has actually indexed for your payTo: pitcrew-api.appin60.com/app#audit.

Fixing it

Make the output example one representative item, not a full response. The schema already documents the shape.
Trim schema description strings in the discovery extension; keep the long prose in your OpenAPI.
Only list accepts entries you actually settle. Every extra network/asset pair costs about 300 bytes.
Aim for under 8 KB. That keeps every common client happy.

I also opened an issue proposing a size budget and a middleware warning upstream: x402-foundation/x402#3803.

Method and caveats

Unpaid GET/POST probes only, up to two resources per origin, using the Bazaar's stored example input (query, path and body). Header bytes are measured on the raw response. Results are a snapshot: sellers change their metadata often, and an origin I could not reach (DNS failure or timeout) is not counted either way. aiohttp and Node limits are defaults; clients can raise them, but most agents don't.

Disclosure: I build Pitcrew, a pay-per-call toolkit for agents and x402 sellers. The audit above is free in the browser and $0.02 per call over x402.

I re-checked 516 startup launch directories from 11 GitHub lists: 66 are dead or moved, and "free" often isn't

Low Key Builds — Wed, 14 Oct 2026 09:49:02 +0000

I wanted a clean list of places to launch a small SaaS, so I merged 11 popular "launch directories" lists from GitHub (516 unique domains) and checked every one on 14 October 2026. Then I read the submit pages of about 250 of them by hand, starting with the most-listed and most-visited.

Short version: the lists are older than they look, and "free" usually has a catch.

What the check found

Out of 516 domains:

436 respond. 46 of those sit behind bot walls, so they are probably fine in a normal browser.
30 are dead: the domain no longer resolves, is parked or for sale, or now shows something else entirely. One former directory is now a slot-gambling shop, one shows a crypto-wallet download page, and another, still in two lists, is an Indonesian "link alternatif" page.
19 are unreachable or erroring (timeouts, TLS errors, Cloudflare 52x).
17 redirect to a different site. Some are renames (betapage.co now lands on pitchwall.co, angel.co on wellfound.com), some are not.

A lot of the dead ones are still in several lists at once. theresanai.com, demos.co and launched.io are each in three lists and none of them resolves.

DNS failures were re-checked through Cloudflare DNS-over-HTTPS before I called anything dead, because my first pass used a flaky local resolver and wrongly marked about 120 live sites as dead. If you script this yourself, use a second resolver.

What "free" means

For 173 reviewed directories where the submit page gave a clear answer:

113 have a free listing with no strings I could find.
18 are free only if you add their badge or link to your site. Examples from the pages: "A backlink to our site is required (on your homepage or footer)", "Free submissions use backlink verification", "Badge must stay on your site permanently".
13 are free only after a queue: "Minimum 30-day waiting period", "Enter the queue (30-90 day listing time)", "Free Launch has 70 weekly slots", and my favourite, "Free slots are fully booked into 2027".
29 are paid only, from $3 to $249 (mostly one-time, a few monthly).

The badge ones add up. If you accept every badge offer you end up with a footer full of other people's logos, so it is worth deciding once whether you will do that before you start.

How I'd use this

Start with directories that are live, take a plain free listing, need no account, and have real traffic. I used the Tranco top-1M list as a popularity signal; most of these directories are not in it at all, which tells you something too.
Then do the ones that need an account but match your category (AI tools, dev tools, SaaS, open source, Mac apps all have their own).
Decide on badges once.
Submit to queue directories on day one and forget about them.
Pay only where the audience matches your buyers. Most paid tiers sell a dofollow link and a faster review, not customers.
Delete the dead ones from whatever list you are using.

The data

There is also a free checker on the page: paste your own list of directory URLs and it tells you which ones are dead or moved.

The full list of 66 dead, down and moved directories, and a sample of 12 popular ones with a plain free listing, are free here: https://submitcheck.appin60.com

Disclosure: I built that page. The complete sheet (all 516 rows with submit URL, free / badge / queue / paid, lowest price seen, account needed, captcha on the form, popularity rank and check date) is $12 there. The method and the source lists (CC0, MIT and CC BY data) are on the page.

If you maintain one of these lists and want the dead entries for it, comment here and I'll send them.

I sent an empty-wallet payment to 4,256 x402 routes. 38 sellers told me their facilitator was down.

Low Key Builds — Wed, 14 Oct 2026 09:38:29 +0000

Answering HTTP 402 is not the same as being payable. On 2026-10-14 I took every Base seller in the Coinbase CDP Bazaar with at least two distinct payers in the last 30 days and sent each of their routes one payment that cannot succeed: an EIP-3009 authorization signed by a brand-new wallet holding zero USDC, through the reference @x402/fetch client. No money can move. A healthy route rejects it for balance and says so. Anything else tells you how that seller treats every buyer whose payment fails.

Disclosure: I built the checker used here (ContractLens). The free single-URL check is linked at the end; it has paid options too.

The sample

CDP Bazaar crawl: 34,672 listed resources from 2,332 origins.
Probed: 4,256 routes from 1,735 origins (up to 5 routes for the 442 origins with 5+ payers and 2+ routes, up to 3 for the rest). GET routes got the listing's example query, POST routes the listing's example body.

Result	Routes	Origins
Payable (rejected only for balance)	2,262	935
Rejected with an opaque reason ("payment_required", "invalid_payload", empty)	916	370
Connection failed during the run (see correction below)	455	181
Other non-balance rejection (mostly input validation)	306	165
HTTP 5xx when the payment fails	91	41
Rejected payment reported as a facilitator outage	77	38
Listed route answers 404, or 5xx before quoting a price	32	20
Description over ~500 characters	16	10
Price above the $1 default client spend cap	17	14
Served the paid response anyway	5	3

Correction (2026-10-14, 10:55 UTC): the 455 "connection failed" routes are mostly not seller outages. I re-checked their 181 hosts about 90 minutes later through public DNS resolvers (1.1.1.1, 8.8.8.8): 133 responded normally, so most failures were transient or my own resolver failing under parallel load. 44 hosts fail DNS at public resolvers (SERVFAIL), which does mean their Bazaar listings point at dead names. The other rows come from responses the sellers actually sent and are unaffected.

Opaque rejections are not defects by themselves: an empty wallet and a broken payment path look identical from outside, so I don't count them as broken. The bold rows are the ones that are wrong regardless of who is paying.

1. "Facilitator unavailable" when the buyer is simply broke (38 origins)

This was the surprise. When the CDP facilitator rejects a payment, /verify answers HTTP 400 with a body like {"isValid": false, "invalidReason": "..."}. The reference SDK handles that: HTTPFacilitatorClient.verify in @x402/core throws a VerifyError carrying the reason, and the middleware returns 402 with it. My own routes answer the empty-wallet test with 402 invalid_payload: ... execution reverted.

Hand-rolled integrations often do this instead:

const r = await fetch(`${FACILITATOR}/verify`, { method: "POST", headers, body });
if (!r.ok) return res.status(503).json({ error: "facilitator unavailable" }); // wrong for 400

So 38 sellers answer a rejected payment with 502/503 "verification temporarily unavailable", "payments_unavailable", "broker_unavailable", "retry in 60 seconds" and similar. Two of them literally put cdp_verify_http_400 and facilitator_status_400 in the message. Funded buyers are fine. Everyone else (low balance, expired authorization, reused nonce, wrong amount) is told to retry later, and agent SDKs do retry 5xx responses. The fix:

const r = await fetch(`${FACILITATOR}/verify`, { method: "POST", headers, body });
const data = await r.json().catch(() => null);
if (data && "isValid" in data && !data.isValid)
  return res.status(402).json({ x402Version: 2, error: data.invalidReason, accepts });
if (!r.ok) return res.status(502).json({ error: "facilitator_error" }); // real outage only

2. HTTP 500 on a failed payment (41 origins)

Same symptom, cruder cause: the verify failure throws and lands in a generic error handler, sometimes rendering an HTML error page. In an earlier run of this test, one seller with 41 buyers fixed this across a whole fleet of subdomains within hours of hearing about it, which suggests it is usually an oversight rather than a design choice.

3. Listings that cannot be called (20 origins)

Twelve origins have Bazaar listings whose listed URL answers 404. In the ones I checked by hand, the URL contained the route template, like /v1/:chainId/quote or /stock/:symbol, or an example id that does not exist. Agents that pick these from the Bazaar get 404 before they ever see a price, while the listing still shows payers from earlier. Declare a concrete, working example URL, or describe path parameters in the Bazaar input schema.

Related: one seller's Bazaar example query used the parameter descriptions as values (?limit=How many articles to return.), which returns 400.

4. Descriptions over ~500 characters (10 origins)

The CDP facilitator rejects payment payloads whose resource.description is longer than about 500 characters (paymentPayload is invalid), before balance is checked. It is tracked upstream (x402#2284, #2993). The clearest case: one origin's routes with 156-character descriptions behaved normally while its 731-character route returned "facilitator rejected (400)". Keep the long text in the Bazaar extension or your docs.

5. Served without payment (3 origins)

Three origins returned a paid result or accepted a paid job (HTTP 200 or 202) for the zero-balance signature; two of them did so in two separate runs. Either verification ran after the handler, or a failed settlement did not stop the response. One also called a paid upstream cloud API before verifying, so every unpaid attempt cost the seller money. I emailed the two with a public contact privately and am not naming any of them.

What I did with this

I re-verified each hard defect, then emailed or opened an issue with 19 sellers who had a public contact, one specific finding each, nothing else attached. In the previous round of this test, three sellers fixed what was reported (one opened an upstream PR, x402#3795, to surface rejection reasons).

Check your own routes

Free, one URL at a time (GET or POST): https://contractlens.appin60.com/x402-payability
Whole origin, every route we can find in your /.well-known/x402, /openapi.json and your own Bazaar entries, with a fix hint per route: $0.25 in USDC via x402 (GET https://contractlens-api.appin60.com/audit?origin=https://your-api) or with a browser wallet on the page above.
A $0.99 monitor re-checks one route hourly for 30 days and emails you when it changes.

Method caveats: one test payment per route, from one location, on one day. Opaque rejections are counted as unknown, not broken. Classifications and raw results are per route; the checker shows the exact response for any URL you give it.

I checked the email DNS of 68 Shopify stores: 63 send order emails without domain authentication

Low Key Builds — Wed, 14 Oct 2026 09:20:53 +0000

Most Shopify store reviews look at the storefront: photos, copy, speed, checkout. I wanted to look at the part customers only see in their inbox, so I checked the public DNS of every store that merchants shared in the Shopify Community Store Feedback board.

Disclosure: I built InboxPass, the free checker used here. Everything below is reproducible with dig.

Method

Pulled 180 recent Store Feedback topics through the forum's public Discourse JSON API and extracted the store links: 113 domains.
A domain counts as a Shopify store if its apex resolves to Shopify's 23.227.38.x range or www is a CNAME to *.myshopify.com: 92 stores.
I kept the stores that run email on their own domain (they have MX records): 68 stores.
For each one I queried SPF, DMARC and DKIM through Cloudflare's DNS-over-HTTPS resolver. (My local resolver was negatively caching and timing out, which produced false "missing" results, so every result below comes from DoH.)

How Shopify authenticates your sender domain

When you authenticate a sender domain under Settings > Notifications > Sender email, Shopify gives you CNAME records like these (you can see real ones posted in this community thread):

mailerXX.yourstore.com        CNAME  <id>.pXXX.email.myshopify.com
s1._domainkey.yourstore.com   CNAME  s1.domainkey.uNNNN.wlNNN.sendgrid.net
s2._domainkey.yourstore.com   CNAME  s2.domainkey.uNNNN.wlNNN.sendgrid.net

The mailer subdomain covers SPF and bounces. The s1/s2 CNAMEs carry the DKIM keys. Shopify's help page says that if the domain isn't authenticated, your sender address is rewritten to store+123@shopifyemail.com. It also says automatic setup doesn't add a DMARC record.

So one lookup tells you whether a store did it:

dig +short CNAME s1._domainkey.yourstore.com
# authenticated:      s1.domainkey.u27818954.wl205.sendgrid.net.
# not authenticated:  (nothing)

Results (68 Shopify stores with their own email domain)

Check	Stores failing
No Shopify DKIM CNAMEs (`s1._domainkey`)	63 of 68
No DMARC record at `_dmarc`	17 of 68
No SPF record	15 of 68
Two or more SPF records, or more than 10 SPF lookups	0 of 68

Only 5 of the 68 stores had authenticated their sender domain with Shopify.

Caveats

DNS can't show which sender address a merchant chose. If the sender is a Gmail address, Shopify can't authenticate it at all, and the fix is to use an address on your own domain.
DKIM selectors can't be listed from DNS. I only treat the specific Shopify s1 CNAME as evidence. Other senders, such as Google Workspace or Klaviyo, have their own selectors.
This is a small, self-selected sample: merchants who asked for feedback, mostly small and new stores.

The 10-minute fix

Settings > Notifications > Sender email > Authenticate, then copy every CNAME into your DNS host.
If dig +short TXT _dmarc.yourstore.com returns nothing, add a TXT record at _dmarc with the value v=DMARC1; p=none; rua=mailto:you@yourstore.com. Never add a second DMARC record.
If you send from Google Workspace or Microsoft 365 and have no SPF record, add one: v=spf1 include:_spf.google.com ~all (or include:spf.protection.outlook.com).

To check a domain in the browser, InboxPass runs these lookups client-side through DoH, with no signup. The engine is about 250 lines of JavaScript: it counts SPF lookups recursively (RFC 7208's limit of 10), parses DMARC, probes 35 common DKIM selectors, and guards against wildcard _domainkey records, because example.com answers every selector with an empty key.

Your Codex logs already contain your quota meter: how to check where your usage went

Low Key Builds — Wed, 14 Oct 2026 09:13:33 +0000

If you use Codex on a ChatGPT plan, you have probably watched the usage meter fall faster than you expected and wondered whether it was your work or the metering. The openai/codex issue tracker is full of these reports (#41220 collects dozens), and most of them compare percentages from screenshots, which cannot settle the question.

Your machine already logs everything needed to answer it with numbers.

What the rollout files contain

Codex writes one JSONL file per thread under ~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl (on Windows, %USERPROFILE%\.codex\sessions). After every model call it appends a token_count event shaped like this (trimmed):

{"type":"event_msg","payload":{"type":"token_count",
  "info":{"last_token_usage":{"input_tokens":152311,"cached_input_tokens":149760,
          "output_tokens":412,"reasoning_output_tokens":160,"total_tokens":152723}},
  "rate_limits":{"plan_type":"pro",
    "primary":{"used_percent":41.0,"window_minutes":300,"resets_at":1792171200},
    "secondary":{"used_percent":12.0,"window_minutes":10080,"resets_at":1792600000}}}}

So for every call you get the tokens it used and the server's view of your quota right after it.

One number that makes reports comparable

For each rate-limit window (same window_minutes and resets_at), take the quota points used (highest minus lowest used_percent you saw) and divide by the tokens logged in that window:

quota points per 1M tokens = points used ÷ (tokens ÷ 1,000,000)

Comparable work on the same plan and model should cost comparable points per million tokens. If that number jumps several times overnight, the metering changed, not your workload. If it stays flat but tokens per hour rose, the cause is on your side, and the logs show where.

Two refinements matter:

Cached input is most of your tokens. On one Pro Lite account I checked, 97% of 285M logged tokens were cached input, 2.6% uncached input and 0.4% output. So also compute points per 1M uncached input + output. A drop in cache hit rate can multiply cost without any change in tokens.
Steps with no local calls. If used_percent rises between two snapshots with no call logged on this machine in between, the quota went somewhere else: another device, a cloud task, or background features. That separates "this prompt cost 9%" from "something else ran at the same time".

On that same account, the weekly windows cost between 0.35 and 1.3 points per 1M tokens, and one step of +28% in a weekly window came after only 350k tokens, about 90 times the window's average rate. That kind of step is worth taking to Support, with its timestamp.

Where the tokens go

The same files show why token counts get so large:

Context replay. Every model call re-sends the whole conversation. A turn with 34 tool calls at a 450k context is about 15.9M input tokens, even if the tools returned little (a real case: #53855).
Big context, tiny answer. Calls with 100k+ context that produce under 300 output tokens: "check status", "run one command", paid at full-context price.
Polling. Calls that follow a sleep, a wait or an empty stdin write.
Re-sent tool output. A 60k-token command output stays in context and is re-sent on every later call until compaction; re-sent 100 times, it is 6M input tokens.

A script that does all of this

I packaged the above as a free, zero-dependency Node script (disclosure: I built it). It reads the logs locally, never uploads anything, and writes a Markdown report with counts only and hashed session ids, so you can attach it to an issue:

npx github:lowkey-studio/quotatrace --since 30d

It produces the per-window table (quota used, tokens, points per 1M), the quota steps out of line with their tokens, the replay, polling and re-sent output breakdown, and the heaviest sessions. It also covers Claude Code transcripts (cache writes, cache rebuilt after a pause, subagent share, most re-read tool results). Claude Code does not log a quota percentage, though, so that part is tokens only.

Source and method: github.com/lowkey-studio/quotatrace. --share turns your per-window aggregates into a prefilled GitHub issue. If enough people contribute, we can show per plan and model what a quota point buys and when that changed.

Caveats: only calls logged on the machine you run it on are counted, used_percent comes in whole points so short windows are noisy, and tool output sizes are estimated at four characters per token.

I decoded every failed transaction in 40 Ethereum blocks and 150 Base blocks. Here is why they fail.

Low Key Builds — Tue, 13 Oct 2026 09:42:39 +0000

"Transaction failed" on a block explorer tells you almost nothing. "Fail with error 'execution reverted'" tells you less. So I took every failed transaction from a recent run of blocks on Ethereum mainnet and on Base, replayed each one against the state of the previous block, decoded the revert data, and counted.

Disclosure: I built the decoder used here, Pitcrew. Its free web version is linked at the end. The sampling script and raw results are linked below, so you can rerun the numbers.

The sample

	Ethereum	Base
Blocks	26,182,107 to 26,182,146 (40)	52,543,866 to 52,544,015 (150)
Transactions	11,080	30,809
Failed	401 (3.6%)	2,745 (8.9%)

Method: for each failed receipt, fetch the transaction, eth_call it with the same from/to/data/value/gas against the parent block, then decode the revert data: Error(string), Panic(uint256), or a custom error selector looked up in the openchain signature database. Free public RPCs only.

Ethereum: why the 401 failed

Share	Count	Cause
50.1%	201	21,000-gas ETH send to an EIP-7702 account (all 0.0000001 ETH dust)
27.4%	110	state changed earlier in the same block (lost a race: MEV/arb/front-run)
8.7%	35	reverted with no reason
6.5%	26	slippage / price moved
2.5%	10	out of gas (gas limit too low)
2.0%	8	balance or allowance too low
1.7%	7	other require() message
1.0%	4	custom error (needs ABI/signature lookup)

Half of all failures were one pattern: 21,000 gas sent to EIP-7702 accounts

201 of the 401 failures were plain ETH sends (no calldata) with a gas limit of exactly 21,000, and every one used all of it. All 50 recipients had EIP-7702 delegation code (0xef0100...), pointing at, among others, MetaMask's delegator and Uniswap's Calibur account.

Since Pectra, an EOA can delegate to contract code. When you send it ETH, that code runs, so 21,000 gas is no longer enough. Anything that hard-codes 21,000 for "simple ETH transfers" (scripts, payout bots, older wallet code) will fail against these accounts every time, and retrying with the same limit changes nothing.

To be honest about this sample: every one of these 201 sends was 0.0000001 ETH from 52 addresses retrying 5 to 8 times in eight minutes. That looks like automated dusting, not people losing money. The failure mode is still real for any payout code that sends ETH with a fixed 21,000 gas. Fix: estimate gas for ETH sends, or detect 0xef0100 code on the recipient and raise the limit.

A quarter could not be reproduced: you lost a race

110 failures (27%) succeeded when replayed against the previous block's state. They failed because a transaction earlier in the same block changed something: a price, a reserve, a nonce. These are mostly arbitrage and MEV bots losing races, but if you see this on your own swap, someone else's transaction landed first.

The ones that hurt people: slippage, balance and allowance

Slippage guards (INSUFFICIENT_OUTPUT_AMOUNT, Too little received, Min return not reached): 26
ERC20: transfer amount exceeds balance, STF (Uniswap's "safeTransferFrom failed", usually a missing approval or balance): 8
Out of gas with a real call: 10

STF deserves a special mention because nobody knows what it means. It is Uniswap V3's TransferHelper saying transferFrom failed: the router could not pull your tokens. Check the allowance first, then the balance (and fee-on-transfer tokens).

Base: why the 2,745 failed

Share	Count	Cause
58.9%	1616	state changed earlier in the same block (lost a race: MEV/arb/front-run)
15.0%	413	custom error (needs ABI/signature lookup)
14.4%	394	other require() message
8.1%	221	reverted with no reason
2.8%	76	slippage / price moved
0.5%	15	balance or allowance too low
0.4%	10	out of gas (gas limit too low)

Base fails 2.5 times as often as Ethereum, and its failures are mostly bots. 59% are lost races: they succeed when replayed a block earlier, and 800 distinct senders produced 2,745 failures, with the top sender (0xc0ffeebabe...) alone accounting for 98. Gas on Base is cheap enough that bots fire speculative transactions and accept that most will fail.

The revert strings show it: the top messages after "no reason" are sl, SPL, SPL1, sbl1, :( and LEG_1_FAILED. Those are private bot contracts saving bytes, not anything a user would see.

Human-facing failures are a small share on Base: slippage guards (Min return not reached, TooMuchSlippage, QuoteBelowMin, OutputTooLow) 2.8%, balance and allowance (transferFrom reverted, STF) 0.5%. 15% end in a custom error, and many of those selectors are not in any public signature database, so an explorer shows only hex. If you are a person debugging your own failed Base transaction, the most likely causes are still slippage and allowance. Just don't expect the network-wide numbers to look like your experience.

Reproduce it

The script is about 80 lines of Node with no API keys: failed_txs.mjs. It runs eth_getBlockReceipts per block, then replays each failure at block - 1.

Decode your own

If you have a failed or stuck transaction, paste the hash into the free checker: https://pitcrew-api.appin60.com/app (Ethereum, Base, Arbitrum, Optimism, Polygon, BSC; 20 free checks a day). It returns the decoded revert reason, gas used vs limit, token transfers and a plain-language fix. Stuck transactions get the nonce-gap and replace/cancel recipe. If your agent needs it, the same call is pay-per-use over x402 at $0.01 (GET /tx/explain?chain=base&hash=0x..., USDC on Base or Arbitrum).

Caveat: replaying against the parent block is an approximation. When an earlier transaction in the same block changed the state, the replay succeeds and the tool says so instead of guessing.

How email verifiers work (SMTP RCPT in 60 lines of Node), and why they fail on 56% of startups

Low Key Builds — Tue, 13 Oct 2026 08:35:33 +0000

Email verification tools mostly do one thing under the hood: they open an SMTP connection to the domain's mail server and ask whether a mailbox exists, then hang up before sending anything. Here is how that works, in about 60 lines of Node, and what happened when I ran it against 499 Y Combinator companies.

Disclosure: I built MailFerret, a pay-per-call email finder for AI agents that uses this technique. The code below is the core idea, free to copy.

The SMTP conversation

Every domain that receives email publishes MX records. Connect to the first one on port 25 and you get a short dialogue:

S: 220 mx.google.com ESMTP
C: EHLO probe.example.com
S: 250-mx.google.com at your service
C: MAIL FROM:<verify@example.com>
S: 250 2.1.0 OK
C: RCPT TO:<paul@supabase.com>
S: 250 2.1.5 OK                      <- mailbox exists
C: RCPT TO:<qzxv81kd@supabase.com>
S: 550 5.1.1 The email account that you tried to reach does not exist
C: QUIT

250 on RCPT TO means "I'll accept mail for this address". 550 5.1.1 means "no such user". You never send DATA, so no email is delivered.

Minimal Node implementation

import net from "node:net";
import { promises as dns } from "node:dns";

async function rcptCheck(domain, addresses) {
  const mx = (await dns.resolveMx(domain)).sort((a, b) => a.priority - b.priority)[0].exchange;
  return new Promise((resolve) => {
    const sock = net.createConnection({ host: mx, port: 25 });
    const out = {}; let step = 0, i = 0, buf = "";
    const send = (l) => sock.write(l + "\r\n");
    sock.setTimeout(12000, () => sock.destroy());
    sock.on("close", () => resolve(out));
    sock.on("data", (d) => {
      buf += d;
      const last = buf.trimEnd().split("\r\n").pop();
      if (!/^\d{3} /.test(last)) return;          // wait for the final line of a multi-line reply
      const code = +last.slice(0, 3); buf = "";
      if (step === 0) { step = 1; return send("EHLO probe.example.com"); }
      if (step === 1) { step = 2; return send("MAIL FROM:<verify@example.com>"); }
      if (step === 2) { step = 3; return send(`RCPT TO:<${addresses[0]}>`); }
      if (step === 4) return;                     // reply to QUIT
      out[addresses[i]] = code;
      if (++i < addresses.length) return send(`RCPT TO:<${addresses[i]}>`);
      step = 4; send("QUIT");
    });
  });
}

// First address is random: if the server accepts it, the domain is catch-all.
console.log(await rcptCheck("resend.com", ["qzxv81kd3j@resend.com", "zeno.rocha@resend.com"]));
// { 'qzxv81kd3j@resend.com': 550, 'zeno.rocha@resend.com': 250 }

To find an address rather than check one, generate the usual patterns (first.last, first, flast, firstlast, f.last...) and RCPT them in order in one session. The first 250 on a domain that rejected the random address is your answer.

The catch: catch-all domains

Some domains accept mail for any address. Send RCPT TO:<anything@domain> and you get 250. On those domains SMTP verification can't tell real mailboxes from fake ones. That's why the snippet probes a random address first.

How common is that? I took 499 random active companies from the public yc-oss YC list and checked each website domain:

	Count	Share
Google Workspace	409	82%
Microsoft 365	23	5%
No MX on the website domain	43	9%
Catch-all (of 456 with mail)	254	56%
Verifiable (random address rejected)	177	39%
Refused to answer (Proofpoint, Cloudflare routing, SES inbound...)	25	5%

On Google Workspace alone, 60% of these startups had catch-all routing on. So for founders' addresses, more than half the "valid" results you get from any SMTP-based verifier are really "unknown". Full numbers and method: mailferret.appin60.com/study.

Things that bite in production

Port 25 is blocked on most cloud hosts (AWS, GCP, Azure, Vercel, Workers). You need a box where outbound 25 is open.
IP reputation matters. Cloudflare Email Routing answered our residential IP with 550 in the banner; Proofpoint and some others just time out. Treat those as "unknown", not "invalid".
Greylisting returns 4xx the first time. Retry later or report unknown. One useful exception: Google's 450 4.2.1 The user you are trying to contact is receiving mail at a rate... is only sent for mailboxes that exist.
Don't hammer one server. Batch all candidates into one session and cache catch-all results per domain.
Large TXT records (SPF/DMARC) can time out through some local stub resolvers; querying 1.1.1.1 / 8.8.8.8 directly fixed it for me.
Policy rejections aren't "user unknown". Parse the text: 5.1.1 / "does not exist" means no mailbox; "blocked", "Spamhaus", "policy" means they refused you.

If you'd rather not run it yourself

MailFerret wraps this as an HTTP API that AI agents pay per call with x402 (USDC on Base, no API key):

POST /find {first_name, last_name, domain}: $0.01, charged only when the mail server confirms the mailbox. Catch-all and not-found results are free.
POST /verify {email}: $0.003.
POST /domain {domain}: $0.005 for mail provider, catch-all status, SaaS tools revealed by SPF, DMARC, public emails and the likely pattern.

From Claude Code or Codex with AgentCash: npx agentcash fetch https://mailferret.appin60.com/find -m POST -b '{"first_name":"Zeno","last_name":"Rocha","domain":"resend.com"}'. There are 5 free lookups a day on the homepage.

Cleaning a whole list instead? The homepage has a bulk CSV option: $4 per 1,000 addresses in USDC, quoted before you pay.

Use it for legitimate B2B outreach, and follow CAN-SPAM/GDPR when you email anyone.

DEV Community: Low Key Builds

Urdu voice notes to text on a free tier: Whisper pinned to Urdu, Roman Urdu without drift, and an honest error rate

1. Whisper on Workers AI, language pinned to Urdu

2. A hard daily cap, enforced before the model runs

3. Roman Urdu: transliterate, do not translate

4. Long recordings: cut at silence, in the browser

5. Share target: one tap from WhatsApp

How accurate is it?

Try it

The 201st unit: modelling Pakistan's 2026 electricity slab tariff from a scanned SRO

1. Find the real source, even when it is a scan

2. The table

3. The rules hide in the footnotes

4. What the 201st unit costs

5. Calibrate against a real bill

The tool and the data

Printing Urdu worksheets in Nastaliq from the browser: joined letter forms with ZWJ and print-to-PDF

1. Ask the font for a joined form with ZWJ

2. Nastaliq needs room, and a real font

3. Print to PDF is the PDF engine

What it makes

A .docx file in 60 lines of browser JavaScript, and other lessons from a Nikah Nama translation tool

1. A valid .docx needs three files and a zip writer with no compression

2. Watermarks that survive "Save as PDF"

3. Nastaliq needs room

4. Amounts in words, the Pakistani way

5. A paid unlock without accounts

What it does not do

Confirming cash-on-delivery orders on WhatsApp without the API, in the browser

1. wa.me links do the sending

2. Pakistani phone numbers in the wild

3. Shopify exports one row per line item

4. Fake-order flags without any server

5. Urdu in Nastaliq, and Roman Urdu

6. Nothing leaves the browser

What I would like to know

I measured the 402 header of every x402 seller in the Coinbase Bazaar. 156 can't be read by aiohttp, 4 break Node

The short version

Why the header gets so big

Check yours

Fixing it

Method and caveats

I re-checked 516 startup launch directories from 11 GitHub lists: 66 are dead or moved, and "free" often isn't

What the check found

What "free" means

How I'd use this

The data

I sent an empty-wallet payment to 4,256 x402 routes. 38 sellers told me their facilitator was down.

The sample

1. "Facilitator unavailable" when the buyer is simply broke (38 origins)

2. HTTP 500 on a failed payment (41 origins)

3. Listings that cannot be called (20 origins)

4. Descriptions over ~500 characters (10 origins)

5. Served without payment (3 origins)

What I did with this

Check your own routes

I checked the email DNS of 68 Shopify stores: 63 send order emails without domain authentication

Method

How Shopify authenticates your sender domain

Results (68 Shopify stores with their own email domain)

Caveats

The 10-minute fix

Your Codex logs already contain your quota meter: how to check where your usage went

What the rollout files contain

One number that makes reports comparable

Where the tokens go

A script that does all of this

I decoded every failed transaction in 40 Ethereum blocks and 150 Base blocks. Here is why they fail.

The sample

Ethereum: why the 401 failed

Half of all failures were one pattern: 21,000 gas sent to EIP-7702 accounts

A quarter could not be reproduced: you lost a race

The ones that hurt people: slippage, balance and allowance

Base: why the 2,745 failed

Reproduce it

Decode your own

How email verifiers work (SMTP RCPT in 60 lines of Node), and why they fail on 56% of startups

The SMTP conversation

Minimal Node implementation

The catch: catch-all domains

1. `wa.me` links do the sending